Simon wrote:Thank you very much testing this after some sleeping

Any success? Problems? Suggestions for improvements?

It is however possible to export to some own xml format for editing and then build a new sgb file based on that. I think it is working now. http://projects.pappkartong.se/sgbconverter/ Converting from sgb to sgb, that is, just reading the file into the internal structure and then writing it down ag...

rafal345 wrote:Can you compare .SGB file of tracks and .BML file of car?

No, not really.
bml files are the same format as bmt files, which is quite different from the sgb files.
More about the bml/bmt format.

rafal345 wrote:They're using the same subformat - .meb.

No.

What happens if you Convert all known things of the SGB to SGX and try loading the Track? (Be sure to Rename/Delete the SGB before) Well, ignoring that I don't have the game and that I'm not running windows, there is too much data in the sgb not in the known sgx structure. In order to be able to do...

Just x,y of the bounding boxes (assuming that is what they are), none of their content and no regard for any grouping.
Seems to be some kind of shape there.
(alpental)

Did you try to use 3dsimed? There is nothing in the change log suggesting it have got support for exporting to this format yet. The unknown value in FLAT is a length, it is sometimes written as the negative number I presume that is to indicate something. So this could perhaps be the PARTITIONs, que...

So I guess the turn have come for FLAT. FLAT consists of two structures repeated. First a 32 byte header block //One point (thee floats) (min?) 015500 ---- C40DB3D5 -1005734955 -566.809875 015516 ---- C10451A1 -1056681567 -8.269929 015532 ---- C34052A2 -1019194718 -192.322784 //One point (three floa...

Looking at OCCL again, it's two string references, and four 3d points (4*3 floats) per block. OCCL Block 0 (28) String 1: 1703128 OccluderHeight01 String 2: 1703145 Tracks\Monte_Grande\OccluderHeight01.meb p1 (c1 => 282.350647, c2 => 52.627357, c3 => 344.877411); p2 (c1 => 215.088501, c2 => 52.62735...

Assuming the above format the block could look like <OBJ_ID no="1930"> <!-- objhead_t num_of_type=24 unknown=00000001 --> <!-- objhead_t str2: tracks\_data\instances\gen_tree10_loda.vhf --> <!-- head subobjects=1 matrices=1 unknown=0 matrix_number=-1 --> <NODE type="LOD" Name=&qu...

For the NODE and SUMM parts I would guess it should be possible to map the values to a structure similar to the referenced .vhf file One block from SUMM Block 0452 : 325708 -> +148 325712 ---- 0000078A 1930 0.000000 325716 string reference (821981): -><- 325720 string reference (839718): ->tracks\_d...

The file contains six sections: SGB, OCCL, NODE, FLAT, SUMM and END. Following after END is strings, or nothing if there are no strings. Each section start with: 32bit int section name 32bit int section length 32bit int number of blocks in section SGB Just a section header + 1 all zero byte. OCCL Ea...

Perhaps you could provide a new sample?
The file linked in the original post is no longer available.

Someone asked about this in an IRC channel a while back, so I have been playing a bit with it when I've been bored. As of two days ago I have figured out enough to generate xml, though I still have no idea what the COLL block is. http://projects.pappkartong.se/bmt2xml/ The tag and attribute names mu...