Hi Sebastian,
First of all, the lightning shader only illustrates one of the cases where
(optionally) repeating a code block containing substitution parameter can be
useful. I used the multi-light lightning as an illustration only.
First, thank you for your input. Yes, that is more or less the same approach
I'm currently using. The downside of this approach is that it requires
additional nontrivial code logic for the uniform array management
(u_LightColor) and that is why I started to look at the alternatives.
What could be more complicated there than to setup individual uniforms? Sorry
this doesn't pass as a valid argument. If you have to hold the number of used
lights somewhere you can hold a reference to the uniform as well.
Sorry, but that is not what I had in mind. The problem here is the management of the array
uniform's content and not the reference to it or the light count etc. Let say I only want to
disable one of the lights, say LIGHT0 eg. stateset->setDefines("LIGHT0",
osg::StateAttribute::OFF). What will you do?
There is also an upper limit for the size of the array that needs to be taken into account.
At least 512. If this is not enough you can use Uniform buffer objects (UBO)[1]
or Shader Storage Blocks[2] which support
If this is not enough for your light-count you will probably hit performance
problems first.
Yes, that is true. The upper limit is not a problem for this specific
multi-light problem.
Also, the loop represents unnecessary overhead (though, this is not a problem on a never hardware).
That's an assumption of yours. Usually constant folded loops with single return
and without break, continue-statements are unrolled by the compiler.
I'll accept performance comparisons however ;)
Yes, you are right about that. The constant loop will most probably be unrolled
by the compiler. Of courses, that is another assumption on top of the previous
assumption :)
On the other hand, my suggestion fits well into existing pragmatic shader
composition logic and probably has less downsides.
Downside is that you're trying to invent a meta-language here out of reasons
that I commented on. The downside of your approach is a preprocessor language
with no clear advantages over the tools already at your disposal.
So to say, the current language is already turing-complete and you're trying to
put some syntactic sugar on top, which adds some high degree of complexity to
the parser and to the shader-code.
Exactly, that was my intention, to add a higher degree of complexity and hopefully solve
some problems that "turing-complete" language can't.
An alternative for you is to manage this part yourself by simply overriding the
parts managing the define-states. Maybe Robert O. can fill in on the details
here.
Cheers
Sebastian
Cheers,
Robert Milharcic
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
