Hi Terry,
Not much progress here. I was using the following completely
unconventional and undocumented way to set up a light that affects only
one particular node of the scenegraph:
osg::ref_ptr<osg::Light> light = new osg::Light();
int num = lightManager->allocate(); //get an unused opengl light slot
light->setLightNum(num);
.... //set misc light parameters (position, ambient, diffuse ...)
//node is the osg::Node that I want to apply the light on
osg::StateSet* stateset = node->getOrCreateStateSet();
stateset->setAttributeAndModes(light.get(),
osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE);
The above code works very well when each object has the same number of
"local" lights affecting it (which in your case is always true, if I'm
not mistaken). But i recently discovered that I'm getting wrong lighting
when the number of local lights varies per object, or if I also use
normal osg::LightSources in my scene. I'm not sure why the above
approach does not always work, I'll be glad if someone explained this to me.
As for the renderstages, to my understanding it's a mechanism to do
multipass rendering in osg. Robert suggested to render each object on a
different pass/renderstage with the appropriate lights enabled on each
pass. But i have yet to figure out the exact way to do it with osg. The
only relative example i could find is the depthpartinion one, but it
does not help much . Note that this is a completely different way than
your shader based approach.
In the end I will probably implement a shader based approach, much like
yours. But in the meantime I'm busy with some other aspects of our engine.
Pavlos
Terry Welsh wrote:
> I made some pretty good progress with selective lighting. How about
> you, Pavlos? Right now I have a class that stores all my light
> world-space positions, colors, and attenuation ranges (I'm only doing
> simple point lights for now). On any node where I want to apply
> lighting I set a CullCallback and all the lighting Uniforms necessary
> for 3 lights. The callback retrieves the node's bounding sphere and
> uses it to decide which, if any, lights have the most influence on the
> node. Then those lights' parameters are assigned to the node's
> Uniforms. If there are less than 3 lights that have influence, then
> black is assigned to some of the light color Uniforms so they won't
> affect the final image.
>
> Currently, this only works for nodes that have no transforms above
> them. But I believe I can use the NodePath in the NodeVisitor passed
> to the callback to get all the transformation information I need.
> Then I can transform the BoundingSphere before using it to calculate
> light influences.
>
> A bigger concern is that I'm doing all my light computations in
> world-space in my shader. It's usually faster to do lighting
> computations in view-space (this is how native OpenGL does them). If
> I was only rendering one view, I could set a view matrix before doing
> my culling and use it to transform all my light positions to view
> space before sending them to my shader. Unfortunately, I want to
> render multiple views, so my Uniforms would have to get updated with a
> different view matrix for each view that is drawn. I'm still trying
> to figure out if everything Robert said about RenderStages can help
> here, but I'm not sure yet.
>
> Another alternative is to use a DrawCallback instead of a
> CullCallback, but then I could only apply it to Drawables. For my app
> this would mean running the callback many more times than if I use a
> CullCallback and assign it to fewer locations higher in my scene
> graph.
> - Terry
>
>
>> Message: 11
>> Date: Thu, 3 Jan 2008 11:29:11 +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 Pavalos,
>>
>> On Jan 3, 2008 10:54 AM, Pavlos Mavridis <[EMAIL PROTECTED]> wrote:
>>
>>> 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.
>>>
>> I think perhaps we should have an osg example that illustrates how to
>> set things up, it should only take a few dozen lines of code to
>> support, but the trick is knowing which lines of code you need...
>>
>> As a general note, the rendering back end of the OSG is its probably
>> its most complex part, the complexity comes from its flexibility.
>> Typically one doesn't need to worry too much about the rendering back
>> end, its just does it stuff behind the scenes, just occasionally one
>> needs cross the line and actually need to know specifics and control
>> things are a finer grained level, when you cross this line the
>> learning curve does unfortunately shoot up.
>>
>> Robert.
>>
>>
> _______________________________________________
> 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
