I now sort of understand why Cadius uses Saftey Nets.

[Observe]

I will continue exploring this time permitting.

1) I've noticed that there's part values for each body in the model file. For example, the centaur has 5 bodies. Centaur, Cockpit, LOD_1, LOD_2, LOD_3. Each have their own part values. Couple of reasons for this:
a) Like physical collision detection (not CA), only the part values from the lowest LOD are used (in this case LOD_3)
b) The game picks one to use based on which LOD is present.
To be safe, I'll have to generate part value for each body in the model file (i.e. usually all LODs).

My guess is we only need to add the PART_VALUES_RAW data to the lowest (last) LOD, because it appears that is how ES does it. Or at least that's how Doubleshadow formats it. I will run some tests to verify.

2) The other values which are now zero'd out, could possible represent, as per KillJaeden's theory, an ellipsoid figure. Or it could represet some offset, as per TrixX's theory.

Yes, any of those explanations may have merit. Or, those other values might have nothing whatsoever to do with collision. They could represent yet another hidden mystery.

This is something I'll have to investigate before I code.

I agree we should do some more testing, and see if we can find consistency in deciphering those other values. However, at some point it may make sense to code DBOX to handle at least those 3 numbers because of the significant benefit of them alone.

[Litcube]

However, at some point it may make sense to code DBOX to handle at least those 3 numbers because of the significant benefit of them alone.

Totally agree. Failing all else, this will we done. In the meantime, we'll strive for a 360 degree understanding of these values.

[Observe]

However, at some point it may make sense to code DBOX to handle at least those 3 numbers because of the significant benefit of them alone.

Totally agree. Failing all else, this will we done. In the meantime, we'll strive for a 360 degree understanding of these values.

It does appear those other values correspond to boxes representing various model dimensions. Somehow I doubt they translate into an ellipsoid, but I may be wrong.

[Observe]

Confirmed: We need PART_VALUES_RAW line in each LOD.

My guess is Doubleshadow stores at the end because he wasn't certain what else to do with them.

I tested by adding that line only to the lowest LOD, and 100% crashes. Only when I added to the highest LOD did crashes go away.

[Litcube]

Roger that.

TrixX and I have been floating a theory that values 5, 6, 7 (in PART_VALUES_RAW) are pivot centers of these collision "objects". They differ from the LOD centers on account of them probably being hand made. The difference between the center of the respective model and the respective LOD are less than milimeters, which can be accounted for by hand (manual) placement.

If true, they can be discounted, or zero'd out.

Centaur part data:

Code: Select all

Main body
/! PART_VALUES_RAW: 0; -2445; 2355; 67891; 0; 0; 0; 14724; 22062; 65536; !/
// point:
// 0; -3731; 3593; 103593; 0; 0; 0; 22467; 33664; 100000; 
// float:
// 0.000000; -0.037308; 0.035934; 1.035934; 0.000000; 0.000000; 0.000000; 0.224670; 0.336639; 1.000000; 
-99; 00000000000000000001; // part 1 end

Body 2 Probably cockpit
// x3 part values
/! PART_VALUES_RAW: -422; 14508; -7229; 422; -422; 14508; -7229; 422; 422; 362; !/
// point:
// -644; 22137; -11031; 644; -644; 22137; -11031; 644; 644; 552; 
// float:
// -0.006439; 0.221375; -0.110306; 0.006439; -0.006439; 0.221375; -0.110306; 0.006439; 0.006439; 0.005524; 
-99; 00001000000000000001; // part 2 end
-99; 0000000000000000; // body 1 end

Body 3 LOD 1
// x3 part values
/! PART_VALUES_RAW: -6; -2880; 1135; 66420; 0; 0; 17; 14724; 22062; 65302; !/
// point:
// -9; -4395; 1732; 101349; 0; 0; 26; 22467; 33664; 99643; 
// float:
// -0.000092; -0.043945; 0.017319; 1.013489; 0.000000; 0.000000; 0.000259; 0.224670; 0.336639; 0.996429; 
-99; 00000000000000000001; // part 1 end
-99; 0000000000000000; // body 2 end

Body 4 LOD 2
// x3 part values
/! PART_VALUES_RAW: 19; -2594; -841; 66112; 0; -98; -7; 14724; 21964; 65278; !/
// point:
// 29; -3958; -1283; 100879; 0; -150; -11; 22467; 33514; 99606; 
// float:
// 0.000290; -0.039581; -0.012833; 1.008789; 0.000000; -0.001495; -0.000107; 0.224670; 0.335144; 0.996063; 
-99; 00000000000000000001; // part 1 end
-99; 0000000000000000; // body 3 end

Body 5 LOD 3
// x3 part values
/! PART_VALUES_RAW: -116; -2225; -382; 65551; -410; 13; 1523; 13382; 21678; 63645; !/
// point:
// -177; -3395; -583; 100023; -626; 20; 2324; 20419; 33078; 97115; 
// float:
// -0.001770; -0.033951; -0.005829; 1.000229; -0.006256; 0.000198; 0.023239; 0.204193; 0.330780; 0.971146; 
-99; 00000000000000000001; // part 1 end
-99; 0000000000000000; // body 4 end

[Observe]

I agree that might have something to do with their (5,6,7) purpose. Although sometimes those values are fairly high numeric - placing pivot point significantly away from center.

For what it's worth, numbers 2,3,4 translated as vertices, always create a narrow box running the entire length of the model. I don't know the purpose.

[Litcube]

I agree that might have something to do with their (5,6,7) purpose. Although sometimes those values are fairly high numeric - placing pivot point significantly away from center.

Uh oh. That'd sink our theory. Can you remember which model or where you saw that?

For what it's worth, numbers 2,3,4 translated as vertices, always create a narrow box running the entire length of the model. I don't know the purpose.

Got it.

[Observe]

Uh oh. That'd sink our theory. Can you remember which model or where you saw that?

Argon M1:

Code: Select all

/! PART_VALUES_RAW: 26; -6576; -1128; 60027; 48; -5617; -5945; 10287; 15400; 55210; !/

Although somehow I think pivot points probably come into the picture because not all models are symetrically located in World Center.

[Litcube]

Yeah. Assuming these are centres, one value that rarely changes is the X value, which, in a ship that has X bi-lateral symmetry, would make sense.

In this example, it's off by 46. Mere micro-units, accountable by an unsteady hand.

I agree, that if we're correct, pivots come into play.

In the
Centaur, this theory checks out. The cockpit position is telling, as the object is just a tiny cube floating above the ship.

[Observe]

My guess is things will work for the main mesh with those other values being zero if the model contains a single object without linked child objects in the body file, and if the mesh is symetrically positioned in World Center. Fortunately I suspect most custom models comply with those stipulations.

[Litcube]

I'd bet you're right with most models. I'd worry about models like the Panther, whose pivot is so far off the centre, it causes navigation issues.

If we can ascertain the certainty of those three values being the centre of the box, we can likely safely proceed with coding.

[Observe]

If we can ascertain the certainty of those three values being the centre of the box, we can likely safely proceed with coding.

Yes, it would be nice to solve the remaining pieces of the puzzle before releasing DBOX update.

[Observe]

One more piece of information for what it's worth. I tried making all those first numbers a high value just to see what happens like so:

Code: Select all

/! PART_VALUES_RAW: 100000; 100000; 100000; 100000; 100000; 100000; 100000; 22982; 17951; 100000; !/

Now my collision avoidance doesn't work. Therefore, it seems safe to say those numbers do play some role in collision avoidance. It also seems relatively safe keeping them zero's until we figure it out.

[Litcube]

Random data addition:

The ratio between the point values and the raw values is always 1.52~

[Litcube]

However, after reading KJ's PDF again, he suggests the two other lines (the non RAW lines) are just garbage pumped out by X2BC and can be safely ignored.

[Observe]

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.

It sounds like the other two lines are just put in there because DS wasn't sure if they should be raw, point, or float.

[Litcube]

Good to know. Using that info:

If you multiply the last three floats by the Y length of the ship (object properties in 3ds max), you get the all 3 dimensions. Every body in the file, Main, Cockpit, LOD1, LOD2, LOD3, uses Main's Y-Length to base these last three values. I believe the floats are used for this.

Example: Centaur's main Y length, as shown in 3ds max: 53686.663


Centaur's last three floats: 0.22467, 0.336639, 1

Multiplied by the Y length we get: 12061.63362, 18072.80135, 53686
Which is the exact dimentions of the main object.


Moving to the cockpit's 3 floats: 0.006439, 0.006439, 0.005524


Multiplied by the Main model's T length of 53686.663 we get the following for each:

345.684154, 345.684154, 296.561464


Which nearly exactly the dimensions of the cockpit object in 3dsmax.


Just further concretes that these three are the dimensions used for the shape, whatever that may be.


Edit: tl;dr: The last three numbers are ratios of size, not rotational values.

[Observe]

Excellent observations!

So, where does that leave us? I'm assuming we are still valid determining those last 3 numbers based on box size of the main mesh?

Beyond that, do you have any suggestions at this stage re. how to calculate those other 7 numbers, or what they might actually depict?

If nothing else, it's good to know the relationships between these values. Perhaps we can come up with a standard algorithm to create them even if we don't know what they represent exactly?

[Litcube]

So, where does that leave us? I'm assuming we are still valid determining those last 3 numbers based on box size of the main mesh?

I believe we are. We can put those last three to bed, I think.

Beyond that, do you have any suggestions at this stage re. how to calculate those other 7 numbers, or what they might actually depict?

I do, actually. I'm still actively working on it, but real time, this is what I'm coming up with.

What we think might be offset, I'm 99% certain is.

Centaur's cockpit offset from the pivot: -172, -2960, 5942.

They have the same ratio as values 5, 6, 7. On the centaur, if you divide the POINT values, by their respective pivot offsets you come up with:

x 3.744186047
y 3.725513295
z 3.726689189

These are too close to be coincidence, I thought. So applied the same formula to the cockpit of the Phoenix:


x 0.100898067
y 0.100910051
z 0.100905361


Currently working on where the ratio is coming from, but we're getting closer to cracking this whole nut.

[Observe]

Yes, I agree 5,6,7 are definitely position coordinates relative to World Center. That's why the main mesh is usually 0,0,0 for those numbers, and why the Cockpit object has offset values in 3DS corresponding relative to 5,6,7 in PART_VALUES_RAW.

So, it does seem we have determined 6 out of the 10 numbers.