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: 64
Joined: Tue Dec 05, 2017 4:54 pm

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

Post by Piita »

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
scene in a clear volume.<br />Parts of the yellow plane is not rendered <br />where it overlaps with the alpha of the first plane. <br />Incorrect render
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 3110 times
scene in no volume. Correct render
scene in no volume. Correct render
2-no volume.jpg (12.18 KiB) Viewed 3110 times
How it is set up. The blue plane is smaller <br />than the second plane so it's hidden behind it
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 3110 times
Piitas.blog
Librem 5 - The privacy focused smart phone
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

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

Post by Dade »

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: 4146
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. »

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.
CodeHD
Donor
Donor
Posts: 437
Joined: Tue Dec 11, 2018 12:38 pm
Location: Germany

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

Post by CodeHD »

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