From owner-fgfs-devel@flightgear.org Thu May 20 08:36:54 1999 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["8912" "Thu" "20" "May" "1999" "08:35:37" "-0500" "Stephen J Baker" "sjbaker@hti.com" nil "210" "Re: [FGFS-Devel] Things to do list" "^From:" nil nil "5" nil nil nil nil nil] nil) Received: from mailhub.woodsoup.org (IDENT:root@anduin.physics.iastate.edu [129.186.82.1]) by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id IAA09534 for ; Thu, 20 May 1999 08:36:53 -0500 (CDT) Received: from majordom by mailhub.woodsoup.org with local (Exim 1.92 #1) for fgfs-devel-outgoing@flightgear.org id 10kSzs-0005Sv-00; Thu, 20 May 1999 08:36:28 -0500 Received: from sunmgr.hti.com ([130.210.206.69] helo=issun6.hti.com) by mailhub.woodsoup.org with esmtp (Exim 1.92 #1) for fgfs-devel@flightgear.org id 10kSzq-0005SX-00; Thu, 20 May 1999 08:36:26 -0500 Received: from issun5.hti.com ([130.210.202.3]) by issun6.hti.com (Netscape Messaging Server 3.6) with ESMTP id AAA3BC4 for ; Thu, 20 May 1999 08:35:55 -0500 Received: from samantha.bgm.link.com ([130.210.66.11]) by issun5.hti.com (Netscape Messaging Server 3.6) with SMTP id AAA3FBA for ; Thu, 20 May 1999 08:35:54 -0500 X-Sender: steve@samantha.bgm.link.com In-Reply-To: <14147.454.803438.762388@pinky.infoplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Reply-To: fgfs-devel@flightgear.org From: "Stephen J Baker" Sender: owner-fgfs-devel@flightgear.org To: fgfs-devel@flightgear.org Subject: Re: [FGFS-Devel] Things to do list Date: Thu, 20 May 1999 08:35:37 -0500 (CDT) On Wed, 19 May 1999, Curtis L. Olson wrote: > Flight Gear world coordinate system: > > (0, 0, 0) is at the center of the earth. Z is up through the north > pole, X is out through point where the zero meridian intersects the > equator (somewhere in africa). Y is out where the 90th meridian > intersects the equator (somewhere in the indian ocean.) Here's a > picture: > > http://www.flightgear.org/Docs/Scenery/CoordinateSystem/img8.gif > > However, using this coordinate system directly to render the scenery > in OpenGL leads to all sorts of precision problems. So, for actual > rendering in OpenGL, I use a coordinate system that is aligned exactly > the same, but is translated so that (0, 0, 0) is at the center of the > current tile's bounding sphere. This means that all the coordinates > I'm feeding to opengl are "near" (0, 0, 0) within a couple thousand > meters. But each tile must have a translation matrix pushed on the OpenGL stack before it is rendered - right? Does that translation operate: * Relative to ownship. * Relative to some arbitary origin (like the center of the 'current' tile) that moves periodically (eg when you cross a tile boundary). * Some other way. > My "embarrassing problem" is that I don't understand enough about ssg > to know if it could be made to mesh well with the current flight gear > coordinate system. Well, I think the problem of point features on the terrain is a different one from moving models like aircraft. For aircraft, we can have an SSG scene graph, with each aircraft model positioned under a ssgTransform node and an ssgSelector node. Something like this: o ssgRoot for all of our | moving models _________|_________ | | | | | o o o o o ssgSelector nodes | | | | | o o o o o ssgTransform nodes | | | | | cessna pitts C130 F16 747 Aircraft models loaded from disk. (It would be more complex if - for example - we wanted three 747's in the scenario - but wanted to use the same polygonal model for all three of them...still, it's not too bad) The ssgSelector nodes allow the planes to be turned on and off as needed in the scenario we are playing. The ssgTransform nodes let us position them relative to some arbitary origin. Each frame, we pick up the location of each model (Lat/Lon/Alt/ Heading/Pitch/Roll) from some FGFS data structure somewhere. We do a very quick and dirty check to see if it is within (say) 20 miles of the eyepoint (you can do that just be comparing lat/long with ownship lat/long using an approximate table to convert degrees longitude into meters depending on your latitude). If the aircraft is too far away, use it's ssgSelector node to turn it off - this saves the expense of a costly LLA->XYZ conversion and makes culling cheaper for SSG when there are a lot of aircraft in the managed scene. We need to pick a 'current local origin'. This could be the center of the nearest terrain tile, it could be a point vertically below the ownship at sea level...somewhere close by. If the aircraft is reasonably close, compute the location of the aircraft relative to the current local origin. This entails some double-precision math but it's not all that hard - and it boils down to a 'float' 4x4 matrix. I imagine the math for this is already there to compute the eyepoint transform for the ownship. Put that matrix into the ssgTransform node and turn on the ssgSelector for that plane. At some point (probably after the terrain is rendered) you tell SSG where the ownship is relative to the current local origin and cull and draw the SSG scene. All done. At present, the aircraft models have to be in AC3D format - because that's the only file loader. However, there is work in progress (check the PLIB mailing list for details) to produce a VRML-2 loader, which should make it possible for anyone to build or convert aircraft models using a variety of modelling tools. For now, I think there is at least one AC3D format plane model on the AC3D demo distribution that will allow us to get all the FGFS code up and running. > Thinking about ground objects for instance (buildings, radio towers, > etc.) Basically we'd need to be able to rotate these ssh objects so > that they are aligned with the up vector for where ever they are being > placed. This rotation matrix can be generated directly from the > object's latitude and longitude. There could be a separate SSG scene graph for each terrain tile. Placing an ssgTransform at the top of that scene graph would allow you to apply the same transform to all the features on the terrain tile as to the terrain itself. The objects beneath that transform could then be positioned on the tile using the same kinds of mechanisms that you use to create the terrain skin. I presume that you have some code to turn a lat/lon/alt/heading/pitch/roll into a matrix (I guess the ownship positioning code must need that). Using that routine to generate the location of objects on the skin (in your offline tools) would allow you to generate a terrain feature set from a pre-built library. So, you'd get this: In your source data: There is a power plant at lat=L1, lon=L2, heading=H In your tools you'll need to figure out the height of the terrain skin at (L1,L2) and use that resulting Lat/Lon/Alt/Heading/0/0 to compute (in double-precision) the transform needed to position that object relative to the center of the earth. Subtract the origin of the terrain tile from the translation part of that - and you have something that you can reduce to 'float' precision. Also offline, decide which of a standard set of pre-built "library" models best represents a power plant. In your output terrain tile file: There is an instance of object number 1234 at the location described by [4x4 matrix] relative to the terrain tile's local origin. There are four ways (I guess) we could do the next part: 1) We could use SSG to cull the entire scene (including terrain skin) - discarding your existing culling routines and creating new SSG nodes for your terrain skin. 2) We could build an SSG scene graph structure that has an ssgTransform for each terrain tile - but have that contain only the point features for that tile. You'd render your terrain with the existing code and then call SSG to cull and draw the point features. 3) We could build a separate SSG scene graph for each terrain tile and call the cull and draw routine for each tile only if the existing terrain tile passes the terrain cull test. 4) Don't use SSG, just extend the existing terrain renderer to do the point features. It seems to me that (2) is not very efficient since the culling process is happening twice for each terrain tile, once in the terrain renderer and again inside SSG. I'm not sure that SSG is mature enough to do (1) yet since it doesn't sort by material property yet. However, that is work that will ultimately need to be done anyway - so maybe we just live with the inefficiency for now. If SSG had existed before the existing terrain renderer had been written, we should certainly have gone this way. (3) is possible. It seems a little messy to have two sets of culling routines layered on top of each other - and I can concieve of a problem when a point feature object is on the very edge of a terrain tile...hanging just off the edge in fact...the terrain culling routines might discard the terrain tile - and hence the SSG scene graph would never be evaluated and the point feature would not be drawn - even though it might be partially on-screen. That would be a bad problem for hand-built airfields for example. (4) might well turn out to be easiest - but Curt would have to write loaders for VRML and other file formats and considerably change the existing terrain rendering code. That would be pretty wasteful and writing good VRML loaders would duplicate the work already being done for SSG. Evidently this requires more thought and discussion between Curt and myself. > Can ssg do these sorts of things? In principle. SSG can be changed if needed. It's my project and I'll do whatever it takes to make it useful. Whether I can do that to a schedule that suits FGFS is not certain. Steve Baker (817)619-2657 (Vox/Vox-Mail) Raytheon Systems Inc. (817)619-2466 (Fax) Work: sjbaker@hti.com http://www.hti.com Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1 -- Please visit the FGFS web page: http://www.flightgear.org For help on using this list (especially unsubscribing), send a message to "fgfs-devel-request@flightgear.org" with a single line of text: "help".