Add custom data painter

[seunghoon-baek]

Description

I suggest a custom data painter that something works like current painter in Navigable Terrain Tool with more colors available. Each color represents a custom data.

If a game logic should depend on a specific location on a terrain, we can benefit from this feature. It could be used for area-dependant event system or simply defining region map across entire terrain for better organization.

[TokisanGames]

You can more effectively trigger events in areas by creating an Area3D. Eg. music and ambience triggers, death areas in a river. Also using the API you can query region locations and other info to compare that with the camera position.

Making custom data paintable is only worth it if you want to define areas as fine grained as per vertex, which could be required to be contiguous like navigation, holes, or perhaps water. What custom data would need to be defined and changed per vertex? If you can define a use case that is better managed by the terrain rather than any other system, I'll consider it.

In the future we will stream regions and send out signals so you can load and unload assets in those regions. That's about as fine grained as I think we should be responsible for, and the rest is out of scope.

[TheOrioli]

This sounds kind of like what we do with our custom data scripts extending the textures, as mentioned here before
#557 (comment)

For our driving game we use that to determine the different ways terrain influences the vehicle-terrain interaction.

The key benefit of being able to paint custom data is that we could detach the visual representation of a terrain with how it behaves. But for 95% of use cases at least we've encountered, simply extending the texture resource has been enough. And the rest we just reuse the same texture and call it a day 🤷‍♂️

[seunghoon-baek]

The idea is about keeping locational data in terrain class. Some top-down games keep data in tiles or grid for defining enemy spawing rules like what type of enemy should be spawned in that location, spawn possibility, or even terrain damage. I believe this is not only the case for top-down games. If I use GridMap class for building terrain, this can be done easily by requesting metadata on that grid but for terrain3d, it is difficult.

If it is possible, we can use custom data for masking custom shader on the terrain. We can use it for indicating where it is possible to place some objects. It would be easier to use predefined boolean data(say "possible_to_place").

I can use Area3D as you mentioned, but the class is basically for detecting CollisionObject. I can inherit Area3D and define custom data inside it, but it would still lack of storing per vertex data. Also, it would be a hassle to manage multiple Area3D for sectioning terrain as they should be adjusted one by one. As for custom data painter, it is easy to organize.

[TokisanGames]

custom data for masking custom shader

Currently, navigation vertices are stored in GPU data, but should not be. GPU data isn't used by the navigation system at all. We will eventually move it to the CPU. That probably means a new 8-bit or higher mask that is not sent to the GPU, but only stored on the CPU side. We only need 1 bit for navigation. The other bits could be used for water info, non-destructive layers, or user bits.

When the navigation tool is selected, this mask could temporarily be sent to the shader to show where it is. That could be something a user turns on all the time to access the custom bits.

[laurentsenta]

I came across this ticket while searching for a similar feature,

Having the ability to paint gameplay-related areas with Terrain3D, and query them would enable much more efficient workflows.

Making custom data paintable is only worth it if you want to define areas as fine grained as per vertex, which could be required to be contiguous like navigation, holes, or perhaps water. What custom data would need to be defined and changed per vertex? If you can define a use case that is better managed by the terrain rather than any other system, I'll consider it.

I can share a few use cases:

• Painting different navigation areas with varying costs for the AI and player - "smooth - rugged - dangerous" terrain.
• Painting areas of interactions like fields the player can plow, water, etc.
• Painting areas of grass, rocks, and trees that I can instantiate myself with more natural algorithms. Similar to ProtonScatter's approach with the relaxing step.

These are tightly coupled with the terrain, its height, etc. I'm not sure about granularity, but I'm pretty sure this is "just" a generalization of the navigation painting feature.

I don't think it's possible without the "repurpose textures" hack or reimplementing most of Terrain3D machinery in a different tool.