Open Madness Track Tools

Well, I put my first track model into the game... Very low res screenshot because in this moment I am using a laptop not capable of running the game properly, haha.

It was actualy easier than I thought... And the tools work as a charm using GNU/Linux.

 

Did you find any part of the initial process to be too confusing, too unorthodox ("there must be a better way to do X step"/"it would be easier if I could do Y for this step instead of X"), or too complicated for what you think would be required? I'm trying to discover any ways in which I could improve the workflow, focusing now on the initial steps (as no one is yet as experienced with using the toolkit as I am, so we can't discuss more advanced stuff with confidence yet).

 

I don't know if this is intentional, but if you set a .dds file as a shader parameter (EPT_TEXTURE type) and later uncheck it, the scene exporter still copies the texture to the textures folder.
Nothing major, you just have to use the clear button of the file path.

 

That's not intended; I'll look into fixing that.

 

I've been stuck for 2 days, have done countless tests and everything I could think off, but I can't seem to debug this:
I have a working version of my track and its associated .blend file. I can reliably export the scene, pack it, and it works every single time.
Now if I go and add even a simple mesh (a cube or a plane) and assign a known to be working material/shader configuration, the game gets stuck on the track loading screen (at about 1/3 of the loading bar. Have observed that problematic visual objects usually stuck there).
Things I've tried among others:

• Tried well known shaders like rz_basic and new_ground
• Used textures from the example project instead of mine
• Copied shader parameters from the example project
• Made sure there were no extra vertex attributes or custom normals
• Placed the mesh closer to the origin (track is big, was initially far away)
• Changed track filenames (including the object names in Blender) to Uppercase
• Tried with/without UV compression
• Checked for correct face normals
• Moved the object out of nested collections (shouldn't matter but still)

Deleting the object (and its meb + mtx) and re-exporting, makes the track load fine.
@ohyeah2389 I know it's hard to debug such a thing and there's still the possibility I'm missing something very obvious (most likely!). I'd hate to waste your time but if you feel you can give this a go, I could send the .blend file, textures, and the track folder structure with all the placeholder files.
Or I'd appreciate if you can share some tips of where I could start looking to tackle this.

 

I've been having a similar issue with my Mid-Ohio model, and it's mainly why I haven't released an update for it yet. There seems to be some form of race condition being triggered for certain counts of materials/meshes, and where that line is is not well defined. I have no idea how to fix this and I don't know exactly what's causing it, nor do I have any ideas of what could be happening; we obviously don't have the tools to debug what's actually going wrong in the loading process that's triggering this freeze.

To be more specific, when I try to use more than 16 materials on Mid-Ohio, the freeze occurs, which is strange because G&J successfully uses 23 materials without issue.

So we can have more statistics on this, please do the following:
- Flush your template folder by deleting the MEBs and MTXs from the Tracks/TrackName folder
- Perform a scene export of the known working configuration
- Count the number of resultant MEB and MTX files in the template Tracks/TrackName folder and post those counts here

The latest working config of G&J has 156 MEBs and 23 MTXs.
The latest working config (more advanced than the latest public release) of Mid-Ohio has 146 MEBs and 16 MTXs.

Also, as a workaround, try setting up the new mesh as part of a combine group with an existing mesh, and see if it loads successfully.

 

Thanks for the quick reply! (and even if it's bad news, at least I'm happy I'm not alone in this )
Here's my findings. Working version of my track has:

MEB = 33, MTX = 5
Visual meshes (before deduplication, as Blender stats show) - vertices = 902.489, triangles = 1.669.601

If you want me to also get the vertex count of the phys/SMS/trigger meshes please say so.
I also did some object combining tests with an existing (A) and the new offending (B) object.

• Both assigned A's material-> Track loads and renders them successfully
• A kept it's original material, B assigned an existing material from another object -> Track loads and renders them successfully
• A kept it's original material, B assigned a newly created material -> Track fails to load

Unfortunately most of my 33 objects are close to the limit of 65k vertex count, and that is only the terrain, roads, and roadlines! I was about to start placing foliage, posts, signs, etc, but I'll put it on ice for the time being.
Thanks for your help and I hope we discover what tricks the engine plays. If you need any beta testing or want me to try anything feel free to ask!

 

Has anyone found a way to get working billboard trees? (the ones that rotate to always face the camera).
I manged to get a mesh rendered with the "basic_billboard_trees" shader but it only shows at very certain camera angles, it doesn't rotate with the view, and beyond those certain angles it disappears.

 

I haven't tried much yet; if you find anything out, let us know!

 

Just FYI for anyone, whose track isn't loading, try and delete unused files before packing the track.

What I mean is for example your track uses objects A, B and C. For whatever reason you decide object B is no longer of use so you hide/delete it from your blender file. When packing up the track via the PackTrack.exe, it will also pack the mtx and meb files leftover from the previous export, where you had object B. This causes the track not to load (gets stuck at 1/3 of the way).

 

v0.2.0 has been released: https://github.com/ohyeah2389/Open-Madness-Track-Tools/releases/tag/v0.2.0

It contains fixes to issues mentioned by @VirusGR42 @immortalx and others, as well as quality-of-life improvements and fixes for certain loading hangs.

 

Thanks a million for the toolset.
Was able to successfully run the workflow on the example project. Track is recognized by the game and is loading. Just noticed that the size of exported live track .mrdf file is higher compared to the file of the example project.
Is that maybe because of a different target cell count?

 

Likely, yes; the size of the MRDF will vary both with the target cell count and how many cells are actually included (depending on the mask area).

 

Hi @ohyeah2389, our team is also now looking into extending our portfolio from Skinpacks to track mods. We currently have 2 very well known race tracks in the works that likely will never be in AMS2 from Reiza´s side.

We too had the issue that some things load, some things won´t. I noticed that it definitely has something to do with the Materials. Not necessarily to the Materials which are connected via the Plugin that have to show up in the game, but maybe even the Materials inside Blender. When I set my Track, the white lines and the curb on my ´´Road´´ Blender Material, everything shows up in AMS2. With other Blender Materials they sometimes not show up. Now the weird thing is they sometimes switch materials around after exporting with the .dds Materials which are different to the Blender Materials I use. So that means while the Curbs do have the correct Material, the track somehow has the same Material suddenly in AMS2, even though it was set to be and Asphalt Material before. After exporting it´s shown like it is in AMS2.
If you need more insights from us, feel free to join our [AMS2] F1 Seasons Discord where we show off all of our work and there we can give you access to our private channels for our tracks that we are working on.