FYI > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Robert Osfield > Sent: Thursday, April 01, 2004 4:50 PM > To: [EMAIL PROTECTED] > Subject: [osg-user]Handling whole earth databases > > > Hi All, > > As I write this, my other machine is churning away generating a PagedLOD > database with about a billion polygons. Its only a chunk of the earth, but > its wide enough area to see the curvature of the earth clearly when you a > zoomed out. With such wide area models a number of issues arise, but first > I'd like to open out two of these issue for discuccsion : > > 1) management of near and far clipping planes as one moves for a distant > view of the the whole earth to a local view with objects visible within > a meter away from the viewer. > > 2) how to adjust the local up vector used in drive manipulators and flight > manipulators & physics models. > > I'd like feedback on the community on my own thoughts below, and any funky > suggestions that might save us all some time :-) > > -- > > My first thoughts on 1) near and far clipping are: > > We basically need to a class that takes as input of the current position in > world coordinates, and output a new near and far value, which all sounds > rather easy... except we need to have need formula for computing the near and > far from the current position, and a framework for attaching this class to > the scene graph, and for the cull traversal to be able to use this. > > As for the formula I have been thinking about having an ellipsode model for > computing the local height of the control point above the ellipsode and from > this compute the near and far value to use in some "magical" way. > > Another addition to this would be the automatic control of glFog (via > osg::Fog) to make the far distance gradually disappear before the actual far > plane cuts in. As you get lower and the far planes moves inward, so does the > fog so you never see a line of terrain disappearing into the clipping plane. > > The framework might be as simple as just a cull callback attached to a node > above the world with a reference to a Fog object which decorates the world. > Only once I get to implementing it will I know for sure. > > Thoughts? Have others done similar things before? Any ideas of your own? > > -- > > My first thoughts on 2) adjusting for a local up are: > > Up in our world is generally defined by us as away from the earth, or to be > more exact orthogonal to surface of the earth (ignore local gradients), or > perhaps better as the axis that gravity acts. Since objects most physical > models use gravity as part of the computation it seems to make sense to > create an local gravity vector. > > We are now back to having a class which takes as input a control position and > outputs a vector, with possibly the length of the vector the strength of > gravity which could neatly allow us to have a model for other planets. The > orientation of gravity vector could either just be modelled on sphere, or on > an ellipsode, or perhaps even allow for local variations in the gravitational > fields (this is the type of stuff that virtual functions were invented for:-) > > Once we have this class we are back to the issue of a framework for physics > models/manipulators accessing the local orientation. For osgGA and other > codes to be able to access this data we'll need a standard framework, most > probably in the core OSG itself otherwise the dependencies list will just > spiral away. osg::GravitationField anyone :-) > > -- > > So I'd love your feedback, is this stuff you've been thinking about before, > and have already tackled and solved? Does the above look promising, or fall > into any traps that need to be avoided. > > Cheers, > Robert. > > > _______________________________________________ > osg-user mailing list > [EMAIL PROTECTED] > http://dburns.dhs.org/mailman/listinfo/osg-user >
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
