WIP PTF Mesh Generator

TChapman500

TChapman500

Test Rank
Joined
Jun 28, 2022
Posts
125
Reaction score
40
Points
28
Website
gaming.tchapman500.com
Over the past month or so, I've been working on a mesh generator to create meshes from PTF files. Currently, I'm just doing it so that I can make my own simulator (using Unity to prototype), but I intend to take what I've learned here to (1) make a better Sandbox (all previous attempts at doing that have failed), and (2) be able to make 3DO files from PTF files, complete with multiple LODs. Here's what the mesh looks like so far:

Wall Generator Working.png
 
This looks like it would be great for prototyping. I too plan on trying to develop my own NASCAR style racing game, but am not sure whether to go full realism like NR2003, or slightly more arcade ala the lines of the NASCAR Thunder series. Though considering you actually have coding and reverse engineering technical know how and I don't, you probably have a much better head start.
 
Last edited:
An arcade game is probably easier than a simulator. But both are hard work as you need a good physics and rendering engine, tracks to race on and vehicles to drive, and a good scoring system that's hard to break.
I've got the mesh generator working to a satisfactory level now. So I'm going to work on generating a mesh for curved catch fences. In terms of NR2003 modding, the tool I'm going to make with this knowledge to generate 3DOs from PTFs will make 3D SimEd obsolete. I also think I'll make a 3DO decompiler which will generate 1 3DO for every mesh inside a given source 3DO, which should help with using 3D SimEd for 3DO conversion to other formats.
 
I finally got curved catch fences working (sort of). The left and right faces of the fence are generating properly, but I have not yet tested the generation for the top, near, or far faces of the fence. But that should come soon. I just need to test to see that the V coordinates generate correctly when the texture isn't stretched across the entire height of the wall first.
Curved Fences.png
 
I just finished-up the tweaks to the wall mesh generator. Now I'm going to make the final tweaks to the surface mesh generator. Then I suppose I should convert the code from C# to C++. This took me about 2 months to do, starting with converting the 3DO and PTF readers from C++ to C#. And by the way, I'm definitely going to be making a PTF to 3DO utility.
Wall Generator Finished.png
 
in blender python, I'm working on a PTF importer as well
... focusing on base geometry (x_sections) as reference for .CAM and .LP file editing


my results so far are okay---this stuff is not easy, or without issues
but it's okay, oval results are matching with sandbox .DXF
(differences are in the sixth decimal place (meter units) of coords' Y component)

***
.CAM and .LP file editing
 
The track maker v..1.7 if you can make a track a xml it'll take and make a ptf that the game can read
 
CenterLine (April 2003) by AxaptaCoder and WhiteFalcon
⠀⠀https://sourceforge.net/projects/centerline/files/centerline/
⠀⠀it reads some .XML, and can save to valid .PTF
⠀⠀(on my end, the app's drawing method is not working: integer overflow issue)
⠀⠀they also uploaded their source code (.vb)
⠀⠀https://sourceforge.net/p/centerline/code/

p2x_alpha.zip⠀⠀contains php script to access .PTF files (and converts to .XML)
⠀⠀http://www.thepits.us/files/n2003/mods/n2003_editing_tools.zip
 
What I'm working on isn't for importing into any modeling programs. It's strictly for converting track geometry to a 3DO file to make it easier to make multi-configuration tracks and at least have a visual representation of the parts of the track not being used. And even this, this is basically another solution to hold us over until I can finish Sandbox 2. And this will basically replace 3D SimEd for converting PTF files to 3DO files.

Also, I'm pretty much finished writing the code that gets point data from segments and X sections. Then after that, I'll be writing the code that generates the mesh (complete with tri-stripping and other optimizations).
 
You can use it to make the. Whole track in to 3do and it. It Will make the. Track iin segments.
 
I've got a few ideas on command line parameters to customize how the 3DOs are generated. For example:
Generate a number of LoDs.
Starting resolution of LoD 0.
First and last segment to generate 3DOs of.
Start and end dlongs to generate 3DOs of.
Whether to generate multiple 3DOs (generally one 3DO per segment).

And a few more, but I'm kind of getting ahead of myself.
 
I ran some tests also now the last one is when you export to bob track builder you will get a bunch of numbers. if you make a point for each line you will have the track but no walls or grass.
 

Attachments

  • Autodesk 3ds Max 8 TEST.jpg
    Autodesk 3ds Max 8 TEST.jpg
    237.3 KB · Views: 9
  • blender-TEST.jpg
    blender-TEST.jpg
    176 KB · Views: 9
  • BTB TEST.jpg
    BTB TEST.jpg
    133.1 KB · Views: 9
TShirt said:
CenterLine (April 2003) by AxaptaCoder and WhiteFalcon
⠀⠀https://sourceforge.net/projects/centerline/files/centerline/
⠀⠀it reads some .XML, and can save to valid .PTF
⠀⠀(on my end, the app's drawing method is not working: integer overflow issue)
⠀⠀they also uploaded their source code (.vb)
⠀⠀https://sourceforge.net/p/centerline/code/

p2x_alpha.zip⠀⠀contains php script to access .PTF files (and converts to .XML)
⠀⠀http://www.thepits.us/files/n2003/mods/n2003_editing_tools.zip
Click to expand...
This use .xtf files which comes with the editing tools.
 
Wireframe template generator complete. On to the mesh generator. For expediency, I'm skipping support for X Section nodes that are not set to "Absolute". This will require you to select "rebuild track" in Sandbox until I implement it, but at least we're going to get something. The wireframe template is what the mesh generator will use for the majority of its calculations.
 
Initial tests aren't going well. I'm having a lot of trouble getting the normals to generate correctly. I think it's a problem with my vectors library. On the plus side, it currently takes about 0.15 seconds to generate 3DOs of the Tereana City Superspeedway with a quad size of 4 meters (no walls). The wireframe template itself takes 0.1 seconds to generate. And that's with the debug build. It takes about 0.08 seconds for the release build to build the mesh.

Edit: Fixed the normal issues.
 
Last edited:
Here's what I got so far. The code to generate this mesh is already a mess, so I'm going to try to optimize it. Basically trying to optimize as I go so. I'm also using 3D SimEd as the renderer, though my mesh generator is already better than 3D SimEd in several areas (eg: properly scaling elevation of curved segments, and properly generating euclidian section geometry).
1771893692211.png
 
And here's the texture coord generation working. Did you know that the PTF file stores both the scaling data for surface and wall textures as well as the texture coordinates at each corner of the surface and wall face? This screenshot was taken after using the pre-generated texture coordinates stored in the PTF file, rather than the texture scaling data also stored in the PTF file.
1771972401603.png
 
I timed the Unity version of the generator to generate the surfaces in ~220 ms, and to generate the surfaces, walls, and LODs in ~1,500 ms. My utility simply generates the surfaces of 1 LOD in ~70 ms. So I'm estimating it'll take ~480 ms to generate surfaces, walls, and all of the LODs. Before I timed the Unity version, I estimated that the C++ version would take ~600 ms to generate surfaces, walls, and LODs. I just added LODs to the C++ version of the generator and it now takes ~300 ms to generate the surfaces at all of the LODs, which is on par with what I expected. Though that's partially because it's calling the functions responsible for generating the walls, which aren't fully implemented yet. Without calling these dead functions, it's still taking ~190 ms to generate the surfaces at all of the LODs. Though for some reason, it's failing to write the files when generating LODs.

EDIT: Fixed the issue with the LODs causing the files to not be written.
 
Last edited:
So I modified the generator to read the texture files BEFORE entering the generation loop (each texture gets read once for the whole program). The generation time for my test mesh is now ~80 ms with LODs and ~35 ms without LODs. Both with 1-meter quads. I've just hardcoded a default resolution of 1-meter quads and 8 LODs. My test track now takes ~25 ms to generate the mesh. Still don't have much in the way of walls though. But I do have the wall ends implemented. And I discovered that the default wall end texture breaks 3D SimEd.
1772706723902.png
 
Got wall generation working. Curved fences coming soon. There's also a switch available in the program to toggle generation of curved fences. And another switch to skew the walls so that they appear in the 3DO as they would appear in Sandbox or NR2003. Again, I'm using 3D SimEd as the renderer, but this generator is already better than 3D SimEd when it comes to the track's elevation profile.
1772824362529.png
 
I don't know why this is, but I decided to test out my existing code on walls that change their height from one end of the segment to the other, and I got the correct results. Though I don't know why this is. Now to generate curved catch fences.
1775761911341.png
 
And there we go! Curved catch fences. Now all I need to do is to check this against Sandbox to see if the meshes are identical. Sort of. The mesh generated here extrudes walls perpendicularly to the surface. NR2003 skews the angle a little bit. I've basically made two assumptions:
  1. The extrusion angle is 1.5 times the banking at the given point along the segment.
  2. The fence curve follows the extrusion angle in both the X and Y axes (relative to the cross section of the segment at the given point along the segment).
Plus, I still need to implement generation of shadow map coordinates and make shadow map generation togglable through a command line parameter. Unfortunately, I don't know what part of the vertex array NR2003 stores the shadow map channel's coordinates. Not yet, anyways.
1775833722949.png
 
I've finished tweaking the mesh generator for the walls. Curved fences on banked surfaces are NOT exactly what is shown in Sandbox, but it's close enough. If you get the camera close enough to clip through the geometry, you will notice an occasional pixel of skybox leaking through the seam. And the multiplier value I'm using to get it that close has 4 decimal places of precision. And barring a decompiling of NR2003, I doubt we'll ever know the exact constant that was used. The skew that NR2003 applies to walls on banked surfaces is nothing like what I expected.

For curved catch fences, the normals used for the lighting are not the same as the normals used to generate the skew. The normals used for lighting are actually tangent to the surface the wall is on. And if that wasn't bad enough, the normals don't bother curving with the fence. The normal used by the straight part of the fence's profile is the normal used for the entire height of the fence. Something tells me that this is also true of walls without curved profiles. So I have adjusted the generator accordingly. As to why Papyrus didn't just use the correct equations for extruding truly perpendicular walls in the first place, we will probably never know.

Not only will I need a flag to toggle the generation of shadow map UV coords, I will also need a flag that toggles which normals are used by the walls. For NR2003, you will want to use the following flags:
  • -curved_fences
  • -skewed_walls
And if you want to see what it would look like if Papyrus used the more intuitive algorithms, use these flags instead:
  • -curved_fences
  • -correct_wall_normals
I will also need to update the C# version of the library eventually, but I might wait to do that until after I do testing on where NR2003 expects the shadow map coords to be in a 3DO file. That's basically the only thing holding me back from implementing shadow maps right now. That and I think I've had enough of this project for today. It took me at least 4.5 hours of trial and error to tweak the wall skew and normal settings. And that's after the time spend implementing curved fences in the first place.
 
good work T.C.

re 3DO uv maps---well yeah ... there are quite a lot of them
hope this helps:
in the "tdo_imp.py" script of blender papynr2003,
... in the function "get_plain_vertex_list_descriptor" (esp. from line 549 on),
... the maps (base, light, spec/shine) are obtained the following way:
aaa.png
so there are, I think, 12 uv maps reserved and I found that element 1 is basemap, 9 is litemap, 11 is specmap
 
You must log in or register to reply here.

Similar threads

TChapman500
WIP 3DO/PTF Reader/Writer
2
Replies
31
Views
7K
TChapman500
TChapman500
Who read this thread (Total readers: 16)
Back
Top