Fix #115460: EEVEE-Next: Missing bind when drawing curves #121064

Jeroen Bakker · 2024-04-25T09:09:39+02:00

Jeroen Bakker commented

2024-04-25 09:09:39 +02:00

When drawing hair/curves the material shader has a "a" texture slot,
but this slot was never bound to a texture. This PR fixes this by
adding a default texture to it and when available tries to bind
CD_AUTO_FROM_NAME resources.

This part seems to be not implemented when the new curve rendering
was added. CD_AUTO_FROM_NAME was never considered and therefore the
layer could not be found and the sampler could not be found.

Fixes #115460

When drawing hair/curves the material shader has a "a" texture slot, but this slot was never bound to a texture. This PR fixes this by adding a default texture to it and when available tries to bind CD_AUTO_FROM_NAME resources. This part seems to be not implemented when the new curve rendering was added. `CD_AUTO_FROM_NAME` was never considered and therefore the layer could not be found and the sampler could not be found. Fixes #115460

Jeroen Bakker added this to the 4.2 LTS milestone 2024-04-25 09:09:39 +02:00

Jeroen Bakker added the

Module

EEVEE & Viewport

label 2024-04-25 09:09:39 +02:00

Jeroen Bakker self-assigned this 2024-04-25 09:09:40 +02:00

Jeroen Bakker added 1 commit 2024-04-25 09:09:47 +02:00

8249711ee1 EEVEE-Next: Fix missing texture bind when drawing curves/hair

When drawing hair/curves the material shader has a "a" texture slot,
but this slot was never bound to a texture. This PR fixes this by
default add a dummy texture to it.

Jeroen Bakker added this to the EEVEE & Viewport project 2024-04-25 09:09:52 +02:00

Jeroen Bakker requested review from Clément Foucault 2024-04-25 09:10:05 +02:00

Jeroen Bakker referenced this pull request

2024-04-25 09:40:28 +02:00

EEVEE: shader UV map input is broken for hair curves #115460

Jeroen Bakker changed title from ~~EEVEE-Next: Fix missing texture bind when drawing curves/hair~~ to WIP: EEVEE-Next: Fix missing texture bind when drawing curves/hair

2024-04-25 10:02:42 +02:00

Jeroen Bakker commented

2024-04-25 10:03:01 +02:00

Moving to WIP, as it might hide other issues as well.

Jeroen Bakker changed title from ~~WIP: EEVEE-Next: Fix missing texture bind when drawing curves/hair~~ to EEVEE-Next: Fix missing texture bind when drawing curves/hair

2024-04-25 12:03:08 +02:00

Jeroen Bakker added 1 commit 2024-04-25 12:03:16 +02:00

6f594db22a EEVEE-Next: Fix auto uvmap attribute binding for curves

Jeroen Bakker changed title from ~~EEVEE-Next: Fix missing texture bind when drawing curves/hair~~ to Fix #115460: EEVEE-Next: Missing texture bind when drawing curves

2024-04-25 12:03:46 +02:00

Jeroen Bakker changed title from ~~Fix #115460: EEVEE-Next: Missing texture bind when drawing curves~~ to Fix #115460: EEVEE-Next: Missing bind when drawing curves

2024-04-25 12:07:29 +02:00

Clément Foucault commented

2024-04-25 12:41:41 +02:00

@HooglyBoogly do you have any input on this?

Hans Goudey reviewed 2024-04-26 18:32:17 +02:00

Hans Goudey left a comment

To be honest I don't really understand the context or the need for separate "input name" and "attribute name" variables, or why the API is set up in a way that requires us to store both of them. My instinct is that it's more complicated than it needs to be, but yeah, I'm definitely missing something.

Jeroen Bakker commented

2024-04-26 23:02:19 +02:00

Gpu materials can be shared between multiple objects. Curves but also other geometry. Each object can have an active uvmap that is differently named.

We don’t want to recompile the shaders based on the geometry. So this pr introduces a mapping system.

This is specific for hair as mapping attributes for meshes is part of the vbo api (aliasing).

For hair we have a refine shader that can create texture buffers. We also don’t want to generate too much texture buffers when the active uvmap is also accessed by name in the same shader.

I am open for other solutions as well. I do thing when the curves.active_uvmap is available we can reduce some lookups during this process. But I am not sure if that attribute should be used in this case….

Gpu materials can be shared between multiple objects. Curves but also other geometry. Each object can have an active uvmap that is differently named. We don’t want to recompile the shaders based on the geometry. So this pr introduces a mapping system. This is specific for hair as mapping attributes for meshes is part of the vbo api (aliasing). For hair we have a refine shader that can create texture buffers. We also don’t want to generate too much texture buffers when the active uvmap is also accessed by name in the same shader. I am open for other solutions as well. I do thing when the curves.active_uvmap is available we can reduce some lookups during this process. But I am not sure if that attribute should be used in this case….

Clément Foucault commented

2024-05-07 12:56:18 +02:00

I would consider adding the CD_AUTO_FROM_NAME support for new hair types orthogonal to this fix.

Adding the missing binds using default dummy texture seems fine to me for now. If we have to fix the discrepancy, it is better to be left to a real design discussion with @HooglyBoogly.

I would consider adding the `CD_AUTO_FROM_NAME` support for new hair types orthogonal to this fix. Adding the missing binds using default dummy texture seems fine to me for now. If we have to fix the discrepancy, it is better to be left to a real design discussion with @HooglyBoogly.

Clément Foucault requested changes 2024-05-10 16:43:34 +02:00

Dismissed

Clément Foucault left a comment

So ParticleHairCache did hold all four possible names char uv_layer_names[MAX_MTFACE][MAX_LAYER_NAME_CT][MAX_LAYER_NAME_LEN]; see #define MAX_LAYER_NAME_CT 4 /* u0123456789, u, au, a0123456789. */. Although, I am not sure if all four are required nowadays.

The missing part of this patch is that the binding code should iterate over all names and bind the same texture for each of them. You can have 2 different attribute node referring to the same attribute using different name.

So `ParticleHairCache` did hold all four possible names `char uv_layer_names[MAX_MTFACE][MAX_LAYER_NAME_CT][MAX_LAYER_NAME_LEN];` see `#define MAX_LAYER_NAME_CT 4 /* `u0123456789, u, au, a0123456789`. */`. Although, I am not sure if all four are required nowadays. The missing part of this patch is that the binding code should iterate over all names and bind the same texture for each of them. You can have 2 different attribute node referring to the same attribute using different name.

👍 1

source/blender/draw/intern/draw_cache_impl_curves.cc Outdated

						
				@ -695,3 +694,1 @@

				      }

				      else if (drw_custom_data_match_attribute(cd_point, name, &layer_index, &type)) {

				        domain = bke::AttrDomain::Point;

Clément Foucault commented

2024-05-10 16:19:57 +02:00

This function should either be a copy of mesh_cd_calc_used_gpu_layers or be unified.

This function should either be a copy of `mesh_cd_calc_used_gpu_layers` or be unified.

Jeroen Bakker commented

2024-05-16 08:27:35 +02:00

Return types are different (bool vs used), data values are different (DRW_MeshCDMask vs DRW_Attributes) CD_MTFACE vs CD_PROP_FLOAT2) data structure storage is different, logic is different. So would most likely be a copy and removing parts that are not needed. Unifying would change the impact in areas that are not well documented.

Would rather see this working, before restructuring the code to be more unified.
Already copying the same logic is a challenge.

Return types are different (bool vs used), data values are different (DRW_MeshCDMask vs DRW_Attributes) CD_MTFACE vs CD_PROP_FLOAT2) data structure storage is different, logic is different. So would most likely be a copy and removing parts that are not needed. Unifying would change the impact in areas that are not well documented. Would rather see this working, before restructuring the code to be more unified. Already copying the same logic is a challenge.

Jeroen-Bakker marked this conversation as resolved

source/blender/draw/intern/draw_curves.cc Outdated

						
				@ -271,3 +272,3 @@

				    char sampler_name[32];

				    drw_curves_get_attribute_sampler_name(request.attribute_name, sampler_name);

				    drw_curves_get_attribute_sampler_name(

Clément Foucault commented

2024-05-10 16:43:12 +02:00

Loop over the name, don't choose one or the other.

Jeroen-Bakker marked this conversation as resolved

Jeroen Bakker added 2 commits 2024-05-16 10:21:30 +02:00

ca577ec465 Merge branch 'main' into eevee/fix/missing-curve-texture-bind

a86a34181f Sync implementation flow with mesh

Jeroen Bakker commented

2024-05-16 10:34:29 +02:00

Reviewing your comments and the code. The new take on this is to store if an attribute is a default layer. if this is the case during bind we can bind the same data to multiple samplers. This shoud replace the input_name with a bool 'is_default_render`. During bind the correct layer name should then be selected.

I haven't seen any way how to unified code as the control flow is different.

Reviewing your comments and the code. The new take on this is to store if an attribute is a default layer. if this is the case during bind we can bind the same data to multiple samplers. This shoud replace the `input_name` with a bool 'is_default_render`. During bind the correct layer name should then be selected. I haven't seen any way how to unified code as the control flow is different.

Jeroen Bakker added 1 commit 2024-05-16 11:28:58 +02:00

96122c5f87 Remove `input_name` and get the render layer during bind

Jeroen Bakker added 1 commit 2024-05-16 11:32:51 +02:00

28f5567c3b Remove unneeded changes to code style

Jeroen Bakker requested review from Clément Foucault 2024-05-16 11:33:47 +02:00

Clément Foucault requested changes 2024-05-16 11:55:54 +02:00

Dismissed

source/blender/draw/intern/draw_cache_impl_curves.cc Outdated

						
				@ -681,26 +681,111 @@ static bool ensure_attributes(const Curves &curves,

				  CurvesEvalFinalCache &final_cache = cache.eval_cache.final;

				  if (gpu_material) {

				    /* Next code should be kept in sync with `mesh_cd_calc_used_gpu_layers`. */

Clément Foucault commented

2024-05-16 11:49:02 +02:00

Next code

Are you refering to following code or future code? This is ambiguous.

I guess you mean The following code.

> Next code Are you refering to following code or future code? This is ambiguous. I guess you mean `The following code`.

Jeroen-Bakker marked this conversation as resolved

source/blender/draw/intern/draw_curves.cc Outdated

						
				@ -268,6 +270,10 @@ DRWShadingGroup *DRW_shgroup_curves_create_sub(Object *object,

				  const DRW_Attributes &attrs = curves_cache->final.attr_used;

				  for (int i = 0; i < attrs.num_requests; i++) {

				    const DRW_AttributeRequest &request = attrs.requests[i];

				    const int render_layer = CustomData_get_render_layer(request.domain == bke::AttrDomain::Curve ?

Clément Foucault commented

2024-05-16 11:51:50 +02:00

Look up how particle code does it, you should also support active color and such:


  if (psmd != nullptr && psmd->mesh_final != nullptr) {
    if (CustomData_has_layer(&psmd->mesh_final->corner_data, CD_PROP_FLOAT2)) {
      cache->num_uv_layers = CustomData_number_of_layers(&psmd->mesh_final->corner_data,
                                                         CD_PROP_FLOAT2);
      active_uv = CustomData_get_active_layer(&psmd->mesh_final->corner_data, CD_PROP_FLOAT2);
      render_uv = CustomData_get_render_layer(&psmd->mesh_final->corner_data, CD_PROP_FLOAT2);
    }
    if (CustomData_has_layer(&psmd->mesh_final->corner_data, CD_PROP_BYTE_COLOR)) {
      cache->num_col_layers = CustomData_number_of_layers(&psmd->mesh_final->corner_data,
                                                          CD_PROP_BYTE_COLOR);
      if (psmd->mesh_final->active_color_attribute != nullptr) {
        active_col = CustomData_get_named_layer(&psmd->mesh_final->corner_data,
                                                CD_PROP_BYTE_COLOR,
                                                psmd->mesh_final->active_color_attribute);
      }
      if (psmd->mesh_final->default_color_attribute != nullptr) {
        render_col = CustomData_get_named_layer(&psmd->mesh_final->corner_data,
                                                CD_PROP_BYTE_COLOR,
                                                psmd->mesh_final->default_color_attribute);
      }
    }
  }

Look up how particle code does it, you should also support active color and such: ```Cpp if (psmd != nullptr && psmd->mesh_final != nullptr) { if (CustomData_has_layer(&psmd->mesh_final->corner_data, CD_PROP_FLOAT2)) { cache->num_uv_layers = CustomData_number_of_layers(&psmd->mesh_final->corner_data, CD_PROP_FLOAT2); active_uv = CustomData_get_active_layer(&psmd->mesh_final->corner_data, CD_PROP_FLOAT2); render_uv = CustomData_get_render_layer(&psmd->mesh_final->corner_data, CD_PROP_FLOAT2); } if (CustomData_has_layer(&psmd->mesh_final->corner_data, CD_PROP_BYTE_COLOR)) { cache->num_col_layers = CustomData_number_of_layers(&psmd->mesh_final->corner_data, CD_PROP_BYTE_COLOR); if (psmd->mesh_final->active_color_attribute != nullptr) { active_col = CustomData_get_named_layer(&psmd->mesh_final->corner_data, CD_PROP_BYTE_COLOR, psmd->mesh_final->active_color_attribute); } if (psmd->mesh_final->default_color_attribute != nullptr) { render_col = CustomData_get_named_layer(&psmd->mesh_final->corner_data, CD_PROP_BYTE_COLOR, psmd->mesh_final->default_color_attribute); } } }

Hans Goudey commented

2024-05-16 14:44:05 +02:00

There is no active/default color attribute for curves, curves don't have color attributes currently.

👍 2

Clément Foucault commented

2024-05-16 14:49:05 +02:00

Ok then i'm fine with the current code. But at least move CustomData_get_render_layer out of the loop.

Ok then i'm fine with the current code. But at least move `CustomData_get_render_layer` out of the loop.

Jeroen-Bakker marked this conversation as resolved

Jeroen Bakker added 2 commits 2024-05-17 08:52:57 +02:00

0a7de8b0c6 Clarified comment

buildbot/vexp-code-patch-lint Build done. Details