Multiple Geometry Using the same display

[CitizenJoe]

Around 2009, having just completed an Isadora course with @mark, excited by the possibilities I bought 2 Apollo Right arms for use with projectors: https://www.apollodesign.net/right-arm-1396.

I've been using them ever since!

Cheers,

Hugh 

[bonemap]

@citizenjoe said:

I've been using them ever since!

 Did you have to fabricate the suspension system for the projectors with these units? They don't appear to be easily available outside US.

best wishes

Russell

[DillTheKraut]

@bonemap

I don't really have any long term experiences about the mechanical strain yet. I maybe can tell end of next month when we move the long term project from one location to another. But there is one Epson only doing two lens movements the day. As this show is one clone of two others in different countries and build by the same agency, they already have at least no bad experience with it.

On the other hand given the use of rental Projectors, where the lens motors are used a lot over there life span, I doubt this being a factor to worry about. In the end it propably will depend on the count of movements it will do in a given time.

Anyway, the Epson projectors and the newer RZ Panasonics give the possibility to save up to 10 presets, which really isn't a little. But about the possible strain in an installation where there are many movements a day, probably only the manufacturer is capable to tell.

[CitizenJoe]

@bonemap said:

 Did you have to fabricate the suspension system for the projectors with these units?

 

I always build something for support. It's simpler than trying to adapt somebody else's idea.

Cheers,

Hugh

[Skulpture]

I have used these before:

http://polestar-productions.uk/projectionmapping/dynamicprojection.php 

[Woland]

@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

[Woland]

@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

[Woland]

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

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