How do you find a bug in a 3D renderer?

General project and community related discussions and offtopic threads.
Post Reply
User avatar
Piita
Supporting Users
Posts: 63
Joined: Tue Dec 05, 2017 4:54 pm

How do you find a bug in a 3D renderer?

Post by Piita » Tue Apr 30, 2019 5:11 pm

I have been thinking about this. How do you find a bug in such a complex piece of software such as a 3D renderer? You got no error message to point you in the right direction. All you have is a visual error. You render a scene and you can see that something does not look right but how do you find the problem in the code?

There is an old bug that I remember, that is now fixed: A ray from the camera would pass through a plane with partial alpha transparency based on a texture. If there is another plane with partial alpha transparency behind that first plane, the renderer did not see the second plane at all. If there is a third plane behind those two and it is opaque, the renderer did see that third plane. The bonus thing is that this bug only occurred when the planes have an interior and exterior volume.
How do you guys know where to look in order to find a bug like that?
Attachments
1-volume.jpg
scene in a clear volume.
Parts of the yellow plane is not rendered
where it overlaps with the alpha of the first plane.
Incorrect render
1-volume.jpg (12.24 KiB) Viewed 376 times
2-no volume.jpg
scene in no volume. Correct render
2-no volume.jpg (12.18 KiB) Viewed 376 times
3-setup.png
How it is set up. The blue plane is smaller
than the second plane so it's hidden behind it
3-setup.png (5.6 KiB) Viewed 376 times
Piitas.blog
Librem 5 - The privacy focused smart phone. It does not run Android or iOS that track you and send data about you to Google.

User avatar
Dade
Developer
Developer
Posts: 2778
Joined: Mon Dec 04, 2017 8:36 pm

Re: How do you find a bug in a 3D renderer?

Post by Dade » Tue Apr 30, 2019 7:34 pm

Piita wrote:
Tue Apr 30, 2019 5:11 pm
How do you guys know where to look in order to find a bug like that?
Human way: you are the best neural network ever built (as far as we know), trained for years by reality. If it looks wrong, it is probably wrong. It is called the Duck test: "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck."

Technical way: cross compare the results within the same rendering software (for instance path tracing Vs. bidirectional path tracing) or across different render engines (for instance Lux Vs Cycles results).

Interestingly, we have seen post here many examples of both ways.
Support LuxCoreRender project with salts and bounties

User avatar
B.Y.O.B.
Developer
Developer
Posts: 2809
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: How do you find a bug in a 3D renderer?

Post by B.Y.O.B. » Tue Apr 30, 2019 7:58 pm

Piita wrote:
Tue Apr 30, 2019 5:11 pm
You got no error message to point you in the right direction. All you have is a visual error. You render a scene and you can see that something does not look right but how do you find the problem in the code?
Sometimes you can guess from the visual error in what part of the code the bug might be. In your example I would first check the code that handles transparency. To narrow down the problem it helps to make the test scene as minimal as possible while still reproducing the bug. It might even help to disable parts of the renderer or to insert debug printf() calls that print color values at different stages in the program.
You can have luck and see an obvious mistake/oversight in the code at your first guessed location, or you can have bad luck and look in all the wrong spots first.
Support LuxCoreRender project with salts and bounties

CodeHD
Posts: 182
Joined: Tue Dec 11, 2018 12:38 pm

Re: How do you find a bug in a 3D renderer?

Post by CodeHD » Wed May 01, 2019 9:08 am

I can give you a practical example from my current work on implementing the tiled OIDN (see this post.)
There I have regions of the image which are computed as an overlap from two stripes, one of which appears to be wrong, but I don't know immediately which. I then comment-out one of the overlap terms and run the code like that. In the result, I can see if the correct part has been commented out or left in. I have now narrowed it down to the block of code where the errorneuos buffer is filled.

Post Reply