I now sort of understand why Cadius uses Saftey Nets.

Observe · Post by **Observe** » Mon, 7. Mar 11, 05:22

Just to confirm what you've said. Using Argon M6, here is what I get (green box) when using numbers 5,6,7 point values (-644; 22137; -11031) as position coordinates for the Cockpit object:

[ external image ]

Spot on match with Cockpit location! And another one bites the dust.

Litcube · Post by **Litcube** » Mon, 7. Mar 11, 05:35

Observe wrote: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.

Good screen shot!

It seems that we have 6 / 10, but I'm not sure we can but 5, 6, 7 to bed yet. I think we still need to determine how the ratio is arrived.

Observe · Post by **Observe** » Mon, 7. Mar 11, 05:38

Litcube wrote:It seems that we have 6 / 10, but I'm not sure we can but 5, 6, 7 to bed yet. I think we still need to determine the ratio.

The ratio is always (I think) 1.526 between 'raw" and "point" values in this case.

Litcube · Post by **Litcube** » Mon, 7. Mar 11, 05:51

Ok, I have to back up a step.

When you made that square for the centaur screen shot, which co-ordinates did you use to place it?

Litcube · Post by **Litcube** » Mon, 7. Mar 11, 06:10

Hazarding annoying redundancy, the ratios I'm referring to are:

The only reason I'm choosing cockpits, is because they're the only object that's easily identifiable as offset, not because they're cockpits, per say.

Code: Select all

The sequence is X, Z, Y:

Centaur Cockpit.
Real Pivot Offsets -172, 5942, -2960
Bod Point Values: -644, 22137, -11031
Ratio:     3.744, 3.725, 3.726


Phoenix Cockpit.
Real Pivot Offsets 59446, 139768, -446834
Bod Point Values: 5998, 14104, -45088
Ratio:   0.1008,	0.1009,0.1009

It's those ratios I need to determine the source of. My brain is melting, Observe.

[/code]

Observe · Post by **Observe** » Mon, 7. Mar 11, 06:13

Yes, I know. I'm having to backtrack to see how I got the M6 Cockpit position worked out. I'll let you know as soon as I can repeat.

Yes, the ratio is the key.

Observe · Post by **Observe** » Mon, 7. Mar 11, 06:57

Ok, this seems to work using Argon M6 for 5,6,7:

Code: Select all

// x3 part values
/! PART_VALUES_RAW: -422; 14508; -7229; 422; -422; 14508; -7229; 
// point:
// -644; 22137; -11031; 644; -644; 22137; -11031; 
// float:
// -0.006439; 0.221375; -0.110306; 0.006439; -0.006439; 0.221375; -0.110306;

The size "multiplier" for this ship is 32212. If we take each of the float values for 5,6,7 (0.006439; -0.006439; 0.221375), and multiply by 32212 (ship size), we get:

207.413068
7130.9315
3553.176872

Now, if we round those off, and place them in a scene file, we have:

Code: Select all

P 0; B Box; F 0; N Box; j  // idx 1
{ 0x2002;  -207; 7131; -3553;  0.000000; 0.000000; 0.000000; 0.000000;  -1; 1; } // 0

Then if we import the scene into 3DS, the box in the scene correspons to the location of the Cockpit. I'll try on a couple of other ships to make sure this relationship holds.

Observe · Post by **Observe** » Mon, 7. Mar 11, 07:01

Verified same method for deriving ratio works for Split M1.

The "missing link" is the ship size multipler in conjunction with the float values.

Litcube · Post by **Litcube** » Mon, 7. Mar 11, 07:42

Hrm. We're so close. But the Teladi M1 is a little off on the box. Enough that the casual observer would see that it's not centred on the object.

We're nearly real time. Do you use DevChat?

Litcube · Post by **Litcube** » Mon, 7. Mar 11, 08:05

It's so close.

http://img716.imageshack.us/i/82512039.jpg/

Sorry about the shot. But you can make out the cockpit. It's the little grey dot near the center.

Litcube · Post by **Litcube** » Mon, 7. Mar 11, 08:58

Going by your math for the position, and the math for the ratio of the Y length, we get this for the Argon M7:

http://img641.imageshack.us/i/31706251.png/

I believe this to be an accurate representation of what ego was trying to reproduce. The data used to generate this box comes from the x3 info line 5,6,7,8,9,10.

Regarding the pivot points and the center of the shape (5,6,7), we were comparing pivots of the objects. Which I don't think was the right way to think.

This Cerberus is a good example. The pivot for the Cerberus has to be low-center, because there's that mast sticking up. However, collision data needs to cover that thing. So the pivot of the object will not match the collision shape in this case. The image is a perfect example.

Due to this theory, I think we can put 5, 6, 7, 8, 9, 10 to bed.

5, 6, 7: Multiply float values by the bod size (Argon M7 is 401434, found right after materials in the decompressed bod)

Result:

5: X
6: Z
7: Y

8, 9, 10: Multiply float values by Y length (Argon M7 is 598313, and can be found in the 3dsmax view object information***)

Result:

8: Width
9: Height
10: Length

Observe, do you agree? Can we put 5,6, 7, 8, 9, 10 to bed?

***This isn't necessarily a rule. I believe these shapes were hand drawn. They just happen to match the length of the ship in most cases.

Litcube · Post by **Litcube** » Mon, 7. Mar 11, 10:08

http://img813.imageshack.us/i/55172267.png/

This is the only idea I have for 1, 2, 3, 4 at the moment.

1, 2, 3 being x, y, z and 4 being radius. Radius calculated the same way length, height, width, of the box.

1, 2, 3 I'm pretty certain are x, y, z values. They correspond exactly in alot of examples.

However, #4 is a mystery.

My certainty on the sphere theory: 18%.

Edit: Mods: I apologize. I'm getting a little carried away with the posts in this thread. Did not realize how many I posted. Will edit in the future.

Observe · Post by **Observe** » Mon, 7. Mar 11, 16:50

Just got up and reading your latest findings before on my way to work.

Yes, I agree we can put 5,6, 7, 8, 9, 10 to bed. Any small inconsistencies can probably be chalked up to developer errors with those numbers.

I'll give some thought re. the remaining numbers, and perhaps between us we can resolve.

Vayde · Post by **Vayde** » Mon, 7. Mar 11, 23:49

Simply stunning. I hope all moders are following this as keenly as I am.

TrixX · Post by **TrixX** » Tue, 8. Mar 11, 00:24

Oh hell yeah, certainly interesting times

killerog · Post by **killerog** » Tue, 8. Mar 11, 00:42

Yep I have been looking at this thread constantly with my Beady little eyes

Litcube · Post by **Litcube** » Tue, 8. Mar 11, 01:51

Observe and I have been working on this all day off forum.

We can confirm the existence of a shape around the ship with the tests we'd done today defined by Width, Height, Length, and an X, Y, Z center. We're sure this represents the collision data people are looking for with regards to collision avoidance behaving oddly with custom ships.

We're also somewhat confident, of the existence of a sphere in the same line defined by a diameter and an X, Y, Z center. Through several tests, we cannot see any result of ship behaviour changing with relation to changing the sphere values. We don't know what the sphere is used for, but we know it's a sphere, and reproducing vanilla values can be done using our methods.

Here's what we think:

http://members.shaw.ca/litcube/X3/Scree ... Values.JPG

The RAW row represents what the bod and bob will ultimately contain in terms of collision data (This is what should be in your file). It will look like this in your bod:

/! PART_VALUES_RAW: 30; -3289; -13779; 65439; 0; 4278; -6929; 7471; 16896; 58606; !/
-99; 00000000000000000001; // end of part
-99; 0000000000000000; // end of body

POINT and FLOAT data are just translations by DoubleShadow, in case anyone wanted to pick up the torch in figuring this stuff out. They're all equal to each other. For example a float value of 1 is equal to 65536.

There's two shapes. A sphere in the first 4 columns. The last 6 columns represent another shape. For all intents and purposes, this shape can be assumed to be a box.

All of the values in the last row are derived from the float values, and multiplying them by either the Y of the main bod (on the right), or the "BodSize" (on the right).

Y of the Main Bod: When you open 3DS max, and select the main model, and open object properties, you'll see the dimentions of the object. It refers to the Y you see there.
BodSize: Before first body in the bod file, is a value that represents the size of the object. For the cerberus, do a search for 401434 to see what I mean.

For our tests, we got all X, Y, Z for each shape by multiplying the float by the "BodSize", and the dimensions of the shapes (Sphere Diameter, Box Width, Height, Length) by multiplying the float by the Y value of the ship itself. It could still be that only one of either BodSize or Y is used to arrive at all 10 values, but the way we did it represented a visually more appropriate collision box when drawn in 3ds Max using those exact values.

As a simple example, if you know that your ship is as wide as 20% of length, and as tall as as 45% the length, and your ship is symmetrical from a, x and y standpoint, your line will look thus:

/! PART_VALUES_RAW: 0; 0; 0; 65536; 0; 0; 0; 13107; 29491; 65536; !/

65536 represents 100%, or 1. Most Spherical diameter values we see are also larger than the Y length by about 5% to 10%. Offsets are used to cover areas that stick out past the pivot of the main model, like the Cerberus, Panther, etc.

Folks, if your custom ship doesn't have this information, it's broken. It will act weirdly with collisions. There is some default collision avoidance by some unknown method if you do not have this info, but it doesn't pass muster. It is broken.

Observe · Post by **Observe** » Tue, 8. Mar 11, 02:25

Just to emphasis for clarity:

All custom models exported via DBOX are currently missing the bounding-box collision avoidance object reference in the exported .bod file.

This means custom models will suffer from other ships crashing into them at a much higher rate than Egosoft ships.

Therefore, best add that PART_VALUES_RAW line for each of your LOD meshes. At minimum, all 10 values can be zero except the last 3 which define the bounding-box.

Observe · Post by **Observe** » Tue, 8. Mar 11, 03:44

Here is basic information so you can understand how to create the collision avoidance bounding box using Argon M1 as example:

- Import Argon M1 into 3DS
- Open Argon M1 bod file in text editor
- Find first occurance of text: PART_VALUES_RAW
- Copy that line, and replace in the following:

Code: Select all

/# Exported with dbox2 1.11 at 3/7/2011 5:47:52 PM
 
540844; // body size
// vertices (8)
-10496; -21334; -65536; // 0
10496; -21334; -65536; // 1
-10496; -21334; 65536; // 2
10496; -21334; 65536; // 3
-10496; 21334; -65536; // 4
10496; 21334; -65536; // 5
-10496; 21334; 65536; // 6
10496; 21334; 65536; // 7
-1; -1; -1; // end of verts
 
// ----- part Box01 (12 faces) -----
0;  3; 2; 0;  -25; 2; 0.000000; 0.000000; 1.000000; 0.000000; 1.000000; 1.000000; /! N: 0.000000; -1.000000; 0.000000; !/ // 0
0;  0; 1; 3;  -25; 2; 1.000000; 1.000000; 0.000000; 1.000000; 0.000000; 0.000000; /! N: 0.000000; -1.000000; 0.000000; !/ // 1
0;  7; 5; 4;  -25; 4; 1.000000; 0.000000; 1.000000; 1.000000; 0.000000; 1.000000; /! N: 0.000000; 1.000000; 0.000000; !/ // 2
0;  4; 6; 7;  -25; 4; 0.000000; 1.000000; 0.000000; 0.000000; 1.000000; 0.000000; /! N: 0.000000; 1.000000; 0.000000; !/ // 3
0;  5; 1; 0;  -25; 8; 1.000000; 0.000000; 1.000000; 1.000000; 0.000000; 1.000000; /! N: 0.000000; 0.000000; -1.000000; !/ // 4
0;  0; 4; 5;  -25; 8; 0.000000; 1.000000; 0.000000; 0.000000; 1.000000; 0.000000; /! N: 0.000000; 0.000000; -1.000000; !/ // 5
0;  7; 3; 1;  -25; 16; 1.000000; 0.000000; 1.000000; 1.000000; 0.000000; 1.000000; /! N: 1.000000; 0.000000; 0.000000; !/ // 6
0;  1; 5; 7;  -25; 16; 0.000000; 1.000000; 0.000000; 0.000000; 1.000000; 0.000000; /! N: 1.000000; 0.000000; 0.000000; !/ // 7
0;  6; 2; 3;  -25; 32; 1.000000; 0.000000; 1.000000; 1.000000; 0.000000; 1.000000; /! N: 0.000000; 0.000000; 1.000000; !/ // 8
0;  3; 7; 6;  -25; 32; 0.000000; 1.000000; 0.000000; 0.000000; 1.000000; 0.000000; /! N: 0.000000; 0.000000; 1.000000; !/ // 9
0;  4; 0; 2;  -25; 64; 1.000000; 0.000000; 1.000000; 1.000000; 0.000000; 1.000000; /! N: -1.000000; 0.000000; 0.000000; !/ // 10
0;  2; 6; 4;  -25; 64; 0.000000; 1.000000; 0.000000; 0.000000; 1.000000; 0.000000; /! N: -1.000000; 0.000000; 0.000000; !/ // 11
/! PART_VALUES_RAW: 1; -6018; -5963; 71499; 0; 0; 0; 10496; 21334; 65536; !/
-99; 00000000000000000001; // end of part
-99; 0000000000000000; // end of body

The above is a simple box mesh in .bod format.

- Change the values in the 3 columns in the vertices section to match the last 3 values in the PART_VALUES_RAW line as shown.

- Save that as collision_box.bod (or some such)
- Now import collision_box.bod into 3DS.
- You should see a box surrounding the Argon M1 mesh:

[ external image ]

That is the bounding box used for collision avoidance.

Obviously you can reverse the process. For example:

- Select your custom ship in 3DS, and right-click Properties. You will see a section indicating the mesh box size:

[ external image ]

- Make a box having the x,y,z dimensions indicated. You will see a box outlining your ship.
- Convert your box to poly (or mesh), Reset Pivot Points, Set x,y,z to zero (World Center), Reset Xform, Collapse Modifier Stack, and export to collision_box.bod
- Open collision_box.bod in text editor.
- Create the PART_VALUES_RAW line in reverse of described above. All values can be zerio except those last three defining the bounding box.
- Paste that line into the end of each LOD in your ship/model in the location shown by the box example.
- Convert your ship to binary (.bob)

Your ship will now possess superior collision avoidance.

[EDIT] It is also possible to do this without opening 3DS, but the method described should suffice in the meantime. Ultimately DBOX should be updated so the proces can be automatic.

Litcube · Post by **Litcube** » Tue, 8. Mar 11, 07:21

I've finished the DBOX patch, but as we don't have permission to mung doubleshadow's code, I'm going to post only my code and show you how to modify your install yourself. There's three snippets.

Before we get to those, what the code does, is fill the PART_VALUE_RAW line that's missing from DBOX1.11 written bods. The line represents exactly the findings that Observe and I have come up with in this post, including offsets, sphere, and box dimensions. It does this line for all LODs, using the largest x or y or z value of of the main body as the ratio benchmark.

On to the snippets.

The first goes in bod_body_writer.ms at line 546:

Snippet 1

Code: Select all

local xs, zs, ys, d, xb, zb, yb, w, h, l

		boxnode = (node.max - node.min)
		w = boxnode[1]
            l = boxnode[2]
            h = boxnode[3] 

            if largest == -99 then
		(
	            if (l > largest) then largest = l
      	      if (w > largest) then largest = w
            	if (h > largest) then largest = h
		)
	      
		l = (l / largest) * 65536
      	w = (w / largest) * 65536
            h = (h / largest) * 65536

		xb = (node.center[1]  / largest) * 65536
		yb = (node.center[2] / largest) * 65536
		zb = (node.center[3] / largest) * 65536

		xs = xb
		ys = yb
		zs = zb

		d = (largest / largest) * 65536
		d = d * 1.1		
		
		format "/! PART_VALUES_RAW: %; %; %; %; %; %; %; %; %; %; !/%" (xs) (zs) (ys) (d) (xb) (zb) (yb) (w) (h) (l) os.newline to:os.stream

To know you're in the right place, the lines above 546 and below 546 are:

Code: Select all

)

		

		format "-99; %; // end of part%" (bitArrayToString flags) os.newline to:os.stream

Snippet 2

This goes at nearly the very end of bod_body_writer.ms. Go to the very end. From the bottom up, you'll see:

Code: Select all

 
   return true;
  )
)

post this right ABOVE return true;

Code: Select all

largest = -99

Snippet 3

Open globals.ms

Paste this as line 2:

Code: Select all

global largest = -99

egosoft.com

egosoft.com

I now sort of understand why Cadius uses Saftey Nets.