1
$\begingroup$

this is my first post on the Computer Graphics Stackexchange forum. Apologies in advance if I am doing something wrong.

I have the problem that I have a scene with overlapping geometries. To be more precise, my scene is a Cornell Box, where the ceiling and the area light are quads that are lying in the same plane, e.g. are having the same height value:

enter image description here

This image is rendered by our "home renderer" and I am working on the integration of Intel's Embree framework into it, to accelerate the ray casting process.

When I render the scene with the help of Embree, it looks like this:

enter image description here

(There is nothing wrong with Embree itself, but probably with what I am doing with it) What is immediately visible is that the ceiling looks more "grainy" or noisy and that pixels in the area light have the colour of the ceiling.

I strongly believe that this has something to do with the fact that the ceiling and the area light are lying in the same plane. So my question is: when such overlapping geometries are intersected with a ray, how does one choose which of the two geometries should be prioritized?

I did a short experiment in Blender with two cubes with different materials: enter image description here

Then I moved the green cube "into" the red one, meaning I assigned the same position, such that the two cubes are overlapping.

This is what the Cycles renderer gave me: enter image description here

Does anyone know what is going on? How can I handle the situation of overlapping geometry in my ray tracer? Many thanks in advance for your help and support. Have a nice Weekend!

Kind regards Sebastian

$\endgroup$
11
  • $\begingroup$ "How can I handle the situation of overlapping geometry in my ray tracer?" Offset your area light slightly. $\endgroup$ – lightxbulb May 9 at 18:18
  • $\begingroup$ @lightxbulb Thank you for your suggestion. Offsetting my area light fixes my problem indeed. However, I have a number of scenes with this edge case. I am trying to figure out something $\endgroup$ – sschimper May 9 at 19:46
  • $\begingroup$ You'll have to offset those too. As far as I am aware that's the best solution. There's also the option of splitting the scene into light sources and non-light sources and intersection those collections separately, then if two intersections are too close, always taking the lights one. But that's more of a hack than anything, and I wouldn't recommend it. Just model your scenes properly - after all in the real world you cannot have two objects that are intersecting. $\endgroup$ – lightxbulb May 9 at 21:17
  • 3
    $\begingroup$ There is no solution. None of the engines i have worked with had any sollution to this and ive used about 40 different renderers. Why? How would the renderer know which one should have a priority? You could actually have a preprocessor that checks for this and cuts offending faces. But this is a modeling time solution. Note that same face on top of each other is different from coplanar faces same is guarateed to have same sample values but coplanar is not. $\endgroup$ – joojaa May 10 at 6:03
  • $\begingroup$ @lightxbulb I am going with your approach for now. I'd have to lie to you when I say "I know everything about our home renderer", but I believe the hack you are describing is what the renderer does in the first place to create the flawless first image (I am going to investigate this later). Thanks again for your help! $\endgroup$ – sschimper May 10 at 7:25
0
$\begingroup$

This is more of a comment then an answer:

I have resolved this problem in a ray tracer using Constructive Solid Geometry(CSG). Which was done by adding operators that allowed us to create objects that are the union, difference, and intersection of a combination of objects. Here is a wiki page on the subject.

CSG sounds difficult to implement, but it is actually surprisingly straight forward.

But, this system was added for other reasons, it just turned out that we could "subtract" the light from the box (using your post as an example), then the intersection for the light itself falls out naturally since it can no longer hit the box where the two intersect.

This really is just reiterating what everyone has been saying in the comments, every solution is either done by creating real geometry that avoids the problem (like CSG) or use some sort of hack. I posted the CSG answer because it resolves the problem so naturally if it is available.

$\endgroup$
1
  • $\begingroup$ Hi @pmv1234, thank you for your post (I would have given it an up-vote, but I do not have enough reputation yet). It is coincidental that you mention CSG since it is the next "big thing" which I would like to implement. So I will definitely keep your suggestion in mind :) $\endgroup$ – sschimper May 10 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.