Another thing that might help with the whole speed vs. flexibility issue is to allow the linking of many shader objects. I believe the SHL framework currently allows one vertex shader and one fragment shader. But if more could be linked together, then it would be possible to spend less time compiling and just link together the correct already-compiled objects. Or maybe an object that only handles lighting could be recompiled and linked without having to recompile the rest of the shader.
Anyway, has there been any more progress with OSGActiveLightsMask? Since bitwise operators aren't available in GLSL I was thinking of trying to add the following bools to the SHL framework: OSGLight0Active OSGLight1Active OSGLight2Active OSGLight3Active OSGLight4Active OSGLight5Active OSGLight6Active OSGLight7Active This is the best solution I can think of for detecting which lights to use at runtime. Comments and suggestions are welcome. -- Terry Welsh - mogumbo 'at' gmail.com www.reallyslick.com | www.infiscape.com | www.vrsource.org On 6/20/05, Dirk Reiners <[EMAIL PROTECTED]> wrote: > > Hi Terry, > > On Mon, 2005-06-20 at 11:54 -0500, Terry Welsh wrote: > > > > Dynamic branching makes for slower shaders, but I am in favor of it > > for the project I am working on because light sources may frequently > > change in number and type. Since GLSL shaders must simulate the > > complete lighting environment in a scene, turning on one light would > > mean recompiling every shader in the scene. This could cause really > > ugly pauses. > > Not necessarily, that's what I meant with caching. If you switched > between different configurations only the first change would need a > recompile, the next ones would be fast (until the cache overflows). > > In general, if the change is triggered by a user interaction, I'd prefer > a little hickup and faster general performance over immediate changes > and slower performance. Things might be different if the changes happen > automatically and very often, though. > > Dirk > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
