BDB Files

[Sluicer]

I tried to replace the test track with a very huge quad but the game (and the explorer and my pc) crashed. I think I will have to change small things first.

 

I tested more smaller changes and I had no success. I added a big quad to the test track but it cant be seen in the game. I added a cube to the test track but it does not show up. I changed the last 8 positions (vertices) of the test track and they was not visible. Except one very long triangle when I was in a special area. I moved the track 50 down so that it was like the car is flying. And voila: only special areas will be visible when the car is in a defined area.

 

So I satrted looking in the other files in the test folder. And here is what I found out about the BDB files:

There are 3 sections:

k_27 - here a binary tree is defined

k_2a - here regions of the track are defined

k_2b - here is defined which regions will be visible

 

In detail:

k_27:

There are two different types of subsections:

k_28 - a node of the tree

k_29 - a leaf of the tree

 

In detail:

k_28 (node):

(int) parent - the parent node

(int) child1 - the first child

(int) child2 - the second child

(float) x

(float) y > - a normalized vector (I only had z = 0 up to now)

(float) z /

(float) w - unknown

I do not know where the 4 floats are for.

 

k_29 (leaf):

(ushort) parent - the parent node

(ushort) offset_GDB_2E - a offset of entries from the matching GDB file (in the 2E section)

(ushort) number_GDB_2E - the number of entries from the matching GDB file (in the 2E section)

(short) region - the region from k_2a the car is in

(short) offsetVisualRegions

(short) numberOfVisualRegions

 

offset_GDB_2E and number_GDB_2E will be the reason why my first test (replace the test track with a very huge quad) does not work.

 

k_2a:

Six values define a cube (the region). The first three are the bottom left front corner - the other three the upper right back corner.

 

k_2b:

A list of ints that define which regions from k_2a are visible.

 

I do not know yet why the tree is needed or how it is analysed but the leafes of the tree define: When the car is in the region of the leaf (defined by the region) then the regions in the lists in k_2b will be visible (use numberOfVisualRegions at the offsetVisualRegions). (Maybe the tree is not so usefull in the test track but a powerfull sructure in the unidirectional racing tracks?)

 

The tree for the test track looks like this:

        |
      +-0---------------------------------------------------------+
      |                                                           |
    +-3---------------------------+                            +-29--------------+
    |                             |                            |                 |
  +-5-------+                  +-17------+                  +-31-----+        +-37----------+
  |         |                  |         |                  |        |        |             |
+-7-+     +-9---------+     +-19-+    +-21--------+      +-33-+   +-35-+    +-39----+     +-45-+
|   |     |           |     |    |    |           |      |    |   |    |    |       |     |    |
1   8  +-11--+     +-15-+   4   20  +-23-+     +-25--+   2   34  32   36  +-41-+  +-43-+  38   46
       |     |     |    |           |    |     |     |                    |    |  |    |
       6  +-13-+  10   16          18   24  +-27-+  26                   30   42 40   44
          |    |                            |    |
         12   14                           22   28

I will try to upload a few images tomorrow.

[Sluicer]

Here are the images with a little bit of description:

The test track has 24 regions (defined in k_2a):

The first leaf in the k_27 section is the following:

k_29
(ushort) 7   // parent node in the tree
(ushort) 0   // offset in GDB 2E
(ushort) 31  // number of elements in GBD 2E
(short) 0    // when the car is in this region
(short) 150  // offset in k_2B
(short) 18   // number of visual regions (values of the k_2B)

If you have a look at the referenced values of the k_2B you will find the following:

(int) 38
(int) 8
(int) 36
(int) 20
(int) 2
(int) 34
(int) 32
(int) 4
(int) 10
(int) 16
(int) 6
(int) 22
(int) 18
(int) 12
(int) 28
(int) 14
(int) 26
(int) 24

These are the leafs that will be also visible. If I visualize the regions in the leafs I get something like (red is the current region; blue are the additional visible regions):

The vertices I had added to the test track should have resulted in something like this (the yellow cube):

But since the last region is the green one I would never see my cube. Here is another example:

When the car is in the red box the blue ones will be visible.

 

So if we want to change tracks it is not enough to change the mesh files and the collide files. We also had to change the BDB files. And they have to fit on the GDB files!

[mumboking]

What would happen if you just made it so that the whole track is visible at all times? I'd assume modern PCs wouldn't struggle too much with that.

[Cirevam]

I'd like to see if that's possible too; just one big BDB box around the whole track. Plus it would make our lives easier when we start making tracks.

[Sluicer]

What would happen if you just made it so that the whole track is visible at all times? I'd assume modern PCs wouldn't struggle too much with that.

I gave it a try. At first I tried to use something like this:

k_27[(int)   1]
{
  k_29            // leaf
  (int)   -1      // parent node
  (ushort)   0    // offset GDB_2E
  (ushort)   401  // number of elements from GDB_2E (all)
  (short)   0     // actual region
  (short)   0     // offset visible regions
  (short)   0     // number visible regions
}
k_2a[(int)   1]
{
  (float)   -544
  (float)   -404
  (float)   -16
  (float)   485
  (float)   225
  (float)   97
}
k_2b[(int)   0]
{
}

But the game yelled: int expected. So I addad a value to the k_2B section:

k_27[(int)   1]
{
  k_29
  (int)   -1
  (ushort)   0
  (ushort)   401
  (short)   0
  (short)   0
  (short)   1        // increased
}
k_2a[(int)   1]
{
  (float)   -544
  (float)   -404
  (float)   -16
  (float)   485
  (float)   225
  (float)   97
}
k_2b[(int)   1]      // increased
{
  (int)   0          // added
}

And the game runs (I do not know if it is the best solution!?!). There still seems to be a fare plane but anything else was visible.

 

I tried to add my cube again (texture is grass). And its working!

[TrussROBLOX]

Nice job! One step closer to custom tracks.    

[Sluicer]

I do not know where the 4 floats are for.

Even if it not necessary any longer because

just one big BDB box around the whole track. Plus it would make our lives easier when we start making tracks.

is working, but I found out what the four floats are for. They discribe planes (one normal and a distance) to divide the 3D world in smaller sections. By this it is very fast to find the region the car is currently in.

The first node of the tree contains

(float) 1

(float) 0

(float) 0

(float) 101.2483

This describes the blue plane. When the x-coordinate of the car is greater than 101.2483 (or -101.2483; I am not really sure) we have to go to the left child of the current node.

That node contains

(float) 0

(float) 1

(float) 0

(float) 68.672

This describes the green plane. When the y-coordinate of the car is greater than 68.672 (or -68.672) we have to go to the left child of the current node.

That node contains the red plane. And so on until we reach a leafe. Then we know in which region the car is.

[KevinVG207]

I'm finally back after a couple months. Not too much has happened, but this is somr great stuff! It gives us a look on how they made the game run more smooth on old PCs and is great info for making our own tracks! :D