Hi Gary,

I am quite sure that FSX uses the WGS84 elipsoid with the geoid and not just a sphere simplification.

When making ground polygons I noticed that the formula's used in FS2004 to calculate the distance from the reference point of a lat/lon position no longer work well. While in FS2004 these formulas resulted in perfect aligned polygons, also when these polygons had different reference points, in FSX there was always a gap between them.

After I implemented the WGS84 geocentric coordinates with the geoid height, my polygons are exactly aligned again. So I am quite sure that is the system they used.

It has also been confirmed to me by one of the ACES team members btw.

Thanks Arno, for that clarification

__and__ for all your work implementing initial and updated earth curvature corrections to placement of

*Ground Polygons* in FSX.

* Would one infer then, from use of FSX BGLComp for export of FSX MDLs by MCX with accompanying XML placement BGLs, that placement coordinates of

__individual__ objects

**othe**r than Ground Polygons ...is being compiled into BGLs (via BGLComp) with "proper" alignment to correct for the Earth curvature of the FSX 3D world model ?

* And if so, when "Batch Mode" processing for export of FSX MDLs from MCX with accompanying XML placement BGLs is used, would one infer that placement coordinates of

__groups__ of Batch Mode processed objects

**other** than Ground Polygons ...is being compiled into BGLs (via BGLComp) with "proper" alignment to correct for the Earth curvature of the FSX 3D world model ?

* And if the answer to both of the above is Yes, is the resulting placement coordinates aligned properly to the FSX 3D world because of coordinates being 'pre-processed' by MCX before they are sent to BGLComp ?

* ...Or does direct use of BGLComp by a 3rd party means

*other* than MCX

__also__ yield accurate XML placement in the FSX 3D world (assuming the placement data is pre-processed by a FS developer for a Geographic Lat-Lon projection / WGS84 Datum destination environment) ?

[

**EDITED**]

Uh-oh, yet another question comes to mind after once again reviewing Adam Szofran's treatise on how the FS scenery terrain engine works:

http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx
"

*The conversion from latitude, longitude, and altitude above sea-level to geocentric Cartesian coordinates is relatively straightforward using equation 4-14 from the WGS 84 specification:*

Where:

a = 6378137.0 meters (Earth's equatorial radius)

b = 6356752.3142 meters (Earth's polar radius)

e = 8.1819190842622 x 10-2 (ellipsoid eccentricity)

The equations must be evaluated using 64-bit floating point to prevent a loss of precision. The seven significant digits of 32-bit floats aren't enough to represent a point with better than sub meter accuracy. Since the rendering pipeline (Direct3D in this case) uses 32-bit floats, the final coordinates used for rendering must be converted to 32-bit offsets from a 64-bit local origin no more than several thousand meters away."

* In your opinion, does this info not compel use of more decimal points of precision in scenery object placement source code when requesting specific locations as a destination for placed objects from

__ex__: BGLComp ?

__BTW__: Whereas Google Earth (which uses a somewhat comparable "spherical" 3D world engine to that of FS for rendering draped photo-real terrain textures and placement of 3D objects) ...previously used 14 decimal places in KML code, now instances of 16, 18, and even 21 decimal place numbers can be seen in captured KML output.

* If one were to use such high precision coordinates in source code for FS scenery, would BGLComp and/or the FS rendering engine behave differently by enabling / displaying placed objects with greater accuracy, and in greater compliance with an intended 'oblate spheroid' 3D world model destination ?

[

**END_EDIT**]

__Knowing that you have an extensive familiarity with SCASM, may I ask one other question of your expertise__:

* Would it be reasonable to assume that since AFAIK, there has not been any apparent updates to the SCASM internal code base since FS2004, SCASM compilations of Geographic coordinates into BGLs will

__not__ have implemented

__ANY__ earth curvature corrections to placement of either FS Effects, Scenery Library Objects, or Ground Polygons ...to accommodate use in FSX, and that a FS Developer must pre-process placement data to do such corrections

__outside__ of a SCASM compilation procedure ?

Sorry for so many questions arising in the context of this thread; thanks in advance for your additional clarification on these, IMHO, pertinent considerations.

GaryGB