LEB Files

[Sluicer]

I had a chance to look closer in the LEB files. And this is what I found out so far:

 

The file has six sections:

k_28 // face definitions

k_29 // positions (3 numbers)

k_2A // normals (3 numbers)

k_28 // uv-map (here I am not sure)

k_2C // connection database (here I am not sure either)

k_27 // part meta

 

With the information I collected I am able to extract or generate parts. Here is a sample (L241900):

The most cryptic part is in the first section (k_28 // face definitions). I will try to give you more detaild information tomorrow.

 

[Sluicer]

I am sorry. I did not found enouth time. So here is a little cryptic information:

LPIECELO.LEB:

k_28 [29057]
k_29 [2000]
k_2A [979]
k_2B [547]
k_2C [1830]
k_27 [161]

k_29 expects 2000 values but there are 6000 numbers. So this invites to create 2000 3D vectors: the positions. There is no position twice!
k_2A expects 979 values but there are 2937 numbers. This also invites to create 979 3D vectors: the normals. There is no normal twice!
k_2B expects 547 values but there are 1094 numbers. This invites to create 547 2D vectors: maybe uv-map data.
k_2C expects 1830 balues but there are 3660 numbers. This also invites to create tupels.

k_27 defines the 161 parts (parts, assemblies and chassis) that are contained in the file. For each part there are a name and 4 values (a selection):

Cylinder 2048 0 16 0          
L241900 5001 2 80 93          
[...]
L300200 5005 29 12 695        
L300300 5006 36 12 737        
L300400 5007 41 12 779        
[...]
s00003 5046 179 36 2978       
s243200 5051 188 26 3201      
[...]
sspider 5190 827 40 16159     
[...]
VVCHAS0 22 1768 150 28437    

I think the values are:

• an internal id
• offset in k_2c
• number of triangle definitions in k_28
• offset in k_28

For example:

L300200 5005 29 12 695   

Part 3002 (Brick 2x3)

• internal id 5005
• offset in k_2c: 29 - since there are tupels in k_2c we have to look at the numbers from 2x29=58 (top and bottom is hypothesis):

    2    // Matrix x
    3    // Matrix y --> x*y = 6 --> next 12 values contain data for this part
    131  // x = 1; y = 1 bottom
    128  // x = 1; y = 1 top
    131  // x = 2; y = 1 bottom
    128  // x = 2; y = 1 top
    131  // x = 3; y = 1 bottom
    128  // x = 3; y = 1 top
    131  // x = 1; y = 2 bottom
    128  // x = 1; y = 2 top
    131  // x = 2; y = 2 bottom
    128  // x = 2; y = 2 top
    131  // x = 3; y = 2 bottom
    128  // x = 3; y = 2 top

• number of triangle definitions: 12 (a brick has six sides --> 12 triangles)
• offset in k_28: the definition for the triangles starts at the 695th number (I have reorganized them; first numer is always triangle type; p is position, n is normal):

    0        25    4    69    75   // normal side triangle p1 n1 p2 p3 (normal is for all points)
    40960    72                    // normal side triangle but use p3 p2 from previous and new p4 (normal is the same as previous)
    0        77    1    74    76
    40960    73
    0        69    5    25    73
    40960    76
    0        74    0    77    72
    40960    75
    1        72    3    69    74  // normal top triangle p1 n1 p2 p3 (normal is for all points)
    40961    73                   // normal top triangle but use p3 p2 from previous and new p4 (normal is the same as previous)
    2        75    2    77    25  // normal bottom triangle p1 n1 p2 p3 (normal is for all points)
    40962    76                   // normal bottom triangle but use p3 p2 from previous and new p4 (normal is the same as previous)

More to come

[lol username]

So, those IDs are the standard IDs LEGO uses to identify bricks:

http://www.bricklink.com/catalogItem.asp?P=2419

http://www.bricklink.com/catalogItem.asp?P=3002

How does the game identify parts that don't exist in real life, or "parts" that are actually assemblies of parts? For example, this part is split into two parts in the game, and the spoilers, headlights, etc would obviously be assemblies of different parts IRL. Many car parts in LR1 are of course stuck to other pieces so they align vertically with entire bricks rather than plates (like that 3x6 wedge), but I'm talking about assemblies that don't really feature a single piece like that.

[Sluicer]

For example, this part is split into two parts in the game

The names are L239901 and L239902.

 

and the spoilers, headlights, etc would obviously be assemblies of different parts IRL. Many car parts in LR1 are of course stuck to other pieces so they align vertically with entire bricks rather than plates (like that 3x6 wedge), but I'm talking about assemblies that don't really feature a single piece like that.

 

s00003 is the treasure chest with an 1x4 plate (I think)

S00007 is the camera

S00014 is the scorpion

s00017 is the crossbow

s00021 is the I think pirate flag from CR

s00022 or s00023 could be the headlights

s00029 is the parrot

s243200 is an assembly of two 1x2 plates and 2432 Tile, Modified 1 x 2 with Handle

s243201 is the rear spoiler

sa0010 and sa0011 are two schields (with support); sshield1 and sshield1 are some special shields

*CHAS are the chassis (e.g. BBCHAS0, BVBCHA0, DACHAS0, etc.)

salndsh and salnds2 are the alien antennas

saxe and saxe2 are the long knight axes

spear is the small spear

spizza will be the pizza :-)

sprtgun and sprtgun2 are the guns at the side of a brick

sRRpipe and sRRpipe are the pipes from RR car

 

and so on.

 

I will try to create an overview. But at first I will have to do a little more research.

[Sluicer]

I will try to create an overview.

I created an image will all available parts (LPIECELO.LEB):

Cylinder L241900  l248900  L287700  L300200  L300300  L300400  L301000  L303800  L303900  L304000  L304900  L329700  L329800  
l347500  L362200  l395700  L416100  L428600  l474600  L656400  L656500  L81423   L81926   L82527   L82528   L82529   L82530   
s00003   s243200  S00007   S00008   s00011   S00014   S00016   s00017   sa0010   sa0011   srrwndw  srrgril  L300100  L239901  
L239902  L304500  L347800  S00018   s00019   S00020   s00021   s00022   s00023   S243201  s395700  SA0012   sadm_flg sFlag    
SLamp    sLance   sLance01 sTorch   s00026   s00027   s00028   Spear    sSpear   sSpear1  sdrum    srrgril2 sFRgril  sFRrgril
sRRTgril spizza   scylnder SRRcube  srocket  srocket1 sRRpipe  sRRpipe1 SVV0001  SVV0002  SVv0003  SVv0004  SVv0005  sVv0007  
sVv0008  SVv0009  SVv0010  sVvflg   SdsrtH1  SdsrtH2  SdsrtH3  Sdsrth4  sdsrtltr sdsrtlty Sdsrtmag sdsrtax1 sdsrtax2 Sdsrtwdw
sdsrtgrl Sdsrtsd1 Sdsrtsd2 Sdsrtbox Sjungem  Saln1    Saln2    Saln3    Saln4    Saln5    Saln6    Saln7    Saln8    Saln9    
salnpst  salnps2  Salnds2  Salndsh  Salngem  Sjunmap  Stnt     Sjundash sspider  Samazon  S00029   s00030   S00031   S00032   
srifle1  srifle02 Sidol    Sjunhood Sjunprop Sshield1 Sshield2 SWand    Sbat     sSWORD   sSWORD01 Saxe     Saxe1    sprt_flg
sprtfnce sprtswd  sprtswd2 sprtoar  sprtoar2 sprtgun  sprtgun2 Sprtprt  sbckpak 

And here are the Chassis:

JTchas0  GM_CHAS0 BVBCHA0  BBCHAS0  CRchas0  KKCHAS0  DACHAS0  DBCHAS0  DCCHAS0  DDCHAS0  RRchas0  VVCHAS0 

In the triangle type (at least I call it so) the last byte defines which material should be used for the triangle. In the images above I only show the first three materials (LPIECELO.MDB) in differen colors:

black is 'unassign'

blue is 'bottom' (why is there no blue?)

green is 'nub' (that is the texture for studs)

[Sluicer]

5 of 6 (this included) posts of this thread are mine!

 

Let the studs raise:

 

They are starting to appear in the game:

 

 

(This stud is only a clone of that one you can see in the building section)

 

The LPIECEHI.LEB is used for building.

The LPIECELO.LEB is used during the races (at least for me).

[Sluicer]

6 of 7

 

Here are two files that contain replacement data for the bricks 3001, 3002, 3003, 3004 and 3010. Both files are the same but one is used in the garage and one is used in the races. Maybe someone is interested in testing.  The source for the meshes is again the LDD.

[Fluffy Cupcake]

Oh, cool!

I completely overlooked this thread until now.

[Car CrazeXVI]

I figured I'd try this out.

Aww yeeaahh.

Wait, what happened to the studs?

Um… I don't think this is supposed to happen.

[Sluicer]

I figured I'd try this out.

Thank you for the try.

 

Wait, what happened to the studs?

This is the first time I have seen that. There seems to be a triangle limit in the garage and in the races. Stupid test, but here you can see the phenomenon (the white bricks use my studs the gray bricks use that of the game):

When I add one more brick to this model the game studs disappear (got replaced by the textures):

When I continue adding bricks, even the textures disappear. In the following image the back of the car is full with 2x4 bricks. But you cant see them .

That is bad. Maybe there is a parameter somewhere, but where? Looks like it was all a waste-of-time .

[Cirevam]

Maybe we can replace all of the low-poly bricks with high-poly ones? I'm guessing the game is loading low-poly bricks when you add too many instead of intelligently removing polygons. We don't need to worry about the textures being removed if the studs stay on no matter what.

[Sluicer]

Maybe we can replace all of the low-poly bricks with high-poly ones?

That is exactly what I started to do. But in the model in the 3rd image I build at least nine 2x4 bricks at the back of the car. But you can only see five. The rest stays hidden! Sorry.

[grappigegovert]

I looked at this with cheatengine.
There is a value stored in [0x4c4918]+0x40ec (1999 nodrm), which looks like the amount of polygons.
Bricks will start losing textures/disappearing when this value reaches 2500.

Maybe there is a way to bypass this limit.

However it also looks like the game does have some kind of system to remove unnecessary polygons when stacking identical bricks.
When stacking bricks with your studs it also removes some polygons, but almost none in comparison to the added amount.
The polygons to be removed might be in the leb files aswell (are there some brick metadata values you left untouched perhaps?)

[Fluffy Cupcake]

Bricks will start losing textures/disappearing when this value reaches 2500.

Maybe there is a way to bypass this limit.

Modified .exe?

 

Two instances of "00 40 1C 45" (2500 float) come up in the .exe when checking big endian, 0 for little endian.

One instance  of "00 00 40 9C" (2500 hex)   come up in the .exe when checking big endian, 0 for little endian.

 

This is in the 2001 version.

[Sluicer]

Wow, there are the skilled people. Thank you.

I looked at this with cheatengine.

Cool, I do not know that tool, yet. Maybe I should have a closer look!

However it also looks like the game does have some kind of system to remove unnecessary polygons when stacking identical bricks. When stacking bricks with your studs it also removes some polygons, but almost none in comparison to the added amount. The polygons to be removed might be in the leb files aswell (are there some brick metadata values you left untouched perhaps?)

Indeed! The bricks themselves does not have the studs.

Here you can see the part 6564 in the LO version, in the HI version, the bounding box with meta data (I added the studs) and the new HD version (gray is the 'unassign' material, green is the 'nub' material).
The bounding box (at least I call it so) defines in a matrix (here 2 x 3) the top and the bottom height of the box and if there is a stud (value >= 128). It is defined in the k_2c section.
For the example piece:

131 128  // stud in height 3; (under) stud in height 0
131 128  // stud in height 3; (under) stud in height 0
131 128  // stud in height 3; (under) stud in height 0
131 128  // stud in height 3; (under) stud in height 0
  3  64  // no stud but heigt 3; no idea in height 0
  3  64  // no stud but heigt 3; no idea in height 0

I can imagine that if a stud meets a understud, it will disappear. Since I did not change the k_2c data, also the old studs appear in the garage. When they are hidden by a new stud you can't see them but they are there. That will be the polygons that got removed.

In the races the stud metadata (from k_2c) is ignored. There the material (nub) will be used. So I had to add the studs to the meshes.

 

One instance of "00 00 40 9C" (2500 hex) come up in the .exe when checking big endian, 0 for little endian.

I do not understand that. The hex value vor (signed int) 2500 is either 0xC4090000 or 0x000009C4?

 

[Fluffy Cupcake]

One instance of "00 00 40 9C" (2500 hex) come up in the .exe when checking big endian, 0 for little endian.

I do not understand that. The hex value vor (signed int) 2500 is either 0xC4090000 or 0x000009C4?

Well I wasn't sure what endian type Racers uses, so I checked both.