Vertex painting detection and modification improvements

[catprisbrey]

Describe the project you are working on

I'm working on a 3rd person 3D stealth action game akin to Metal Gear, the Last of Us, etc., and trying to keep the game slim and fast for potato PCs. 8 Decal limitations for Mobile or Compatibility renderer is fine in most circumstances but i've hit an annoyance when trying to efficiently handle things like burn/scorch marks, blood splatter, etc.

Describe the problem or limitation you are having in your project

With limitations like 8 decals per surface, and not wanting to give my enemies lots of collider shapes, to have blood splatter decals follow their body parts individually, and using normal facing mesh cards instead look great for walls but bad on enemy bodies and not great for blood. Also since my UV's are mirrored, and body textures/UVs are trimsheeted, i don't want to just paint on the UV since a shot on the arm would appear on both, (and likely my legs too, depending on the enemy, their trimsheet/clothing).

So with all this, it makes sense to me to use vertex painting to just paint vertexes red wherever shots are hit on the mesh (N64 GoldenEye Style, etc).

Digging into how implement that, it appears the only option i can find is detecting nearby verts, replicate the current mesh as an ArrayMesh, change the vertex color of the detected verts, and then commit that mesh and replace the original one. At runtime, that's a lot of iterating and parsing when being hit with a machine gun. And seems like there should be an easier more performant way to adjust vertex colors of the current mesh rather than spinning up constant replicas at runtime.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Simpler vertex detection, and modification at runtime would make this old-school feature more accessible, especially with vertex shadows coming back, it'd really be handy for more of the old-school aesthetic games.

An added benefit, is for decals, i fade them away, and queue_free() in order to keep the game light and processing lower, and free up more decal use. But with vertex coloring, i can leave enemies and walls permanently colored, without wasting further processing after the change happens. and if i use vertex color material shaders, i could even have detailed injury/damage materials blend into areas with certain vertex RGB colors. Possibilities are endless :)

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I'm uncertain if this is even possible but I'd imagine the Area3D node (since this is a pretty specific, and heavy for performance to have a default Area3D be detecting every vert for every frame, so perhaps it's a bool or enum on Area3Ds like "monitor Verteces toggle, or Enum Monitor: BODIES, AREAS, VERTICES" ) Then adding a new method to detect with get_overlapping_vertices(), returning an array of verts. From there it'd be great if vertices color could be modified like
for v in the_vertices: v.color = Color.RED

Or other cool modifications it could lead to would be setting new transform positions for verts if players wanted to move a the transform of a vert in order to deform it, maybe for explosions or something to distort a mesh after impact, or create divots.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I think i'd be used a lot in the old-school, low poly, vertex color styled games. I also think it'd lead to some better tools for vertex painting in editor, which would likely lead to better terrain editor/splat map making tools and shaders, sparing some work going back and forth between Blender and Godot so heavily just to shift some vert colors.

Is there a reason why this should be core and not an add-on in the asset library?

Digging through the asset library, vertex coloring code is still pretty heavy it looks like. Nothing I've found that is light and fast, and can't find much documentation for it online for anybody attempting it. With Vertex shading adding, it just feels like that next natural step.

[Calinou]

• Related to Implement persistent MeshInstance3D vertex colors on a per-instance basis #6486
  and Add support for vertex-based lightmaps #8062.

Vertices are skinned on the GPU, so there is no way for the physics server to know where the vertices are actually located for skinned meshes. You would need to do a round-trip between the CPU and GPU, which will break parallelism unless you do it with a delay of 2 frames or more.

Also since my UV's are mirrored, and body textures/UVs are trimsheeted, i don't want to just paint on the UV since a shot on the arm would appear on both, (and likely my legs too, depending on the enemy, their trimsheet/clothing)

If your textures are of a low enough resolution, you could mirror the texture and use non-mirrored UVs instead, so that texture painting can be used.

[catprisbrey]

Are there non-physical methods that could be used? I'm not well versed in this, but knowing that we now have vertex lighting/shadows, is there such a way as of vertex coloring light feature? Where rather than shooting a bullet with collisions to detect what vertices are struck, It shines a special sort of spotlight node that shades vertices a light color, and leaves them that color afterward?

(Perhaps that's what you're discussing in the other issue relating to light maps, I'm just not sure I understand)