Shrinkwrap roads to terrain

[TheDuckCow]

Already being asked for by a few people, eventually it would be nice if we have a way to shrinkwrap the road to a terrain.

We need to think this feature out some more, but ideas so-far on requirements:

• Must be able to project onto already set up collission meshes
• Must be optional, likely default off for performance. Could make sense to make this be a per RoadPoint setting (so that you could disable or enable it only for relevant stretches)
  • This could pair with a toggle on the RoadContainer which sets/unsets for all RoadPoints within the container. This is instead of it being a RoadContainer-level setting
• Should have a max distance param, which defines the maximum amount down-wards the road should be projected (so it doesn't try to go into deep ravines/consider bridges). Ideally some smoothing between loop cuts that are floating from those on the ground
• Should have a max "angle" which basically says how steeply the road is allowed to change due to shrinkwrapping. This way a small but very deep crevice only makes a subtle difference, instead of the whole road sinking down for just one loop cut.

Technical ideation:

• Projection could work in a number of ways:
  • Per vertex point projection: Will be a bumpy road for sure! And the most expensive to compute. We could probably do some smoothing based on the distance of the gutter profile height, to make it a bit less wobbly
  • 2 or 3-point leveling: basically instead of per vertex, compute the height to the left and right of a given edge loop of the road, and possibly a point in the middle. So cross sections are still mostly smooth, but still roughly conforming to the road. Paired with a high-enough gutter profile, this likely could work for most terrains for expected results (if the terrain is so bumpy this doesn't work, it probably realistically needs to be smoothed anyways)
• Raycasting: will be expensive, might be able to use threads for some of this, maybe creating a lookup dict or something. We should also assume that the raycast will be emitted from somewhere well above

Expecting this would be a v1.0+ (ie Godot 4 only) feature.

[dev-bre]

is this going to allow the road to adjust itself to the terrain shape? I see that similar tools in unity and UE allow also the other way round.. the road changes the shape of the terrain below (raising the terrain to fill the space).

[TokisanGames]

For Terrain3D you can require the user to enable our full terrain collision in the editor. Or you can just detect if we're installed and query heights directly. https://terrain3d.readthedocs.io/en/latest/docs/collision.html

As for using raycasts to place your roads, running thousands of raycasts once in the editor, even if it takes a few seconds after a button push is not a concern.

[TheDuckCow]

Thanks for sharing the ideas! For sure @TokisanGames I'll be giving this a try once we wrap up/have a first stable godot 4 version. I definitely have the intention of integrating smoothly with as many terrain editors as is realistically feasible.

@dev-bre yup that is a common feature as well, but it the terrain engine itself needs to provide a way to do this. With at least one terrain dev I spoke with, they have a feature to input curves/paths which are used to define areas to smooth out and level the terrain. So as long as we can feed in the road generator's underlying curves through an appropriate callback, we'd be in good shape.

[TheDuckCow]

Hi @renzo-massaro! Following up on your question

Is there any progression with terrain roads? And specifically with the heights and place a road on the different heights??

Unfortunately I don't have news to share on this front. We're stretched pretty thin (e.g. this PR took quite a bit longer than expected, and this PR is proving difficult)

This feature of shrinkwrapping the road to nearby colliders is an area we'd need some external contributing help to get to it in the immediate term as we are otherwise focussed on the milestone features below which are more necessary before more scaled usage of the Road Generator is possible:

https://github.com/TheDuckCow/godot-road-generator/milestone/10

If you have any interest in contributing though, I can definitely point out to where these changes would be made and some thoughts on the design of the feature! It'd be all about performing raycasts in the body of this function, taking into account the displacement amount of the prior/next loop so we can apply some smoothing / shrink angle limitations. This would be a decent new contributor task since it's pretty isolated from anything else like the UI / input callbacks.

[FishOfTheNorthStar]

I'm working on this. So far it integrates tightly with my non-standard Terrain3D implementation, and should port over fairly cleanly to the actual Terrain3D project when it's ready.

Couple things I'm doing may be off spec, most notably that I'm not working from the collider, it'll be entirely off height lookups in the terrain storage. Basically a 32 bit float grayscale image. Also, I just can't imagine any form of this that doesn't need to modify the terrain, perhaps a lot. So I am, for now, implementing an extra custom step in the Terrain3D loading process that overlays an additional height adjustment image on top of the primary elevation, so the modifications can be done non-destructively to the existing heights, and changed or adjusted later. This adjustment layer would simulate the extensive grading necessary for actual roads, and may occasionally carve it's way through otherwise unpassable peaks, or fill in sharp dips, or add height to smooth out bumps to happen as gradually as possible.

Ultimately I expect this 'terrain modification layer' to also overlay splat-map overrides, too. so road edges can fade to gravel, and maybe certain very simple roads could be visualized with no other mesh component, just staining the texturing of the existing terrain and adjusting it's height.

How this would translate to other non-Terrain3D systems is a little up in the air. Maybe the general process could have an abstraction layer in the middle somewhere so other systems can hook into the relevant phases and get access to the modification maps, and provide height data however they do that.

OK so all of that said, I do see a lot of need for purely physics-collision based shrinkwrapping, too... it's just not in my own use-case scenario. So one thing occurred to me on that... the GPU particles collider maker... that might be very useful for this because it is not physics based, it's depth map based and it manages the whole process of pulling a big overhead orthographic depth render and translating that into heights, which is most of the work. It might be useable for the purpose as is, actually. But at least it could provide a good starting point for similar stuff.

Also interesting is that particles can use compute shaders I think, so path solving could perhaps be done on the GPU as a particle system that responds to the elevation map or wherever it physics-detected a collision at, and the particle emitter would move from the start, towards the goal, following certain maximum banking/pitch/yaw adjustment parameters? Just guessing if that's possible but it might be extremely performant, if so.