Hi Robert,
Thanks again for getting SM started.
While playing around with the example, I noticed that if using
""--directionalLight", the code to re-calculate the RTT frustum would
not do it's job( lightpos[3] == 0.0), for now I included a small patch
to the example that cheats a bit by setting lightpos[3] = 1.0f in this case.
Cheers
Mihai
Robert Osfield wrote:
On 2/19/07, *Mihai Radu* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
The SVN version compiles & works very nice (Fedora 6).
Thanks for the feedback.
About the clipping for SM creation; if we could get the shadowers
clipped by the main view frustum, and then use the bounding box of
this for adjusting the SM camera, it would make a big improvement
for SM anti-aliasing. With the current method, adding in a
shadow-casting terrain makes the part of SM used close to the main
camera very small, therefore very jaggy.
To make ShadowMap and ShadowTexture more usable in real apps we have
implement better set up of the RTT cameras/shadow texture so that its
view dependent. The funding I have for osgShadow doesn't encompass
this though, its focused on ShadowVolume so this is where I'll be
spending my efforts so I'll have to come back to ShadowMap later.
In March I'll be doing some work on view dependent OverlayNode, and
this will require similiar view frustum constrained RTT set up, so
once I've written this we should be able to reuse the various utility
classes that I put together in ShadowMap and ShadowTexture.
On the subject of texturing control, for the simulation at work I
wrote a little "ShadingHelper", that applies shaders ( with
sources taken from lua config files), and applies them according
to an [enum] criteria to selected parts of our scene. Right now we
are distinguishing between regular 3D objects, particle systems
and text (this one has a NULL Program on it).
I think this is the beginning for more control for shading in osg,
it could be used to delegate the creation and storage of shading
programs and uniforms for the rest of the application. Then if
below a certain node there's a need for a specific program
something like this could be called:
ShadingHelper::setShadingProgram((osg::Node*)
i_node,ShadingHelper::ShadingProgramType::SHADOWED_TEXTURED);
for uniforms I can call something like this:
ShadingHelper::setShadingValue((osg::Node*) i_node,
(std::string)i_uniformName, <class T> value);
Some ideas on the things a general design should accomplish would
be very welcome.
I don't really have any ideas on this topic off the top of my head,
and certainly needs a clear head to think about so I'll have defer my
contributions on such topics till my working life settles down a bit
more .i.e less 12 hours days...
Robert.
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Index: ../examples/osgshadow/osgshadow.cpp
===================================================================
--- ../examples/osgshadow/osgshadow.cpp (revision 6239)
+++ ../examples/osgshadow/osgshadow.cpp (working copy)
@@ -567,7 +567,7 @@
}
else
{
- lightpos.set(0.5f,0.25f,0.8f,0.0f);
+ lightpos.set(0.5f,0.25f,10.8f,1.0f);
}
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
