Support vertex displacement texture for StandardMaterial

MirceaKitsune

I keep noticing a basic feature that's to be missing for the StandardMaterial, and was curious if there are any plans to change it or why if not. I was thinking about the ability to use a grayscale texture for vertex displacement across the UV map: Custom shaders can easily do this, but why not have it as one of the many options for the default material? Many textures come with heightmaps intended to displace vertices packed with the albedo / specular / normal / metallicity maps: You shouldn't have to make a custom shader just to use that, it would be much easier for developers to create a subdivided plane textured with a standard material then just plug the displacement image in along with all the other maps.

There already seems to be a good place to add this: The standard material has a grow section, when enabled it gives you an amount slider which lets you shrink or expand the surface. Why not just add an optional texture input so the growth amount can be controlled by a texture? And maybe rename it from Grow to Displacement which would be a more fitting name.

When this feature can be implemented for the visual material, it would be great to also support it as a collision shape: We can then plug the image directly into a HeightMapShape or new shape type, allowing a subdivided plane to take collisions directly from a texture's displacement map.

Using the builtin noise texture, those two changes would more easily allow for procedural terrain without having to reprogram the feature yourself each time. Most requirements to support this by default are there, the only limitation is that displacement always needs to be scripted manually and needs a custom shader, with a few changes this could be supported in the default material and nodes.

Jesusemora

MirceaKitsune heightmaps intended to displace vertices packed with the albedo / specular / normal / metallicity maps

No. the godot PBR material has height, this uses a parallax effect to create displacement. PBR materials will come with a height texture for this and for generating a normalmap, but sometimes these are different textures, one is displacement and the other is bump.

MirceaKitsune You shouldn't have to make a custom shader just to use that

no. it's 2024, these things are considered obsolete except for very special situations.

MirceaKitsune create a subdivided plane textured with a standard material then just plug the displacement image in along with all the other maps.

that is not how games are made in 2024.

MirceaKitsune here already seems to be a good place to add this: The standard material has a grow section, when enabled it gives you an amount slider which lets you shrink or expand the surface. Why not just add an optional texture input so the growth amount can be controlled by a texture? And maybe rename it from Grow to Displacement which would be a more fitting name.

because it's more expensive. grow is intended for outlines, not displacement.

Ok, I'll explain in more detail: back in... IDK 2008? crysis came out and made use of tesselation, this allowed to increase detail at close distances by procedurally generating geometry. this was in theory good for performance, but not all GPUs supported it and openGL didn't. so GPUs added support for tessellation and became better at it.

years passed and the consensus years ago was that tessellation is bad. a modern artist can more easily create a high poly mesh, and this is better handled by the GPU, than procedurally generated geometry that requires a texture.
It's been stated that more geometry is always preferred to using a bigger texture/more textures.

and Displacement is worse than tessellation. It shifts the vertices in a single direction and uses the existing geometry, so you need a higher poly mesh that will not be optimized.
Normally you are supposed to create your meshes, and you can optimize them at this stage.

The only instances where displacement is used is with water and maybe some other mesh.

MirceaKitsune When this feature can be implemented for the visual material, it would be great to also support it as a collision shape: We can then plug the image directly into a HeightMapShape or new shape type, allowing a subdivided plane to take collisions directly from a texture's displacement map.

that is not how things work.
The physics part of an engine and the visual part are SEPARATE, they don't interact with each other.
If you really need to displace a terrain with a texture for procedurally generated geometry, you are supposed to use the mesh tools, then generate the collision data.

Megalomaniak

If ever godot gets support for tesselation, say via the OpenSubdiv library from Pixar for an example, then vertex displacement in the StandardMaterial would start making sense. Without that it makes little sense for it wouldn't be much use. Of course exceptions can exist, but in those cases a custom shader material will likely make more sense anyways.

As for your examples of texture packs with height maps included, most cases parallax/relief mapping is a more sensible use for those. The StandardMaterial already supports that.

Jesusemora Ok, I'll explain in more detail: back in... IDK 2008? crysis came out and made use of tesselation, this allowed to increase detail at close distances by procedurally generating geometry. this was in theory good for performance, but not all GPUs supported it and openGL didn't. so GPUs added support for tessellation and became better at it.

years passed and the consensus years ago was that tessellation is bad. a modern artist can more easily create a high poly mesh, and this is better handled by the GPU, than procedurally generated geometry that requires a texture.
It's been stated that more geometry is always preferred to using a bigger texture/more textures.

Honestly this is only really true for the most basic form of tesselation, which is why above I mentioned Pixars OpenSubdivision library. Ask artists and most will agree that Catmull-Clark SubDivs are very useful.

MirceaKitsune When this feature can be implemented for the visual material, it would be great to also support it as a collision shape: We can then plug the image directly into a HeightMapShape or new shape type, allowing a subdivided plane to take collisions directly from a texture's displacement map.

Jesusemora that is not how things work.
The physics part of an engine and the visual part are SEPARATE, they don't interact with each other.
If you really need to displace a terrain with a texture for procedurally generated geometry, you are supposed to use the mesh tools, then generate the collision data.

True that.

MirceaKitsune

That is interesting to know. I work mostly with open-source engines, and since they tend to be based on older code (eg: Quake engine) I'm used to a few things being done in more old fashioned ways.

Though tesselation I wouldn't add to that list: Last I heard that's still a new and very good technology which I fully support us having! After all, those are all features creators can choose to use or not use, such technologies may be fitting in some games but not others: As long as it's not something useless that just causes bloat I'm in favor of the engine offering it. My only issue with tesselation is that it subdivides everything based on distance, a proper implementation should also account for the sharpness of each corner / edge so it doesn't needlessly create vertices for parts of a mesh that are already smooth enough.

In this case I'm thinking of it from the perspective of the average creator: Say I downloaded a texture set which has albedo + metallicity + roughness + normal map + height map. I create a plane, give it a new material, then go to each section to add the appropriate texture. Except for the height map there is none, so I think to myself "where do I add this and what am I doing wrong".

Note that tesselation isn't necessary for displacement maps, though it would be a great addition. You can already create multiple planes at different resolutions and give each one a draw distance range, texture all planes with the same material and it will automatically LOD the way you expect it. Same with collisions, obviously they need to be generated separately from the image data... still there would be nothing wrong with allowing HeightMapShape to take an image as an input in the editor, something creators can commonly find themselves using and shouldn't need to write a script for every time they make a terrain tile or such.