Hi Zeiki, On 8 February 2013 06:56, Zeki Yugnak <zeki.yug...@gmail.com> wrote: > Hi Robert, > > I found the problem yesterday. You are right, the problem is regarding to > floating point usage. > > I am computing camera position using center of the object's BoundingSphere. > When I start debug whole code, I figure out that the BoundingSphere type is > floating point and "OSG_USE_FLOAT_BOUNDINGSPHERE" parameter is defined in > Config header file as default. So, Flicker problem is regarding to camera > position. The problem is gone after this parameter is undefined.
You shouldn't need to build the OSG with double BoudingSphere for GIS applications. FYI, the header file is written by the CMake so use ccmake/CMakeSetup to select the OSG_* build options you want and let it set the headers that need setting. > One more question is Why is osg::Vec3's type defined as a floating point? OpenGL hardware is built around floats so when you pass in vertex arrays they need to floats so it makes sense for the default Vec3 to be Vec3f rather than Vec3d. You can use Vec3d arrays with OpenGL but typically the driver will convert from doubles down to float and will be very very slow. The OSG avoids the precision issues that would occur normally with OpenGL and systems with large coordinate values that would be an issue with floats by using doubles in the Camera and internal Transform nodes, and during the cull traversal accumulates the projection and modelview matrices all in doubles maintaining the precisions as long as possible before it's passed to OpenGL where the driver typically casts down to floats. If you manage your Camera positioning and the database creation correctly you create a system that doesn't suffer from visible jitter as the precision issues are subpixel. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
