Yes and no. Unfortunately in general physical simulation you don't have the luxury of culling away things that are not visible. So even for an airplane flying over vast areas, the visual part around the airplane can still be handled using float, and objects further away require less precision, but in simulations over the earth, you need to keep the simulations running in the same world most of the time, especially if there are constraints connected between objects miles and miles apart.
You need cm precision over tens of kilometers, that require the use of Double and having objects in the same coordinate system... For example off-shore wires anchoring ships and oil-rigs, they can have kilometers of wires, but on the ship/oil rig there are at the same time detailed simulations that require high detail. But, yes you dont want higher precision than required in the rendering due to memory footprint... In this case, it would have been handy to handle double for bounds though. I did a quick fix by using an inverse inside my custom rendering code to move the system to origo... /Anders On Tue, Mar 11, 2008 at 12:48 PM, Robert Osfield <[EMAIL PROTECTED]> wrote: > HI Anders, > > It isn't possible just to remap the Vec3 typedef from Vec3f to Vec3d, > as you have found the their are many places that explicitly rely on > floats. Places like BoundingBox and BoundingSphere could potentially > be moved across to use Vec3d rather than Vec3f, and the way to do this > would be to use a local vec_type typedef. This type of change is best > done locally, as has been done with other similar classes such as > Plane and LineSegment that now do this. > > General conversion to using double versions is a bad thing w.r.t > rendering, and general performance, not from double maths, but rather > memory footprint of double vector data and the inability of OpenGL > drivers/hardware to handle double data without converting to floats. > The thing to do is to keep all vertex data destined for OpenGL in > floats, and just keep high level scene graph objects in doubles where > required for precision. > > In the case of managing whole earth databases, almost all of the work > I have done in the past year has been in this area, here I use > MatrixTransform's to place geometry in a local coordinate frame into > its final ECEF coordinate frame. The OSG's Camera's view matrix is > all in doubles, and the cull traversal accumulates all matrices from > the camera right down to the geometry leaves in doubles so keep > precision for as long as possible. Only when the final matrices are > passed to OpenGL does precision get lost, but generally the errors are > subpixel by this stage thanks for the tiles local to the viewer having > a relatively small modelview matrix translation, and far tiles which > do have greater translation and hence high values and more error are > further away so the errors are relatively the same - still subpixel so > you don't see any jitter. > > You physics engine integration would be best to use the same approach, > keep local origins and transforms to place this in ECEF. > > Robert. > > > On Tue, Mar 11, 2008 at 11:11 AM, Anders Backman <[EMAIL PROTECTED]> > wrote: > > Hi all. > > > > Im +working in a project where we are rendering objects on Center of > Earth > > (ECC) so we have a z-coordinate of 6.7E6Meters. > > So obviously we need to transform objects close to origo to be able to > > render them. > > > > I noticed that I got quite a few anomalies in the rendering, > > flickering/jumping objects. > > > > This probably comes from that I do some custom OpenGL rendering in a > > Drawable, where I update the bounding box of the drawable. > > > > In this update of the bounding box, I have the large translation built > in, > > so the BoundingBox will contain the 6.7E6 coordinates and this obvious > > affects the resolution of the float used everywhere in BoundingBox > > calculations... > > > > > > So I wanted to use double for this, but this caused quite a lot of > problems > > during build because its more or less hardcoded that Vec3f is default: > > > > To avoid this, I would have to apply this translation above the > Drawable, > > instead of sending the matrix to my custom drawable (where I do > > glMultMatrix()). > > Now as this transformation is a result of a Physical simulation (in the > ECC > > coordinate space) its not that trivial to get to the result I want, it > would > > more or less require me to get the transformation for each simulated > object > > and multiply with the inverse before sending it to the rendering. This > is of > > course possible, but I was wondering if it would be possible to switch > to > > Vec3d implementation of Vec3 using for example a flag in CMake? > > > > I guess all the Vec3Array etc, is still depending on Vec3f for OpenGL > > compatibility so in theory it would be possible. > > But in BoundingBox for example float is used explicitly for > > getMin()/getMax() etc.. > > > > Here is the beginning of the list of compilation errors I got when I > tried > > to change Vec3 to Vec3d (in the Vec3 header file): > > > > > > > 2>C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/Array(458) > > : error C2535: 'void osg::ValueVisitor::apply(osg::Vec3 &)' : member > > function already defined or declared > > 2> > > > C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/Array(444) : > > see declaration of 'osg::ValueVisitor::apply' > > > 2>C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/Array(492) > > : error C2535: 'void osg::ConstValueVisitor::apply(const osg::Vec3 &)' : > > member function already defined or declared > > 2> > > > C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/Array(480) : > > see declaration of 'osg::ConstValueVisitor::apply' > > > 2>C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(82) > > : error C2440: 'return' : cannot convert from 'osg::Vec3d::value_type' > to > > 'float &' > > > > > 2>C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(85) > > : error C2440: 'return' : cannot convert from 'osg::Vec3d::value_type' > to > > 'float &' > > > 2>C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(88) > > : error C2440: 'return' : cannot convert from 'osg::Vec3d::value_type' > to > > 'float &' > > > > > 2>C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(91) > > : error C2440: 'return' : cannot convert from 'osg::Vec3d::value_type' > to > > 'float &' > > > 2>C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(94) > > : error C2440: 'return' : cannot convert from 'osg::Vec3d::value_type' > to > > 'float &' > > > > > 2>C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/BoundingBox(97) > > : error C2440: 'return' : cannot convert from 'osg::Vec3d::value_type' > to > > 'float &' > > > 2>C:\projects\algoryx\agx_dependencies\OpenSceneGraph\include\osg/Plane(222) > > : error C2535: 'int osg::Plane::intersect(const std::vector<_Ty> &) > const' : > > member function already defined or declared > > ... > > > > > > > > -- > > > > > > ________________________________________________________________ > > Anders Backman Email: [EMAIL PROTECTED] > > HPC2N/VRlab Phone: +46 (0)90-786 9936 > > Umea university Cellular: +46 (0)70-392 64 67 > > S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 > > > > http://www.cs.umu.se/~andersb<http://www.cs.umu.se/%7Eandersb> > > _______________________________________________ > > 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 > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- ________________________________________________________________ Anders Backman Email: [EMAIL PROTECTED] HPC2N/VRlab Phone: +46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
