BGLViewer for FSX BGL files.

[Patrick Germain]

Updated version 1.0.1.4

- Fixed name label of the subsection 0x19
- Magnetic Variation is now in the range [-180 , 180] instead of [0, 360]
- PageUp/PageDn, End , Home, ArrowDn, ArrowUp are now operational in the right pane, provided that the mouse in positionned in that panel.

(Thanks to Hervé for the suggestions and bug reports)

 

[ollyau]

Thanks for the update!

Would you consider making your utility open source or providing a .NET library to read vector and/or airport BGL files? I'm sure it's possible to figure something out based on the information contributed to the wiki, but I'd appreciate not needing to reinvent the wheel if I don't have to.

 

[GaryGB]

Hi Patrick:

Your latter post immediately above compelled me to remember another "gotcha" that was discovered here some time ago which is related to RWY Headings requiring specific units for the expression of degree ranges, and IIUC, needing a minimum of 2-decimal places in the parameter value in the XML source code to avoid MSFS run time performance issues.


I see from the "BlgViewer.png" image posted above in your OP:

http://www.fsdeveloper.com/forum/attachments/blgviewer-png.20984/

...that your output table uses 2 decimal places for Heading, but I thought it might be best to check whether your intended output of viewed / extracted values in your BGL utilities would implement a "correct" (or better yet, a "corrected") format for Heading, which puts the Heading Degree units in a format which would not invoke performance issues even though the original stored RWY Heading value of a BGL might have been coded by the author of that airport BGL ..."incorrectly" to begin with.

[EDITED]

http://www.fsdeveloper.com/forum/threads/scasm-lights-kill-my-fps.21793/

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

[END_EDIT]


Hope you might be receptive to considering this.

"Also, since others here have previously discovered some quirky behavior when using integer (rather than floating point) and certain numeric value ranges in SCASM source code with degrees of "RWY Heading", might "Altitude" be yet another parameter where a floating point value (to a specified number of decimal places) needs to be utilized ...in one's parameter value units ? "

http://www.fsdeveloper.com/forum/threads/scasm-lights-kill-my-fps.21793/

http://www.scasm.de/doc/sca_s16.htm#mb

Thanks again for all the diligent work with your excellent utilities !

GaryGB

 

[GaryGB]

Oh, one more issue, Patrick:

I am new to the obscure innards of BGLs, but I must ask if the parameter syntax "IsAboveAGL" seen in your utility output ...is actually supposed to be worded as: "AltitudeIsAGL" ?

http://www.fsdeveloper.com/forum/attachments/blgviewer-png.20984/

http://www.fsdeveloper.com/wiki/index.php?title=BGL_File_Format#IsAboveAGL

https://msdn.microsoft.com/en-us/library/cc526978.aspx#XMLFormat


Hope this helps !

GaryGB

 

[Patrick Germain]

I am new to the obscure innards of BGLs, but I must ask if the parameter syntax "IsAboveAGL" seen in your utility output ...is actually supposed to be worded as: "AltitudeIsAGL" ?

Yes. It should be "altitudeIsAgl" since the 'above' is already in the 'A' of Agl

Your latter post immediately above compelled me to remember another "gotcha" that was discovered here some time ago which is related to RWY Headings requiring specific units for the expression of degree ranges, and IIUC, needing a minimum of 2-decimal places in the parameter value in the XML source code to avoid MSFS run time performance issues.

I also believe that heading/pich/bank value should not be displayed with decimals. Same thing for Altitude. I will remove that in the next version.

Thanks Gary

 

[Patrick Germain]

Thanks for the update!

Would you consider making your utility open source or providing a .NET library to read vector and/or airport BGL files? I'm sure it's possible to figure something out based on the information contributed to the wiki, but I'd appreciate not needing to reinvent the wheel if I don't have to.

That should be possible. That DLL already exists but, honestly, right now, I'm too lazy to write the API doc ! That will come though....

 

[GaryGB]

Yes. It should be "altitudeIsAgl" since the 'above' is already in the 'A' of Agl

I also believe that heading/pitch/bank value should not be displayed with decimals. Same thing for Altitude. I will remove that in the next version.

Thanks Gary

OOPS !

It looks like I may have made an editing error while copying / posting links above; I have now corrected the links in my post above at:

http://www.fsdeveloper.com/forum/threads/bglviewer-for-fsx-bgl-files.432840/page-3#post-709294

Sorry for any confusion this may have caused.



I believe that a further review might be helpful in considering the apparent conclusions to be drawn from this thread linked from my post above:

http://www.fsdeveloper.com/forum/threads/scasm-lights-kill-my-fps.21793/

...and the subsequent wiki apparently written by Gianni Mantellini (aka "thebeloved"):

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


FYI: I posted further on the important impact on FS run time performance the "Heading" variable may have ...depending on how it is interpreted, compiled, and stored within a BGL ...at another thread here:

http://www.fsdeveloper.com/forum/th...e-called-from-fs9-fsx-xml.431609/#post-709391


AFAIK, the conclusion arising within the above threads is that the intended parameter "value" for Heading must be submitted to the SCASM compiler as a floating point number (aka a "float" in programmers terminology).

The distinction between the required specifically-formatted, minimum (2)-decimal place floating point Heading parameter value source code submitted to the SCASM compiler, and that of "other" parameter variables submitted to FS default SDK compilers, is ACES has stated a minimum of (6)-decimal places are required for proper (or 'any' !) utilization of certain objects and content ...when developing for MSFS.

http://en.wikipedia.org/wiki/Floating_point.


I am inclined to assume that after compilation of the source code, the intended parameter "value" for Heading will also then be stored within the BGL ...as the (proprietary ?) digital representation of the original floating point number for that parameter "value" in the original source code.


When I refer to a MSFS variable expressed as a parameter "value", I am of course referring to the entire string of characters (digits) such that the string of numerical digits used represents a number which is not an integer (aka a "non-integer") ...by virtue of having a minimum of 2 (two) decimal places.

http://en.wikipedia.org/wiki/Numerical_digit

http://en.wikipedia.org/wiki/Integer


NOTE: You are probably already quite familiar with the concepts in the wikipedia articles I linked to above; I cited that info here to minimize misinterpretation of my statements by those new to such info, while also hoping to minimize misrepresentation and/or obfuscation of my statements which might otherwise occur due to posts by certain mischievous individuals here at fsdeveloper forums .


Thus, IIUC, MSFS Heading should be expressed as a specifically-formatted floating point number parameter "value" when submitted to the ex: SCASM compiler.

Since it has been emphasized on multiple occasions by Arno that after compilation into a BGL, the (functionality and/or the actual digital code ?) of MSFS BGL code generated by SCASM is no different from that generated by the equivalent FS SDK compiler(s), one might wonder if the same criteria for Degree range formatting and minimum 2-decimal floating point applies with parameter values for Heading when submitted to the equivalent FS SDK compiler(s) ...just as it does with the SCASM compiler ?

I 'infer' that parameter values for Heading may also subsequently be stored within the BGL as a digital representation of the original floating point number for that parameter "value" in the source code submitted to the compiler; if that is actually the case, then it would seem appropriate that when de-compiling / viewing / extracting the parameter "value" as ex: tabular info and/or 'source code', one should also write it back out as a floating point number.


Again, I am new to the "obscure innards of BGLs"; but I am compelled to ask, in light of your quoted statement above and my elaborations on the topic within this post:

* After compiled, aren't floating point numbers in parameter values stored inside BGLs as a digital representations of those floating point numbers ...with levels of precision matching that used in the source code (assuming degradation of data accuracy has not taken place via lossy compression imposed 'mandatorily' by the compiler) ?

* When de-compiled / viewed / extracted from a BGL, shouldn't the parameter "value" output as ex: tabular info and/or 'source code', also be written back out as a floating point number ...with levels of precision matching that used in the "original" source code (assuming degradation of data accuracy has not taken place via lossy compression imposed 'mandatorily' by the compiler) ?

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


Thanks again for your efforts with this project, and I look forward to your reply to these questions.

GaryGB

 

[GHD]

I also believe that heading/pich/bank value should not be displayed with decimals. Same thing for Altitude. I will remove that in the next version.

Altitude should be displayed to at least 3 decimal places.

Also, the "bgl" output doesn't include the altitude:

7,1,AirportBounds_0_0
45.0442171096802,12.83203125
45.0430226325989,12.8338658809662
45.0348973274231,12.8321009874344
45.0340461730957,12.8351372480392
45.0169658660889,12.8335976600647
45.0169944763184,12.83203125
45.0442171096802,12.83203125
10,1,AirportBounds_1_0
45.0169944763184,12.83203125
45.0170660018921,12.8272837400436
45.017237663269,12.8265756368637
45.0189471244812,12.8252345323563
45.0209212303162,12.8247141838074
45.0250768661499,12.8194892406464
45.0214147567749,12.8059548139572
45.0583076477051,12.8103107213974
45.0442171096802,12.83203125
45.0169944763184,12.83203125


It should be "long,lat,altitude".

 

[Patrick Germain]

Also, the "bgl" output doesn't include the altitude:
It should be "long,lat,altitude".

I don't recognize this output format. It looks like some BLN output. Is it BGLViewer or CvxExtractor ?.
If it's BLN output for CvxExtractor, then (wrong chat) that's right , I do not output altitude. Ny understanding is that BLN is 2 dimentional only. But I may be wrong...

Patrick

 

[GHD]

Sorry, I did mean .bln format. It is 3-D.

 

[ollyau]

That should be possible. That DLL already exists but, honestly, right now, I'm too lazy to write the API doc ! That will come though....

Ah, good to hear, thanks! Could you possibly make an interim release without the docs for the adventurous to try?

 

[GaryGB]

I don't recognize this output format. It looks like some BLN output. Is it BGLViewer or CvxExtractor ?.
If it's BLN output for CvxExtractor, then (wrong chat) that's right , I do not output altitude. Ny understanding is that BLN is 2 dimensional only. But I may be wrong...

Patrick

Hi Patrick:

Indeed as George cites above, the "3-D" BLN format typically contains X,Y,Z data; and in the context of working with MSFS GIS data, IMHO, BLNs "should" contain X,Y,Z (aka Lon,Lat,Alt) data in each record line following the header line ...when stored / viewed / extracted / output to a file.


IIRC, SBuilder for FS9 originally utilized X,Y (Lon,Lat) fields in each record within a experimentally adapted header line "2nd parameter" integer value in a custom version of the original 'simple' Golden Surfer BLN format ...in an attempt to define an intended vector line 'width' while importing X,Y poly-line data.

And it is true that the very earliest uses of the Golden Software "Surfer BLN" format was to define a polygon area via X,Y coordinate pairs for purposes of "blanking" GIS data.

However a "X,Y,Z" version of the Surfer BLN format also subsequently proved useful in setting elevation for each point by inclusion of the 3rd "Z" field for Altitude / elevation when modifying display of GIS data in earlier versions of the Golden Software using the older "Surfer Blanking file" formats.

And of course newer versions of that "Surfer Blanking file" utilized by current Golden Software products seem now to be a hybrid ASCII / Binary and are no longer the same file format as the original 'preferred' BLN (header,X,Y,Z) format still being used globally in most 'non-Golden Software' GIS applications /utilities ...and for MSFS data I/O work with ex: newer versions of SBuilder for FS9 and/or SBuilderX.


And indeed, as you said, the thread ("chat") or topic wherein BLN format was discussed previously is at:

http://www.fsdeveloper.com/forum/threads/cvxextractor-exporting-vector-data.432918/

Hope this helps !

GaryGB

 

[Patrick Germain]

George, Gary,

I will update the CvxExtractor to take this into account.
However, in a BGL file , there are 3 cases for the vector points:
1 - No altitude is provided
2 - All points of a vector have the same altitude
3 - Points of a same vector have different altitudes.

In case 2 and 3 , that's a no-brainer. I will oupyr the altitude (as I do for KMZ files).

However, what should I do for case 1 ? Output 0 as altitude or do not output altitude at all (just X,Y) ?

 

[Patrick Germain]

Ah, good to hear, thanks! Could you possibly make an interim release without the docs for the adventurous to try?

Sure . Gimme a few days though.....

 

[Patrick Germain]

Altitude should be displayed to at least 3 decimal places.

George, sorry to be blunt but that does not make sense to me: 3 decimal places for the altitude resolves to a precision of 1 millimeter ! Do we really need that kind of precision for vector data ?

 

[GHD]

George, sorry to be blunt but that does not make sense to me: 3 decimal places for the altitude resolves to a precision of 1 millimeter ! Do we really need that kind of precision for vector data ?

Well, if one is placing other polygons at that height, I would say that we do.

Most default airports have their elevation defined as feet so outputing the vector polygon to a precision of a metre doesn't make sense to me.

I use the output purely to see whether an addon airport needs a "stub" file in World\Scenery to redefine the default elevation.

 

[rhumbaflappy]

I think the standard for FS9 was 1/125th of a meter for elevation (I think...). So 3 decimal places wouldn't be so odd for FSX. A worry here is to prevent shimmering polys overlapping other polys by elevating them slightly. $0.002

Dick

 

[GaryGB]

Hi Patrick:

Many thanks for implementing a '3rd' X,Y,Z field value for Altitude in parametric output from your excellent utilities !

I think the standard for FS9 was 1/125th of a meter for elevation (I think...). So 3 decimal places wouldn't be so odd for FSX. A worry here is to prevent shimmering polys overlapping other polys by elevating them slightly. $0.002

Dick

IIRC, the original "precision" utilized in FS2002 (aka "FS8") was 1/128th of a Meter, with FS9 and FSX expanding this to 1/256th of a Meter for vector coding of TMF content ...as documented in the legacy SDKs cited in this post:

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

See: MSFS 2004 Terrain SDK - Terrain Vector Data.Doc (Page 25)


Also, IIUC, the Altitude of vertices in vector objects requires sufficient bit depth to allow calculation of slope values for Direct Draw 3D surfaces in the MSFS terrain rendering process.

ISTR Luis Sa' mentioning SBuilder uses Altitude increments of 1/256 Meter to compute slope values for terrain polygons.


Also, the MSFS SP2 SDK specifies a requirement that sloped vector content (ex: textured streams / rivers with a sloped orientation, hydro polys etc.) must be coded with "SLOPE-X and SLOPE-Y" floating point parameter values for Altitude / Elevation of vertices:

"Hydro Polygons - used for slopes and medium/high resolution water polygons"

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

"WaterPolys - SlopeX - Slope in vertical meters per degree of longitude. 13 char floating point number"

"WaterPolys - SlopeY - Slope in vertical meters per degree of longitude. 13 char floating point number"

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


..and as clarified in a post by ACES' Doug Matthews:

"(the SlopeX and SlopeY need to be Float 13 >characters)"

http://forum.avsim.net/topic/81298-excluding-autogen-with-shp2vec/


BTW: I have also found that "precision" floating point values with a minimum of 13 decimal places are apparently required to achieve desired results when working with some aspects of the FSX SDK, and other than ex: RWY Heading, I endeavor to format all my MSFS SDK source data for scenery ...with that same level of 13 decimal place precision (even when zeros are used as 'decimal place-holders').

George, Gary,

I will update the CvxExtractor to take this into account.

However, in a BGL file , there are 3 cases for the vector points:
1 - No altitude is provided
2 - All points of a vector have the same altitude
3 - Points of a same vector have different altitudes.

In case 2 and 3 , that's a no-brainer. I will (output) the altitude (as I do for KMZ files).

However, what should I do for case 1 ? Output 0 as altitude or do not output altitude at all (just X,Y) ?

A standard GIS industry 'fall-back' as a "NO_DATA" place-holder value for elevation is "-9999":

http://2012books.lardbucket.org/books/geographic-information-system-basics/s08-data-models-for-gis.html#−9999



MSFS SDK implementation of a "NO_DATA" 'fall-back' value for elevation which makes scenery content display as mesh-clinging "object-on-ground" (where 'AltitudeIsAGL=True') ...is shown here:

See: MSFS 2004 Terrain SDK - Terrain Vector Data.Doc (Page 28)

"The LWMDataAreaHeight structure contains only 2 values: a height and a fraction. The iHeight represents the integer based meter to which to flatten. The iFraction value of this structure contains a decimal portion of the height multiplied by 128. The reconstructed height will be iHeight + (iFraction / 128).

If you do not know the elevation of a body of water, you can set iHeight to -9999 and iFraction to 0. Doing so will tell Flight Simulator to just cut a hole into the land without setting the elevation."



Alternatively, the MSFS SDK may use "-32767" as a "NO_DATA" 'fall-back' value for elevation.

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

"Although the position of objects on the earth is specified in the world coordinate system, actual design work is done in smaller rectilinear coordinate systems placed with their centers at a given world coordinate.

The Object Coordinate System
The object coordinate system is used to design scenery. The object coordinate system is based on the X, Y, Z concept of design space. The rectilinear, 3-D X, Y, Z coordinate system is set up with its center, X=Y=Z=0, at the specified latitude, longitude, and altitude. The Z-axis aligns with true north (parallel to lines of longitude), the X-axis aligns with east (parallel to lines of latitude), and the Y-axis aligns with altitude. You can define points, lines, and polygons within the X, Y, Z design space.

The X, Y, and Z-axes each have a range of +/-32767 (16-bit linear design space). The size that each unit along the axes represents depends on the scale factor. The scale factor can range from less than 1 millimeter per unit to 32768 meters per unit."


IIUC, this infers a required elevation data 'attribute' for (all ?) terrain and/or scenery objects in 'placement' BGLs.

What with default units for elevation in the MSFS SDK being Meters, one might also infer that fractional meters (floating point format ! ) are required for elevation parameter values with MSFS vector content ...as addressed by Scott Smart (aka "scott967"):

http://forum.avsim.net/topic/311168-fs9-autogen-issues/#entry1864559

"LWM3 poly for FS9 requires for each polygon, a min altitude and a max altitude. Then, for each point in the polygon 3 values are needed, corresponding to lat, long, and an 8-bit fractional height (i.e., in 1/256ths) <IIUC: 1/128ths...GaryGB> between the max and min alt defined for the polygon"


NOTE: I would welcome having the following hypothesis "corrected" by someone with deep "FS-Insider" knowledge (preferably with some substantial documentation and/or explanation ...rather than 'hearsay' or vague allusions perhaps arising from ongoing apprehension over 'NDA enforcement' by MS Game Studios ex: on-site visits by black helicopters with big green "X" icons and/or 'Men-In-Black' threatening to confiscate personal computers etc.):

AFAIK, much of the FSX-era MSFS code base utilizes similar "pre-FSX" (ex: FS2000 - FS2002) version BGL code as generated by legacy FS SDK compilers ...even when generated by FSX-era SDK compilers.

IMHO, the FS9 - FSX SDK "XML front-end" ACES imposed for ex: MakeMDL, XtoMDL, BGLComp and SHP2VEC, largely served to help with content management for the FS rendering engine via mandated use of a GUID for every object.

And AFAIK, all layers of content (including vector data) are ultimately flattened / combined / merged when "rasterized" for display in FS at run time.


Hope this helps !

GaryGB

 

[rhumbaflappy]

Yes Gary, 1/128th m. Elder moment...

Dick

 

[GaryGB]

ATTENTION Administrators:

This thread and the other related thread originated by OP Patrick Germain on matters of major importance to the FS Devlopment Community have, IMHO, earned a 'transplant' (and perhaps even a dedicated sub-forum ?) ...to a location within another section of the FSDeveloper Forum area.


I respectfully suggest that this thread:

http://www.fsdeveloper.com/forum/threads/bglviewer-for-fsx-bgl-files.432840/


...and this thread:


http://www.fsdeveloper.com/forum/threads/cvxextractor-exporting-vector-data.432918/

...should be "moved" (with 'forwarding address' posted links) ...to a new home in ex:


Microsoft Flight Simulator development > "Scenery Design - Other"

http://www.fsdeveloper.com/forum/categories/scenery-design-other.30/


The current location in the "entirely too-busy" Developers coffee house > "Showroom" seems inappropriate to these ongoing discussion threads for an advanced and stable set of utilities such as have been created and released to the FS Development Community by Patrick Germain.

I believe others here agree that this outstanding effort by Patrick has earned his work it's own "home" in the FSDeveloper forums.

GaryGB