Quick Question - Airport Design

#1
I have a quick question for when people are developing airports and airport polygons in 3DS.

When you import imagery as a ground polygon (either for reference or use) in 3DS/GMAX are you using WGS84 imagery?
 
#3
Perhaps Arno or Rhumbaflappy may wish to correct me on this in the event that I have somehow mis-interpreted something about Ground Polygons (aka "G-Polys") being a type of 3D scenery object. ;)

IIUC, G-Polys are compiled with the FS2002 (aka "FS8") SDK as 3D 'models' (and not "MDLs" in the same sense as structured and used in FS9 / FSX / P3D et seq.), and are "flat", thus appearing as 2D planar objects).


AFAIK, 3D scenery objects are "ready to display" when placed and rendered in the MSFS 3D world, and are NOT intended to be locally "warped" at run time by the FS terrain rendering sub-system to fit onto quad tiles that vary by size and shape at specific locations on the MSFS 3D world "spheroid".


G-Polys, as types of 3D scenery objects, are NOT intended to be locally "warped" at run time by the FS terrain rendering sub-system to fit onto quad tiles that vary by size and shape at specific locations on the MSFS 3D world "spheroid".


Thus, G-Poly objects should IMHO, be created and textured etc. using ex: aerial imagery which has been "projected" (in ex: Global Mapper) with these parameters:

Projection: Mercator
Datum: Google Maps (Sphere Radius 6378137 Meters)

Prime Meridian Degrees: 0
Ellipsoid Spheroid Selection: Sphere Radius 6378137 Meters
Datum Transformation Method: 3-parameter (Molodensky) Transformation

Shifts to WGS84 (Meters)
X-Shift: 0
Y-Shift: 0
Z-Shift: 0

Planar Units: Meters
Scale Factor: 1
Central Meridian: 0
True Scale Latitude: 0
False Easting (Meters): 0
False Northing (Meters): 0

...or:

Projection: Universal Transverse Mercator (aka "UTM")
Zone: (varies by local geographic coordinates)
Datum: Google Maps (Sphere Radius 673813)
Planar Units: Meters
Central Meridian Scale Factor: (varies by local geographic coordinates)
Central Meridian: (varies by local geographic coordinates)
Origin Latitude: (varies by local geographic coordinates)
False Easting (meters): (varies by local geographic coordinates)
False Northing (meters): (varies by local geographic coordinates)


...or as older versions of ESRI GIS applications used to call such projections: "Flat Earth".


Additionally, perhaps Scruffyduck or one of the 'ADE team' may wish to correct me on this in the event that I have somehow mis-interpreted something about airport "objects" (to include airport RWYs, Taxiways, Aprons) being processed at run time as special types of textured 3D scenery objects, and in the case of RWYS, actually having a built-in MDL ...with a attached "flatten" and/or "platform" attribute.


BGLComp XML airport "objects" (to include airport RWYs, Taxiways, Aprons) are processed at run time as special types of '3D scenery objects', and are NOT intended to be locally "warped" at run time by the FS terrain rendering sub-system to fit onto quad tiles that vary by size and shape at specific locations on the MSFS 3D world "spheroid".


IIUC, BGLComp XML airport "objects" (to include airport RWYs, Taxiways, Aprons) should be traced / created using background ex: aerial imagery which has been "projected" (in ex: Global Mapper) ...with the same "non-warped" GIS parameters as cited above for G-Polys.




SHP2VEC Terrain Vector "objects" and Resample terrain mesh or photo-real imagery rendered within the QMID grid, however, ARE intended to be locally "warped" when displayed at run time by the FS terrain rendering sub-system to fit onto quad tiles that vary by size and shape at specific locations on the MSFS 3D world "spheroid"; as such the SDK requires that source data input formats for these objects must be "projected" (in ex: Global Mapper) with these parameters:

Projection: Geographic (Latitude/Longitude)
Datum: WGS84
Planar Units: Arc Degrees
Central Longitude: 0



Hope this helps ! :)

GaryGB
 
Last edited:
#5
He was referring to the imagery to be placed onto the tiles, which needs to be WGS84, not the 3d tiles themselves. That was probably the most verbose reply possible.
 
#6
He was referring to the imagery to be placed onto the tiles, which needs to be WGS84, not the 3d tiles themselves. That was probably the most verbose reply possible.
Actually, I'm confident that with a bit of encouragement, I could have made that post even more detailed ! :D

But it's true that I do tend to address 'certain' topics in more detail when I believe that there has been a longstanding "under-documentation", or where there has been what appears to be conflicting information; ...or worse yet, when there has been what IMHO, might reasonably be interpreted as obfuscation of information regarding FS development procedures. :pushpin:

Thus when I reply to threads (as explained elsewhere on more than one occasion), I sometimes do so in a way which I hope will benefit other newcomers in the would-be FS development community ...as well as the OP that originally poses a question. :idea:

And I believe you can see that the "WGS84" info I posted in good faith (with an invitation to renowned experts such as cited above to 'correct me if I'm wrong' in my interpretation of the subjects under discussion), asserts that WGS84 is not intended to be the projection used for 3D modeling, and that G-Polys, as a type of 3D model, are not intended to be created using textures projected in WGS84. ;)

And again, I both invite and encourage discussion here by others, with presentation of additional viewpoints and rationales (even those with substantial distinctions from those I posted) on this topic. :)


PS: Having been involved with the FS Community for many years, and subsequently knowing that Dean Mountford (aka "=Hollywood=") uses Global Mapper extensively, I believe the 'extra' projection detail offered might be quite specific to his inquiry, and even 'individually' helpful too ! :twocents:


Oh, and I almost forgot to mention this... the G-Poly creation is even more complex than I alluded to above. :duck:

G-Polys must match the shape and size of tiles in the local QMID grid (especially for larger airport areas); therefore, if seeking optimal compatibility with the MSFS rendering system, one cannot simply cut a 3D rectangle into segments of equal sizes and shapes ...and texture them with WGS84 projected imagery.

GaryGB
 
Last edited:
#7
Actually, I'm confident that with a bit of encouragement, I could have made that post even more detailed ! :D
G-Polys, as a type of 3D model, are not intended to be created using textures projected in WGS84. ;)
GaryGB
therefore one cannot simply cut a 3D rectangle into segments of equal sizes and shapes ...and texture them with WGS84 projected imagery.

GaryGB
Well I have been doing so, with ever other developer that I am aware of, and as far as I can see it matches the underlying photo-scenery accurate to the inch even on my current airport which is about 4km across.

Now of course I'm sure there are more complicated ways of doing it with non projected images. But this method works absolutely fine, and is what everyone uses.

If you have a better way, why not describe how to match the tiles with this QMID grid and texture the locally projected imagery onto it?
 
Last edited:
#8
Well I have been doing so, with ever other developer that I am aware of, and as far as I can see it matches the underlying photo-scenery accurate to the inch even on my current airport which is about 4km across.

Now of course I'm sure there are more complicated ways of doing it with non projected images. But this method works absolutely fine, and is what everyone uses.

If you have a better way, why not describe how to match the tiles with this QMID grid and texture the locally projected imagery onto it?
MSFS scenery development is an open (and ideally "level") 'playing' field of endeavor, subject to the personal preferences of anyone who wishes to create something and somehow get it displayed in FS at run time.

So I'm not certain that "a better way" would be a concept (or workflow) everyone would agree upon.

I do appreciate your 'encouragement' to devote an additional allocation of my limited available free time to create a (IMHO, "sufficiently") detailed and comprehensive tutorial as a 'worked example'.

To re-direct the line of inquiry where it may prove most helpful to "better" understanding of a topic, IMHO, each of us must engage in a thorough course of self-study (...with or without the assistance of a "study group" within the context of 1 or more ongoing threads, and regardless of the chronological "age" of those threads).

I would "encourage" all readers here to challenge current 'working assumptions on workflow', and to seek their own answers via a diligent and thorough review of available information here at FSDeveloper and at other online locations hosting such information as may be pertinent to MSFS development.

I'd also 'encourage' openly discussing ideas and 'hypotheses' (aka "tentative assumptions") in a spirit which acknowledges that we are all engaged in an ongoing process of learning, and thus we may all potentially benefit from sharing of individual insight and suggestions with one another ...all of which might compel us to repeatedly re-consider one's 'preferred / tentative assumptions' in light of new info.

The are many learning resources available to be considered, but again my limited available free time must necessarily re-direct the inquirer to seek their own answers as recommended above.


Certainly there are references to be considered as a "minimum" for study material, ex: as cited in these documents / threads / posts: :idea:

https://msdn.microsoft.com/library/ff798293

http://go.microsoft.com/?linkid=8084323

https://msdn.microsoft.com/en-us/library/cc707102.aspx#AppendixI

http://www.fsdeveloper.com/wiki/index.php?title=Align_background_image_in_3D_editor

http://www.fsdeveloper.com/forum/threads/possible-solution-for-fsx-groundpoly.5094/page-2

http://www.fsdeveloper.com/forum/threads/fsx-earth-curvation-and-ground-polygons.19928/page-2

http://www.fsdeveloper.com/forum/threads/coordinate-systems-and-object-placement-issues.426110/

http://www.fsdeveloper.com/forum/threads/calculation-of-lat-lon-can-it-be-done.425018/

http://www.fsdeveloper.com/forum/threads/effects-in-wrong-place.77677/page-4

http://www.fsdeveloper.com/forum/th...porting-vector-data.432918/page-3#post-706407

http://www.fsdeveloper.com/forum/th...buildings-with-incorrect-orientations.430094/


References to compare "Spheroid" vs. purportedly "oblate" 3D world models and associated 'projections' in MSFS and online tile servers:

https://msdn.microsoft.com/en-us/library/cc707102.aspx#QMIDandLODValues

https://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/

https://en.wikipedia.org/wiki/Web_Mercator

https://msdn.microsoft.com/en-us/library/bb259689.aspx

https://msdn.microsoft.com/en-us/library/aa940990.aspx

https://developers.google.com/maps/documentation/javascript/maptypes?csw=1#MapCoordinates



PS: Note that Arno's Ground Polygon Wizard in ModelConverterX (aka "MCX") internally performs certain 're-projections' for the end user, and requires that ones imported source code should be 3D-modeled in alignment with imagery projected in "Flat Earth" (...or its 'non-warped' equivalent).


Hope this helps ! :)

GaryGB
 
Last edited:
#9
So basically we need a better and easier system :) hehehe Actually I'm dying to track down an old 3DS piece of software that could import geotiffs into it, seems it has disappeared. Existed back in 2006 but now seems to be no more :(

And Gary thanks you did answer my question exactly. The Geo WGS84 was an issue due to severe distortion near the poles which doesn't work for 3D modelling. :) Mercator makes more sense.
 
Last edited:
Top