Hi, I would do something like this: - Use cull visitor do determine which nodes will possibly be rendered - For each node, determine the shader characteristics (like a bit field; number of textures, lighting computation, shadows or none, ...) - Build or fetch the shader that matches these characteristics - Attach the shaders to the nodes - Render the scene We could have shader characteristics on the viewer and various nodes specifying them like you say with something like "ShadingHelper::setShadingCharacteristics". This would also require the setup of uniforms that can match shader characteristics like the ith texture, the shadow map, vectors/normals, ... Martin
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, February 19, 2007 3:14 PM To: osg users Subject: Re: [osg-users] osgShadow::ShadowMap implementation On 2/19/07, Mihai Radu <[EMAIL PROTECTED]> wrote: The SVN version compiles & works very nice (Fedora 6). Thanks for the feedback. About the clipping for SM creation; if we could get the shadowers clipped by the main view frustum, and then use the bounding box of this for adjusting the SM camera, it would make a big improvement for SM anti-aliasing. With the current method, adding in a shadow-casting terrain makes the part of SM used close to the main camera very small, therefore very jaggy. To make ShadowMap and ShadowTexture more usable in real apps we have implement better set up of the RTT cameras/shadow texture so that its view dependent. The funding I have for osgShadow doesn't encompass this though, its focused on ShadowVolume so this is where I'll be spending my efforts so I'll have to come back to ShadowMap later. In March I'll be doing some work on view dependent OverlayNode, and this will require similiar view frustum constrained RTT set up, so once I've written this we should be able to reuse the various utility classes that I put together in ShadowMap and ShadowTexture. On the subject of texturing control, for the simulation at work I wrote a little "ShadingHelper", that applies shaders ( with sources taken from lua config files), and applies them according to an [enum] criteria to selected parts of our scene. Right now we are distinguishing between regular 3D objects, particle systems and text (this one has a NULL Program on it). I think this is the beginning for more control for shading in osg, it could be used to delegate the creation and storage of shading programs and uniforms for the rest of the application. Then if below a certain node there's a need for a specific program something like this could be called: ShadingHelper::setShadingProgram((osg::Node*) i_node,ShadingHelper::ShadingProgramType::SHADOWED_TEXTURED); for uniforms I can call something like this: ShadingHelper::setShadingValue((osg::Node*) i_node, (std::string)i_uniformName, <class T> value); Some ideas on the things a general design should accomplish would be very welcome. I don't really have any ideas on this topic off the top of my head, and certainly needs a clear head to think about so I'll have defer my contributions on such topics till my working life settles down a bit more .i.e less 12 hours days... Robert.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
