Gdb

[Jimbob]

Thanks both o' ya'll! I plan to write a tutorial on scratch-building models soon.

 

Thats purposeful and the modellers were being clever. The Modellers knew that the Player wouldn't look behind the Menu's high Poly models and saved space by not including a behind to the model.

Hey, that's what I told you earlier!

[Fluffy Cupcake]

 

 

Thats purposeful and the modellers were being clever. The Modellers knew that the Player wouldn't look behind the Menu's high Poly models and saved space by not including a behind to the model.

Or, they just didn't want to waste their time on something no one will be able to see in the game. That's why Jimbob wrote "depending on how you look at it".

If you're a 3D modeler, you'd know it takes more work removing faces then keeping them. At least when using preset shapes and not building the model with your bare hands planes.

[joeytheleo]

Wow this is some awesome progress! Looks like we are getting closer to switching individual parts of the AI minifigs!

[Car CrazeXVI]

These experiments have unveiled new modding potential for those willing to exploit it, so l thank you for that.

 

I wounder why you only got the face. You'd think there'd be an entire head…
 

something no one will be able to see in the game.

Not so. We can see the backs in the builder and in Rocket's intro.

[Sluicer]

A 3D image of the RACE0R1 track with one ai path. For this track my export works perfectly - for the test track sadly not. There are still some triangles that does not work correctly.

The red triangles have vertices in a different (always the previous) vertex range.

[Sluicer]

There are still some triangles that does not work correctly.

It looks like I managed it.

This is the test track.

The red triangles are the ones with vertices at the end of the previous vertex range. I could handle them also the last time.

The blue triangles are the ones that did not work. Now they work. The reference vertices at the beginning or the previous vertex range.

 

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.

 

Here are exports of two other gdb files of the RACEC0R1 folder:

SHIP01:

and LINE06:

[grappigegovert]

I managed it.

[Jimbob]

 

Spiffing work, sir!

[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 changed smaller things and it worked:

 

 

I divided each z coordinate by 10. Z is the up coordinate. The gate, the flags and some other things are in a different file.

 

I do not know yet why some of the textures are mixed up/change while I am driving.

[grappigegovert]

Sluicer (or anyone else that knows), how do you know exactly which indices are referencing vertices in the previous range?

[Jimbob]

I haven't done this for a while, let me think... If I recall correctly, the Indices Meta section sets the ranges of Vertices and Indices to use. The Vertices and Indices lists themselves start from zero as a result.

At least that's how it works with cars, if you check out my file here you'll hopefully see what I mean - at the bottom the Indices Meta specifies a range of Vertices and Indices to use for a specific part. The Indices/Vertices lists don't connect with each other directly.

[grappigegovert]

Thanks Jimbob, but that was not what I asked.
I was asking about what Sluicer discovered 5 posts above, of which he did not reveal the technical details yet.

Edited April 29, 2015 by grappigegovert

[Jimbob]

Ah, my apologies. I did wonder as I thought you had a handle on what I'd described already.

Edited April 30, 2015 by JimbobJeffers

[Sluicer]

Sluicer (or anyone else that knows), how do you know exactly which indices are referencing vertices in the previous range?

​I am sorry, I totally missed your post. It looks like I have still some issues with the new forum.

The indices are defined in the k_2e section in the subsections k_31 (or the struct 1a).

  (1a)            // indexList
  {
    (byte) 0      // relIndexOffset
    (ushort) 0    // indexOffset
    (ushort) 40   // numberOfIndices
  }

At first I substract the relIndexOffset from the index.

If the result is bigger than the amount of vertices in the current vertexList you have to use the index in the previous vertexList, respecting the
relIndexOffest from the previous indexList.

If the result is smaller than 0 you can simply use the index in the previous vertexList.

If the result is in the amount of vertices in the current vertexList you can use the calculated index in the current vertexList.

foreach (i in indexList)
{
  index = i - indexList.relIndexOffset
  if (index >= vertexList.numberOfVertices)
  {
    vertex = previousVertexList[i - previousIndexList.relIndexOffset]
  }
  else if (index < 0)
  {
    vertex = previousVertexList
  }
  else
  {
    vertex = vertexList[index]
  }
}

Maybe there is an better way, but this is the way I found out. I hope it is undersandable?

[grappigegovert]

Thanks Sluicer, it works great.
The code made it very understandable, although you forgot a small thing:

else if (index < 0)
  {
    vertex = previousVertexList[i ]
  }

Edit: I now know why the [ i] was missing in your post, it's just because the new wysiwyg editor doesn't like it.

Edited May 7, 2015 by grappigegovert