Multiple Geometry Using the same display

Woland

Or maybe you could do it automatically with choosing it in the projector actors, but only activate the last chosen one, to be sure to avoid conflicts. But I guess it would be difficult to automatically decide whether a stage is involved and switched off or not.

Seems like it would be too easy to accidentally create conflicts in crossfades and within Scenes.

DillTheKraut

@woland said:

Or maybe you could do it automatically with choosing it in the projector actors, but only activate the last chosen one, to be sure to avoid conflicts. But I guess it would be difficult to automatically decide whether a stage is involved and switched off or not. Seems like it would be too easy to accidentally create conflicts in crossfades and within Scenes.

Actualy, I wouldn't take that as an issue. If you move the whole 'stage' aka projection or screens, you would not want any fadings here anyway. And if I, there would be much more problems by 'morphing the picture from one stage state to another. One would need a totally different approach to get there, then just an output switch.

Woland

@dillthekraut said:

Actually, I wouldn't take that as an issue. If you move the whole 'stage' aka projection or screens, you would not want any fadings here anyway. And if I, there would be much more problems by 'morphing the picture from one stage state to another. One would need a totally different approach to get there, then just an output switch.

I understand if you plan well it wouldn't be an issue, I'm just saying that it would be incredibly easy, even in a simple patch, to accidentally create a conflict.

Example:

DillTheKraut

@woland

I see what you mean, couldn't this be solved by the stage hierarchy? Only the one on the highest level should be shown. I guess this would need some extra routines in the code probably, wouldn't it?

Woland

@dillthekraut

It’d likely be resolved by which actor was executed last. Operations in isadora go from top left to bottom right, so the Projector actor at the bottom would be the one that takes precedence.

You can see this if you have two picture players, each connected to separate projectors going to layer 1, blend mode Transparent.

The content is all going to the same layer on the same stage, so one is rendered, then the second one is rendered in the same place, causing the second one to end up “in front”.

If you physically move the bottom projector actor above the other one in the patch, you’ll see the change in the execution order as the other picture will then end up in front.

Woland

Other node-based programming environments also do this. I know Notch does, and I think TouchDesigner and MaxMsp does as well.

mark

@woland said:

I understand if you plan well it wouldn't be an issue, I'm just saying that it would be incredibly easy, even in a simple patch, to accidentally create a conflict.

Well, I suppose that's true, but that's the user's issue, not Isadora's. Again, the user would have to acknowledge they were doing something unusual by disabling the warnings and allowing multiple stages to share displays. Once they have taken this step, I would argue it is their responsibility to make things work.

But I wanted to agree with @DillTheKraut about the cross fades. The applicaton we're talkging about here requires the lenses of the projectors to shift, etc... you absolutely would not do a crossfade while this was happening.

The thing I'm trying to avoid is yet another layer of rendering. Imagine Stage 1 and Stage 2, both rendering to Display 1. What would have to happen is that you'd render the image of Stage 1 (even if there's no image) and then render that on to the Display 1. Then you'd render the image for Stage 2, and additively render that also on to Display 1 -- again even if their's no image to render. I mean, doing this is also possible, but it's going to be less efficient than using an actor to activate/deactive a given stage.

Also, @Woland -- I'm confused as to what you were referring when you wrote "Other node-based programming environments also do this. I know Notch does, and I think TouchDesigner and MaxMsp does as well." Can you elaborate?

Best Wishes,
Mark

Woland

@mark

If I recall correctly in Notch the execution order of nodes is affected by where they are placed so if what you’re doing requires a specific execution order you need to understand that where the nodes are placed does actually matter.