Hi Steve:
I only had time to view about 1/2 of your fascinating vido posted above, but I must say this is an interesting "worked example", with some very innovative methods used to work around the limitations of TMFViewer to view data.
Since IIUC, your goal is to achieve a more accurate way of inspecting how a 3D model of a "terrain object" fits into the surrounding ground surface (which is created by the FS terrain mesh
as interpreted and rendered by FS at run time, and subject to interactions of multiple terrain mesh, water, or land surface flatten files etc.), a few considerations merit mentioning:
* TMFViewer only reports geographic coordinates as 6-decimal place floating point numbers in the bottom status bar text area, so the data captured via OCR from the status bar display is limited as to its usefulness for purposes of only
low-resolution scenarios.
Although the FS SDK documentation has various (IMHO, inappropriately low-precision) examples using
ex: "decimal" Geographic Lat-Lon coordinates which have only 6-to-8 decimal place floating point numbers, in my experience, this is rarely sufficient to achieve the accuracy required in some aspects of scenery development.
IMHO, use of
13-decimal place Geographic Lat-Lon coordinates is the bare minimum necessary in some FS development situations to achieve even "reasonably accurate" precision with very high resolution GIS data interpretation / rendering ...such as when working with terrain mesh.
FYI:
*FS itself sometimes represents Geographic Lat-Lon coordinates in saved *.FLT files with 14-to-16-decimal place numbers
* Examination of KML files used by Google Maps and/or Google Earth represent Geographic Lat-Lon coordinates by use of 16-decimal place numbers
* Examination of geo-referencing data files accompanying downloaded tiles of aerial imagery from Google Maps represent Geographic Lat-Lon coordinates by use of 16-decimal place numbers, (which, IIUC, reproduces the precision Google uses for "placement" data in their online 3D spheroid world model of the globe)
However, 3D modeling may also compel use of very small units of measure in some scenarios.
Thus, I would speculate that you may wish to consider this, as IIUC, you have a goal of creating a very high resolution 3D model of several "terrain landmarks" in Yosemite for your project.
IIUC, you want a more accurate 3D model of selected portions of the FS ground surface as a "interpretation" of the FS terrain mesh surface rendered at run time.
There is a more accurate way to read and log the ground elevation beneath one's user aircraft position in FS at run time, as I mentioned here:
http://forum.avsim.net/topic/340961-reverse-engineer-mesh-into-3d-format/
Possibly when you resume your project we may discuss this further in the event that you might wish to program a new utility (freeware to be shared with the FS development community) ...which is able to more accurately capture terrain surface elevation data from FS with greater precision, and in a format matching that of the FS Quad Matrix Grid for terrain mesh at various uer-specified LODs, .
PS: Perhaps this caveat might merit mentioning again, to pro-actively dissuade would-be posters of EULA / copyright objection "nonsense":
"
...one must note that terrain surface elevations logged by such a process would only be as interpreted and rendered by FS at run time, and subject to interactions of multiple terrain mesh, water, or land surface flatten files etc., and should not be construed as capable of precisely reproducing original source data used to create terrain mesh files."
GaryGB
