Change Details

This adds support to render Curves attributes in EEVEE. Similarly to the hair length attribute, each attribute is stored in a texture derived from a VBO. As the shading group needs the textures to be valid upon creation, the attributes are created and setup during its very creation, instead of doing it lazily via `create_requested`. Doing it via `create_requested` was also a bit tricky, as contrary to the mesh batch, we cannot rely on `DRW_batch_requested` to tell us if attributes need to be updated or else. Uniforms are added to the shaders to tell in which scope the attribute is in (for each point vs. for each curve). The code generation and shaders had to be modified to pass the uniforms to each of the `attr_load_*` functions, but only if the shader is for curves (`HAIR_SHADER` is defined). Uniforms are also declared during code generation as declaring them in the `common_hair_lib` file did not work as it is included after the call to `attrib_load()` which depends on the uniforms to properly select the lookup index. Common utilities with the mesh code for handling requested attributes were moved to a separate file. ----------------- TODOs: - figure out how to properly store and name uniforms for scoping, the current strategy fails as the uniform name is based on numbering derived from the position of the attribute in the GPUMaterial. For multiple objects sharing the same material, this will fail if one attribute is missing, it also causes wrong missing updates/wrong attribute usage when editing shaders as the attributes are kept around like for meshes (in `attr_used`). Test file : {F13071995} All types except FLOAT2 were tested, as this is not yet supported by geometry nodes. I would need to check if one of my alembic files has such attribute.

This adds support to render Curves attributes in EEVEE. Similarly to the hair length attribute, each attribute is stored in a texture derived from a VBO. As the shading group needs the textures to be valid upon creation, the attributes are created and setup during its very creation, instead of doing it lazily via `create_requested`. Doing it via `create_requested` was also a bit tricky, as contrary to the mesh batch, we cannot rely on `DRW_batch_requested` to tell us if attributes need to be updated or else. Uniforms are added to the shaders to tell in which scope the attribute is in (for each point vs. for each curve). The code generation and shaders had to be modified to pass the uniforms to each of the `attr_load_*` functions, but only if the shader is for curves (`HAIR_SHADER` is defined). Uniforms are also declared during code generation as declaring them in the `common_hair_lib` is not possible due to their names being based on the attributes' "safe" names. Using the name is required to ensure that there is no conflicts between shaders or between old and new attributes when tweaking shaders. Common utilities with the mesh code for handling requested attributes were moved to a separate file. ------------------------- Test file : {F13071995} All types except FLOAT2 were tested, as this is not yet supported by geometry nodes. I would need to check if one of my alembic files has such attributes.

This adds support to render Curves attributes in EEVEE. Similarly to the hair length attribute, each attribute is stored in a texture derived from a VBO. As the shading group needs the textures to be valid upon creation, the attributes are created and setup during its very creation, instead of doing it lazily via `create_requested`. Doing it via `create_requested` was also a bit tricky, as contrary to the mesh batch, we cannot rely on `DRW_batch_requested` to tell us if attributes need to be updated or else. Uniforms are added to the shaders to tell in which scope the attribute is in (for each point vs. for each curve). The code generation and shaders had to be modified to pass the uniforms to each of the `attr_load_*` functions, but only if the shader is for curves (`HAIR_SHADER` is defined). Uniforms are also declared during code generation as declaring them in the `common_hair_lib` file did not work as it is included afteris not possible due to their names being the call to `based on the attrib_load()` which depends onutes' "safe" names. Using the uniformsname is to properly select the lookup indexrequired to ensure that there is no conflicts between shaders or between old and new attributes when tweaking shaders. Common utilities with the mesh code for handling requested attributes were moved to a separate file. ----------------- TODOs: - figure out how to properly store and name uniforms for scoping, the current strategy fails as the uniform name is based on numbering derived from the position of the attribute in the GPUMaterial. For multiple objects sharing the same material, this will fail if one attribute is missing, it also causes wrong missing updates/wrong attribute usage when editing shaders as the attributes are kept around like for meshes (in `attr_used`).-------- Test file : {F13071995} All types except FLOAT2 were tested, as this is not yet supported by geometry nodes. I would need to check if one of my alembic files has such attributes.