[ANSWERED] Multiple Geometry Using the same display

DillTheKraut

We once even went further and mounted a 20k Panasonic Projektor to a moving head base, pointing it to up to 5 different positions in one show! The Lens presets work pretty well and are very tight.

But yes, the 'Activate/Deactive Stage' actor, was in my mind too. 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.

I'm aware, this isn't a usual setup, but I have the feeling, this feature would have some other potentials, we don't see yet.

@Fred

The matrix idea is a good one! But this has limits as it would need more outputs at your machine. If you already use 3 out of 4 from your GPU, where to get the others from? I know the datapath and tripple head options, but every extra device is a time consuming and risky extra. I use matrices often anyway for a second backup machine, which would as well push the needed inputs.
But anyway a good approach!

DillTheKraut

@fred said:

Ps how does the lens shift get in exactly the right place in the show, I never saw a beamer that had perfect recall.

I do have very good experiences with the bigger Panasonic Projektors (PT-DZxx / RZxx) and the Epson EB-L1505U. I set up a long term Show with the Epson EB doing a relatively complex mapping of different levels and depth without bigger issues. It ran for month now already. But it is the first Time I use these Projectors doing a soft edge blend. They tend to shift over the days a little bit (maybe 1 or 2 Pixel), but as the projection surface moves anyway, I can't for sure tell which is giving this. But after a little correction at the show presets it works very well. And with some (relatively speaking - small) Text, I do have some matching critical content to put on that surface!

bonemap

Hi,

We are looking at a project in June 2020 in a large round ex WW2 storage tank 1023 sq mtr. Have been thinking about a moveable yoke projection. The solution for dynamic edge blending discussed in this thread could be very useful for that project. We are seeing these moving head projectors around - used for public art installations and other projects. @DillTheKraut, I had not thought to use the lens shift of a projector like that, and I am not sure that I would subject the lens shift motors to that much repetitive work, do you think there is any issue with motor strain doing that? I have found the lens shift on the Epson pro's impressive - depending on which lens is fitted. The moving yoke projector is something I am very keen to play with.

Best Wishes

Russell

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.

danzltessio

@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

DusX

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