How do I get terrain data out of a BGL?

[Guest]

Greetings to all!This is my first post to the forum, but I came in and lurked a bit yesterday and it looks to me like a lot of you guys know your stuff.Anyway...I'm writing a proggy to read BGLs and convert them to OpenFlight models. It's been kinda tricky, but most objects are converting alright (woohoo!). However, there's one problem with positioning them.....Scale_AGL (Opcode 0x77) is used a lot. The AGL stands for "At Ground Level". For those of you who don't know much about BGL opcodes, a scale is a local set of coordinates to create an object. It's got a centre (lat/lon/alt) and the number of metres per unit. Scale_AGL doesn't have the altitude of the centre defined within the arguments for the opcode because Flight Sim just sets it to the height of the ground at that lat/lon. The problem here is that I don't know how to get the height of the ground at a given point...At the moment I'm just using 0 for ground level because I don't know what to use. It's making a bit of a mess because the runways and some objects (those created with a normal scale instead of scale_AGL) appear at the correct altitudes (normally about 150m above where I'm creating all the stuff for the ground).I've read through the FS2000 Scenery SDK, but there's no mention made of how the terrain data is stored in a BGL. The terrain SDK is just a set of tools for creating terrain and also appears to have no info on how the results are stored. I guess MS want people to use tools to create the stuff and aren't interested in people who want to read it.The only clue I have is in the Scenery SDK, where the BGL header contains a pointer they call "misc_data (ground alt db)". I got out my trusty hex editor and followed this pointer to the appropriate point in a few files that I've been testing the converter on.I've copied the appropriate sections into notepad and then tried to break them up.For example:*15* <1c 28> <52 28> _0a 00 00 00_*00**06* _0b_ <3e 4d 28> [3d 05 a9] {82 00 00}*05* _0b_ <39 40 28> [53 05 a9] {82 00 00}*05* _0b_ <5a 37 28> [61 05 a9] {82 00 00}*04* _0b_ [56 05 a9] {82 00 00}*05* _0b_ <39 40 28> [53 05 a9] {82 00 00}*07* _37_ <3b 38 28> [0f 06 a9] {00 82 00} <54 3d 28> [07 06 a9] {00 82 00} 00 00 '53 65 61 74 74 6c 65 2d 54 61 63 6f 6d 61 20 49 6e 74 27 6c 20 20 20 20 20 20 20 20 20 20 20 00' ?22 10 00?*00*I used the following key to say what I thought each part was...*opcode* - command that tells FS to do something_pointer_ - normally the offset to the next opcode - latitude, normally 24-bit, 16 bit after opcode 15[lon] - longitude, 24-bit{alt} - altitude, 24-bit'string'?NFI? - No... err... Forthcoming Ideas? (Me? Swear? NEVER! :()I'm trying to figure out what the *opcode*s and the ?NFI?s mean, and how to use all this to get a ground level for my Scale_AGL conversion to use.I reckon that *15* is a latband like in object definitions. It just gives a latitude range that the data it points to fits in to.*00* is the end of a list. When inside a latband it ends the latband to tell FS to go look at the rest of the latband list. When in the latband list it tells FS that the latband list is over.*07* appears to be a definition of an airport. I think. It seems to have two points defined (makes a rectangle, perhaps?) and a string for the name of the airport.*04*, *05* and *06* all define a point. Probably. Not sure what the significance of the different opcodes are, so that makes things a little difficult.Anybody got any ideas on how this stuff all works and how I can use it to get the right ground levels to use with scale_AGL?

[Guest]

Hmmm... That was a really long post.Basically all I needed to say was that I want to know how to find the ground level at a certain point using the misc_data section of a file.If you want the full info on what I've figured out for myself then read the original post.Please help me out here!

[Guest GerrishGray]

Hi there m'ludThere is no way that we know of at present to do what you want. The terrain elevation at any given point is obtained from data in the mesh terrain BGL's. We know how to create those BGL's, thanks to the Terrain SDK tools supplied by MS, but they have not given us any tools for reading the data back from a compiled mesh terrain BGL and nobody has, as yet, managed to reverse-engineer it.Only the MSFS engine itself knows how to do this. It does make the data available at run-time via a visible global variable, but that's not going to help you in trying to translate BGL's into a different format for another program.Perhaps I should point out that you are infringing MS copyright if you do this anyway. They allow us FS enthusiasts and developers quite a bit of leeway in this respect in the interests of expanding the MSFS hobby - but porting the scenery across for use in a different program would be quite another matter, methinks.From a humble untitled plebGerrish

[arno 1]

I agree about the copyrights, but the technique could be interesting for addon sceneries (if the designers allow the conversion). I know that the university I am studying on is also very interested in this conversion for their flight simulator and I talked about it with them.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

[rhumbaflappy 113]

Hi all.Elevation bgls are almost always compressed TMF's, and that's why they are unreadable.

[Guest]

Hmmm... I had a feeling this would be the case... :(I figured that things were a little too complicated with the terrain mesh stuff. What about earlier versions of flight sim? How does the seed system (pre-7.0) work, for example?And also... What was that stuff I was pulling out of the misc_data sections of files if it wasn't terrain? The stuff following opcodes 4, 5 and 6 all seemed to define points that would actually be on the ground. Altitude of the point = 0x82 = 130 = altitude of runways in same file, so probably altitude of ground.Oh yeah... Copyright... OpenFlight is just a 3D-modelling language. Not some other flight sim program that would compete with MSFS, so it shouldn't cause HUGE copyright issues. It's just a different way of viewing the models that are already in the BGLs. I'm using OpenFlight because I have lots of info on working with the files (A lot more than what MS has released regarding BGLs, I must say... :() and I even managed to get a good API for all my OpenFlight-editing needs. Hooray for open file structures! :D

[Guest christian]

I cracked the whole header in the beginning and the lookup table at the end. In the middle there is a block of raw elevations. Read my tmfdoc.zip (which you can get here, but don't get the newer tmfdoc2.zip, because the binary info isn't in there). The default data is indeed compressed. I'm able to read uncompressed land class data, but never tried it with elevations. If you can come up with a decompression algorithm you'd be a champ :)Regarding copyrights, the terrain data is based on public available data in the first place. The data surely isn't copyrighted, but the fileformat may be. I guess this is sort of a grey zone...Cheers, Christian

[Guest]

Hmmm..."This document is not for the faint-hearted"/me checks pulse. It's findable.Oh good... I should be able to use it.Thanks for that file... I will work through and see what I can come up with. If I was faint-hearted I wouldn't have been able to get as far as I have with the Scenery SDK (Nasty piece of work, that... Some opcode definitions were dead wrong... Also, the last few opcodes listed go: ad, ae, ad, b0, b4. I've seen b2 and b3 used in files. Just a little confusing...) so I should go alright with what you've given me.

[Guest]

The info in that doc is good, but it still doesn't help much when I'm trying to read the stuff out...Anybody else got any ideas?Now... Can anybody tell me how the old seed system worked? I'm hoping to make this proggy compatible with older versions of FS too, so I'd better find out how seeds work.

[Guest christian]

Where are you stuck? Maybe I can help... If you really want to read the raw data, you'll probably have to know something about 2D lossless compression algorithms, or at least be willing to dig into that...Christian

[Guest]

I think I'll need the raw data. I need to be able to find a ground level to use as the centre of the stuff in the scale_agl. AFAIK, the raw data of which you speak is the only way to do this (apart from maybe the misc_data, but I don't know what's going on in that.) so I'm going to have to get it out.Unfortunately, I know nothing about compression algorithms. My partner in crime, however, knows a little and could probably look up a lot more. Pity he's away on holidays for the week. :SWe'll see how we go next week. Thanks for your help and I'll probably get in touch with queries and progress updates Monday or Tuesday.P.S. Anybody know how seeds work?

[Guest luissa]

>P.S. Anybody know how seeds work? Hi,I think that BGL decompilers, like BGLAnalyser or SCDIS, will transalate "BGL seed files" into txt files but I also think that there is very litle relation to TMF terrain files.Regards, Luis