render_color_index API is lost after GN mdifier #108343
Operating system: Mint
Graphics card: Nvidia
Broken: 3.6 beta
Short description of error
render_color_index API is lost after GN mdifier
Exact steps for others to reproduce the error
Open the attached file and run the script
When we get the evaluated mesh, you can see that for meshes without modifiers or with "simple" modifiers, we still can access the render_color_index value.
For GN modifier, this value is lost, return -1
It not happen is GN tree has only input -> output, but when you modify the tree, like in my example, value is -1
@Baardaap What do you think, can something be done here?
I'm not sure it's possible to interpolate discrete indices...
At a first glance I guess this is the same problem as:
I don't have much time to really look into it this weekend though. Do you think it's the same?
edit: I now see that's one of the cases you listed.
I have an experimental patch:
However that patch is a bit in limbo as we're not sure it's the right way to go about it. I'll update the patch to current master tonight, so at least you can test it...
For me here is the problem:
- Mesh with active color (Index 10, Name aabbbv).
- And another mesh with active color (Index 4, Name hii).
How can we get the correct result of joining here? What might be expected?
Clearing this data seems to be the only way...
What might be expected?
My expectation was to get the index of the original mesh, whatever the value of other joined meshes.
But I know this is maybe not the right/good/best solution.
Not everyone wants to just ignore all the actions in the nodes and get the data from the original mesh.
If we can input data from another object (
Object Info node), it should also input data from another mesh. But joining such meshes...
It should ate least be predictable what happens. To me 'pick the first one' would be ok. Combined with an explicit 'set active color index' node or something like that.
I think (considering the amount of bugreports) that just erasing / not copying anything is too bad of a regression. @mod_moder : most people needing this don't merge multiple meshes. And it not working there because you optionally could merge meshes is annoying an imo unnecessary. It's quite surprising to people that a mesh only has one vertex color defined and it isn't used.
Before v3.5 having a vertex color but not having an active one was an invalid state.
But maybe it would be a better plan to just always use the first vertex color available if the active one is -1... though that turns out not to be that much simpler code-wise than passing on the info like I did in my patch.
I'll try to find the time to get my brain back into the space of that patch and see what's missing from it and how it could be done differently...
Looking into this it is related, but a slightly different code path, which this patch does not solve.
the patch solves propagating the active/render color index across instancing, while this would need the same but across joining .
I'm a bit stuck on how to proceed. I have the feeling we first need a plan how to handle active/render color indices across GN I think it's a rather large regression that you just plain loose them, imo there are 3 ways to proceed (for both cases):
- Pick the first active index set on join/realize (this is what the patch does for realize)
- When there is a vertex color but no index is set, always consider the first vertex color the active/render one. (which is about as complicated to do as (1) while being slightly less flexible/predictable.
- Create a node to get/set the active color index so the user can handle it in the node tree.
I think this one fixes it now:
Need to do some more testing tomorrow.
AFAICS Active color attribute is only cleared when primitive nodes are included in node tree.
(i.e. cylinder in example file)
In any other case
render_color_index has active color attribute after GN applied.
Check with different node tree in uploaded file
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?