[FEATURE REQUEST] Reapply position to terrain

[aXu-AP]

Describe the problem you're trying to solve in your project
I'm iterating on landscape, changing the terrain and foliage to find something I like. However, any time I change the terrain, foliage stays in place. I need to erase the foliage and repaint each time I want to iterate on the underlying terrain.

Objects floating above the terrain which was lowered.

Objects sunk inside the terrain which was raised.

Describe a feature you consider and how it will help you
Using reapply brush should recast the position of the instances so that they stick to the terrain properly again.

Describe alternatives you've considered
Erasing and repainting will suffice in the earlier stages of map development, but once I settle on something and make it look good, I'm not sure what to do if I want to fine tune the terrain.

Describe how you imagine it would work. With code, pseudo-code, diagram or a drawing
Add option to recalculate position on the Reapply brush (or a separate Reposition brush). I'd imagine doing a raycast from object's position + up on local axis towards down on the local axis would usually give good results. Maybe needs some parameter to adjust the search range.

[dreadpon]

I think this was raised somewhere before (perhaps on discord?), but so far wasn't a priority.

The "proper" way to handle this would probably be to perform a raycast in the same direction, that was performed originally. But:

1. This implies storing the initial raycast vector, which is additional 3 floats per instance. ooff
2. Okay, this works when terrain moves further along the raycast vector. What if it moves in the opposite direction? What if it disappears? Any sort of "assumptions" we make about these are bound to break pretty often.
   So

This calls for some more sophisticated system, while also allowing users to manually take control of it. I haven't thought that far myself though.

Would appreciate any thought others might have.

[nan0m]

Maybe a simpler approach would be to only re-apply the position on the vertical axis. So instead of storing the raycast vector, one could only store the vertical offset from the terrain obj.

I am thinking something similar to what terrain3D does here TokisanGames/Terrain3D@7188b74

[dreadpon]

Maybe a simpler approach would be to only re-apply the position on the vertical axis. So instead of storing the raycast vector, one could only store the vertical offset from the terrain obj.

I am thinking something similar to what terrain3D does here TokisanGames/Terrain3D@7188b74

That's a possibility, but most terrain plugins use heightmap, meaning they operate strictly on one axis (vertical; other two are constant for each point on the heightmap).

When I was making Spatial Gardener I explicitly wanted full 3D placement. This preposition somewhat goes against that vision, even though it's probably reasonable given most peoples' use-cases.

So like, maybe I'll do that, but I need time to workshop other possible solutions.

[aXu-AP]

@dreadpon The "proper" way to handle this would probably be to perform a raycast in the same direction, that was performed originally

I think new placement depending on original raycast would be very unpredictable, if I understand the idea right. For example if I was to place some rocks on this hill:

But then decided to flatten the hill, the rocks would move up to tens of meters horizontally, since the camera was facing the hill from the side when they were originally placed? (the image isn't perfect, but you get the idea)

And if I had some other objects in the same spot, but camera happened to be looking downwards when I placed them, they would end up entirely different place than the rocks.

However, my original of instance's local down also wouldn't work perfectly, since these rocks for example have entirely random rotation. But if I understand it correctly, you are already saving the terrain normal in the data. Maybe casting by that normal would tick all the boxes?

@nan0m Maybe a simpler approach would be to only re-apply the position on the vertical axis. So instead of storing the raycast vector, one could only store the vertical offset from the terrain obj.

I think vertical axis does sound also good for the most typical use case (or user-provided axis for more flexibility). Also I think this way no additional data needs to be saved as reapply recalculates the offset anyway from the plant properties. Unless we want a separate reposition brush which wouldn't perform reroll. Which, might be the best way to go, since it wouldn't be too nice for these two functions be binded together.

@dreadpon Okay, this works when terrain moves further along the raycast vector. What if it moves in the opposite direction? What if it disappears?

As my original proposal goes, the raycast should start further upwards (altough what counts up is debatable).

So here's a tldr version: