Hello Johannes,
On 11/29/2012 10:14 AM, Johannes wrote:
> I have some additional questions with respect to shader programming in
> the scene graph world. After I have glanced through the GLSL
> specifications and some shader books, I'm puzzled with respect to the GL
> state.
>
> The scene graph defines the rendering properties of its constituents.
> This is done with a fine granularity via the material chunk objects.
> This defines the rendering state for sets of objects. Now, if I use
> shader replacements for the fixed function part of the pipeline I have
> to access this state in order to emulate the functionality. But some
> state is not available in the shader (on present GLSL versions all state
> is actually gone). I could set up some state as uniforms on the start of
> the render function but then I would lose the fine grained scene graph
> description of the rendering task. The state I have currently in mind
> consists of
in my view the programming model with shaders changes quite a bit. Due
to their flexibility shaders become more or less the entire rendering
state and there is no modularity any more. Or rather there is no
pre-determined modularity any more, it becomes the shader author's
responsibility to decide how much/at what level modularity is needed and
then write the code accordingly. That way you get to pick the sweet spot
between flexibility and performance for your application - at the cost
of being forced to pick it yourself ;) ;)
One way to get some of that modularity back is to use an "Über-Shader",
i.e. one that can handle all sorts of different rendering scenarios by
executing parts of it conditionally.
This can be achieved in different ways: for example by using the
preprocessor, if() statements that test boolean uniforms or by writing a
shader that calls a bunch of functions for different processing steps.
These functions can be compiled separately and then linked together into
the shader program.
> GL_LIGHT_MODEL_TWO_SIDED, GL_LIGHT_MODEL_LOCAL_VIEWER,
> GL_LIGHT_MODEL_COLOR_CONTROL as well as of the texture application
> functionality, i.e. GL_REPLACE, GL_MODULATE, GL_DECAL, GL_BLEND and GL_ADD.
lighting and texturing is entirely up to the code of your shader, so it
is entirely up to the author to pick a suitable way to control these.
In a way shaders take the old C paradigm "you only pay for what you use"
to the limit: there is very little built in stuff and you are free to
pick the most efficient way to solve a problem.
> Does OpenSG provide support for these; or do I have misconception of the
> problem? How, do you solve this problem? Is this expectation in the line
> with the scene graph paradigm?
Two geometries that use the same shader code can execute it with
uniforms set to completely different values inside a single scene.
Placing a ShaderProgramVariableChunk in a ChunkOverrideGroup can be used
to achive that for branches of the scene.
Cheers,
Carsten
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
VERIFY Test and improve your parallel project with help from experts
and peers. http://goparallel.sourceforge.net
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
