blender/blender-test-data
0
0
Fork 7
Code Pull Requests 11 Activity

WIP: Add Texture coordinate render tests #11

Draft
Alaska wants to merge 1 commits from Alaska/blender-test-data:texture-coordinate into main
pull from: Alaska/blender-test-data:texture-coordinate
merge into: blender:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 3 Commits 1 Files Changed 1 +3
Alaska commented 2024-09-03 16:25:03 +02:00
Member
Copy Link

WIP: Wanted to go through a review process first before deciding to make all the relevant files.

WIP: Wanted to go through a review process first before deciding to make all the relevant files.
Alaska added 1 commit 2024-09-03 16:25:05 +02:00
Alaska commented 2024-09-03 16:40:38 +02:00
Author
Member
Copy Link

I feel like the render tests need more tests specifically for the texture coordinate node. So I've started this PR to get that going.

At the moment there is only one file (The Window output), and this is for two reasons:

  • I want to go through a review process and modify the file with feedback provided by the review before making the other test files (All the other outputs of the Texture Coordinate node).
  • The Window output is the most important to get a test made for it. Because it was requested by Clément (on the old Blender chat), it's currently broken in OptiX OSL, and was broken oneAPI in the past, and there is currently only one test for it, and it's "frequently" disable as it's part of a denoising test.

General things I wanted to note and get feedback on.

  • The current file contains these features:
    • A mesh room. Nothing special about it.
    • A scaled and rotated object. (More important for some of the other output types)
    • A instanced scaled and rotated object. (More important for some of the other output types)
    • A point cloud object.
    • A hair curve (with a large radius and end caps out of view to reduce differences between backends).
    • A glossy sphere so objects can be viewed from alternative directions. Also useful for the Window output to see what happens for non-camera rays.
    • A visible world background.
  • There are currently a few configurations missing. The examples I can think of at the moment are:
    • Using the From Instancer option on the Texture Coordinate node.
    • Using the Object option on the Texture Coordinate node.
    • Testing lights with these options.

How important do you think it is to try and include tests for these missing configurations? Should I try and merge them into a single file or create separate test files?

One other question I had was should I just display the output of the Texture Coordinate node directly to the camera, making it easier to see when something's wrong, or do something like what I've done now (connect the output to a texture node)?

I have attached a example image generated with texture_coordinate_window.blend

I feel like the render tests need more tests specifically for the texture coordinate node. So I've started this PR to get that going. At the moment there is only one file (The `Window` output), and this is for two reasons: - I want to go through a review process and modify the file with feedback provided by the review before making the other test files (All the other outputs of the Texture Coordinate node). - The `Window` output is the most important to get a test made for it. Because it was requested by Clément (on the old Blender chat), it's currently broken in [OptiX OSL](https://projects.blender.org/blender/blender/issues/126371), and was broken [oneAPI in the past](https://projects.blender.org/blender/blender/issues/118713), and there is currently only one test for it, and it's "frequently" disable as it's part of a denoising test. General things I wanted to note and get feedback on. - The current file contains these features: - A mesh room. Nothing special about it. - A scaled and rotated object. (More important for some of the other output types) - A instanced scaled and rotated object. (More important for some of the other output types) - A point cloud object. - A hair curve (with a large radius and end caps out of view to reduce differences between backends). - A glossy sphere so objects can be viewed from alternative directions. Also useful for the `Window` output to see what happens for non-camera rays. - A visible world background. - There are currently a few configurations missing. The examples I can think of at the moment are: - Using the `From Instancer` option on the Texture Coordinate node. - Using the `Object` option on the Texture Coordinate node. - Testing lights with these options. How important do you think it is to try and include tests for these missing configurations? Should I try and merge them into a single file or create separate test files? One other question I had was should I just display the output of the Texture Coordinate node directly to the camera, making it easier to see when something's wrong, or do something like what I've done now (connect the output to a texture node)? I have attached a example image generated with `texture_coordinate_window.blend`
Example.jpg
47 KiB
Example.jpg
Alaska requested review from Sergey Sharybin 2024-09-03 16:40:51 +02:00
Alaska requested review from Weizhen Huang 2024-09-03 16:40:52 +02:00
Sergey Sharybin commented 2024-10-15 15:57:46 +02:00
Owner
Copy Link

@Alaska Generally i think the texture_coordinate_window.blend is good. The only thing I am not sure is the mirror ball: it adds noise to the scene, which might make it harder to ensure test passes on all platforms. Is it essential for testing the texture mapping?

Having single file for tests simplifies some things, but makes it harder to notice actual regressions (if the "failed" feature is too small, and falls under the failed pixels threshold).
So, perhaps, best would be to have separate files for the configurations you've mentioned (From Instancer, Object) as separate files that are based on the current one you're proposing.

The light better be a separate file, as it is quite different from objects.

For the importance: is good to expand our testing, but i wouldn't consider lack of those tests a stopper for a smaller steps forward.

@Alaska Generally i think the `texture_coordinate_window.blend` is good. The only thing I am not sure is the mirror ball: it adds noise to the scene, which might make it harder to ensure test passes on all platforms. Is it essential for testing the texture mapping? Having single file for tests simplifies some things, but makes it harder to notice actual regressions (if the "failed" feature is too small, and falls under the failed pixels threshold). So, perhaps, best would be to have separate files for the configurations you've mentioned (`From Instancer`, `Object`) as separate files that are based on the current one you're proposing. The light better be a separate file, as it is quite different from objects. For the importance: is good to expand our testing, but i wouldn't consider lack of those tests a stopper for a smaller steps forward.
Alaska commented 2024-10-16 15:24:32 +02:00
Author
Member
Copy Link

The only thing I am not sure is the mirror ball: it adds noise to the scene, which might make it harder to ensure test passes on all platforms. Is it essential for testing the texture mapping?

It's not essential to testing texture mapping, but for something like the Reflection and Window modes, it does test a extra aspect (They produce different/interesting results when viewed through a reflection)

I can swap it out for something like a reflective plane, or a subtley curved surface rather than a ball, or just remove it entirely if you want.

> The only thing I am not sure is the mirror ball: it adds noise to the scene, which might make it harder to ensure test passes on all platforms. Is it essential for testing the texture mapping? It's not essential to testing texture mapping, but for something like the `Reflection` and `Window` modes, it does test a extra aspect (They produce different/interesting results when viewed through a reflection) I can swap it out for something like a reflective plane, or a subtley curved surface rather than a ball, or just remove it entirely if you want.
This pull request is marked as a work in progress.
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u texture-coordinate:Alaska-texture-coordinate
git checkout Alaska-texture-coordinate
Sign in to join this conversation.
Reviewers
No reviewers
Sergey Sharybin
Weizhen Huang
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
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-test-data#11
No description provided.
Delete Branch "Alaska/blender-test-data:texture-coordinate"

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?