Extra informations contained in BOB format:
===========================================

Egosoft was saying in their official X2 - The Threat Modding Documentation that
BOB format contains exactly the same data as BOD format.

This is not truth.

There are two main types of extra data contained in BOB format:

Extra point informations and X3 specific data.

Extra point informations:
=========================

Points stored in binary BOB1 format contain more values then is ouputed to text
BOD. So when compiling from BOD back to BOB, the original values cannot be
restored and x2bc must "guess" the values - it use zeroes. In order to be able
to make 1:1 conversion between BOB and BOD, x2bc can write these extra
informations to special block after part definition. Those values are invisible
to X2 because they are after comment '/' operator but x2bc can "see" them. This
allows x2bc to create the BOB file with all the information from the original
BOB file. If the extra information block is missing, x2bc will use the default
values.
Meaning of these values is unknown. I didn't have time to play with them but
they seem to affect reflectivity of textures.

Example of part definition from 06070.bod decompiled with --xpinfo+ (default
setting)

3; 6450; 6447; 307; -25; 8; 0.789230; 1.981689; 0.872757; 1.971878; 0.882034;
1.981689; /! { 0.753128; 0.795624; 0; 0.782364; -0.622803; }
{ 0.752258; 0.788239; 0; 0.782364; -0.622803; }
{ 0.753128; 0.787415; 0; 0.782364; -0.622803; } !/ // 12766

NOTE: the line is wrapped at column 80 - normally the extra point information
block must be at one line otherwise X2 will not load such BOD file!

All the values in the /! !/ block are invisible to X2 and those are the extra
values we are talking about. There are 3 blocks delimeted by curly brackets
'{}'. Each of these blocks belongs to 1 point. 1st to point index 6450, 2nd to
point 6447 and 3rd to point 307.

Rules for special values:
Each value can range from -1.0 to +1.0
The number of values in one block must be 1, 3 or 5 otherwise compilation will
fail.

To instruct the decompiler to output the extra informations, use the --xpinfo
flag. (or --xpinfo- to supress it)

Outputing the xpinfo is safe - X2/X3 will load such bod file without problems.

X3 body specific data:
======================

If body stored in BOB format is marked as "X3 body", then there are additional
data sections present.

Part values:
------------

Part values consist of 10 numbers which are present in all parts in the body.
content of this section is always outputed by the decompiler.

Because nothing is known about these values, x2bc will output them in 3 formats:

raw - numbers are outputed directly as they are stored in bob
point - numbers are converted in the same way as vertex coordinates
float - numbers are converted to floats

I have no idea what is the "correct" format.

Secondary UV coordinates:
-------------------------

Secondary UVs are stored in every part (precisely in every face list).
I'm calling those data "secondary UVs" but I have no idea what are they.
They seem to be float numbers ranging from -1.0 to +1.0 and thus they look
similar to UV coordinates.
However they are connected to vertices instead of faces which is strange because
UV coordinates are defined per face, not per vertex.
My second idea is that they can be vertex colors, but as they are ranging from
-1.0 to 1.0 it seems unlikely.


To instruct the decompiler to output the X3 informations, use the --x3info flag.
(or --x3info- to supress it)

Outputing the x3info is UNSAFE - X2/X3 will FAIL to load such bod file and so
will DBOX2.

Only use this option for hacking purposes.

x2bc will compile x3info without problems.

