Am 14.01.2016 um 11:56 schrieb Robert Milharcic:
On 14.1.2016 9:52, Sebastian Messerschmidt wrote:
Hi Robert,
This seems more complicated than needed.
Why not pass the number of lights as a compile time constant
#pragma import_defines (NUM_LIGHTS)
shader_state->setDefine("NUM_LIGHTS",12);
and use uniform arrays:
uniform vec4 u_LightColor[NUM_LIGHTS];
for (int i = 0; i < NUM_LIGHTS;++i)
{
light+=calcLight(u_LightColor[i], ...):
}
I feel your approach will bloat the preprocessor code path and will
complicate the use.
Hi Sebastian,
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.
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.
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 ;)
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.
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
[1]https://www.opengl.org/wiki/Interface_Block_%28GLSL%29#Uniform_blocks
[2]https://www.opengl.org/wiki/Interface_Block_%28GLSL%29#Shader_storage_blocks
Cheers,
Robert Milharcic
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
