assurance-tunnel
assurance-tunnel
assurance-tunnel
assurance-tunnel

Multiple Geometry Using the same display


  • Tech Staff


  • Tech Staff

    @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.

     Crossfades between Scenes using the same displays but different Stages wrecks this


  • Tech Staff

    @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


  • Tech Staff

    @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.


  • Tech Staff

    @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:



  • @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?


  • Tech Staff

    @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.


  • Tech Staff

    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