Allen Bierbaum
Thu, 08 May 2008 15:20:36 -0700
Dirk Reiners 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? We never really solved it fully. We started down the path of adding double precision transforms and internals to OpenSG, but it exceeded our capabilities. The big hang up was actually getting the matrix class refactored to handle both float and double precision calculations. We fixed the jittering by keeping the camera fixed and moving the world around the camera, but there are still precision issues in many places of the code. We are still very very interested in it though. If anyone else is interested in adding this to 2.0, we would be more then happy to give you any code we have around and tell you about the issues we ran into. > >> 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. We are still very interested in getting this working. I don't know what the "correct" solution may be, but I am willing to talk about it on the list and see if we could come up with something. One idea we threw around initially was to make it possible to change the "Real" type use by OpenSG at compile time and make sure to use that any place where precision matters. This would then allow the user to select their precision at compile time and only pay the performance cost if they really needed the extra precision. I am not sure if this would work well or not, any thoughts? > >> 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). We are using something like this, but the problem that we run into is that we have multiple tiles that border each other. So when those tiles are handed off to OpenSG for rendering they don't quite match up at the borders and thus the vertex transformations end up off a bit. Then again, maybe I am misunderstanding your idea. What we do is have planet tiles. Each tile has locale vertex data for that tile on the surface of the planet. Then there is one transform core for each tile that positions the tile relative to the center of the planet. The center of the planet is then positioned relative to a fixed camera position. So the float precision kills us when rendering because all verts run through a transform of the combination of two floating point matrices. At least I think that is what is killing us. :) -Allen > > 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