|
|
GLSL shader bypass? Hi I've got some epic compositions with 3d content that I'd like to dump into some GLSL shaders. How can I "bypass" the shaders to show the unaffected, i guess unshaded contents of the glsl macro patch without duplicating the contents and using a multiplexer. I'm hoping it's bleedingly obvious that I can't program glsl so hopefully it's a simple line or two that somebody could help me with? Thanks.
|
simple answer: you can't
long answer: due to QC forward rendering mechanism, duplicating stuff has no impact on performance (theoretically) as long as the involved macco is disabled.
So you could, for instance, put your 3d loader patches at root level, then head down to 2 distinct macro (each having a 3d object renderer patch inside): a shaded one and a un-shaded one, each of these macro being either on or off, but never both on the same state at the same time.
To do this, use a boolean, and with the math expression patch : " !boolean " , you'll just invert the bool value. (thus disabling a macro when the other one is enabled)
Hence, this simple rule: the content is there only ONCE, only the renderers are duplicated.
Franz's suggestion is totally right on, but something comes to mind after reading it.
It may be splitting hairs, but I'd suggest to avoid putting the renderer that needs no GLSL inside of an "empty macro" that's being turned off, and instead to turn it off at the enable.
One thing that I've come to realize over time, is that every time you macro-ize you're inducing more steps of evaluation, and making it so the macro is partially in control of the function that makes the subpatches evaluate, instead of just the parent. Extra ports are created and that macro dips in a "tier" deeper in the hierarchy of the plist.
The difference can be trivial in some scenarios, but when there are "many" macro shells around things, or things are macro'd in macros, in macros (eg., many levels down), the overall evaluation of the composition gets slow/uneven/clogged...for lack of a better term. QC is generally best, imo, with everything working at 1~3 macro levels deep, if humanly possible. That's not an opinion I hear many people share, or even mention, I can only say it's from my own experience and a/b testing.
If your 3D objects aren't textured, you can "get" the GL Color they are set at (eg., the color port value) and fade to that in the shader, but you can't "get" the texture that's connected inside. Under that one circumstance, what you're describing is possible, but texturing is what will be the impasse.
you might be right, however, as QC is slow by nature, I tend to avoid over-optimizing and rather keep my graph clean and organized.
Speed wise, it's better avoiding noodling than avoiding macros, imho. My rule is "the less noodles, the better".
I can't possibly agree with that more (though I might mince words on the slow by nature part). The "all code happens in one patch" method has always seemed faster, and has delivered as speedy performance w/ "rendering lots of stuff" as other systems. It's that structures and certain types have wrappers that make stuff slow when trying to shuffle around too much info in a "node graph". QCStruct/GFList is ehhh.