@bonemap Woland said you're the 3D expert but I’m open to anyone for advice!

Woland really kindly built me this patch. It’s for a greenscreen installation where you can add “stickers” of 3d animals with different backgrounds. I can’t seem to get the lighting right. I’m exporting different hedgehogs from blender with edits to its material but no matter what I do the light in the Isadora 3d player seems to blow it out or barely make it visible. I am ok with turning lighting off for the different animals but it would obviously be cooler to have a bit of overhead light.
I’m a little experienced with blender but never heard of a 3ds file before this. I have the blender addon meant for autodesk to just be able to export them if that helps. I’m not sure which end the issue is on.
Hedgehog 3ds file
@jfg said:
Where the gate input of the Gate Actor is set to initialize as off
I forgot to mention this in my last post. Thank you @jfg !
my proposition:

Where the gate input of the Gate Actor is set to initialize as off
Thanks, I was excited to hear about this actor, but then I saw this in it's help text:
"Take note that upon entering a scene, the current value of 'value in' will be sent to the 'out' output, and the 'trigger' output will fire. This ensures actors connected to this actor always have the correct value."
I tried it anyway, but to no avail.
@dillthekraut said:
My intuitive solution would be, to build a mechanism which catches the first user input update, after scene activation and only allows updates to the selector after this first one.But maybe there is some basic, more general solution to it I don't know and which you can tell me about?
I think you might want to add a 'Value Changed' actor into the mix.
@3perf
The ISO / ANSI standardizations are probably as well the reason, why you aren't getting the same numbers the manufactures propagate. As you are not using the distinctive measurement standards as they are defined. In the end, these numbers are only meant to have the possibility of a basic comparison between different devices, not exactly a quality aspect. It is kind like the PS/kw for cars.
Since the switch from conventional lights to laser and LED sources, some manufactures tend to push the power of their devices above the advertised Lumens, to compensate the loss of brightness (aging) over the much longer live expectancy (20 000 hours fixed light source vs. 2000 hours changeable conventional bulbs).
There is more to this nowadays!
A couple of years ago ANSI was the value, most projector manufacturer used to define their light output level. Only a couple others already used ISO. Both stand for different standardization organizations (one might know them for keyboard layout and especially ISO for many other standardizations). In the case of projections, they are two different definitions on how to measure and define the average light output on a specific surface. As a white light output might differ on a square screen (higher brightness on the center, dimmer to the edges), the ANSI and ISO standards define different key aspects to get the average lux values of a light source, based on the reflections of a square meter of screen. As these standards are different, they are not directly comparable!
Nowadays most professional manufactures moved to ISO standard which are more strict and therefore result in lower numbers compared to the ANSI Lumen levels of the same device! Therefore you need to double check, which numbers (ANSI or ISO) are used by the advertisement (specs) of the specific projectors! This sometimes is difficult to find. If there is no standard named at all (Or "standard Lumens"), mostly ISO is meant.
https://en.heimkinowelten.de/d...
Second this. I generally prefer properly wired connections, as wireless can never be as reliable. But there are scenarios.
We do that a lot at our theater in both directions, from wireless camera connections to free movable displays as a sink. Just now for a production we got a freely movable multi display platform, which gets its feed from two our Teradek bolt 4K lt 750. But it needs quite some experience and knowledge to navigate the caveats.
E.g. an issue to be aware of, can be the 5Ghz Wifi Networks in the same room. Especially if you go to have wireless (NDI) streams from a mobile device in the same frequency bands. As the Teradek doesn't recognize existing wifi networks, they just overpower them if on the same channel. This needs proper channel management, especially in Europe where most of the 5Ghz channels are DFS (radar saved) channels, leaving only two fixed channels for two wireless sets.
Therefore, if it doesn't need to be second hand for budged reasons, I very much recommend the 6Ghz versions.
For indoor usage, I can recommend the Mushroom Antennas as an upgrade. They are available for both Ghz variants and added connection stability for us big time. We don't have any experience with the internal antenna variant though.
Hello Izzadorians,
I do have an issue, which probably isn't unknown to many of you, since it is related to the user actor processing mode, which was introduced to Isadora 2, back in the days.
As I could not find an answer in the forum (I might not find an appropriate search term at last), I'll try it with a new thread.
Below you'll find a simplified user actor, which only is a part of a more complex one, just to represent the mechanics which results in the issue. The base Idea is an automatic source selection. When content like a movie, picture or live feed is selected, the selector should be set to the according player/source actor.
The issue here is, that every time the scene is activated, the first user input value triggers to update any connected actor, which in return sets the selector to input 1, despite any other setting done in that scene before.
Example:
Scene 1: choose a content ID at user input 2, which sets the selector in scene 1 to input 2
switch to scene 2
Scene 2: select live input, which sets the selector in scene 2 to input 3
switch back to scene 1
On scene activation, the user actor sets back the selector to input 1
Same goes for the selector in scene 2, etc. when activated.

My intuitive solution would be, to build a mechanism which catches the first user input update, after scene activation and only allows updates to the selector after this first one.
But maybe there is some basic, more general solution to it I don't know and which you can tell me about?
My second question is about this mechanism in general;
Why does always the first user input is the one winning this?
As the actor processing order is from top to bottom, shouldn't be the last user actor win this, as all these values will be updated one after another, having the fourth input giving his trigger at last, setting the selector to input 4?
Maybe someone can put light to this?
Thank you
