render_color_index API is lost after GN mdifier #108343

New Issue

Julien Duroure · 2023-05-27T07:42:14+02:00

Julien Duroure commented

2023-05-27 07:42:14 +02:00

System Information
Operating system: Mint
Graphics card: Nvidia

Blender Version
Broken: 3.6 beta
Worked: ?

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

**System Information** Operating system: Mint Graphics card: Nvidia **Blender Version** Broken: 3.6 beta Worked: ? **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

render_color_index_lost_in_GN.blend

896 KiB

Julien Duroure added the

labels 2023-05-27 07:42:15 +02:00

Iliya Katushenock commented

2023-05-27 11:13:16 +02:00

Interpolation single mesh value -> #106578
Active data layer -> #98366
Rendered data layers -> #106563

@Baardaap What do you think, can something be done here?
I'm not sure it's possible to interpolate discrete indices...

Interpolation single mesh value -> https://projects.blender.org/blender/blender/issues/106578 Active data layer -> https://projects.blender.org/blender/blender/issues/98366 Rendered data layers -> https://projects.blender.org/blender/blender/issues/106563 @Baardaap What do you think, can something be done here? I'm not sure it's possible to interpolate discrete indices...

Martijn Versteegh commented

2023-05-28 13:58:03 +02:00

At a first glance I guess this is the same problem as:
#106563

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:
#107066

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...

At a first glance I guess this is the same problem as: https://projects.blender.org/blender/blender/issues/106563 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: https://projects.blender.org/blender/blender/pulls/107066 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...

Iliya Katushenock commented

2023-05-28 14:01:38 +02:00

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...

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...

Julien Duroure commented

2023-05-28 14:14:47 +02:00

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.

> 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.

Iliya Katushenock commented

2023-05-28 14:16:49 +02:00

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...

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...

Martijn Versteegh commented

2023-05-28 15:31:05 +02:00

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.

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.

Martijn Versteegh commented

2023-05-28 15:39:19 +02:00

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...

Martijn Versteegh commented

2023-05-31 13:32:50 +02:00

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'd love @HooglyBoogly and @JacquesLucke 's opinion on this...

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): 1) Pick the first active index set on join/realize (this is what the patch does for realize) 2) 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. 3) Create a node to get/set the active color index so the user can handle it in the node tree. I'd love @HooglyBoogly and @JacquesLucke 's opinion on this...

Martijn Versteegh commented

2023-06-15 23:50:49 +02:00

I think this one fixes it now:

Need to do some more testing tomorrow.

#107066

I think this one fixes it now: Need to do some more testing tomorrow. https://projects.blender.org/blender/blender/pulls/107066

Pratik Borhade commented

2023-06-22 09:20:46 +02:00

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

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

108343.blend

896 KiB

Pratik Borhade added

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

render_color_index API is lost after GN mdifier #108343