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 \/