Tracks Pittsburgh International Race Complex LiDAR "Tech Demo" 0.2

[phloozy]

I enabled extended physics, are you running the latest public version of CSP?

I fixed it, I needed the most recent untested patch.

 

[ohyeah2389]

ohyeah2389 updated Pittsburgh International Race Complex LiDAR "Tech Demo" with a new update entry:

Not the update I promised, but still an evolution

I went off and did some research projects on Geometry Nodes in Blender, and I discovered some things and made some useful node trees. I haven't figured out how to do everything, but I did figure out two things: how to generate a convincing terrain mesh and attach it to the track, and how to do a separate physics mesh that meets properly with the edge of the track.
View attachment 584439
All this means two things:
1. The grass has been expanded out to fill the entire area of...

Read the rest of this update entry...

 

[Ryno917]

Just stumbled on this, after just discovering the real circuit the other day in a historic Formula Ford FB group. Looked like a fantastic layout, so I'm excited to see this being worked on.

 

[macko68]

Not to discourage you but there will be a full rf2 convertion. I've got a permission from author and we are about to finalize it soon. All 5 layouts. "Whereisthebeef" did amazing job for rf2. He got worked with latest Lidar and put a lot of effort into it. Track objects and even the tarmac patches are just like in real life. Personally I love this track. The layout and flow are just pure fun. Stay tuned for this weekend release

 

[Johnr777]

Not to discourage you but there will be a full rf2 convertion. I've got a permission from author and we are about to finalize it soon. All 5 layouts. "Whereisthebeef" did amazing job for rf2. He got worked with latest Lidar and put a lot of effort into it. Track objects and even the tarmac patches are just like in real life. Personally I love this track. The layout and flow are just pure fun. Stay tuned for this weekend release

Scratch built RF2 not the same as scratch built AC...

 

[ohyeah2389]

Not to discourage you but there will be a full rf2 convertion. I've got a permission from author and we are about to finalize it soon. All 5 layouts. "Whereisthebeef" did amazing job for rf2. He got worked with latest Lidar and put a lot of effort into it. Track objects and even the tarmac patches are just like in real life. Personally I love this track. The layout and flow are just pure fun. Stay tuned for this weekend release

Ok. Good luck. I'll be waiting for it, and I'll test it when it comes out.

Scratch built RF2 not the same as scratch built AC...

That's true, but if they know what they're doing, and pay attention to the physical mesh and the shaders, then it should be pretty good. We'll have to wait and see though, if macko68 is the one doing most of the conversion work, they haven't uploaded anything to RD yet for me to judge them on.


Until that conversion comes out and we can all test it (or sufficient time has past that indicates to me that the conversion project has been abandoned), I've got a backup plan already in motion. I was working on it to see if I could do a track almost entirely in Geometry Nodes, but it didn't quite work (I couldn't figure out how to do curbs, and it was insanely slow to update). I eventually figured out how to use Geometry Nodes as part of a larger modifier stack to achieve more flexible results. Someday, when all modifiers are fully represented inside of Blender's Geometry Nodes, I might be able to make a fully Geo Nodes track.

The aerial laserscan of this track is actually even higher quality (0.25m-0.75m horiz) than Pitt's (0.4m-1m), but not by a mile.

I'll put it up on RD soon.

 

[Ryno917]

Any chance you could shed some light on your geometry nodes workflow for the terrain? I'd love to see what exactly you're achieving with it and what the goals are.

I've briefly had a look at using it to scatter trees, for instance, but I really haven't even dug into that basic of functionality for it yet

 

[ohyeah2389]

Any chance you could shed some light on your geometry nodes workflow for the terrain? I'd love to see what exactly you're achieving with it and what the goals are.

I've briefly had a look at using it to scatter trees, for instance, but I really haven't even dug into that basic of functionality for it yet

First of all, Blender's Geometry Nodes system has a few key nodes in it that completely delete any UV data sent through them. This is a know issue due to old design decisions that the Blender team are working to solve: https://developer.blender.org/T85962
This means, while there exist addons like Graswald's GScatter https://www.graswald3d.com/gscatter that appear to be able to scatter trees and bushes (and grass, but CSP makes that unnecessary), you'll run into 2 problems when using them:

Problem 1. All GScatter is is a wrapper for Geometry Nodes that makes it easier to use. It auto-generates and configures a Geo Nodes node tree for you, and you could do everything that it could do yourself. What it does, in basic terms, is instance an object (or a random object picked from a collection) on some points that have been scattered on a surface according to an algorithm of your design. Instance is the key word here; instances don't work properly with AC; they cause issues with materials: https://assettocorsamods.net/thread...-fbx_material-txdiffuse-null.2899/#post-20409
To fix this, you need to add a "Realize Instances" node at the end of either your own or GScatter's node tree, but then you'll run in to...

Problem 2: The "Realize Instances" node kills the UV data, making your trees either invisible or one solid color.

The workaround is to apply the Geo Node modifier without the "Realize Instances" node present, and then make all the instances of tree objects either real or just one object. I don't like that, because, being raised on parametric modeling, I'm a big proponent of non-destructive workflows. Whatever the problem is, it can be solved in Blender, but if you want to make a change to some fundamental aspect of it, you'll probably have to redo quite a few steps if you aren't:
* Making node-based materials,
* Making Geo Nodes objects,
* Using a crazy, insane, overcomplicated, laggy modifier stack...
...all of which I have experience with.

On to your question...

Initially, I said I was going to try do to the entire terrain system in Geo Nodes, and I got pretty close, but due to the way Geo Nodes is coded (and my relative inexperience with optimizing it), it was extremely laggy and took about 30sec to 1min30sec to update after I changed even the smallest thing.

Instead, I turned back to the Modifier system, using one (and another, but I'll talk about that at the end) Geo Nodes modifier in between several other modifiers, which I will go through now:

Here's the end result...

...and here's the modifiers that make it happen...

...and here's the source mesh before the modifiers:

Here's what all the modifiers do, an image of the config for them, and an image of how the terrain differs after they are turned on:

Initial - No Modifiers

Subdivision - Multiplies the resolution of the base grid by 2.

Shrinkwrap1 - Snaps the vertices of the mesh to the full-resolution DEM.

GeometryNodes - RaceTrackForge_AdaptiveSubdTerrain - RaceTrackForge is the name for my Geometry Nodes node trees which I have created to assist me in the track modeling process. I may release them publicly along with a demo project at some point in the future, once they and Blender's Geo Nodes mature some more. AdaptiveSubdTerrain is loosely based on this Blender StackExchange answer: https://blender.stackexchange.com/q...rain-lod-system-stiching-holes-on-lod-borders and is intended to provide more precision to the terrain mesh in the areas directly adjacent to the track.

\/ continued below \/

 

[ohyeah2389]

Triangulate1 - This triangulates the mesh. I know you're kinda supposed to keep everything quads in AC, and I did keep the physical track mesh as quads, but the terrain should be fine with tris.

Boolean - This cuts out the extra terrain impinging upon the track itself, and in doing so, adds extra vertices to the terrain mesh in order for it to correctly snap to the track. "MainTrackThicc" is the physical mesh, without shrinkwraps, but with a Solidify modifier of 20m and an offset of 0 to expand the track 10m up and down to provide a good boolean source.

Shrinkwrap2 - Same as Shrinkwrap1, needed to position the edge verts closer to the track mesh.

DataTransfer - Vertex Groups - This causes the edge verts that are right next to the track to become part of the "TransferToEdgeVertices" vertex group. The vertex group "AllVertices" is part of MainTrackThicc, and all verts in MainTrackThicc are assigned to it.

[no visible change in mesh]

Shrinkwrap3 - This snaps the vertices that are part of the aforementioned "TransferToEdgeVertices" group to the closest vertex of the track mesh.

Weld - The Shrinkwrap3 modifier can sometimes snap 2 vertices to the same location, as the above process produces more edge vertices than neccesary; this takes care of them.


\/ continued below \/

 

[ohyeah2389]

[no visible change in mesh]

Triangulate2 - The above process can produce quads or n-gons adjacent to the track; this makes them tris.

Here's a larger shot of the terrain before the next modifier...

Decimate - This "optimizes" the mesh in a way that keeps its shape, but greatly reduces the number of vertices to a more reasonable number. It also then triangulates the resulting mesh.

GeometryNodes - RaceTrackForge_MeshSelectorAbsoluteDistance - This is a modification of the RaceTrackForge_MeshSelector node tree. The RaceTrackForge_MeshSelector node tree is designed for the track physical mesh; as Assetto Corsa can only handle 65535 verts per object, this allows me to "select" which parts of a mesh are "visible" to AC. That way, I can have duplicates of a single mesh that are all the same, but each one only has around 30000 verts "selected". I use this method https://assettocorsamods.net/threads/road-how-to-physical-and-visual-layer.996/#post-10226 to reduce the computation time of each piece. RaceTrackForge_MeshSelector is based on this Blender StackExchange answer (which I asked): https://blender.stackexchange.com/q...s-in-a-way-that-modifiers-can-still-affect-th
RaceTrackForge_MeshSelectorAbsoluteDistance's modification is that it selects faces based on absolute distance in the X direction, rather than along the track's length.

\/ continued below \/

 

[ohyeah2389]

DataTransfer - UVs - In the above process, the UVs are not correctly preserved, so I take a 2d plane with correct UVs and project its UVs onto the terrain pieces.

(texture for demonstration and placeholder purposes only)

That's about it. If you or anyone else has any other questions, comments, or helpful tips for me or others, please post them.

 

[Ryno917]

@ohyeah2389 This is awesome. Thanks for the detailed run-through, I'm going to have to bookmark this for later

I, too, come from a parametric background (Solidworks from 2004-2020, then I decided to make the change to OnShape in my firm) so there's a lot of the poly model workflow that makes me uncomfortable. That's why the node workflow is so interesting to me. I sadly just haven't had the time to really dig into it myself, yet. I was not aware that it can kill the UVs, so that's good to know!

I know about the 'multi user objects' issue in Blender 2.8+ as I currently work with them a lot and I just put up with the materials issues until I'm ready to collapse things. Or, alternately, I append all of those objects into a file in 2.79 to use the old FBX exporter where it's not an issue at all. In my own WIP circuit I've got all the foliage in its own KN5 for this reason; I've named the objects in a way to easily append them all into a 2.79 scene for their own foliage FBX export. Same for the smaller buildings and crowd vehicles (which are also instanced).

Once I'm further along, and set with the objects and their locations, I'll start making them unique and grouping into objects.

Thanks again for the info! I'll be watching this space for more developments Do you think there's a viable way with geo nodes to make road surfaces from multiple curves and automatically handle the intersections?

 

[ohyeah2389]

Do you think there's a viable way with geo nodes to make road surfaces from multiple curves and automatically handle the intersections?

There probably is, to be honest I haven't gotten to that part yet and was just going to do it "by hand". But then I have to juggle the issue of what driving surfaces do I make have separate phys and vis components-- I can't just do everything like that, even escape roads and runoff-- well I could, but it seems like a waste of time, and then how would I get the grass to attach to both the runoff and the track, while having the runoff attach to the track, and the vis track attaching to the phys track...

...and I just remembered that I have to do a transition mesh with a little groove between the track and grass-- but can I just make that part of the phys layer? And how do I wrap it along the edge of the track, and then attach the grass to it-- but it's not the track it has to attach to, it's the edge of any asphalt...

...and then there's CURBS! I've been doing the baby easy method of curbs up until very recently, which is to just have the curb be a seperate, non-connected 3d model, but that's dumb, or at least I think it is?

If Assetto Corsa assigned physics properties to objects based on the name of their MATERIALS, not the name of the objects themselves, this would be an order of magnitude or two easier, because you could have just one single mesh for the entire track, terrain, and curb surface, with no need to do any of that stuff I mentioned above at all-- but Blender would need to support Vertex Groups more robustly, such as in the Subd modifier-- or would you need to invent, like, face groups, or something weird like that?

I feel like I'm putting the cart before the horse when it comes to my modeling process, but I don't want to live in a world where we have to force horses to draw carts, if you get my analogy.

I do wonder how 3DSmax handles these things, but I don't really want to find out by myself on principle...

 

[pugsang]

Well this is the rf2 conversion

 

[Mitch9]

Well this is the rf2 conversion

What´s the point of bringing this up in someone's pet project? Seems to me that this is as much about the process as it is about the track, who cares if theres another version to be released?

 

[ohyeah2389]

What´s the point of bringing this up in someone's pet project? Seems to me that this is as much about the process as it is about the track, who cares if theres another version to be released?

I already said I’m going to switch from working on this to working on another track until I can personally test the conversion. How the other track was made, or at least how it looks in editor, is somewhat relevant.

 

[Ryno917]

There probably is, to be honest I haven't gotten to that part yet and was just going to do it "by hand".

This is basically all I've been able to find... But even then, I'm not sure how to get a smooth transition in any reasonable way. If I make two separate road surface as arrays on a curve, even if I do bridge the gap, how can I make it smooth without having to go in and manually adjust every single bridging edge/vertex by eye to make it feel smooth? Applying a subd modifier would apply to everything, too, potentially compromising other areas.

I'm still yet to find any type of tutorial for this workflow. All intersection type stuff I can find is for people making, more or less, flat intersections where height differences aren't even a thing. Or, at the very lease, they're making stuff that's not meant for racing sims where a smooth transition is of high importance; not just something that looks smooth.

 

[ohyeah2389]

This is basically all I've been able to find... But even then, I'm not sure how to get a smooth transition in any reasonable way. If I make two separate road surface as arrays on a curve, even if I do bridge the gap, how can I make it smooth without having to go in and manually adjust every single bridging edge/vertex by eye to make it feel smooth? Applying a subd modifier would apply to everything, too, potentially compromising other areas.

I'm still yet to find any type of tutorial for this workflow. All intersection type stuff I can find is for people making, more or less, flat intersections where height differences aren't even a thing. Or, at the very lease, they're making stuff that's not meant for racing sims where a smooth transition is of high importance; not just something that looks smooth.

I went ahead and made a video about it, but it's not a tutorial; it's more of a random ramble through my thoughts of how I would do it.

 

[Ryno917]

I went ahead and made a video about it, but it's not a tutorial; it's more of a random ramble through my thoughts of how I would do it.

Amazing! I'll give this a watch this weekend. Thank you!

 

[ohyeah2389]

Development has been paused until the community can evaluate the rF2 convert, available here: https://www.racedepartment.com/downloads/pittsburgh-international-race-complex.52845/

If the quality of that version is good enough, then there's no need for me to continue work on this track.

For now, I'm going to work on the other track, Autobahn Country Club.

If anyone's got any other interesting track ideas that:

1. Haven't been done for AC yet (and are not "in danger" of being converted),

2. Have only a few buildings in view from the track (because building modeling is a weak point for me),

3. Have good quality LiDAR data available (check https://www.coast.noaa.gov/inventory/ and https://www.coast.noaa.gov/inventory/, or introduce to me an international source where the data is available),

4. Have good quality satellite data available (I can use Google or Bing imagery, as well as any GeoTIFF),

5. Don't have too many layouts,

then please let me know here or in the track requests section of my Discord server: https://discord.gg/9cv8aeQr6S