Advanced Tutorial: 3D Modelling

[Cirevam]

I think can delete files. I know I can't; I don't have the right permissions.

[Fluffy Cupcake]

I think

Let that thinking be put to rest with this post. He can.

[grappigegovert]

In line 9404 I made a little mistake. There must be a [22] (not a [4]). But I do not think that that is the reason for the failure.

The error 'expected right curly' seems to me that this actually was the reason for the failure.

Unfortunately I don't have time to test it right now.

[alan]

After I fixed all syntax errors (the number in [ ] brackets of the Indices section didn't match the actual number as well), a new error message has occurred:

[Sluicer]

I am sorry for the errors. It looks like I lost some indices.

 

I hope its ok if I post a new try. This time anything should match: https://ore.rockraidersunited.org/legacy/3001.gdb_120196.zip

 

There are two files in the archive. These are files that should both represent the standart 2x4 brick. One is scaled by 78.125 to reach the brick height of 75. The other is not scaled. Means: it has the same size as in the LDD.

 

I hope I am not bothering you but would someone like to try these two files in the game?

 

By the way: 1 / 78.125 = 0.0128. This is near 0.015625 (the scale in the files). 1 / 0.015625 = 64. How did you calculate the 75, the height of the bricks in the game?

[alan]

This time anything should match: https://ore.rockraidersunited.org/legacy/3001.gdb_120196.zip

 

 

[Jimbob]

By the way: 1 / 78.125 = 0.0128. This is near 0.015625 (the scale in the files). 1 / 0.015625 = 64. How did you calculate the 75, the height of the bricks in the game?

I used LDU (LDraw Units) to get an idea of how the width of a stud relates to the height of a plate, and hence a brick. Then I kept adjusting a block in-game until its width fitted perfectly to an in-game car's brick width, and used that to decide the stud width. Then I just converted that to height using LDU.

 

I said it was approximate though, although it seems to look alright on my STT.

[ProfessorBrickkeeper]

I think I need the game myself...

@Sluicer For basic modding purposes, you ought to be able to get by on the free demo version, which used only a slightly modified version of the 1999 game framework. You can find it here: https://archive.org/details/LegoRacersDemo

[Sluicer]

Small update:

 

I managed to insert a 1x1 brick into the game (source is LDD). 2x4 brick does not work, yet.

 

(Its not very good to see)

[Jimbob]

Awesome work! How long did it take to extract that part from LDD (excusing the errors along the way)?

 

On an unrelated note, I'll be adding the Texturing section to the tutorial soon. Texturing actually makes colouring and shading models incredibly simple, I've discovered.

[Sluicer]

How long did it take to extract that part from LDD

 

Not very long. That is something I have in my desc since brickset 113.3 (at least).

[Jimbob]

Aha! To redeem my dignity, I tested whether having Float values with 'e' in them would crash the game. They do!

 

(No, I didn't randomly stick in 'e' to a float, I used an actual number)

[Sluicer]

After removing the biggest subpart (100 vertices and 90 indices (the interior of the brick)) the 2x4 brick is also working. There must be some kind of limit below 255. The biggest value the 2x4 brick is using now is 48. The biggest value I found in the game till now is 67 (if I remember right).

[Jimbob]

You can have more than 255 vertices or indices, you just have to put them in separate lists (as grappigegovert explained >here, and I will add to my tutorial later). My Small Transport Truck mod has much more than 255.

 

But that's awesome to hear that you've got the 2x4 working too now.

[Sluicer]

You can have more than 255 vertices or indices, you just have to put them in separate lists (as grappigegovert explained here, and I will add to my tutorial later). My Small Transport Truck mod has much more than 255.

 

Ok - sorry - I was unspecific. What I ment was: I thought that in the Indices Range the second value is allowed to be between 0 and 255. Because the corresponding values are of type byte.

In my 2x4 brick the Indices Meta entrys for the inside of the brick reference to an amount of 100 vertices and 90 indices. This seems to be to big. Or lets say: The brick works when I remove this Indices Meta entrys (and reduce the entry amount):

k_2E    // Indices Meta
[28]                                               // reduce to 26
{
  k_27    // Material ID
  (ushort)0
  k_32    // Bone ID
  (ushort)0
  k_31    // Vertices Range
  (byte)0
  (ushort)0
  (ushort)20
  k_2D    // Indices Range
  (ushort)0
  (ushort)10
  k_31    // Vertices Range
  (byte)0
  (ushort)20
  (ushort)48
  k_2D    // Indices Range
  (ushort)10
  (ushort)48
  k_31    // Vertices Range
  (byte)0
  (ushort)68
  (ushort)48
  k_2D    // Indices Range
  (ushort)58
  (ushort)48
  k_31    // Vertices Range
  (byte)0
  (ushort)116
  (ushort)48
  k_2D    // Indices Range
  (ushort)106
  (ushort)48
  k_31    // Vertices Range for the inside         // remove
  (byte)0                                          // remove
  (ushort)164                                      // remove
  (ushort)100                                      // remove
  k_2D    // Indices Range for the inside          // remove
  (ushort)154                                      // remove
  (ushort)90                                       // remove
  k_31    // Vertices Range
  (byte)0
  (ushort)264
  (ushort)37
  k_2D    // Indices Range
  (ushort)244
  (ushort)36
  k_31    // Vertices Range
  (byte)0
  (ushort)301
  (ushort)37
  k_2D    // Indices Range
  (ushort)280
  (ushort)36
  k_31    // Vertices Range
  (byte)0
  (ushort)338
  (ushort)37
  k_2D    // Indices Range
  (ushort)316
  (ushort)36
  k_31    // Vertices Range
  (byte)0
  (ushort)375
  (ushort)37
  k_2D    // Indices Range
  (ushort)352
  (ushort)36
  k_31    // Vertices Range
  (byte)0
  (ushort)412
  (ushort)37
  k_2D    // Indices Range
  (ushort)388
  (ushort)36
  k_31    // Vertices Range
  (byte)0
  (ushort)449
  (ushort)37
  k_2D    // Indices Range
  (ushort)424
  (ushort)36
  k_31    // Vertices Range
  (byte)0
  (ushort)486
  (ushort)37
  k_2D    // Indices Range
  (ushort)460
  (ushort)36
  k_31    // Vertices Range
  (byte)0
  (ushort)523
  (ushort)37
  k_2D    // Indices Range
  (ushort)496
  (ushort)36
}

I will try to upload a new sample tomorrow (relative ).

 

Here is an image of the 2x4 brick (again not very good to see).

[Jimbob]

Hmmm, that's interesting. I guess I haven't gone beyond 100 myself. But I think ushort types can go up to 65535 or some similar number, so I don't understand that, plus 100 isn't a particularly binary number. Anyway, it's easily resolved by removing it as you did, or just splitting it into two smaller ones of 50 each.

[Brickulator]

This is pretty cool, lot of potential with this. Surely this should be stickied, if my boring old scene thread is?

[grappigegovert]

I ran into this problem too while working on my ply converter.
I think the max value for a vertex range length is 64.

 

O.T.	50 posts, yay! I wanted to release a ply->gdb converter with my 50th post, but I can't get it to work properly.

[Sluicer]

I think the max value for a vertex range length is 64.

Yes, looks like you are right. For the vertices range I found no higher value than 64 till now. The value I mentioned before (67) was for an indices range.

 

Anyway, it's easily resolved by removing it as you did, or just splitting it into two smaller ones of 50 each.

Yes, that is a solution but if I split it can became complicated. There will be vertices that needs to be used in both index ranges. I think there are at least two possible ways to resolve this:

1. Add the needed vertices twice
2. Use the techniqe that the game is using

The first one needs a bit more implementaion and the second one... I did not get it. I tried to extract the *.gdb files but every time when there is this overlap between two vertex ranges the model became mixed up. I think I only miss a small detail but I cant get it to work. And so I can not implement the other way around. I read your post

The 19th index is the first index in the 2nd range, you see that it contains a 0, but also a 31 and 30. If you were to convert it to the format you have now, the 0 would become 32 (0+vertex start) but the 31 and 30 stay the same to connect the 2nd range with the 1st range. In all the other indices you add 32 (vertex start)

but for me it does not work till now.

[le717]

Have you considered adding GDBump as an optional requirement?

 

Few questions for GDBump development:

• QP said all (byte) vales must be integers. You may want to mention that/comfirm/deny that but also, are ushort values also supposed to be integers?
• Although this would only happen unintentionally, since it supports changing of RGB values, should I cap those at values between 0 and 255?

 

Note on the tutorial: Material lists can be missing. There are in-game files this way.

[Jimbob]

1) Have you considered adding GDBump as an optional requirement?

 

Few questions for GDBump development:

• 2) QP said all (byte) vales must be integers. You may want to mention that/comfirm/deny that but also, are ushort values also supposed to be integers?
• 3) Although this would only happen unintentionally, since it supports changing of RGB values, should I cap those at values between 0 and 255?

 

4) Note on the tutorial: Material lists can be missing. There are in-game files this way.

1) Aha! Yep, added now.

 

2) Both the bytes and ushorts are integers, yes, but there's no reason for someone to make a mistake and give them decimals as they point to positions in the file, so it shouldn't be a problem.

 

3) I guess you could, yeah. If so, you'll probably want to include the Alpha one too, as that's capped at 255.

 

4) Um, I'm not sure what you mean by that... What in-game files? Besides, as I'll explain when I add the texturing part (I've nearly finished my STT now), it's much much better to use textures anyway.

 

P.S. Thanks for the pin!

[Quisoves Potoo]

So, I've been learning Python...

 

Gee-up, Rocket!

 

OMGz! :0
Rockut racr is mealstorm spie!

[Jimbob]

I don't even know what reaction I'm supposed to give to that, I love it!

 

Right, that's it - some day, someone has to make a Sonic model for LEGO Racers. Custom animations are possible so he could even move!

[le717]

So, I've been learning Python... -snip-

 

Surce code and byenary plz.

[KevinVG207]

Yes! Does it work with ply or obj?