Multiple Geometry Using the same display
-
@mark said:
I would want to make the user check a box that says "Advanced Mode - Disable Stage Conflicts" or something like this because, for many users, those warnings are important and useful (especially if you're using splitting an output, i.e., using a Data Path or TripleHead2Go.)
Sounds like a good plan
-
@dillthekraut 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.
-
@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.
-
@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:
-
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?
-
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.
-
Other node-based programming environments also do this. I know Notch does, and I think TouchDesigner and MaxMsp does as well.
-
@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 -
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.
-
@mark said:
I can imagine a way of doing this, where you could define multiple stages that use the same displays, and then a "Activate/Deactive Stage" actor to activate one or the other. So in Scene A, you'd activate "Stage 1" and deactivate "Stage 2", giving the geometry for Stage 1. Then later, in Scene B you'd deactivate "Stage 1" and activate "Stage 2", giving the geometry for Stage 2 instead. The reason you'd need to deactivate it is to prevent Stage 1 and Stage 2 from both attempting to draw to the same stage, leading to a conflict.
hi mark,
I am encountering this problem now -- I want to have 2 stages with different geometries on the same display. I can't find an activate or deactivate stage actor anywhere in Isadora (running v4 now) -- has this actor been removed from this version? Let me know! Thanks
-
@danzltessio said:
can't find an activate or deactivate stage actor anywhere
This is not any actor that exists. The closest is "Show-Hide Stages" which is used to activate/deactivate stages entirely.
As mentioned in Multiple stages with same display | TroikaTronix Forum you likely want to use Izzy Map in different Projector actors, to create different mapping/geometries.
You can have as many different mapping/geometries as you like in a Isadora file, that are output to a single stage, or even switch the target stage if you have multiple displays connected allowing multiple stages.