WIP: Pass on color_attribute metadata through instancing, only for mesh #107066

Since color attributes don't use the CustomData active/render/clone index system
anymore the active status is no longer embedded in the CustomData itself.
In 3.4 and earlier if you use an Instance on Points node to instance mesh data
on the vertices of a base mesh and then realize the instances the first color attribute
in the resulting mesh (which can be inherited from the base mesh or the instances)
gets set as the active color attribute. This is useful because it allows rendering
pointcloud data in a fast way in solid mode (see #106563).

However with the named system this no longer works and the resulting mesh after realize
does not have an active color attribute (even though the attribute data itself is inherited just fine)

Since color attributes don't use the CustomData active/render/clone index system anymore the active status is no longer embedded in the CustomData itself. In 3.4 and earlier if you use an `Instance on Points` node to instance mesh data on the vertices of a base mesh and then realize the instances the first color attribute in the resulting mesh (which can be inherited from the base mesh or the instances) gets set as the *active* color attribute. This is useful because it allows rendering pointcloud data in a fast way in solid mode (see https://projects.blender.org/blender/blender/issues/106563). However with the named system this no longer works and the resulting mesh after realize does not have an *active* color attribute (even though the attribute data itself is inherited just fine)

This patch shows one approach.

It stores the active/default color attribute from the instancer mesh on the Instances level and then uses that to set the active/default in the resulting mesh. If the instancer mesh does not have an active/default color attribute it uses the first one it encounters in the list of instanced meshes.

Questions/doubts I have:

I used std::string, but maybe this is overkill? Could probably just be a char * referencing the base mesh? I guess the base mesh will always stay alive at least up till the 'realize instances' node?
I now have to include "DNA_mesh_types.h" in node_geo_instance_on_points.cc just to get at those strings. I don't really like it.

Other possibilities:

Another approach would be to just check if there are color attributes present on the resulting mesh after a realize instances just make the first one active+default. Slightly less control, but maybe easier to implement and probably more or less equivalent to what happened in 3.4.

Yet another approach would be to build a full system of priorities and collect all this metadata in the gather phase and then use the priorities to pick the best option. I'd imagine the instancer mesh to have the highest priority. Direct mesh instances a lower one and instances in instances an even lower one. That might be slightly better than what I do in this patch (just pick the first I encounter in the list of instanced meshes) at the cost of considreably more complexity.

edit:
Another approach would be to leave the strings alone completely and if a mesh has no active/default set just always use the first one as active/default. That would have the added benefit of fixing #107206

It might be nice to also have this active/default metadata on other objects (PointCloud? Curves?)
Eventually we want to get rid of the active/render/clone layer indices in CustomData I guess. Because that would make CD layers implicitly shareable between meshes with different active layers. Having these be name based is (I think) more robust than the constant jugging of indices anyway.

With these 2 possible future developments in mind it might be better to eventually store this metadata in some sort of easier to handle container then as bare char * on the object data. Maybe a key-value based system?

This patch shows one approach. It stores the active/default color attribute from the instancer mesh on the Instances level and then uses that to set the active/default in the resulting mesh. If the instancer mesh does not have an active/default color attribute it uses the first one it encounters in the list of instanced meshes. Questions/doubts I have: - I used std::string, but maybe this is overkill? Could probably just be a char * referencing the base mesh? I guess the base mesh will always stay alive at least up till the 'realize instances' node? - I now have to include "DNA_mesh_types.h" in node_geo_instance_on_points.cc just to get at those strings. I don't really like it. Other possibilities: --------------------------------- Another approach would be to just check if there are color attributes present on the resulting mesh after a realize instances just make the first one active+default. Slightly less control, but maybe easier to implement and probably more or less equivalent to what happened in 3.4. Yet another approach would be to build a full system of priorities and collect all this metadata in the gather phase and then use the priorities to pick the best option. I'd imagine the instancer mesh to have the highest priority. Direct mesh instances a lower one and instances in instances an even lower one. That might be slightly better than what I do in this patch (just pick the first I encounter in the list of instanced meshes) at the cost of considreably more complexity. edit: Another approach would be to leave the strings alone completely and if a mesh has no active/default set just always use the first one as active/default. That would have the added benefit of fixing #107206 Related thoughts ---------------------------- - It might be nice to also have this active/default metadata on other objects (PointCloud? Curves?) - Eventually we want to get rid of the active/render/clone layer indices in CustomData I guess. Because that would make CD layers implicitly shareable between meshes with different active layers. Having these be name based is (I think) more robust than the constant jugging of indices anyway. With these 2 possible future developments in mind it might be better to eventually store this metadata in some sort of easier to handle container then as bare `char *` on the object data. Maybe a key-value based system?

I think the conclusion from the last module meeting was that the thing this patch does for instances should be done for joining as well. I'll try to update the patch and add join handling.

I *think* the conclusion from the last module meeting was that the thing this patch does for instances should be done for joining as well. I'll try to update the patch and add join handling.

rebased onto blender-v3.6-release

rebased onto blender-v3.6-release again.

I had to untangle some erroneous merges with main.

rebased onto blender-v3.6-release again. I had to untangle some erroneous merges with main.

 @ -215,2 +217,4 @@
                                      params,
                                      attributes_to_propagate);
         if (type == GEO_COMPONENT_TYPE_MESH) {
           const Mesh *src_mesh = ((MeshComponent *)geometry_set.get_component_for_read(type))->get_for_read();

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

WIP: Pass on color_attribute metadata through instancing, only for mesh #107066

Other possibilities:

Related thoughts

Reviewers