Thought I could share an example. Feel free to comment…
http://www.tooltech-software.com/forum/topic.asp?TOPIC_ID=43
So a gzState represents how the geometry will be rendered? And you’ve added a new member to attach a vp/fp to this state?
I notice that your gzState doesn’t seem to have an interface that deals with the concept of passes - what if you want to draw the geometry 3 times with different vp/fp’s each time?
I ususally set up a group with the same child share three times and select scene graph order rendering. This way I get selective mulipass counts per object so multiple objects can be rendered with various number of passes with different states. However I must say that you have a point so the shader could be “compatible” with more advance FX mulipass scripts.
To be honest, even as it stands you could just point it at a CgFX shader and it would work for multipasses ok!
GW! Pat yourself on the back! 
“This is an example of a complete shader example”
Ok.Ok. I know its not a complete shader example but it shows how to integrate the shader stuff into Gizmo3d.
About the Cg. Is there any possibility to implement Cg on Mac OSX ? Does NVidia provide or even allow you to use Cg alike syntax on other platforms ? Or do I have to use ARB vp/fp ASM.
Well, this example shows how to load and use “the shader stuff” into a scene graph API. Many scene graphs already support this. But the example does not solve any of the problems that current scene graph libraries have for really integrating vertex and fragment programs.
The concept of all scene graphs includes some notion of “attributes”, which are contained in the graph and modify how to render “shapes”, a different sort of nodes in the scene graph. For example you have a “light attribute”, a “clipping plane attribute”, or a “material attribute”. The beautiful thing is that those attribute types are compatible with each other. For example, you can setup a light source at the root of the scene graph, and it will illuminate all the shapes rendered with different materials.
Not so with your vertex program attribute. It will override all the lighting/material/transformation stuff that the scene graph would otherwise handle. So most of your scene graph stuff isn’t useful anymore.
Truly, for real integration of vp / fp stuff into a scene graph lib, I would expect automatic compilation of scene graph settings into corresponding shader programs. As bonus, scene graph users should be able to “plug in” user-defined shader scripts into the auto-compiled shaders (some sort of conventions obviously would be needed for this).
I realize that these are tough problems, and that probably nobody currently knows the solution to this problem.
flo
(wouldn’t that discussion better fit into the “Higher Level APIs” forum? Hmm, that one seems to be quite abandoned…)
Ok. The state management will work just like the other states so a vertex program will be able to use the material settings, light settings etc. from the scene graph. I will very much be able to use the strength of the scene graph. E.g. a shader will be able to work in combination with the scene graph lighting. We have an example that enables a Phong lighting model on a model subtree, where it is integrated with the rest of the scene graph with light positioning and shadows.
As you also might see if you look deeper, the implementation does support the user adding new shader “interpretors”. It does support version management of different “shader versions”. I have not added a default Cg interpretor because it is not platform independant, but the user can add such a feature easly into an existing scene graph.
The scene graph is fully integrated with multiple passes, stenciling, recursive rendering,compiled nodes etc. and sure … it’s been really tricky to get it to work but its a beauty when it does. To add support for glslang is just to add a plugin.
Sure you can access light and material properties from within the shader program - but however the user of the scene graph is responsable for the shader program to emulate the required parts of the fixed function pipeline. And generally a scene graph user would not want to hassle with that.
The feature list you describe surely looks impressive! However, I am quite sure that very much care is needed to design a costum shader that correctly interoperates with, say, shadow maps. One would have to figure out which texture contains a shadow map, setup texgen and texture matrix for this shadow map in the vertex program and the depth comparison in the fragment program. A typical user of the scene graph, writing a custom shader, will not be able to develop that.
(I see you have opted for shadow volumes instead …)
Well if the user don’t want to hassle with replacement for the fixed function pipeline he can skip the shader stuff or he can use a template that we provide with a replacement for the ffp.
The whole idea behind shaders is to let the user get a higher level of freedom in rendering. If he just want some extra features like phong,brd,bumpmapping, gloss etc he can select “standard” shaders for these features that we provide.
I agree with you anayway. You need kind of a “standard” how the shader shall interoperate with the scene graph. E.g. you will always find the shadow map in map 3, the normal in map 2, etc…
Yes I have opted for shadow volumes. When displacement mapping gets reality you can use shadow maps for shadow volumes with softshadow etc…