Hello Johannes, Good to see you are interested in my submission and that you actually took the time to look at what it contains. The submission is intended to be a big first step for integration of shader composition into OpenSceneGraph. This includes mixing the FFP with custom shader code and even building complete new shader trees.
I agree with you that there are parts that need more attention, especially when we are going to add a lot of new ShaderModes. I wouldn't say a more complex system is needed, because complexity can never be a goal. ;-) Unfortunately I didn't have the time to actually add non-FFP shadermodes to demonstrate that it is possible to extend the FFP. maierjoh wrote: > > 1. How do you make sure, that your code-snippets get placed in the right > order? Some parts of the FFP may not be commutative and it seems to me, that > your shadergenerator works "first come, first served"? > Indeed linking of ShaderModes based on inputs and outputs needs further discussion and work. Currently the linking is done in a greedy manner, where the first ShaderMode that can provide a requested input is used as a source. The sorting of ShaderModes based on their type combined with the input and output parameter name matching is what determines how the tree is constructed. What is needed is a semantically richer description of the input and output variables so they are no longer only dependent on exact parameter names. This is needed for more robust linking and allows for automatic translations (for instance from vec4 to vec3 etc.) when parameters don't match exactly. maierjoh wrote: > > 2. It would be nice to use i.e. the vertexshader replacing the FFP together > with an own fragmentshader-implementation (as is possible with the FFP now). > I don't understand what you mean with this. Do you mean mixing FFP vertex processing with only a custom fragment shader? In my opinion this does not have to be a feature of this shader composition code since the FFP is going to dissappear alltogether. maierjoh wrote: > > The last few days I looked into the code, run the testprogram and found a > problem in this concept. > If you run the testprogram and try to add 2 lights, the generated > vertexshader won't compile, because of missing declarations of the > Ambient/Diffuse/SpecularLightIntensity. > > Please correct me, if I understood something wrong: > > Example: > > 1 Light - Generated Shadertree: > > FFVisualRoot > ___FFLighting > _____FFLight1 > _______FFBase > _____FFBase already traversed. > > Generating the Code: > > Visiting all nodes from root to leafs (depth first) - and setting "traversed > = true" before visiting the children. > Writing the code-snippets, if "traversed = false". > In our example the order of the codesnippets would be: FFBase, FFLight1, > FFLighting, FFVisualRoot. > > At the Light1-node there are some unlinked input-variables > (Ambient/Diffuse/SpecularLightIntensity), which are written out with > default-values. > > vec4 AmbientLightIntensity = vec4(0.0, 0.0, 0.0, 0.0); > // 2 > vec4 DiffuseLightIntensity = vec4(0.0, 0.0, 0.0, 0.0); > // 3 > vec4 SpecularLightIntensity = vec4(0.0, 0.0, 0.0, 0.0); > // 4 > > That's working well. > > Now 2 Lights - Generated Shadertree: > > FFVisualRoot > ___FFLighting > _____FFLight1 <- LightIntensity-inputs set by Light0-outputs > _______FFBase > _______FFLight0 <- LightIntensity-inputs set by Light1-outputs > __________FFBase already traversed. > __________FFLight1 already traversed. > _____FFLight0 already traversed. > _____FFBase already traversed. > > Now we have set the inputs Ambient/Diffuse/SpecularLightIntensity for Light1 > by Light0. > And we have set the inputs Ambient/Diffuse/SpecularLightIntensity for Light0 > by Light1 - at least in the Shadertree. > In this example the order of the codesnippets is: FFBase, FFLight0, FFLight1, > FFLighting, FFVisualRoot. > > Now - writing out the code, there seem all inputs linked for the lights, but > as you may notice: Ambient/Diffuse/SpecularLightIntensity are never really > set AND they won't be written out as default either because of the Light1 -> > Light0 -> Light1 linking. > > The generated vertex-shader won't compile, because of the missing lines: > > vec4 AmbientLightIntensity = vec4(0.0, 0.0, 0.0, 0.0); > // 2 > vec4 DiffuseLightIntensity = vec4(0.0, 0.0, 0.0, 0.0); > // 3 > vec4 SpecularLightIntensity = vec4(0.0, 0.0, 0.0, 0.0); > // 4 > The problem you see here demonstrates circular linking due to the greedy linking mentioned above. Feel free to tells us about the shadertree concept you have in mind. kind regards, Roland Smeenk ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27289#27289 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
