Aron Bierbaum
Thu, 08 May 2008 15:33:30 -0700
We have looked into solving this problem in the past by using double matrices for the render traversal. but like Dirk said we didn't want to change the entire code base to use double precision for all bounding volumes and frustum culling. After starting down this path we quickly realized that we would need to change OSG::Matrix to allow operations between different value types. So for example we could have the current traversal matrix as a OSG::Matrix4d and multiply by any normal OSG::Matrix4f transformations. This became a template nightmare that we didn't have the time to deal with. In order to get around the precision problems for the near term we did as Dirk suggested and used a floating origin. We found that floating point precision worked fairly well if we positioned our geometry tiles close to the camera so that the final model-view matrix handed off to OpenGL was fairly small. We are still running into issues because we use floating point OSG::Transforms to position the geometry tiles. This issue is becoming more and more critical and we will need to address it in the near future. So any help with finding a good solution would be much appreciated. After reading Dirks response, I am considering changing the way that we do things a little. Currently our scene graph looks like: Root -> Navigation[1] -> LandTile[1..n] Where both the navigation and each land tile have very large floating point values. Our current approach relies on the fact that the result of the Navigation * LandTile[n] will be a small floating point number. Instead of doing it this way we could introduce our own Transform core (LandTileTransform) that is still floating point. It could also contain a double precision 'global' position. Then we could run an additional traversal each time the camera moves, updateViewEnter(OSG::Matrixd navMatrix), that can do the high precision calculation, navMatrix * mGlobalPosition, and store it in the normal Transform core. Can you see anything wrong with this approach? -Aron [1] The inverse of the normal camera matrix. On Thu, May 8, 2008 at 8:53 AM, Dirk Reiners <[EMAIL PROTECTED]> wrote: > > Hi Thiago, > > Thiago Bastos wrote: >> Hi all, >> >> Our project has been using OpenSG 1.8 for eight months (thanks btw!). >> Everything was fine until now, when we finally got to create a really large >> scene, with objects at very different scales (say, a country-sized terrain, >> geological data, and buildings with small objects). >> >> Our coordinate system is in meters. The diameter of our scene's bounding box >> is now close to 10^7. Some objects are located very far from each other. >> >> The main problem we are experiencing is spatial jittering (and consequently, >> severe Z-fighting) due to the lack of precision in 32-bit floats. >> We also had problems with the default OpenSG navigators (probably due to a >> very large scene bbox), but that's secondary. We just can't find a good >> solution to the spatial jittering problem. > > I know the Infiscapes had the same problem, but I don't know how they solved > it. > Aron? Allen? > >> I've already done a decent amount of research. I also searched this list and >> found the wiki page http://opensg.vrsource.org/trac/wiki/HDI/HugeScenes - >> but it was not terribly helpful. > > Yeah, on your problem essentially it says: use offsets instead of absolute > positions. > >> It seems that our problem would be solved if we could use double-precision >> floats for the camera; or have a DoubleTransform somewhere in the >> scenegraph, and have the render traversal accumulate the matrices using >> double-precision. > > ...and do all the math related to that (bounding volumes, frustum culling, > box, > plane, line primitives etc.) in double precision, too. > >> For instance, this kind of support has been part of >> OpenSceneGraph for quite some time. > > Yeah, they have been dealing with these kinds of scenes much longer due to > their > flight sim background. > >> It seems you have already considered adding DoubleTransforms to OpenSG, but >> later the idea was dumped. >> I must ask: why? > > The problem is the cost. The transformations themselves are not too expensive, > but the bounding box and culling parts are used very often, and in many > different operations, so just switching them to double would have a noticeable > impact. So you can't just do that, you have to support both single and double > versions of everything, and have a semi-intelligent way to switch between > them. > In the end it seemed like a pretty serious amount of work, and only rather few > people were interested in it. As the page says we might revisit that for 2, > but > unless there is a fairly clear interest form the users it might not be all > that > high up in the priority list. > >> If you don't think DoubleTransforms are really important, >> do you know any other decent way to solve our precision problems? > > There's no trivial way to do it. However, if your system is built > intelligently > it's not all that hard. > > Most people that have these scenarios use some tiling mechanism (i.e. have > tiles > of geometry that are paged in and out instead of one gigantic scenegraph), > where > inside the tiles float precision is fine, and only the whole tile is moved > around with a high precision transform. If that's the case you can keep the > viewpoint yourself in double, and just update the tile matrices with the > difference of their real position and the viewpoint for every frame, > essentially > keeping the viewpoint fixed and moving the world underneath it. That way you > keep the precision where you need it (around the viewer), and you don't see it > where it's lost (far away). > > Hope it helps > > Dirk > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users