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 Tricarico<[email protected]> 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. Caldwell<[email protected]> 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/[email protected]/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 >> [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
