Pasquale,
Thanks for the quick reply. We are considering the use of cones as you
describe for things like solar/lunar eclipses, but we were hoping to use
osgShadow, especially when dealing with terrain and self-shadowing of
complex geometry.
I should have included the command line arguments I used to produce the
images in my email (although I embedded them in the image names):
--SingleThreaded --earth-centered --noUpdate --no-base-texture
Please, address me as D.J., since I refer to myself as D.J.
My given name is Darrell, but I reserve that name for formal situations.
Since the list is trying for a more friendly atmosphere, I am giving you
the name I use in *ALL* other situations: D.J. (which is an abbreviation
of Darrell Junior).
Thanks, again!
D.J.
On Tue, Jul 21, 2009 at 5:57 PM, Pasquale Tricaricotrica...@gmail.com wrote:
Hi D.J.,
(please use your name so we know how to address you)
I am in the same business as you, solar system simulations and such.
And I too use DPN happily, but not much experience with osgShadow. One
advice is to make sure you're running single thread with OSG, I think
it is a strong requirement of DPN so far, it might get better with
future. As for the eclipses, it's hard to model them correctly with
regular shadows, so I opted to just draw transparent cones (one for
the penumbra, one for the umbra) see i.e.:
http://orsa.sourceforge.net/screenshots/misc/eclipse.png
Cheers,
Pasquale
On Tue, Jul 21, 2009 at 2:30 PM, D.J. Caldwelldlcaldwel...@gmail.com wrote:
I am a developer for a program that visualizes large scale (solar
system) and small scale (desktop) scenes. We would like to be able to
visualize shadows in our scenes for things like solar/lunar eclipses,
and ground vehicles with headlights traveling over terrain in and out of
sun light.
We started using OpenSceneGraph around version 2.2 or 2.4. We are now
moving from version 2.6 to version 2.8. We have been using an
adaptation of the DepthPartitionNode from the osgdepthpartition example
to help with rendering since we often operate in a solar system scene,
with orbits, trajectories and lines of sight displayed as lines.
We also keep the camera positioned at the origin and move the scene
(by way of a transform) to help cut down on jitter in the near view
caused by floating point error.
The problem is...
While trying to make use of osgShadow, I have discovered apparent
interference between shadowing and the depth partition node (see two
images attached). It would seem that the depth partition node causes
the shadow to move with the camera viewing direction, rather than
staying with the light direction. In other words, moving the camera
causes the shadow to move in an unexpected and undesired manner.
My questions are...
Is there a way to get osgShadow and a depth partition node to play nice
together, or are they at odds by design? Is that, in fact, what I am
seeing, or have I set my test case up incorrectly? Perhaps there is
some other way to get the benefits of depth partitioning that will not
interfere with shadows?
I have searched the archives for discussion of using shadows with a
depth partition node, but I seem to be missing it (or it just isn't
there). I did find one reference
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg11218.html
which says to follow the source code. I looked under the hood for
ParallelSplitShadowMap, ShadowMap, and LightSpacePerspectiveShadowMap to
try to get a feel for how best to proceed, but I'm not seeing a clear
path to a solution which allows use of shadowing with a depth partition
node. I was hoping to avoid a custom solution, either that combines
the two, or maybe goes in a totally different direction, but my gut
reaction is that it may be unavoidable.
In addition to the images, I have also attached my test environment
source code, so that you can interact with the test environment which
produced the two attached images. The source code represents a
simplified model of our use of OSG in our program. I have it set up so
that, if --noUpdate is specified on the command line at run time, the
home position of the camera manipulator is set to show the problem I am
seeing. It may be easiest to see with --no-base-texture on the command
line (which is what I used for the images).
My development environment is currently:
OpenSceneGraph 2.8.1
Visual Studio 2005 Professional Edition SP1
Microsoft .NET Framework Version 2.0 SP2
Microsoft Windows XP Professional Service Pack 3 (win32)
NVIDIA GeForce Go 7950 GTX (nv4_disp.dll version 6.14.10.9422)
Thanks in advance!
D.J. Caldwell
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
