WIP PTF Mesh Generator

[TChapman500]

Oh thanks. 12 channels matches my notes as well.

---

By the way, I've been testing the generator on the Tereana City Superspeedway. I set the quad size to 1 meter, LOD count to 8, max curved fence LOD index to 8. The generator was able to generate the mesh for the whole track in just ~145 ms. For reference, the C# version of the generator that I'm using in the Unity Engine takes ~1500 ms to do the same task for the same track.

 

[TChapman500]

Anyone up for dynamic mesh resolution? I've added it as an option that can be toggled on. It's complete with an option to adjust the sensitivity to changes in elevation gradients. The default is to double the number of quads on the segment for each percent of gradient change. This is only applied to straight segments though.

 

[Mystical]

Does this mean your sandbox program will make the 3d mesh thats used as the PTF in NR2003 will be more performance friendly where unnecessary segments are unneeded? Or is it just a visualizer?

I am guessing larger tracks are technically more performance heavy as the track is larger = more poly cunt has to be rendered for the surfaces.

 

[TChapman500]

I plan on using this generator in my sandbox replacement program. The default settings will result in low-resolution track segments in general, with straight segments that have little to no gradient changes having only a single quad length-wise. Also, larger tracks are not necessarily more performance heavy than small tracks though. It all depends on the geometry of the track, probably even more than the size of the track. But there may still be a weak correlation between track size and rendering/mesh generation performance. Most of the performance penalty will come from having to regenerate the mesh if a segment or section is moved. Bonus points if the vertex buffers need to be reallocated as well. The rendering is actually the relatively easy part in terms of the required processing power.

 

[TChapman500]

When you said that it uses channel 9, I assumed a zero-indexed list. I needed to put the shadow map coords into channel 8.

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:
View attachment 9125
so there are, I think, 12 uv maps reserved and I found that element 1 is basemap, 9 is litemap, 11 is specmap

By the way, I've got this now:

Other than the wall texture segments not generating properly, it looks like everything is working the way it's supposed to. Oh, that and the enormous bounding box size, which I believe is linked to the wall subsegments not working yet.

---

EDIT: I fixed all of the shadow map and subsegment issues. Though for some reason, some meshes are not merging properly under certain, unknown conditions. I will want to fix that before releasing the tool. But the tool is almost finished now.

---

EDIT 2: Fixed the meshes not merging properly. It was caused by 2 lines of code being out of order in the function that consolidated the materials. It looks like this tool is just about finished.

 

[TShirt]

Very good.

***
I notice that track materials (drivable surfaces) support bump/normals texture:

C:\NR2003\tracks\atlanta\atlanta.dat​

trackmat\asphbump.mip​

trackmat\grass_bump.mip​

Files are associated in C:\NR2003\tracks\shared.dat\trkembm.inf

;Here's where we associate a base texture with its bumpmap and envmap index​

trackmat\asphalt.mip 0 trackmat\asphbump.mip 0 7 0.6 0.3 1​

trackmat\grass.mip 0 trackmat\grass_bump.mip 0 7 0.8 0.6 1​

---The "7" (seven) would be the uv map index (yeah, zero-based here) for the normals tex?​

But the PAS format and make3do.exe do not support it---base,lite,spec,emap are the four available PAS inputs for tex config of a material.

Any thoughts on bump/normals textures in 3DO files?

 

[TChapman500]

Here's what I know about NR2003's Appearance node:

• Diffuse (base texture)
• Unknown
• Shadow Map (light map, 3DS Max's "self illumination" map)
• Specular Map (shineness map)
• Reflection Map (environment map)
• Reflection Mask?
• Unknown

It's very possible that normal maps are supported by the 3DO in the appearance node. There are two slots available. However, the "7" may be using a one-based indexing system if it refers to a material's texture slot (as there are only 7 slots). If it's referring to the UV channel, then it may be zero-indexed. I also can't help but notice the "1" and the end of each line. That may be a zero-based index into the material's texture list. I believe some experiments are in order.

As for the UV channels, other than the information you already provided, I do not know what any of them do. However, thanks to me putting the shadow map coords on the wrong channel, I now know that sandbox will quietly not load the 3DO if the wrong channel is set, and will give a vague "could not load" error message if you try to add it back.

 

[TShirt]

Thanks for your input. I don't like to be the one to tell but that list (its order) is incorrect.
The NR2003.exe (at offset (dec): 3492738) holds some strings --- most interestingly within what I find seems to resemble a 3DO file validator, its printout of stats.
Here as follows, the order of things matches my reading (however clumsy it is /1/) of known tex nomination:

0--- Base Texture:​

1--- Detail Texture:⠀⠀⠀⠀⠀---???​

2--- Light Map:​

3--- Bump Map:⠀⠀⠀⠀⠀⠀⠀---up for tests​

4--- Environment Map:​

5--- Specular Map:⠀⠀⠀⠀⠀---NOTE: spec is at 5 (not 3)​

6--- Morph Texture:⠀⠀⠀⠀⠀---???​

Most interesting affairs. To say that "I believe some experiments are in order" has to be the understatement of the month.
Agreeing with that (as I find normal maps do wonders for the dashboard etc. of a virtual cockpit), I'll plan to write the bump MIP at tex index 3 and some bump coords at uvm index 7 ...

/1/ My 3DO imports via python rather stand like the (Leaning) Tower of Pisa: they, well ... stand.

 

[TChapman500]

Interesting. At least the indices I needed for this mesh generator are correct. I will not be adding normal map support to my mesh generator. Nor will I be adding support for any other texture.

 

[TChapman500]

I know it's been a while since I posted on this thread, but I do have some relevant updates. First, thanks to the RE2003 project, I now know that the PTF file uses Cubic Hermite splines and not Bezier curves. Through experimentation with node weights (note that I don't actually have any code from the RE2003 project), I was able to find that a weight of exactly 1 produces an elevation profile that exactly matches what we are given in Sandbox and NR2003.

The screenshot below compares a segment generated with Sandbox with a segment generated with my mesh generator. I've changed the texture on the Sandbox-generated mesh on the reference segment with a bump map texture so that I can distinguish the two meshes. My mesh still uses the grass texture and has a resolution 4 times higher than the Sandbox-generated mesh. But where the vertices in the two meshes are supposed to meet, they meet in the exact place they are supposed to meet.

A couple more things: The length of the section is calculated by taking the average dlat of the section head + (tail - head) * 0.5 and calculating the length of the arc at that dlat. My generated mesh matches the Sandbox mesh exactly even on X sections that are not parallel to the segment. And I still don't have the exact values for replicating the wall lean on banked surfaces. But I've come very close to the exact values.