|
|
Multi-View RIIThis patch would be like a Render In Image/Stereoscopic Environment, save that it would have 2 or more outputs that could be set to totally different camera views, allowing one to render a front and a side view simultaneously. This could possibly be incorporated into the "Slice RII" concept/request, if it is possible at all.
|
How would this be advantageous over duplicating the RII Macro oneself? Apart from the connivence of editing macro contents once only (obviously). Could it be any faster?
If there's a lot going on inside the macro, it's conceivably near 2x faster. Imagine something nasty like a large iterator arranging cubes. You could be doing that once instead of twice.
It's a good idea actually, but I'm not sure what issues could crop up here. Probably some nasty ones! The stereo patch works ok though, maybe it's not much of a stretch to adapt that for this kind of case.
That said, I think this idea can be taken a lot further and made a lot more useful! All we'd get from this is multiple camera angles, but I'd want to use it in other ways (e.g. multiple shaders rendering the same content).
How about this then: a 'special case' macro, that can be duplicated many times but only executes once. I envision something with 2 patches: one would be the 'real' macro, with your contents in it, call it something like 'multiple renderer source'. This might be left somewhere away from where you want to use it, because it's only your source macro.
Elsewhere you'd have something like 'multiple renderer alias'. You'd drop this in wherever you want to use your macro. It would be non-editable (i.e. you can't open this kind of macro.. or maybe it would act a shortcut to the original).
When the graph gets evaluated, all the 'aliases' are marked as dependent on the source macro. That gets evaluated once, then the results are passed to all the render-in-image (or whatever else happens to be using it).
This is something like the kineme spooky send/receive patches actually, except it's sending an evaluated macro rather than a standard data type.
I don't know about that...
The stereoscopic environment requires the renderers to execute twice, so I'm not sure if your premise is sound.
What your talking about is like an "in composition" virtual macro that can respond to GL translate / rotate commands. In that case, one could just wrap the virtual in a regular render in image if one wanted to get the pixels....rebuilding that part becomes sort of unneeded. Not a bad idea.
I'm dubious about the ability to "send" a macro as it were, or avoid evaluation, but I think this is probably attainable in other ways...
Yeah, this would only be of serious value if it avoids the repeated evaluation.
In composition alias macros would still be valuable. The whole virtual macro thing needs to be fleshed out more and be made into something a little more workable.
If virtual macros could be all types of patch (right now it can't be an environment either, which makes it impossible to store a bunch of GLSL environments in the patch list... not too great), and if you could click on it and open up the original composition to edit, and do either a save or save as, and have it update the composition instantly, instead of having to open and close QC, it would still be very valuable to workflow. The other thing that kind of sucks about virtual macros is that renderers inside won't respond to 3D transforms, to my memory. Hmm, not sure...
Having multiple camera views is something that many other graphics engines cover, and I think it's not unreasonable even if there is a hit in fps. There would be multiple rendering going on, so I don't see how the scene could not evaluate more than if there was just one view. I know QC isn't a gaming engine, but many games take advantage of multiple views in realtime to good result. I think it would make it stronger as a design tool, and for making interesting multidisplay presentations... if combined with the whole z-clip concept of my other request, it could give a pretty enormous amount of power.
I don't know if having more control over rendering/camera(s) in QC can be covered entirely by the virtual macro/alias concept but both are highly intriguing to me.
Your idea and GT's original idea are really interesting suggestions.
Just to knit pick a little more: I don't see why all the duplicated patches that are expensive to repeat can't be pulled out of the Macro to execute once only with the results ported into each RII as inputs. I mean, I know it is potentially more messy but from a purely can-this-be-done-with-existing-means pov.
Having in composition alias macros (as was suggested on the QC list not too long ago), would add a layer to QC that would give it some capabilities of the world of traditional programming.
I see your point, but it requires your patch count increases X times amount of viewpoints desired. It's also kind of user unfriendly, and makes it so that each renderer needs to be adjusted exactly the same as the other X times amount of views needed.
This is something I think I may have requested before, now that I think about it.
It's like, if you simply want to make it look like an animated character is standing on a floor you have to do this lame kind of back and forth, shifting it in a 3D transform or trackball, as you move the object, checking to make sure a "foot" doesn't go through a floor, etc. Totally sucks. I see the point about setting up the entire scene twice, but I don't know if that is any improvement to the process of setting up a scene in QC.
Porting in works great, but only for the standard QC datatypes. Take my example before, you want to draw 1000 boxes using an iterator, and apply a several shaders (I've had this case before myself!)
You put each shader in an RII patch. Ok, how do you get the 1000 boxes inside there without duplicating the patches? It's impossible. You have to duplicate the iterator, which effectively halves the framerate.
Try to place an object on another object in QC. Having multiple views, even from a utility perspective, could at least let you place an object so it's on a floor, or whatever.