Ah, well I'll send you a quick hack for this. The INT is used to identify the active light, in the example uLightID is just zero.
This is actually one of the problems that I tried to address with the half finished DynamicShader class in amongst the code. I came to the conclusion that it might be better to have a huge uber shader and block out bits effects code with #defines or add constant variables such as the light id using the same method. This way the shader is much more effecient as it reduces branching and also the number of uniforms sent to the shader which is important for the cards supporting lesser shader models. Anyway drop the attached shaders into the resources/shaders directory and give it a whirl. You may find that the shader maxes out the number of varying variables allowed in glsl 1.1 but I can't remember how many are allowed off the top of my head. Let me know how you go. Kim. -----Original Message----- From: [email protected] on behalf of Ümit Uzun Sent: Thu 07/05/2009 09:07 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean release Hi Kim; After last updates I don't see any error about vertex shader as before I saw. But now I have checked the OpenGL and GLSL driver version and saw that OpenGL is 2.0 and GLSL is 1.1 so when I opened up the osgOceanExample I see Error: glUniform1uiv not supported by OpenGL driver. Because of glUniform1uiv function is in GLSL 1.3. I have tried to update my driver for 2 hours but can't find anything because of my card is about 2 years old :( Is there any way to update my driver to OpenGL 3.0 seperate from Graphic Card driver? Or what can I do for this trouble? My Graphic Card : ATI Radeon Mobility HD 2300 256 MB OS : Windows XP Best Regards. 2009/5/6 Jean-Sébastien Guay <[email protected]> > Hi David, > > I would suggest that an all GPU FFT would just be one in a selection of >> possible ocean surface techniques. An architecture that supports many such >> techniques would be a good goal for this kind of project ! >> > > I totally agree. I'll be looking into how feasible this is, not just for > offloading surface generation to the GPU, but in general for allowing > selecting the surface generation technique from a list of possible > techniques with different tradeoffs. > > As soon as there's a non-GPL alternative integrated instead of FFTW, I can > start working on that. > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay [email protected] > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Ümit Uzun
<<winmail.dat>>
***************************************************************************************** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *****************************************************************************************
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
