RE: [Flightgear-devel] Coordinates fact check
Curtis L. Olson writes: Jon S Berndt writes: Curtis L. Olson wrote: Andy Ross writes: and the code to calculate the scenery center for each tile can simply go away. This however isn't true. You still need to have an 'origin' for each scenery tile so you know how to translate it relative to your scenery center point (now perhaps they eye.) The scenery center point defines our (0,0,0) for our world as opengl sees it. If this point is always coincident with the eye point, then we would have to continually be reshifting each of the scenery tile transforms. I don't know if this applies at all, but it worries me to hear what Andy wrote about the code going away. Will this have any impact on the ability to calculate the location, height, and orientation of an aircraft on a tile given the tile may have a non-vertical normal? This stuff sounds like a candidate for a branch in the code... Ahhh, Jon, that's a good point. If we make changes that affect the scenery center and all the terrain transforms we definitely will need to make sure that we don't break the line/terrain intersection code. I think all that is needed is the transform that will take the points returned by the line/terrain intersection code to where they would have been if we were using the original VIEW transform and still doing the individual 'preptile()' translates before making the sgGeocToGeod() call inside fgCurrentElev(). However exactly what this transform 'will be' I am not sure of FWIW Studying Dave's profiling statistics leads me to believe that resetting all the transforms with in the SceneGraph, what we essentially end up doing when we translate all the individual tiles in tilemgr::prep_tiles is in the neigborhood of ~2% of the total time taken per frame. So even if we had to do this twice, once for terrain intersection and once for rendering it wouldn't be catastrophic and may be a cheap enough price to pay, if needed, for the cleaner 'VIEW' Cheers Norman _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinates fact check
Andy Ross wrote:
Model coordinates (that is, the reference frame of the local aircraft,
into which the model and panel geometry will be drawn):
Origin = nose of the aircraft (?)
X = backwards
Y = up
Z = left
First confusion: the /sim/view/pilot/{x,y,z}-offset properties don't
use this system. They use (I think, at least this is what YASim
exports and it seems to work):
X = back
Y = right
Z = up
I got the original numbers by looking at the dc3-dpm.ac model file.
Can someone tell me where the mixup is? Does the ac3d model loader
change coordinates, perhaps?
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinates fact check
Norman Vine wrote: Andy Ross wrote: The location of the scenery origin is another. I thought I that this would have been self evident apon reading the code sections I pointed out yesterday. But just to be clear THERE IS NO FIXED SCENERY ORIGIN Norman, stop it. The world may be full of idiots, but I am not one of them. I'm fully aware of the problem with using floats for global coordinates. Which begs the question (posed above, and still unanswered): what *is* the location of the scenery origin when the tile is drawn? Where does it come from? What must it be set to? Since it cannot be the center of the earth, it must be somewhere else; where? The code that does this can be just thought of as a 'black box' as it is all handled for you transparently and is made available as scenery.get_center() Why do we consistently go in circles on this? It (where it means everything rendered under the modelview matrix, including the scenery tiles) is certainly not a black box, since it requires modifications. To do those modifications, I need to figure out how it works. To figure it out, I ask questions. To answer my questions, you tell me that I don't need to know how it works? Regardless, I think I've got this one now. Thanks for your (not terribly polite, but helpful nonetheless) assistance. The scenery center is set out of the main loop, and looks to me like it can be easily replaced with the eyepoint with no loss of function. This has two nice side effects: the view matrix generation is no longer dependant on data stored in scenery tiles, and the code to calculate the scenery center for each tile can simply go away. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Coordinates fact check
Andy Ross writes:
Norman Vine wrote:
Andy Ross wrote:
The location of the scenery origin is another.
I thought I that this would have been self evident apon reading the
code sections I pointed out yesterday.
But just to be clear
THERE IS NO FIXED SCENERY ORIGIN
Norman, stop it.
Whoa there ..
Obviously we have a hard time communicating but I don't
understand how I could have been any clearer then what
I posted yesterday
Hence my somewhat glib answer today.
Please enlighten me has to how I could have been
more helpful
Cheers
== below snipped from yesterdays post ===
and see -
main.cxx
void fgRenderFrame( void ) {
// calculate our current position in cartesian space
scenery.set_center( scenery.get_next_center() );
}
int FGTileMgr::update( double lon, double lat ) {
if ( tile_cache.exists( current_bucket ) ) {
current_tile = tile_cache.get_tile( current_bucket );
scenery.set_next_center( current_tile-center );
} else {
SG_LOG( SG_TERRAIN, SG_WARN, Tile not found (Ok if
initializing) );
scenery.set_next_center( Point3D(0.0) );
}
...
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinates fact check
Andy Ross writes: Which begs the question (posed above, and still unanswered): what *is* the location of the scenery origin when the tile is drawn? Where does it come from? What must it be set to? Since it cannot be the center of the earth, it must be somewhere else; where? It wouldn't necessarily have to be this way, but for historical reasons, the 'origin' of the tile is defined at the time that the tile is created. This way we can find a point that is 'most' central to that tile for some definition of 'most'. It would probably work just fine to pick the actual center lon/lat of the tile and zero elevation for the tile center, but again, historically that's not how we did it. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinates fact check
Andy Ross writes: The scenery center is set out of the main loop, and looks to me like it can be easily replaced with the eyepoint with no loss of function. This has two nice side effects: the view matrix generation is no longer dependant on data stored in scenery tiles, and the code to calculate the scenery center for each tile can simply go away. That sounds like an excellent idea. Are there any hidden gotchas? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinates fact check
Jon S Berndt writes: On Wed, 13 Mar 2002 16:46:17 -0600 (CST) Curtis L. Olson [EMAIL PROTECTED] wrote: Andy Ross writes: and the code to calculate the scenery center for each tile can simply go away. This however isn't true. You still need to have an 'origin' for each scenery tile so you know how to translate it relative to your scenery center point (now perhaps they eye.) The scenery center point defines our (0,0,0) for our world as opengl sees it. If this point is always coincident with the eye point, then we would have to continually be reshifting each of the scenery tile transforms. I don't know if this applies at all, but it worries me to hear what Andy wrote about the code going away. Will this have any impact on the ability to calculate the location, height, and orientation of an aircraft on a tile given the tile may have a non-vertical normal? This stuff sounds like a candidate for a branch in the code... Ahhh, Jon, that's a good point. If we make changes that affect the scenery center and all the terrain transforms we definitely will need to make sure that we don't break the line/terrain intersection code. That's a chunk of code that I definitely don't have my head around and am not excited about the prospects of needing to figure it out. However, scenery center is currently designed to be changed to arbitrary values to moving it to the eye point might not hurt anything. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinates fact check
David Megginson wrote: Andy Ross writes: The scenery center is set out of the main loop, and looks to me like it can be easily replaced with the eyepoint with no loss of function. That sounds like an excellent idea. Are there any hidden gotchas? None yet. Code that doesn't exist can't have bugs. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinates fact check
Jon S. Berndt wrote: I don't know if this applies at all, but it worries me to hear what Andy wrote about the code going away. Will this have any impact on the ability to calculate the location, height, and orientation of an aircraft on a tile given the tile may have a non-vertical normal? Really, this is just changing the place where we do addition. Right now, (someone correct me if I've goofed something up) the tile renders all the vertices on all the tiles relative to the centroid of one of them, and expects the view code to put the origin at that centroid. My proposition has the view code placing the origin at the eyepoint (about which it must know something) instead of the tile centroid (about which it can be clueless), and the tile renderer doing the appropriate magic to move the origin based on the eyepoint exported by the view code. That way, the tile renderer depends on the view code (it has to, if you think about it), but the view code can live completely independant of the tile renderer. And the normal will always be vertical, at least for some point on the tile. Actually, this is another spot where I think we can slice the view code apart from the tile renderer. Right now, the tile renderer gets its up vector as the local up vector for the aircraft. But why not just cache an up vector at the tile centroid instead? All locations on the tile have a valid up vector, that's just a normal property of being, er, uh, a place on earth. :) You could even argue that this is more correct if we start rendering far-off tiles. A tile 60nm away should have an up vector off by 1 degree from the aircraft's, for example. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinates fact check
Andy Ross writes: Good point, I overstated. The code to compute an exact center is not longer an issue (any vertex on the tile will do) but clearly it has to be stored somewhere. Still, getting it out of the way of the view code can't do anything but help modularity. Right, but at some point we have to convert from earth centered cartesian coordinates into local tile centered cartesian coordinates so that we can place the opengl view in the correct place relative to the scenery. view_pos = world_pos - current_scenery_center I think this is OK, no? The vertices are stored as a big float table inside the tile, relative to the (global, double-valued) centroid location. Just push a tile-centroid-to-viewpoint offset matrix onto the stack before rendering each tile, and things should work. I may have missed something, but this sounds right to me. It's basically the same operation that happens already, but done inside the tile relative to the viewpoint, rather than in the view code relative to the tile centroid. You say potato, I say... Yah, pretty much ... too late for me to be splitting hairs here. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Coordinates fact check
Andy Ross writes:
While I'm thinking about it, can someone with knowlege please let me
know that I've got the right facts for the following coordinate systems:
What I'm fuzzier on is where
the origin is when the scenery tiles are drawn (it has to be local, as
floats don't have sufficient precision). I can probably figure it out
from reading the code, but yell if there are nasty subtleties here.
Reread my post from yesterday about how the VIEW is created
and see -
main.cxx
void fgRenderFrame( void ) {
// calculate our current position in cartesian space
scenery.set_center( scenery.get_next_center() );
}
int FGTileMgr::update( double lon, double lat ) {
if ( tile_cache.exists( current_bucket ) ) {
current_tile = tile_cache.get_tile( current_bucket );
scenery.set_next_center( current_tile-center );
} else {
SG_LOG( SG_TERRAIN, SG_WARN, Tile not found (Ok if
initializing) );
scenery.set_next_center( Point3D(0.0) );
}
...
}
void FGTileMgr::prep_ssg_nodes()
void FGTileEntry::prep_ssg_node( const Point3D p, float vis) {
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
