Change Details

This adds support to render Curves attributes in EEVEE. For each attribute we create a set of VBOs and textures. 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`. For now, only attribute on the curve domain work. Point attribute will render something, although the value used will be the value of the point whose index corresponds to the current spline index. This is not ready for review, but can be somewhat tested already I guess. TODOs: - make point attributes work - fix memory leak - cleanup, check on deduplicating some logic with the mesh code - try to move logic to `create_requested`, at least the data update

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`). - updating drawn attributes is also a bit wrong 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 For each attribute wecreated and setup during its very create a setion, instead of VBOs and textures.doing it lazily As the shading group needs the textures to be validvia `create_requested`. Doing it via `create_requested` was upon creationalso a bit tricky, as contrary to the mesh batch, the attributes are created and setupwe cannot during its very creation, instead of doing it lazilyrely on `DRW_batch_requested` to tell us if attributes need via `create_requested`to be updated or else. For now,Uniforms are added to the shaders to tell in which scope the attribute is in (for each point vs. for each curve). only attribute onThe code generation and shaders had to be modified to pass the uniforms to each of the curve domain work.`attr_load_*` functions, Pointbut only if the shader is attribute will render something,for curves (`HAIR_SHADER` is defined). although the value usedUniforms are also will be the value of the point whose index corresponds todeclared during code generation as declaring them in the the current spline`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. This is not ready for review, but can be somewhat tCommon utilities with the mesh code for handling requested already I guess.attributes were moved to a separate file. ----------------- TODOs: - make point attributes workfigure 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`). - fix memory leak - cleanup, check on deduplicating some logic with the mesh code- updating drawn attributes is also a bit wrong Test file : {F13071995} - try to move logic to `create_requested`,All types except FLOAT2 were tested, as this is not yet supported by geometry nodes. at least the data updateI would need to check if one of my alembic files has such attribute.