Hi Robert, Thank you for your rigorous explanation of the renderstage functionality. It's good to know that OSG offers such flexibility. The separation of the scene to different renderstages is probably what I was looking for, but unfortunately it's not as simple as I was hoping. I will look into culling callbacks and I will be back soon with more questions....
In the meantime, If anyone else has any other suggestions i would be glad to hear them. Pavlos. Robert Osfield wrote: > Hi Pavlos, > > Using shaders is certainly more flexible, but it does bring its own > complexities. > > FYI, the complexities in handling standard OpenGL lighting with more > than the max supported comes down to the way that the OSG handles that > fact that lights are positional state, and positional state has to be > bound to a specific modelview matrix to position it in the correct > place - OpenGL lights can't just be assigned at any time in the draw > traversal as their modelview matrices will be indeterminate and end up > jumping around the place relative to different chunks of your scene > graph. > > To cope with the correct binding of position state with the intended > modelview matrix the OSG detects the LightSource nodes in the scene > graph during cull traversal and then binds the modelview matrix > inhertied down to this LightSource with the Light attached to the > LightSource, then this pairing of matrix and light are assigned to the > current RenderStage (a render backend object that manages the > rendering of a single stage in the rendering pipeline). Each > RenderStage can only have up to the max supported lights assigned to > at any one time and a single light can't be in more than one place at > one time as there is only one entry for it. To handle more lights you > need to segment you scene up so that different parts render into > different RenderStage, these RenderStage will need to be chain so that > the first one does the usual OpenGL clear of colour and depth > buffers(as is default for a RenderStage), the subsequent ones then > switch off the clear, so they overlay on top. You can do custom > control of the RenderStage by using a cull callback that > creates/maintains them appropriately. > > Robert. > > > > > On Jan 3, 2008 9:03 AM, Pavlos Mavridis <[EMAIL PROTECTED]> wrote: > >> Hi Paul, >> Your suggestion to use shaders and perhaps pass the light parameters >> using uniforms, >> as Terry suggested, seems very reasonable to me. That way we can bypass >> the OSG >> backend and manage the lights in our code. And it's probably simpler >> than messing >> with the backend. >> >> Of course, if there's a better or more elegant approach I would like to >> hear it. >> >> Pavlos >> >> >> Paul Martz wrote: >> >>> As Robert said, using the fixed function pipe involves knowledge of >>> the backend. I believe multiple RenderStages would allow multiple >>> PositionalState, which means you could support more than the fixed >>> function limit for lights. This gets complex. >>> >>> It'd probably be easier to use shaders to do what you want, as they >>> aren't limited by the number of fixed function lights. >>> >>> Paul Martz >>> Skew Matrix Software >>> >>> >>> On Jan 2, 2008, at 5:06 PM, "Terry Welsh" <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>>> Hi Pavlos, >>>> I'm interested in this topic too. I haven't found the discussions in >>>> the archives, but I probably just haven't picked the right search >>>> keywords. >>>> >>>> My problem is very similar to yours I think. I want to have a lot of >>>> lights in my scene that falloff completely after a reasonable distance >>>> and only apply 3 of them to each piece of geometry, probably choosing >>>> them based on proximity and/or brightness. I was thinking of only >>>> activating lights 0, 1, and 2 and applying a cull callback to all my >>>> geodes that would set different light positions and colors for each >>>> geode that doesn't get culled. The positions and colors would be >>>> chosen from a much larger pool of lights that I store in my own data >>>> structures outside of OpenGL and OSG. I haven't figured out if I >>>> would do this by setting parameters for OpenGL lights 0, 1, and 2, or >>>> by setting custom shader Uniforms. >>>> >>>> Or there might be a much better approach I haven't thought of. >>>> Anyway, I'd like to discuss this more or hear from anyone who has done >>>> this.... >>>> - Terry >>>> >>>> >>>> >>>>> Message: 3 >>>>> Date: Wed, 2 Jan 2008 16:42:37 +0000 >>>>> From: "Robert Osfield" <[EMAIL PROTECTED]> >>>>> Subject: Re: [osg-users] Selective lighting in OSG >>>>> To: "OpenSceneGraph Users" <[email protected]> >>>>> Message-ID: >>>>> <[EMAIL PROTECTED]> >>>>> Content-Type: text/plain; charset=ISO-8859-1 >>>>> >>>>> Hi Pavlos, >>>>> >>>>> I'm afraid handling more than max number of OpenGL lights is awkward >>>>> in the OSG, it is possible but you'll need to learn quite a bit about >>>>> the internals of how the rendering back end is setup and traversed. >>>>> This topic has been discussed in the past on osg-users so have a bash >>>>> at going through the email archives. >>>>> >>>>> Robert. >>>>> >>>>> On Jan 2, 2008 4:13 PM, Pavlos Mavridis <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>>> Selective lighting in OSG >>>>>> >>>>>> Hello everyone, >>>>>> what is the best way to define a light that affects not the entire >>>>>> scenegraph, but only a part of it? >>>>>> >>>>>> For example I have a scene with many objects. Each one of them is >>>>>> lit by >>>>>> one light that is >>>>>> different from one object to another. So the number of lights can be >>>>>> greater than GL_MAX_LIGHTS, >>>>>> but since each object is lit only by one light, using opengl we >>>>>> could >>>>>> render the entire scene using >>>>>> only one hardware light (lets say GL_LIGHT0), by resetting its >>>>>> parameters per object. >>>>>> >>>>>> In the general case we can have more than one light per object and >>>>>> the >>>>>> lights can be >>>>>> turned on and off per frame. So, what is the best way to do this >>>>>> in OSG? >>>>>> >>>>>> I've tried passing the stateset of the sub-tree I want to light on a >>>>>> lighsource node using: >>>>>> lightsource->setStateSetModes(stateset,osg::StateAttribute::ON); >>>>>> but it doesn't work as expected. >>>>>> >>>>>> Also I've tried changing the stateset of the sub-tree I want to >>>>>> light >>>>>> directly, >>>>>> without using any lighsource nodes: >>>>>> stateset->setAttributeAndModes(light, osg::StateAttribute::ON); >>>>>> stateset->setMode( GL_LIGHT0 + num, osg::StateAttribute::ON ); >>>>>> to enable a light and >>>>>> stateset->setAttributeAndModes(light, osg::StateAttribute::OFF); >>>>>> to remove it. >>>>>> >>>>>> The last method seems to work when the number of lights is >>>>>> constant per >>>>>> frame, >>>>>> but it brakes when I try to dynamically turn on and off lights per >>>>>> frame. (perhaps >>>>>> because I have to manually enable/disable the corresponding opengl >>>>>> lights?) >>>>>> >>>>>> So, what is the best way to do this in OSG? >>>>>> >>>>>> Thanks in advance >>>>>> >>>>>> Pavlos Mavridis >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> osg-users mailing list >>>> [email protected] >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >>> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
