2015: What is keeping us away from creating custom tracks?

[TheChief]

Simple answer of course, we know what files we need to edit but we either don't know exactly how to edit them or with the current means, it would take too long to edit them for a proper result.

Let me sum a few things that I think are worth some (more) investigation, along with a few questions I have about certain files.

1. 3D Model files (.GDB). First of all, I have seen a possibility to edit the code directly to add and remove textures, objects and so on. This might take some time, but has anyone tried to create a simple .GDB model with a square of grass and a circle of road to ride on? For a first try, a track does not need to contain any more objects, its just intended to see and exiperiment with model editing this way. Secondly, I have seen a .GDB to .PLY converter; very useful for use with the above, but in addition: a little bit of programming could create an .EXE file doing the opposite: converting .PLY to .GDB. Blender can convert models to .PLY, we could add textures to the track in code like mentioned in one of the tutorials.

2. Checkpoint files (.CPB). These look like they are not very hard to edit, as the location and direction of each checkpoint is listed quite clearly. With use of the .GDB file, it might be not that much work to find out what the exact checkpoint coordinates and directions should be.

3. AI Path files (.RPB). Not quick a must at this early stage of custom track creation as without the files an AI would just stand on it's startposition; meaning the track model could be tested, played in Versus Mode or even in Time Trial Mode. Isn't this defining the waypoints in the created track? With use of the .GDB file, it might not be that much work to find out what the exact waypoint coordinates should be.

4. Collision Meshes (.BVB). This is where I see that custom collision mesh and a simple custom test track have been created. I think several collide possibilities (like onroad, offroad, etc.) are defined and that they could be changed. Don't know for sure, though.

5. Lego bricks: Anyone succeeded in changing the positions, adding them or removing them? I bet someone did it at least once.

6. Custom audio: Is already documented and possible, right?

7. .BDB files: Are doomed to match the .GDB files. Won't give a lot of problems when the whole track is set to be visible.

Of course I have forgotten some files that might desperately need editing, please mention them. I could also be completely wrong about something I've just said, but I think that at this point, we would be able to create a simple custom track: take the circle in a square track if you please. I wonder what the current progress is on reseach, and what exactly need to be investigated before we can create our own tracks. Maybe I can help :).

Greetings,

TheChief

[MaelstromIslander]

1. This has been possible. We've known how to edit models (http://www.rockraidersunited.com/topic/6072-small-transport-truck/) but the only thing holding us back is that its quite hard (Jimbob's transport truck took a while to make and its just a car) and too much work.

2. I think we've edited the checkpoints before. And IIRC its not hard to edit so you're right there.

3. Done before, however, if you don't do it correctly the racers will go through the track (Collide meshes don't affect them)

4. IIRC we're still working on that. Don't know the current progress though.

5. We've known this for a long time. Its been done much more than once as a matter of fact.

6. Yes, we can do custom audio. However some things (like the horribly screwed up A.I. voices) cannot be changed.

7. I forgot what the .BDB files were/did. I think they were the object files... (the UFO, the Imperial Armada ship in Imperial Grand Prix, etc.) Maybe someone else can explain this?

I think i've seen screenshots of an editted Test Track (it was turned into a flat plane) but thats blurry in my memory.

Correct me if i'm wrong on any of the above.

[TheChief]

Correct, it was a flat plane indeed.

So the main problem is that creating the track model is too much work to do in code. Then why not use some coding to make that .GDB to .PLY converter into a .PLY to .GDB converter? If we can do it one way, the reverse should not be that much of a problem. Then try out a few really simple models that you already have, or that you create in a 3D modelling program, convert it to .PLY using Blender, use that converter and done. I don't think the actual developers of the game coded all the tracks themselve, but just created them and then converted them with a tool.

Though, the plane with a circle idea still stands, I think, because that should not be that much to code and is great for some first real custom track tests. Take that plane, make circle on it, assign collision meshes, AI paths, LEGO bricks, etc.

So as it sounds now, were just waiting for that .PLY to .GDB converter to come out. Or have I missed anything else?

[MaelstromIslander]

So the main problem is that creating the track model is too much work to do in code. Then why not use some coding to make that .GDB to .PLY converter into a .PLY to .GDB converter? If we can do it one way, the reverse should not be that much of a problem.

 The reason a .PLY to .GDB converter doesn't exist is probably because such a thing could screw up the model (like this: http://s5.postimg.org/riz2nhcsn/KKDebris.png) beyond repair.

[Sluicer]

I have created a new test 'track'. It is a flat cube and I can drive in it. But that is not all. It is easy to create .GDB files. I used files from the LDD to create cars and buildings. In the test track I can ignore checkpoints and ai paths. And now comes the complex parts: the BVB and the BDB files. With the BDB files you are right. It is easy to create a file that make the whole track visible. But in the BVB files there is a tree at the end of the hex file and I did not found the time yet to create an algorithm that generates this tree. In a race track you will also need a checkpoint .BVB - again with that tree.

I do not know the .PLY files. I use .OBJ files or .LDR files. The problem is, that e.g. the triangles in the BDB files need additional information (wall, drive through, ...). You can not define that in a .OBJ file.

If you are willing to create a new track, you might upload a .OBJ file and I will try to create a .GDB file out of it (I am not a designer). This would only be the first step - but maybe worth a try.

Attached you can find my test track. Hope it still works. I can not run the game currently. The texture is from RockRaiders. I wanted to create a RockRaides test track but did not have the time to .

TEST.zip

[Fluffy Cupcake]

Attached you can find my test track.

TEST.zip

​We still don't have permission to view/download attachments right now, only upload, it seems.

 

If you are willing to create a new track, you might upload a .OBJ file and I will try to create a .GDB file out of it (I am not a designer). This would only be the first step - but maybe worth a try.

I have a textured test track I made back in November if you would like to try that. Here it is in .obj, I didn't use any vertex colors: -Link Outdated-

It even has a ball-o-physics for gravity testing.

[Jimbob]

I know your questions have been answered already, but I thought I'd provide relevant links for each one. Apologies if I get anything here incorrectly.

1. 3D model files (.GDB). As Mael pointed out, I've created one through code here. I also have a tutorial on creating .GDB models through code here. I believe someone was working on a way to convert 3D .PLY models into GDB files, but I could be wrong as I have an awful memory.  And Sluicer is also working on similar conversions as stated above.

2. & 3. Checkpoint files (.CPB) / AI path files (.RRB). Correct me if I'm wrong, but I think Rob has made a full overhaul mod here which changed these files.

4. Collision Meshes (.BVB). You said you've already seen progress here, but for anyone else looking, the research topic is here.

5. LEGO bricks. Yep, Oboe created a mod which adds new colours here, as did Car Craze here. As for adding new shapes entirely, I'm sure it's possible but I assume it requires more work in the .BVB department. If it just requires .GDB editing though, I imagine it could be done now if other parts' collision meshes are used.

6. Custom audio. Ba-da-bam, we have a nice tutorial on this courtesy of le717 here and an example music mod here. There may be a sound mod somewhere too.

7. .BDB files. Not sure what these are, but the topic is here.

I hope this helps!

 

EDIT: With the forum update, I noticed some links in those topics are broken (they appear with an > before them for me). Sorry about that, I guess I'll go through all my topics and fix them at some point.

Edited April 29, 2015 by JimbobJeffers

[MaelstromIslander]

Turns out the .BDB files are rendering files which describe if your car is in a certain region, areas in the distance's models (IIRC) are smaller, so they don't have to render the entire track in full size without old computers (modern back then) struggling with it.

Oh and about LEGO Bricks, I think TheCheif meant Power bricks, not building bricks, Jimbob. But I could be wrong.

By the way, are .GDB files exclusive to Tracks, or do they work for minifigures, cars, hats, etc.?

Edited April 29, 2015 by MaelstromIslander

[TheChief]

@MaelstromIslander: Do you know why the models end up like that? Maybe it was a mistake in code. .GDB to .PLY converter works great, why would the other way around be impossible?

@Sluicer: Can't download the file. That tree in the .BVB file, does it look similar for different for the different Lego Racers tracks? That could be interesting. Yes, .BDB files and .BVB files will need to know what the use of some of the polygons is (road, wall, offroad, etc.). Maybe using different polygons in the .obj file could make it easier to assign those? I don't know.

@Xiron: Nice model.

@Jimbobjeffers: For Lego Bricks, I actually meant the powerup bricks on the tracks, but I saw that it is possible to change positions and colours for them as well.

So to conclude: The .GDB 3D Models aren't quite that much of a deal, the collision meshes (.BVB) and corresponding .BDB files is what takes the most time, because they aren't fully examined and understood yet.

1. Can be done with a lot of time, hopefully a good tool for modelling will be created. 2 and 3 we are able to do. 4 needs some work. 5 and 6 can be done. 7 can be done, but may be investigated a bit more. Does not sound very bad at all. Keep me updated.

[grappigegovert]

By the way, are .GDB files exclusive to Tracks, or do they work for minifigures, cars, hats, etc.?

​.GDB files are just 3d meshes (with colors etc.), so all 3D objects in the game use .GDB files.
The .BVB and .BDB files are exclusive to tracks as far as I know.

Do you know why the models end up like that? 

Probably because my .PLY converter does NOT work great. It only works properly with a few.GDB files, and I haven't taken the time to update it yet.

For the AI paths, I have a modified version of my ghost path recorder that records AI paths, but I can't get the timing correct.

Edited April 29, 2015 by grappigegovert

[Sluicer]

I have a textured test track I made back in November if you would like to try that. Here it is in .obj, I didn't use any vertex colors: https://www.dropbox.com/s/5va8tuxgkgdvl0m/Experiment.zip?dl=0

I have downloaded the file. I will give it a try.

It even has a ball-o-physics for gravity testing.

​I used a cylinder for that . You can not drive on walls or upside down. My steepest driveable section had 67.5°. If you leave it alone the car is rolling downwards.

@Sluicer: Can't download the file. That tree in the .BVB file, does it look similar for different for the different Lego Racers tracks? That could be interesting. Yes, .BDB files and .BVB files will need to know what the use of some of the polygons is (road, wall, offroad, etc.). Maybe using different polygons in the .obj file could make it easier to assign those? I don't know.

It might be the best to use different colors to describe the different area types. One color named wall, etc.

So to conclude: The .GDB 3D Models aren't quite that much of a deal, the collision meshes (.BVB) and corresponding .BDB files is what takes the most time, because they aren't fully examined and understood yet.

Well, I would say that I have understood both files. I created some myself and the game is working with them. But it is not easy to create them. if you have only concave section the tree will be a list. But as soon as you have convex sections it will become a binary search tree. The track will be splitted up into more and more sections until you have reached each colliding triangle (in .BVB). Some entries might appear multiple times in the tree other only once. I have currently no working algorithm to split these things up. So I can not create complex tracks yet.

[TheChief]

@grappigegovert: Great to see that you have found a way to record AI paths on a track. Good for use in a later stage. If you don't have much time, maybe you can share your codes and stuff with someone who does have more time then you (providing he or she can code).

@Sluicer: Yes, colours will probably work great as well. Good idea, actually.

No creating complex tracks yet, maybe you can give a short overview of what you and others are able to create? The expressing concave section and convex sections don't say a lot to me. Nice to hear that you understood the files, that is always step one in creating them.

I can see that a lot is possible already, so that there is a lot of potential. Keep the good work up. Now I start to wonder what tools the developers used for creating the tracks can't believe they would all code it by hand.

[MaelstromIslander]

Do you know why the models end up like that? Maybe it was a mistake in code. .GDB to .PLY converter works great, why would the other way around be impossible?

 Its not a mistake, its just that because its a different format it has its own coordinates and mapping, and if you change it to .PLY reality sets in, and the very strange .GDB's coordinates and mapping are uncovered to be a mishmash of insanity only known as King Kauhka, lord of crazy .GDB models that explode if you change the format, long lost brother to King Kahuka only that Veronica Voltage in her high state took him away and placed him in the game, and compressed his body, soul, and sole into a file format, the .GDB files.

[RobExplorien]

For the AI paths, I have a modified version of my ghost path recorder that records AI paths, but I can't get the timing correct.

​I'm wondering, could the bytes of each node in an AI's path be the times in milliseconds between two succesive nodes? If so, these are generally measured at 200 millisecond intervals (though that is a rough estimate, it really depends on the correlation with displacement every node). Then again, you also had the problem of exceeding the relative height (ascending or descending) if your intervals were too big for the displacement to be stored, right? Perhaps, to solve this, you can keep record of the overflow may it occur, and then pass that on to the next node's byte, as a ripple-carry adder would do too with its overflow, until your overflow record is back at 0 again. The path may then look a little unproperly aligned at some times, but it does evade the mess-up of z-position.

NOTE: the quoting got a little messy

Edited April 30, 2015 by RobExplorien

[Sluicer]

I have a textured test track I made back in November if you would like to try that. Here it is in .obj, I didn't use any vertex colors: https://www.dropbox.com/s/5va8tuxgkgdvl0m/Experiment.zip?dl=0

It even has a ball-o-physics for gravity testing.

​I was able to generate a valid .GDB file (no textures yet):

Some of the triangles are wrong in the .OBJ file:

 

Edited April 30, 2015 by Sluicer

[MaelstromIslander]

I have a textured test track I made back in November if you would like to try that. Here it is in .obj, I didn't use any vertex colors: https://www.dropbox.com/s/5va8tuxgkgdvl0m/Experiment.zip?dl=0

It even has a ball-o-physics for gravity testing.

​I was able to generate a valid .GDB file (no textures yet):

-snip-

Some of the triangles are wrong in the .OBJ file:

-snip-

​Yay, its a LEGO City!

Or Roadland, "The Road to Another Road", sponsored by Roadpowder, Powder For Your Road.

I bet the mayor lives in that sphere, plotting to terrorize our .GDB's with the DNA of King Kauhka and turning them all into mashed potatos!

[Fluffy Cupcake]

Cool.

Do I need to scale up the map Sluicer? It looks small. Actually, having a proper sized dummy car would be very useful.

Is the red the flipped stuff? Because when I opened my map the only thing I could find flipped the wrong way is the topside of the ramp, which you showed in-game.

 

I uploaded a new version:

Scaled x2, fixed ramp triangles, moved physics ball to be grounded (it was floating).

-Removed For Being Outdated-

What would be the best way for me to export the faces? The options are by Triangles, Quads, Or Polygons. The first time I did Quads because it was on that by default. I went triangles this time.

[TheChief]

@Sluicer: Great work. U can actually drive on that track, right? Xiron has already done something on custom texturing, maybe he can color it a bit more nicely, I don't know.
I'm curious what comes out of the second version.

By the way, maybe you can tell us how u actually created the .GDB and other files? Then I can try it once for myself too :D.

[Fluffy Cupcake]

Xiron has already done something on custom texturing, maybe he can color it a bit more nicely, I don't know.

​Are you talking about when I replaced textures on tracks that were already in the game? This is a totally different story here.

Also, the track I gave Sluicer came fully pre-textured, they just haven't been put on when it got converted to GDB.

[Sluicer]

Do I need to scale up the map Sluicer? It looks small. Actually, having a proper sized dummy car would be very useful.

No, I have scaled your data by 1/50. But this was only for the first test. The cars in the game have a different scaling. Maybe you should have a look at the obj files I shared here:

That are tracks of the game.

Is the red the flipped stuff? Because when I opened my map the only thing I could find flipped the wrong way is the topside of the ramp, which you showed in-game.

Yes, the red triangles are flipped. You will not see them. You can see the sphere because you see the inner side.

What would be the best way for me to export the faces? The options are by Triangles, Quads, Or Polygons. The first time I did Quads because it was on that by default. I went triangles this time.

​In your first .obj file I only found triangles. The game is also working with triangles. I did not found the time yet to have a look in your new file.

@Sluicer: Great work. U can actually drive on that track, right? Xiron has already done something on custom texturing, maybe he can color it a bit more nicely, I don't know.​

No I can not drive on that track. I am driving in my old box (flying over the track). The box is much smaller than Xirons track. So I can only fly over a small section. Sorry, but there will be much to do.

By the way, maybe you can tell us how u actually created the .GDB and other files? Then I can try it once for myself too :D.

​I use the descriptions here in the forums and write binaryfiles with c#.

Are you talking about when I replaced textures on tracks that were already in the game? This is a totally different story here.

Also, the track I gave Sluicer came fully pre-textured, they just haven't been put on when it got converted to GDB.

​Xiron is right. If you convert the GBD file in a ttext file it contains more than 78000 lines. I will put a hand on here.

Sorry for the short answers. I am a little bit out of time.

[TheChief]

@Sluicer: Short answers are always better then no answers, thanks! Did you write the .GDB by hand? In the 3D Modelling tutorial I find a tutorial for placing a cube in a track, but coding a whole track is at a much larger scale. How did you come up with those 78000 lines? (U mean, 78000 lines in the .GDB file with floats and bytes, right?). Not being able to drive on the track sounds like its got to do with collision mesh. Did you mean with the box that it was ur box with the flat cube I saw and that Xiron's model is place around it but you can still only drive in your box? (sorry, wierd sentence).

Yes, a lot of work to do but you guys also achieved great things. Keep the work up!

[Fluffy Cupcake]

 

Is the red the flipped stuff? Because when I opened my map the only thing I could find flipped the wrong way is the topside of the ramp, which you showed in-game.

Yes, the red triangles are flipped. You will not see them. You can see the sphere because you see the inner side.

Alright, I created a clone of the sphere and flipped all the normals. Hopefully it works correctly now.

https://www.dropbox.com/s/5va8tuxgkgdvl0m/Experiment.zip?dl=0

I also downloaded the .obj and scale my track down to their size.

[Sluicer]

@Sluicer: Short answers are always better then no answers, thanks! Did you write the .GDB by hand? In the 3D Modelling tutorial I find a tutorial for placing a cube in a track, but coding a whole track is at a much larger scale. How did you come up with those 78000 lines? (U mean, 78000 lines in the .GDB file with floats and bytes, right?). Not being able to drive on the track sounds like its got to do with collision mesh. Did you mean with the box that it was ur box with the flat cube I saw and that Xiron's model is place around it but you can still only drive in your box? (sorry, wierd sentence).

Yes, a lot of work to do but you guys also achieved great things. Keep the work up!

​No, I did not code the track by hand. I used Xirons obj file. I parsed it with a tool and then generated the gdb file out of it. the gdb file is a binary file. For quiet some time there exists a BinaryEditor implemented by WillKirkby that can open and write these binary files. I wrote a small converter that converts the binary file in a txt file myself so that I can read it with a normal text editor. When I generate the track from Xiron into a gdb file and generate then a txt file out of it, the file contains 150408 lines (last track version). It should be similar in the BinaryEditor.

Currently I can only drive in a small box (the transparent blue area):

This is due to my first test track: a simple box. There the collision was easy to calculate.

Alright, I created a clone of the sphere and flipped all the normals. Hopefully it works correctly now.

https://www.dropbox.com/s/5va8tuxgkgdvl0m/Experiment.zip?dl=0

I also downloaded the .obj and scale my track down to their size.

​I gave it a try. There are still some triangles wrong but it is much better now. I am not sure why, but I had to scale the track again. The following results are scaled by 5.

I hope the dummy texture was a better choise this time.

That is it for today.

Edited May 1, 2015 by Sluicer

[TheChief]

@Sluicer: Yes, that would make more sense to do. I know about the binary editor, it gave me a first insight into the Lego Racers files. Pretty ossem tool. I already thought it would be because of your first test simple box track. Since you are able to drive on the whole blue area, are you able to drive up to the, ehm, whatever for an object that is I see in your second picture?

Looks pretty good, nice work.

[Fluffy Cupcake]

Since you are able to drive on the whole blue area, are you able to drive up to the, ehm, whatever for an object that is I see in your second picture?

​If you wanted a cleaner view you could of just asked.

These should help:

http://postimg.org/image/ik5u6d9tv/

http://postimg.org/image/mht3vrwn7/