Thanks for adding that. It looks like the & is not available in GLSL, which is why your driver doesn't implement it. Operators are listed on page 83 of the orange book. However, the & is reserved in the GLSL spec, so they might use it in the future. Currently, this data would probably have to be passed as an array of bools or individual bools with unique names.
I have given this problem some more thought in the last couple days, and I still cannot come up with the best all-around solution. For example, I can implement one lighting function that handles all types of lights, or I can implement specialty lighting functions that are more efficient. But for specialty lighting functions, I also need to tell my program what type of light to use with each light index. Asking OpenSG for that much information is probably overkill. As long as conditionals executed fast enough in GLSL, using one big lighting function with something like OSGActiveLightsMask is probably the most flexible solution. If I understand correctly, OSGActiveLightsMask would be computed for each SHLChunk individually just in case a light only affects some of the nodes in a scene instead of all of them. Is that right? - Terry On 6/17/05, Andreas Zieringer <[EMAIL PROTECTED]> wrote: > Hi Terry, > > I added a new OSGActiveLightsMask parameter. In your shader you can do > now something like this: > > uniform int OSGActiveLightsMask; > > if(OSGActiveLightsMask & 1) > ... > if(OSGActiveLightsMask & 2) > ... > > I added an small example (OpenSG/Source/Experimental/SHL/testSHLLights.cpp) > The bad news is that the & operator is not supported by my driver. > > Andreas > > > Thanks Andreas. That's too bad. If anyone has any other suggestions > > on ways to the standard gl lighting information, I would like to hear > > them. > > > > The main thing I am worried about is using up all my available > > uniforms. Each light will require somewhere between 8 and 12 uniform > > floats depending on the type of light. And I want to specify OpenGL > > lights anyway, so that if a shader gets too big to compile, the object > > using that shader will revert to standard OpenGL lighting instead of > > turning black. Since I will already be specifying that lighting > > information, it would be nice to reuse it instead of specifying it > > again for the shaders. > > - Terry > > > > On 6/15/05, Andreas Zieringer <[EMAIL PROTECTED]> wrote: > > > >>Hi Terry, > >> > >>not yet, but you can't put this information on application level into a > >>uniform because in local lights render mode the active lights can change > >>dynamicly for each rendered node. I could add this information to the > >>special osg uniform parameters like "OSGViewMatrix", ... > >>But one index is not enough we need a array of indices or use on uniform > >>with a bit mask of active lights. > >>Well the easiest way is to add the lighting information like light > >>position, count, ... directly to your shader. > >> > >>Andreas > >> > >> > >>>When OpenSG sets up lights, is there any way to have it tell which > >>>glLights are being used, and perhaps what type of light each one is? > >>>I think this would be useful information for writing GLSL shaders > >>>because it would allow me to pass only the light index as a uniform > >>>and gank all the necessary lighting information from > >>>gl_LightSource[i]. The alternative is to pass *all* the lighting > >>>information as uniforms. > >> > >> > >> > >>------------------------------------------------------- > >>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 > > > > > -- > Andreas Zieringer [EMAIL PROTECTED] > Fraunhofer IGD - A4 phone +49 (0)6151 155 289 > Fraunhoferstr. 5 fax +49 (0)6151 155 196 > D-64283 Darmstadt www.igd.fhg.de/www/igd-a4 > > > ------------------------------------------------------- > 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ÿick _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
