Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement persistent MeshInstance3D vertex colors on a per-instance basis #6486

Open
tomankirilov opened this issue Mar 12, 2023 · 5 comments

Comments

@tomankirilov
Copy link

Describe the project you are working on

A vertex painting addon for godot 4.x

Describe the problem or limitation you are having in your project

I am currently editing the mesh itself and that results in mesh duplication.
That makes reimporting the mesh not reimporting the mesh with edited vertex colors.

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

Unity or Unreal engine save the vertex data per instance. That way the mesh remains the same and after reimport the vertex color is not lost. Sometimes it's scrambled if the mesh is too different from the original but in most cases edits are not chaning vertex count or order.

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

A simple way would be for the MeshInstance3D to save the vertex data and not the mesh itself.
Certainly there are better ways to go about it ...

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

It could be, but it will be ugly and not performant. The best way would be to be a part of either the MeshInstance3D or the mesh resource itself.

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

In my experience as an environment artist I have worked with multiple engines. Both publicly available and in-house.I never worked on a 3d project that does not require vertex color for some aspect of the workflow.

@Calinou
Copy link
Member

Calinou commented Mar 12, 2023

I agree this will be needed at some point, but I'm not sure how it can be designed efficiently. Vertex color data is large when using detailed models, so it should be stored in an external binary file, not as text. This means we should avoid storing the data as a PackedColorArray in the MeshInstance3D properties, as this means it'll have to be saved as text if using the .tscn scene format.

This will require something similar to UV2 import cache to be implemented. However, this system works on a per-mesh basis, not a per-MeshInstance basis. This means all instances must share the same UV2 layout, unless you make the mesh resource unique.

Handling mesh changes on reimport is also a tricky subject. You could check the position of each vertex and restore their custom color from the cache on reimport, but this may be slow with very complex meshes. (This means the vertex color cache would also have to store vertex position.)

@Calinou Calinou changed the title Per instance vertex color Implement persistent MeshInstance3D vertex colors on a per-instance basis Mar 12, 2023
@solitaryurt
Copy link

@Calinou, agreed. This is definitely something the engine is missing. This would enable a whole new set of plugins for the engine that don't currently exist.

@solitaryurt
Copy link

External bin that's a resource makes sense, allows for you to have different resources for the same mesh. Omitting the resource is simple as well.

@tomankirilov
Copy link
Author

Is there any chance that this may be implemented in the engine relatively soon?
I've been working on an addon for editing vertex colors since version 3.x.
I started rewriting it for 4.x but I realized that for most use cases per instance vertex color is required.

@Calinou
Copy link
Member

Calinou commented Jun 16, 2023

Is there any chance that this may be implemented in the engine relatively soon? I've been working on an addon for editing vertex colors since version 3.x. I started rewriting it for 4.x but I realized that for most use cases per instance vertex color is required.

To my knowledge, nobody is currently working on this. Also, 4.1 is currently in feature freeze. As a result, we don't expect this to be implemented anytime soon.

This is a feature I would personally like to see, but I'm not well-versed in helping someone implement this. If you are looking to implement this, you could join the #rendering channel on the Godot Contributors Chat 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants