blender/blender
147
472
Fork 689
Code Issues 6.7k Pull Requests 889 Projects 18 Wiki Activity

Cycles: Improve the coverage of automated regression tests #123012

New Issue
Open
opened 2024-06-10 15:59:15 +02:00 by Weizhen Huang · 15 comments
Weizhen Huang commented 2024-06-10 15:59:15 +02:00
Member
Copy Link
  • Add tinted glass for glass BSDF tests
  • Add multiscatter GGX glass test
    • can use the same one as tinted glass
  • Add tests for light and shadow linking
  • Enable MIS on light in some test files
    • especially for perfectly specular surfaces, as the light contribution is otherwise zero. Can modify the newer files such as principled_thinfilm_xxx.blend, with increased light radius
  • More tests for point/spot light without soft falloff
  • Add an option to test with OSL (!124601)
    • Improve OSL test coverage by avoiding SVM constant folding of nodes (#123012 (comment))
  • Add overlapping volume test
    • VDB and Volume overlap (!123733)
    • Different phase functions (#125595)
  • Add texture nodes tests (blender/blender-test-data#6)
  • Add test for zero weight coat with tint (#124856)
  • Add light test for all IES types (#123012 (comment))
  • Add the option to more easily test HWRT (!125082)
  • Enable MNEE tests on Metal (!124709)
  • Multiple transparent bounces (#125093)(blender/blender-test-data!9)
  • Investigate adding precision tests like the issue reported in #125307
  • Improve hair/curve tests on GPU (some are disabled due to "Inconsistency between Embree and Hair primitive on GPU". Not sure if it's straightforward to fix and re-enable the tests. Ref #124295)
  • Add option to ignore render block list for investigation purposes (2724f296b2)
- [x] Add tinted glass for glass BSDF tests - [x] Add multiscatter GGX glass test - can use the same one as tinted glass - [ ] Add tests for light and shadow linking - [x] with volume (#122976, #124241) - [ ] Shadow linking with curves and points to test custom BVH (https://projects.blender.org/blender/blender/pulls/125803#issuecomment-1257065) - [x] Enable MIS on light in some test files - especially for perfectly specular surfaces, as the light contribution is otherwise zero. Can modify the newer files such as `principled_thinfilm_xxx.blend`, with increased light radius - [ ] More tests for point/spot light without soft falloff - [x] Add an option to test with OSL (!124601) - [ ] Improve OSL test coverage by avoiding SVM constant folding of nodes (https://projects.blender.org/blender/blender/issues/123012#issuecomment-1271847) - [ ] Add overlapping volume test - [x] VDB and Volume overlap (!123733) - [ ] Different phase functions (#125595) - [ ] Add texture nodes tests (https://projects.blender.org/blender/blender-test-data/pulls/6) - [ ] Add test for zero weight coat with tint (#124856) - [ ] Add light test for all IES types (https://projects.blender.org/blender/blender/issues/123012#issuecomment-1242062) - [ ] Add the option to more easily test HWRT (!125082) - [x] Enable MNEE tests on Metal (!124709) - [ ] Multiple transparent bounces (#125093)(blender/blender-test-data!9) - [ ] Investigate adding precision tests like the issue reported in #125307 - [ ] Improve hair/curve tests on GPU (some are disabled due to "Inconsistency between Embree and Hair primitive on GPU". Not sure if it's straightforward to fix and re-enable the tests. Ref #124295) - [x] Add option to ignore render block list for investigation purposes (2724f296b21e13562ece5a629b38252fa239e2df)
🚀 4
Weizhen Huang added the
Type
To Do
 label 2024-06-10 15:59:16 +02:00
Weizhen Huang added this to the Render & Cycles project 2024-06-10 15:59:16 +02:00
Alaska commented 2024-06-12 07:28:45 +02:00
Member
Copy Link

Here are a few ideas for other things that could be added to the test suite.

  • Negative brightness/colour lights (Both analytical and mesh lights)
  • A larger mesh light sampling test (#117771 was a case that wasn't caught during a refactor, I presume due to missing tests?)
  • More OSL testing (Maybe run every file with SVM and OSL?) Done
  • Test more baking options
    • More passes
    • Bake view from active camera option
    • Bake from selected to active option
    • Baking denoising

I created a script that interates through objects in the Cycles test files looking for nodes that aren't being tested. According to my script, these nodes aren't being tested on any non-light objects, so we should probably add tests for some of these.

  • Camera Data
  • Fresnel
  • Layer Weight
  • Object Info
  • Volume Info
  • Hue/Saturation/Value
  • Invert
  • Light Falloff (Probably doesn't need test on non-light objects)
  • Clamp
  • Combine XYZ
  • Float Curve
  • Map Range
  • RGB to BW
  • Separate Color
  • Wavelength (Probably already tested on lights)
  • Environement texture (Probably doesn't need testing on non-world shaders)
  • IES texture (Probably doesn't need testing on non-light objects)
  • Sky texture (Probably doesn't need testing on non-world shaders)
  • Wave texture
  • White noise texture (Maybe do a test for 1 SPP and something higher like 128 SPP)
  • Normal node
  • Vector Curves
  • Vector rotate

For the nodes that are already tested, there may be configurations that aren't tested (E.g. The Mutliscatter GGX Glass case). I will investigate these next.

Here are a few ideas for other things that could be added to the test suite. - Negative brightness/colour lights (Both analytical and mesh lights) - A larger mesh light sampling test (#117771 was a case that wasn't caught during a refactor, I presume due to missing tests?) - ~~More OSL testing (Maybe run every file with SVM and OSL?)~~ Done - Test more baking options - More passes - `Bake view from active camera` option - `Bake from selected to active` option - Baking denoising --- I created a script that interates through objects in the Cycles test files looking for nodes that aren't being tested. According to my script, these nodes aren't being tested on any non-light objects, so we should probably add tests for some of these. <details> - Camera Data - Fresnel - Layer Weight - Object Info - Volume Info - Hue/Saturation/Value - Invert - Light Falloff (Probably doesn't need test on non-light objects) - Clamp - Combine XYZ - Float Curve - Map Range - RGB to BW - Separate Color - Wavelength (Probably already tested on lights) - Environement texture (Probably doesn't need testing on non-world shaders) - IES texture (Probably doesn't need testing on non-light objects) - Sky texture (Probably doesn't need testing on non-world shaders) - Wave texture - White noise texture (Maybe do a test for 1 SPP and something higher like 128 SPP) - Normal node - Vector Curves - Vector rotate </details> For the nodes that are already tested, there may be configurations that aren't tested (E.g. The Mutliscatter GGX Glass case). I will investigate these next.
👍 1
Weizhen Huang commented 2024-06-12 13:34:18 +02:00
Author
Member
Copy Link

Map Range and Wave Texture are tested on lights though, we can add them on lights but not sure if it's necessary.

Map Range and Wave Texture are tested on lights though, we can add them on lights but not sure if it's necessary.
Alaska commented 2024-06-12 14:01:16 +02:00
Member
Copy Link

Sorry about that. Quite a lot of what I'm finding is "there's a gap in testing, but that gap probably doesn't need testing". For example the wave texture on a mesh. There probably isn't a need for a mesh test, unless the wave texture has a 3D component that can't be captured in the light test.

For the next list I'm creating (the configurations of nodes that aren't tested from the nodes that are tested), I will include more notes about the things that likely don't need extra tests made.

Sorry about that. Quite a lot of what I'm finding is "there's a gap in testing, but that gap probably doesn't need testing". For example the wave texture on a mesh. There probably isn't a need for a mesh test, unless the wave texture has a 3D component that can't be captured in the light test. For the next list I'm creating (the configurations of nodes that aren't tested from the nodes that are tested), I will include more notes about the things that likely don't need extra tests made.
Alaska commented 2024-07-09 09:18:51 +02:00
Member
Copy Link

Sorry it took me so long to creating the second list (Configurations we don't test from nodes we do test).

In the list below you will find nodes that are being tested, but configurations of these nodes that aren't. Many of these can probably be skipped.

Sorry the list is so long. There are a lot of nodes.

List of nodes
Ambient Occlusion
  • The Inside option (Probably doesn't need a extra test because it just flips a vector)
  • AO node sample counts higher than 1
    • A similar test with a render sample count of 1 (One of the cases Weizhen found didn't work well with some sampling patterns)
  • Distance limiting (Probably doesn't need a test)
  • A Ambient Occlusion node with a normal input (Probably doesn't need a test)
Attribute

These extra configurations probably don't need testing.

  • The alpha output in Geomtry mode
  • The Vector and Fac outputs in Object mode
  • The Vector and Fac outputs in Instancer mode
  • The Vector and Fac outputs in Viewlayer mode
Bevel
  • Bevel with a custom input normal (Probably doesn't need a test)
Color Attribute
  • Explictly specifying a attribute we want to get on a node
Hair info
  • Thickness output
  • Tangent Normal output

Should we test every output of the node with both rounded ribbons and 3D curve hairs?
What about on meshes?

Geometry
  • The Tangent output on a hair strand (Usually takes a different code path from meshes)
  • True Normal output (Probably doesn't need a test as the value it outputs is already being tested by many pieces of sampling code and will appear as noise or artifacts in other tests)
  • Parametric output (Probably doesn't need a test as it's likely to be tested by various other pieces of code, but a test would make the change clearer)
  • Random Per Island output

Would it be a good idea to test each output on a mesh, strand, and a point object?

Light Path

None the inputs from the light path node are properly tested, except for the Is diffuse ray.

Object Info

None of it's outputs seem to be properly tested.
It's tested in the "Opengl" section, but these tests don't appear to run by default.

Particle Info
  • Is strand output
  • Intercept output
  • Thickness output
  • Tangent Normal output
Tangent
  • None of the radial modes are tested
Texture coordinates

Note: I skimmed through this section as there were a lot of files to look at. So I may of missed some cases that are tested.

Most of the inputs aren't properly tested

  • Normal output

  • Object output

  • Camera output

  • Window output

  • Reflection output

  • The object input

  • The From instancer boolean

It might be a good idea to test each option on different object types (mesh, light, hair, etc)

Wireframe
  • The node isn't tested with the "Pixel size" setting turned off.
Brightness/Contrast
  • The brightness slider isn't tested
Hue/Saturation/Value

None of it's outputs seem to be properly tested.
It's tested in the "Opengl" section, but these tests don't appear to run by default.

Invert

The node doesn't appear to be properly tested.
It's tested in the "Opengl" section, but these tests don't appear to run by default.

Mix node
  • The non-uniform mode of the vector mix node isn't tested
  • The float mode of the mix node isn't tested.
  • Basically every mode other than mix isn't tested in colour mode.
Combine colour
  • HSV mode isn't tested
  • HSL mode isn't tested
Combine XYZ

The node doesn't appear to be properly tested.
It's tested in the "Opengl" section, but these tests don't appear to run by default.

Math

Note: I only looked at float_math.blend for simplicity sake. Some of these modes may already be tested in other files.
light_texture.blend test some of them.

  • Add mode
  • Subtract mode
  • Multiply mode
  • Divide mode
  • Multiply Add mode
  • Power mode
  • Log mode
  • Square Root mode
  • Inverse Square Root mode
  • Absolute mode
  • Exponent mode
  • Minimum mode
  • Maximum mode
  • Less than mode
  • Greater than mode
  • Sign mode
  • Compare mode
  • Round mode
  • Floor mode
  • Ceil mode
  • Truncate mode
  • Fraction mode
  • Truncated Modulo mode
  • Sine mode
  • Cosine mode
  • Tangent mode
  • Arcsine mode
  • Arccosine mode
  • Arctangent mode
  • Arctan2 mode
  • Hyperbolic Sine mode
  • Hyperbolic Cosine mode
  • Hyperbolic Tangent mode
  • To radians mode
  • To degrees mode
RGB to BW

This node isn't directly tested, but it is likely to be indirectly tested wherever a RGB socket is connected to a value socket.
This node is directly tested in the "Opengl" section, but these tests don't appear to run by default.

Seperate Color

The node doesn't appear to be properly tested.
It's tested in the "Opengl" section, but these tests don't appear to run by default.

Vector Math

Note: I only looked at vector_math.blend for simplicity sake. Some of these modes may already be tested in other files.

  • Add mode
  • Subtract mode
  • Multiply mode
  • Divide mode
  • Multiply add mode
  • Absolute mode
  • Minimum mode
  • Maximum mode
  • Floor Mode
  • Ceil Mode
  • Fraction mode
  • Modulo mode
  • Sine mode
  • Cosine mode
  • Tangent mode

Note: For BSDF testing, I primarily tested the "main shader files" (E.g. the files in the bsdf test folder). This means I may miss some cases that are tested in other files.

MOST BSDFs
  • A test with a non-white base colour.

I bring this up because I was making some changes to the glass BSDF a few months ago. And according to the Cycles test suite, the change had "no impact on the rendering of glass". But it did have an impact, it specifically had a impact on every coloured or darker coloured glass, which wasn't tested.

This same issue may be encountered with other BSDFs if people are working on them.

Emission shader
  • Negaive brightness/color lights
Diffuse BSDF

Note: A lot of files use the Diffuse BSDF as a background, so I didn't check them all. A roughness greater than 0 may already be tested

  • Roughness greater than 0
Glossy BSDF
  • Smooth GGX mode (glossy_ggx_smooth.blend)
  • Smooth Multiscatter GGX mode (glossy_multiscatter_ggx.blend was supposed to be this test, but it's not setup properly. Smooth MultiGGX is equivalent to Smooth GGX, probably no additional testing needed.)
  • Anisotropic tests for Multiscatter GGX mode
Hair BSDF
  • The offset parameter isn't tested
Holdout

Holdout + transparent file
I'm not sure if this test is needed.

Principled BSDF
  • Diffuse roughness
  • Sheen normals (The sheen normals are computed as a mix between the base normals and the coat normals. This logic isn't tested)
  • GGX specular mode
Principled Hair BSDF

  • Absorption input in Huang mode

  • Melanin input in Huang mode
    Both of the tests above probably don't need to be added as the colour part of the code parth is probably the same between the Huang and Chiang models.

  • Random roughness

  • Random colour

  • Different IORs?

  • Coat parameter in the Chiang mode

  • Test on a mesh?

Principled Volume
  • Anisotropy isn't tested
  • Direct colour emission isn't tested
  • Black body emission tint isn't tested
Ray Portal
  • Coloured ray portal for tinting the rays
Sheen BSDF
  • Microfiber mode
  • Roughnesses lower than 1?
Subsurface Scatting
  • Random walk (Skin) isn't tested (all_light_types_in_volume.blend)
  • Anistropy doesn't appear to be tested
Toon BSDF
  • The Smooth parameter isn't tested
  • Diffuse mode with size 0 (I tested Blender 2.93 and it has a bug with that configuration. It's fixed now, but it's a edge case that might need testing for the future)
Volume Scatter
  • Anisotropy doesn't appear to be tested
Brick texture

This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well)

Gradient Texture

This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well)

Magic Texture

This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) principled_emission_alpha.blend

Noise texture

This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) principled_emission.blend

Voronoi texture

This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) light_texture.blend

Wave texture

This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) light_texture.blend

Bump
  • The invert mode isn't tested (Probably not neccesary)
  • Bump with a normal input connected to it.
Displacement
  • World space mode isn't tested
Mapping

This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well)

Normal

The node doesn't appear to be properly tested.
It's tested in the "Opengl" section, but these tests don't appear to run by default.

Normal Map

The "Blender Object Space" and "Blender World Space" don't appear to be tested. I'm unsure if these are legacy options or not.

Vector Curve

The node doesn't appear to be properly tested.
It's tested in the "Opengl" section, but these tests don't appear to run by default.

Vector Displacement

World space mode isn't tested

Vector transform

This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well)

Edit: I have shifted nodes that we now properly test into the list below. I will try and keep this up to date.

Updated
Glass BSDF
  • Multiscatter GGX (Addressed by !124360, glass_multiggx_tinted.blend)
Seperate XYZ
  • Y output isn't tested (light_texture.blend)
  • Z output isn't tested (all_light_types_in_volume.blend)

This probably don't need a test added for it.

Sorry it took me so long to creating the second list (Configurations we don't test from nodes we do test). --- In the list below you will find nodes that are being tested, but configurations of these nodes that aren't. Many of these can probably be skipped. Sorry the list is so long. There are a lot of nodes. <details> <summary><b>List of nodes</b></summary> <details> <summary><b>Ambient Occlusion</b></summary> - The `Inside` option (Probably doesn't need a extra test because it just flips a vector) - AO node sample counts higher than 1 - A similar test with a render sample count of 1 (One of the cases Weizhen found didn't work well with some sampling patterns) - Distance limiting (Probably doesn't need a test) - A Ambient Occlusion node with a normal input (Probably doesn't need a test) </details> <details> <summary><b>Attribute</b></summary> These extra configurations probably don't need testing. - The alpha output in `Geomtry` mode - The Vector and Fac outputs in `Object` mode - The Vector and Fac outputs in `Instancer` mode - The Vector and Fac outputs in `Viewlayer` mode </details> <details> <summary><b>Bevel</b></summary> - Bevel with a custom input normal (Probably doesn't need a test) </details> <details> <summary><b>Color Attribute</b></summary> - Explictly specifying a attribute we want to get on a node </details> <details> <summary><b>Hair info</b></summary> - Thickness output - Tangent Normal output Should we test every output of the node with both rounded ribbons and 3D curve hairs? What about on meshes? </details> <details> <summary><b>Geometry</b></summary> - The Tangent output on a hair strand (Usually takes a different code path from meshes) - True Normal output (Probably doesn't need a test as the value it outputs is already being tested by many pieces of sampling code and will appear as noise or artifacts in other tests) - Parametric output (Probably doesn't need a test as it's likely to be tested by various other pieces of code, but a test would make the change clearer) - Random Per Island output Would it be a good idea to test each output on a mesh, strand, and a point object? </details> <details> <summary><b>Light Path</b></summary> None the inputs from the light path node are properly tested, except for the `Is diffuse ray`. </details> <details> <summary><b>Object Info</b></summary> None of it's outputs seem to be properly tested. It's tested in the "Opengl" section, but these tests don't appear to run by default. </details> <details> <summary><b>Particle Info</b></summary> - Is strand output - Intercept output - Thickness output - Tangent Normal output </details> <details> <summary><b>Tangent</b></summary> - None of the radial modes are tested </details> <details> <summary><b>Texture coordinates</b></summary> Note: I skimmed through this section as there were a lot of files to look at. So I may of missed some cases that are tested. Most of the inputs aren't properly tested - Normal output - Object output - Camera output - Window output - Reflection output - The object input - The From instancer boolean It might be a good idea to test each option on different object types (mesh, light, hair, etc) </details> <details> <summary><b>Wireframe</b></summary> - The node isn't tested with the "Pixel size" setting turned off. </details> <details> <summary><b>Brightness/Contrast</b></summary> - The brightness slider isn't tested </details> <details> <summary><b>Hue/Saturation/Value</b></summary> None of it's outputs seem to be properly tested. It's tested in the "Opengl" section, but these tests don't appear to run by default. </details> <details> <summary><b>Invert</b></summary> The node doesn't appear to be properly tested. It's tested in the "Opengl" section, but these tests don't appear to run by default. </details> <details> <summary><b>Mix node</b></summary> - The non-uniform mode of the vector mix node isn't tested - The float mode of the mix node isn't tested. - Basically every mode other than mix isn't tested in colour mode. </details> <details> <summary><b>Combine colour</b></summary> - HSV mode isn't tested - HSL mode isn't tested </details> <details> <summary><b>Combine XYZ</b></summary> The node doesn't appear to be properly tested. It's tested in the "Opengl" section, but these tests don't appear to run by default. </details> <details> <summary><b>Math</b></summary> Note: I only looked at float_math.blend for simplicity sake. Some of these modes may already be tested in other files. `light_texture.blend` test some of them. - [x] Add mode - [x] Subtract mode - [x] Multiply mode - [x] Divide mode - Multiply Add mode - Power mode - Log mode - [x] Square Root mode - Inverse Square Root mode - [x] Absolute mode - Exponent mode - Minimum mode - Maximum mode - [x] Less than mode - Greater than mode - Sign mode - Compare mode - Round mode - Floor mode - Ceil mode - Truncate mode - Fraction mode - Truncated Modulo mode - [x] Sine mode - [x] Cosine mode - Tangent mode - Arcsine mode - Arccosine mode - Arctangent mode - [x] Arctan2 mode - Hyperbolic Sine mode - Hyperbolic Cosine mode - Hyperbolic Tangent mode - To radians mode - To degrees mode </details> <details> <summary><b>RGB to BW</b></summary> This node isn't directly tested, but it is likely to be indirectly tested wherever a RGB socket is connected to a value socket. This node is directly tested in the "Opengl" section, but these tests don't appear to run by default. </details> <details> <summary><b>Seperate Color</b></summary> The node doesn't appear to be properly tested. It's tested in the "Opengl" section, but these tests don't appear to run by default. </details> <details> <summary><b>Vector Math</b></summary> Note: I only looked at vector_math.blend for simplicity sake. Some of these modes may already be tested in other files. - Add mode - [x] Subtract mode - Multiply mode - Divide mode - Multiply add mode - Absolute mode - Minimum mode - Maximum mode - Floor Mode - Ceil Mode - Fraction mode - Modulo mode - Sine mode - Cosine mode - Tangent mode </details> #### Note: For BSDF testing, I primarily tested the "main shader files" (E.g. the files in the `bsdf` test folder). This means I may miss some cases that are tested in other files. <details> <summary><b>MOST BSDFs</b></summary> - A test with a non-white base colour. I bring this up because I was making some changes to the glass BSDF a few months ago. And according to the Cycles test suite, the change had "no impact on the rendering of glass". But it did have an impact, it specifically had a impact on every coloured or darker coloured glass, which wasn't tested. This same issue may be encountered with other BSDFs if people are working on them. </details> <details> <summary><b>Emission shader</b></summary> - Negaive brightness/color lights </details> <details> <summary><b>Diffuse BSDF</b></summary> Note: A lot of files use the Diffuse BSDF as a background, so I didn't check them all. A roughness greater than 0 may already be tested - Roughness greater than 0 </details> <details> <summary><b>Glossy BSDF</b></summary> - [x] Smooth GGX mode (`glossy_ggx_smooth.blend`) - Smooth Multiscatter GGX mode (glossy_multiscatter_ggx.blend was supposed to be this test, but it's not setup properly. Smooth MultiGGX is equivalent to Smooth GGX, probably no additional testing needed.) - Anisotropic tests for Multiscatter GGX mode </details> <details> <summary><b>Hair BSDF</b></summary> - The offset parameter isn't tested </details> <details> <summary><b>Holdout</b></summary> Holdout + transparent file I'm not sure if this test is needed. </details> <details> <summary><b>Principled BSDF</b></summary> - Diffuse roughness - Sheen normals (The sheen normals are computed as a mix between the base normals and the coat normals. This logic isn't tested) - GGX specular mode </details> <details> <summary><b>Principled Hair BSDF</b></summary> - Absorption input in Huang mode - Melanin input in Huang mode Both of the tests above probably don't need to be added as the colour part of the code parth is probably the same between the Huang and Chiang models. - Random roughness - Random colour - Different IORs? - Coat parameter in the Chiang mode - Test on a mesh? </details> <details> <summary><b>Principled Volume</b></summary> - Anisotropy isn't tested - Direct colour emission isn't tested - Black body emission tint isn't tested </details> <details> <summary><b>Ray Portal</b></summary> - Coloured ray portal for tinting the rays </details> <details> <summary><b>Sheen BSDF</b></summary> - Microfiber mode - Roughnesses lower than 1? </details> <details> <summary><b>Subsurface Scatting</b></summary> - Random walk (Skin) isn't tested (`all_light_types_in_volume.blend`) - Anistropy doesn't appear to be tested </details> <details> <summary><b>Toon BSDF</b></summary> - The Smooth parameter isn't tested - Diffuse mode with size 0 (I tested Blender 2.93 and it has a bug with that configuration. It's fixed now, but it's a edge case that might need testing for the future) </details> <details> <summary><b>Volume Scatter</b></summary> - Anisotropy doesn't appear to be tested </details> <details> <summary><b>Brick texture</b></summary> This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) </details> <details> <summary><b>Gradient Texture</b></summary> This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) </details> <details> <summary><b>Magic Texture</b></summary> This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) `principled_emission_alpha.blend` </details> <details> <summary><b>Noise texture</b></summary> This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) `principled_emission.blend` </details> <details> <summary><b>Voronoi texture</b></summary> This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) `light_texture.blend` </details> <details> <summary><b>Wave texture</b></summary> This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) `light_texture.blend` </details> <details> <summary><b>Bump</b></summary> - The invert mode isn't tested (Probably not neccesary) - Bump with a normal input connected to it. </details> <details> <summary><b>Displacement</b></summary> - World space mode isn't tested </details> <details> <summary><b>Mapping</b></summary> This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) </details> <details> <summary><b>Normal</b></summary> The node doesn't appear to be properly tested. It's tested in the "Opengl" section, but these tests don't appear to run by default. </details> <details> <summary><b>Normal Map</b></summary> The "Blender Object Space" and "Blender World Space" don't appear to be tested. I'm unsure if these are legacy options or not. </details> <details> <summary><b>Vector Curve</b></summary> The node doesn't appear to be properly tested. It's tested in the "Opengl" section, but these tests don't appear to run by default. </details> <details> <summary><b>Vector Displacement</b></summary> World space mode isn't tested </details> <details> <summary><b>Vector transform</b></summary> This node doesn't appear to be properly tested. (There's no test dedicated to it, and the tests that do use it don't test it well) </details> </details> --- Edit: I have shifted nodes that we now properly test into the list below. I will try and keep this up to date. <details> <summary><b>Updated</b></summary> <details> <summary><b>Glass BSDF</b></summary> - [x] Multiscatter GGX (Addressed by !124360, `glass_multiggx_tinted.blend`) </details> <details> <summary><b>Seperate XYZ</b></summary> - [x] Y output isn't tested (`light_texture.blend`) - [x] Z output isn't tested (`all_light_types_in_volume.blend`) This probably don't need a test added for it. </details> </details>
Weizhen Huang commented 2024-07-09 11:13:59 +02:00
Author
Member
Copy Link

@Alaska thanks a lot for the list, I've updated your reply with the things that I know are tested, and struck through the bullet point where all sub-bullet points are tested.
For the texture nodes, I simply mentioned the test files I know that include those texture, probably you want to have a check if those are enough.

@Alaska thanks a lot for the list, I've updated your reply with the things that I know are tested, and struck through the bullet point where all sub-bullet points are tested. For the texture nodes, I simply mentioned the test files I know that include those texture, probably you want to have a check if those are enough.
Alaska commented 2024-07-09 11:29:37 +02:00
Member
Copy Link

Thanks for that. I'll take a closer look at some of these nodes later this week and provide some new test cases if I have the time.

For co-ordination with regard to updaing the tests, I'll discuss it in Blender chat.

Just as a note. I've mainly been looking at missing tests for nodes because the search can be assisted with automation. There are obviously other areas/render settings (E.g. light linking in volumes) that need to be tested. From my perspective, it's hard to know what specific combinations that aren't being tested need testing unless there's a bug report for it. So I don't have plans to provide a list for render setting combinations to test.

Thanks for that. I'll take a closer look at some of these nodes later this week and provide some new test cases if I have the time. For co-ordination with regard to updaing the tests, I'll discuss it in Blender chat. --- Just as a note. I've mainly been looking at missing tests for nodes because the search can be assisted with automation. There are obviously other areas/render settings (E.g. light linking in volumes) that need to be tested. From my perspective, it's hard to know what specific combinations that aren't being tested need testing unless there's a bug report for it. So I don't have plans to provide a list for render setting combinations to test.
Alaska commented 2024-07-12 07:10:52 +02:00
Member
Copy Link

I have attached some test files for texture nodes. In it you will find .blend files and a readme that should hopefully explain things.

Notes:

  • I do not have commit access to the Blender repo or the tests repo. So someone else will need to commit these test files for me. Obviously a review process should probably happen first.
  • I have three folders of tests, 3.6, 4.2, 4.3 (main). I was hoping the tests could be added to the respective branchs of the test respository so they can be used for testing backports.
  • I was hoping these tests could be added to a new /render/texture/ folder. This will require the texture tests folder to be enabled: !124574
  • Since most of these tests were made in 3.6, they can be used right now to see if anything has changed between 3.6 and 4.3 by generating the test images in 3.6 and re-testing in 4.3.
    • In my own testing, a few scenes failed. Quite a few of them are due to noise differences, while two (IES on a mesh, and image texture) may need to be looked at due to differences which aren't noise.
I have attached some test files for texture nodes. In it you will find .blend files and a readme that should hopefully explain things. Notes: - I do not have commit access to the Blender repo or the tests repo. So someone else will need to commit these test files for me. Obviously a review process should probably happen first. - I have three folders of tests, 3.6, 4.2, 4.3 (main). I was hoping the tests could be added to the respective branchs of the test respository so they can be used for testing backports. - I was hoping these tests could be added to a new `/render/texture/` folder. This will require the texture tests folder to be enabled: !124574 - Since most of these tests were made in 3.6, they can be used right now to see if anything has changed between 3.6 and 4.3 by generating the test images in 3.6 and re-testing in 4.3. - In my own testing, a few scenes failed. Quite a few of them are due to noise differences, while two (IES on a mesh, and image texture) may need to be looked at due to differences which aren't noise.
Texture Tests.zip
5.1 MiB
Alaska commented 2024-07-12 14:07:18 +02:00
Member
Copy Link

I've created a rough pull request that allows the enablement of OSL for the Cycles render test: !124601

It's a "rough pull request" because it works, but it seems a bit hacky. Not sure if it's up to the standard of the Blender foundation.

I've created a rough pull request that allows the enablement of OSL for the Cycles render test: !124601 It's a "rough pull request" because it works, but it seems a bit hacky. Not sure if it's up to the standard of the Blender foundation.
Weizhen Huang commented 2024-07-15 12:34:19 +02:00
Author
Member
Copy Link

@Alaska
Thanks for the extensive test files, I have started looking into the individual blend files.

I do not have commit access to the Blender repo or the tests repo.

For a proper review process, would you like to have temporary commit access to blender/blender-test-data, so that you can create a PR in blender/blender-test-data like this blender/blender-test-data#5, and then creata a PR in blender/blender to point to your commit in the PR, like this #124360, to call the blender-bot for testing?

Otherwise I can make a PR in the test repo, but then it becomes my PR and it would be quite complicated for you to make subsequent changes.

Let me know what works best for you.

@Alaska Thanks for the extensive test files, I have started looking into the individual blend files. > I do not have commit access to the Blender repo or the tests repo. For a proper review process, would you like to have temporary commit access to `blender/blender-test-data`, so that you can create a PR in `blender/blender-test-data` like this https://projects.blender.org/blender/blender-test-data/pulls/5, and then creata a PR in `blender/blender` to point to your commit in the PR, like this https://projects.blender.org/blender/blender/pulls/124360, to call the blender-bot for testing? Otherwise I can make a PR in the test repo, but then it becomes my PR and it would be quite complicated for you to make subsequent changes. Let me know what works best for you.
Alaska commented 2024-07-15 15:35:40 +02:00
Member
Copy Link

The main benefit commit access would grant me is the ability to quickly iterate on files and get then tested by the build bot? Or is it that I can iterate on files in a repo and you can get them with a simple git pull.

In either case, it might be better to NOT give me commit access.

I can do testing locally (I have access to a wide range of hardware and OS'), and I can create a temporary repo you can pull from.
Once we've gotten the tests to a state where it's ready for commiting to blender/blender-test-data, you could open a pull request in the blender-test-data repo, I can modify !124574 to point to it, then we can run a final test on build bot and commit if it passes.

Note: I believe @blender-bot build requires the user to have commit access to blender/blender to stop people from running code on the build machine without going through some sort of review first. So giving me commit access to blender/blender-test-data wouldn't be enough for build bot testing.

I believe we should start with getting the tests commited to 4.3/main, then can work backwards and add them to the 4.2 and 3.6 LTS branchs if desired.

The main benefit commit access would grant me is the ability to quickly iterate on files and get then tested by the build bot? Or is it that I can iterate on files in a repo and you can get them with a simple `git pull`. In either case, it might be better to NOT give me commit access. I can do testing locally (I have access to a wide range of hardware and OS'), and I can create a temporary repo you can pull from. Once we've gotten the tests to a state where it's ready for commiting to `blender/blender-test-data`, you could open a pull request in the `blender-test-data` repo, I can modify !124574 to point to it, then we can run a final test on build bot and commit if it passes. Note: I believe `@blender-bot build` requires the user to have commit access to `blender/blender` to stop people from running code on the build machine without going through some sort of review first. So giving me commit access to `blender/blender-test-data` wouldn't be enough for build bot testing. --- I believe we should start with getting the tests commited to 4.3/main, then can work backwards and add them to the 4.2 and 3.6 LTS branchs if desired.
Alaska commented 2024-07-16 20:37:15 +02:00
Member
Copy Link

While investigating texture tests, I found a few other areas we should probably add tests for:

  • Image loading - Sometimes there are bugs with loading some images in Cycles due to bugs in OIIO. Having render tests for this would be nice. However there are many different file types, with many different configurations (bit depth, number of channels, compression scheme, even image resolution can have a factor in some cases), I'm not sure how feasible it'll be create and test all of them.
  • IES tests - We should test to make sure that all IES types that Cycles supports loads and renders properly (I believe they're called "Type A, B, and C"). And we should maybe add a IES on mesh test (I'm still not sure if it's even worth testing)
While investigating texture tests, I found a few other areas we should probably add tests for: - Image loading - Sometimes there are bugs with loading some images in Cycles due to bugs in OIIO. Having render tests for this would be nice. However there are many different file types, with many different configurations (bit depth, number of channels, compression scheme, even image resolution can have a factor in some cases), I'm not sure how feasible it'll be create and test all of them. - IES tests - We should test to make sure that all IES types that Cycles supports loads and renders properly (I believe they're called "Type A, B, and C"). And we should maybe add a IES on mesh test (I'm still not sure if it's even worth testing)
Alaska commented 2024-08-02 12:52:36 +02:00
Member
Copy Link

While working on !125803 I noticed there was no test for shadow linking with curves/point objects, which is important for testing some custom BVH functions.

I've added a point for this to the original report.

While working on !125803 I noticed there was no test for shadow linking with curves/point objects, which is important for testing some custom BVH functions. I've added a point for this to the original report.
👍 1
Alaska commented 2024-08-07 15:43:20 +02:00
Member
Copy Link

#125307 is a bug report about precision realted artifacts that occured when far away from the world origin on Metal-RT due to the disabling of ray offsetting on that platform during the development of 4.2.

In that bug report Michael Jones from Apple asked if it was possible to add a render test away from the world origin to test these sorts of issues so they can be picked up easier. I volunteered to investigate if this was feasible by comparing the results across many different devices. And here are some quick results.

I created a standard size test scene at position x=500m, y=1000m, z=2000m to test these precision issues, although other precision related tests could be (I have attached an example image and .blend file). Note: This files tests 1, maybe 2 precision issues. There are many others we could try testing.

A lot of platforms are fairly consistent with subtle noise differences between them. However, some platforms do have differences that will make them fail our render tests. For example, comparing x86 Windows to ARM macOS has enough of a difference to fail the render test using our standard test threshold (See x86 vs ARM.png). The exact same differences between x86 and ARM also propergate to x86 vs Metal. So I assume the issue is with slight precision differences during scene setup, not during rendering, but I'm just guessing here. However with the same CPU there can still be some large differences. For example x86 vs HIP with BVH2 is fine, but x86 vs HIP-RT is not (see x86 vs HIP-RT.png). And ARM CPU vs Metal is fine, but ARM CPU vs Metal-RT is not.

So at this scale, we can't add a precision test to the test suite.

I had a few thoughts on how to resolve this:

  • Shift the scene closer to the origin, it will make precision issues less obvious, but should reduce differences between platforms.
  • Most of the differences seem to come from the monkeys, which have their origin at 0,0,0 but the geometry is placed at 500, 1000, 2000. We could remove those and create seperate tests for that sort of precision issue.
  • Increase the noise threshold or number of failure pixels and hope it can still detect precision differences.
  • Investigate a alternative failure system.
    • If precision issues suddenly manifest, they're more likely to appear as changes in the "structure" of the image, not the noise of the image. So using a failure system that judges based on structure would be better than judging on absolute difference. I believe SSIM could be a good candidate for that, but I'm not sure how we can access with the current tools avaliable to us from the Blender repo and libraries. I ran some quick tests to verify SSIM as a potential tool. SSIM score between x86 CPU and MetalRT is 0.95, while SSIM between x86 CPU and MetalRT with ray offsetting disabled is 0.68. There are obviously other options we could try.

What are peoples thoughts? CC @Sergey for your input.

#125307 is a bug report about precision realted artifacts that occured when far away from the world origin on Metal-RT due to the disabling of ray offsetting on that platform during the development of 4.2. In that bug report Michael Jones from Apple asked if it was possible to add a render test away from the world origin to test these sorts of issues so they can be picked up easier. I volunteered to investigate if this was feasible by comparing the results across many different devices. And here are some quick results. --- I created a standard size test scene at position x=500m, y=1000m, z=2000m to test these precision issues, although other precision related tests could be (I have attached an example image and .blend file). Note: This files tests 1, maybe 2 precision issues. There are many others we could try testing. A lot of platforms are fairly consistent with subtle noise differences between them. However, some platforms do have differences that will make them fail our render tests. For example, comparing x86 Windows to ARM macOS has enough of a difference to fail the render test using our standard test threshold (See `x86 vs ARM.png`). The exact same differences between x86 and ARM also propergate to x86 vs Metal. So I assume the issue is with slight precision differences during scene setup, not during rendering, but I'm just guessing here. However with the same CPU there can still be some large differences. For example x86 vs HIP with BVH2 is fine, but x86 vs HIP-RT is not (see `x86 vs HIP-RT.png`). And ARM CPU vs Metal is fine, but ARM CPU vs Metal-RT is not. So at this scale, we can't add a precision test to the test suite. I had a few thoughts on how to resolve this: - Shift the scene closer to the origin, it will make precision issues less obvious, but should reduce differences between platforms. - Most of the differences seem to come from the monkeys, which have their origin at 0,0,0 but the geometry is placed at 500, 1000, 2000. We could remove those and create seperate tests for that sort of precision issue. - Increase the noise threshold or number of failure pixels and hope it can still detect precision differences. - Investigate a alternative failure system. - If precision issues suddenly manifest, they're more likely to appear as changes in the "structure" of the image, not the noise of the image. So using a failure system that judges based on structure would be better than judging on absolute difference. I believe SSIM could be a good candidate for that, but I'm not sure how we can access with the current tools avaliable to us from the Blender repo and libraries. I ran some quick tests to verify SSIM as a potential tool. SSIM score between x86 CPU and MetalRT is 0.95, while SSIM between x86 CPU and MetalRT with ray offsetting disabled is 0.68. There are obviously other options we could try. What are peoples thoughts? CC @Sergey for your input.
Example.jpg
314 KiB
x86 vs ARM.png
1.8 MiB
x86 vs HIP-RT.png
2.9 MiB
Precision Test Scene.blend
1.1 MiB
Example.jpg x86 vs ARM.png x86 vs HIP-RT.png
Alaska commented 2024-08-15 04:32:21 +02:00
Member
Copy Link
  • Add an option to test with OSL (!124601)

One thing I noticed while creating and testing the OSL patch was that if constant folding can be done, then the node will be constant folded using SVM.
For example, in the vector math nodes test all the vector math nodes are constant folded by SVM. Meaning that the OSL version of this test doesn't actually test the vector math node in OSL mode.

I have added a bullet point for this issue.

> - [x] Add an option to test with OSL (!124601) One thing I noticed while creating and testing the OSL patch was that if constant folding can be done, then the node will be constant folded using SVM. For example, in the vector math nodes test all the vector math nodes are constant folded by SVM. Meaning that the OSL version of this test doesn't actually test the vector math node in OSL mode. I have added a bullet point for this issue.
Alaska commented 2024-08-15 09:42:54 +02:00
Member
Copy Link
  • Improve hair/curve tests on GPU (some are disabled due to "Inconsistency between Embree and Hair primitive on GPU". Not sure if it's straightforward to fix and re-enable the tests. Ref #124295)

Here are the test result from the major GPU platforms we support to help gauge the "inconsistency between Embree and Hair Primitives on GPU".

Process for creating these test results:

  1. Use BLENDER_TEST_IGNORE_BLOCKLIST=1 whenever I ran a test to ensure these blocked tests were run.
  2. Regenerate all the reference images with ARM macOS. (Some of the tests have old images and fail on all platforms due to changes in sampling patterns or something. So I had to regenerate the images to avoid that issue)
  3. Run tests on the various platforms with the new test images.

Notes:

  1. The denoising hair test fails on most platforms I tested. This is because the placement of hair strands is different between my ARM Mac and my x86 Windows device, which already marks a lot of pixels as "failed" but it's not enough for the render test to actually fail. It's that plus the noise differences from the different BVH that causes the failure.
  2. There are a lot of other failing tests you can ignore (E.g. OSL tests on GPU). And the various issues that HIPRT has.
> - [ ] Improve hair/curve tests on GPU (some are disabled due to "Inconsistency between Embree and Hair primitive on GPU". Not sure if it's straightforward to fix and re-enable the tests. Ref #124295) Here are the test result from the major GPU platforms we support to help gauge the "inconsistency between Embree and Hair Primitives on GPU". Process for creating these test results: 1. Use `BLENDER_TEST_IGNORE_BLOCKLIST=1` whenever I ran a test to ensure these blocked tests were run. 2. Regenerate all the reference images with ARM macOS. (Some of the tests have old images and fail on all platforms due to changes in sampling patterns or something. So I had to regenerate the images to avoid that issue) 3. Run tests on the various platforms with the new test images. Notes: 1. The denoising hair test fails on most platforms I tested. This is because the placement of hair strands is different between my ARM Mac and my x86 Windows device, which already marks a lot of pixels as "failed" but it's not enough for the render test to actually fail. It's that plus the noise differences from the different BVH that causes the failure. 2. There are a lot of other failing tests you can ignore (E.g. OSL tests on GPU). And the various issues that HIPRT has.
metal - metalrt.zip
23 MiB
metal - bvh2.zip
23 MiB
oneapi - embree.zip
23 MiB
optix.zip
23 MiB
hip - hiprt.zip
23 MiB
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset System
Asset datablocks, libraries, browser and shelf

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
Backward and forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Viewport & EEVEE

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Wayland windowing on Unix

  
Interest
Workbench

  
Interest: X11

Xorg/X11 windowing

  
Legacy
Asset Browser Project

Archived

  
Legacy
Blender 2.8 Project

Archived

  
Legacy
Milestone 1: Basic, Local Asset Browser

Archived

  
Legacy
OpenGL Error

Archived

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Related to security, https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Module
Viewport & EEVEE

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Severity
High

  
Severity
Low

  
Severity
Normal

  
Severity
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

Archived

  
Type
Report

Archived

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Render & Cycles
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#123012
No description provided.
Delete Branch "%!s()"

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?