<p>This is more of a comment then an answer:</p>
<p>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. <a href="https://en.wikipedia.org/wiki/Constructive_solid_geometry" rel="nofollow noreferrer">Here is a wiki page on the subject.</a></p>
<p>CSG sounds difficult to implement, but it is actually surprisingly straight forward.</p>
<p>But, this system was added for other reasons, it just turned out that we could &quot;subtract&quot; 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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-05-10T20:06:11.200Z
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 :)
sschimper
CC BY-SA 4.0
2021-05-10T12:37:41.837Z
2021-05-10T12:54:53.393Z
2021-05-10T12:54:53.393Z
pmw1234
<p>this is my first post on the Computer Graphics Stackexchange forum. Apologies in advance if I am doing something wrong.</p>
<p>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:</p>
<p><a href="https://i.sstatic.net/qjJfD.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/qjJfD.png" alt="enter image description here" /></a></p>
<p>This image is rendered by our &quot;home renderer&quot; and I am working on the integration of Intel's Embree framework into it, to accelerate the ray casting process.</p>
<p>When I render the scene with the help of Embree, it looks like this:</p>
<p><a href="https://i.sstatic.net/ruuES.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ruuES.png" alt="enter image description here" /></a></p>
<p>(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 &quot;grainy&quot; or noisy and that pixels in the area light have the colour of the ceiling.</p>
<p>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?</p>
<p>I did a short experiment in Blender with two cubes with different materials:
<a href="https://i.sstatic.net/rX9Lk.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/rX9Lk.jpg" alt="enter image description here" /></a></p>
<p>Then I moved the green cube &quot;into&quot; the red one, meaning I assigned the same position, such that the two cubes are overlapping.</p>
<p>This is what the Cycles renderer gave me:
<a href="https://i.sstatic.net/6uRaL.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/6uRaL.jpg" alt="enter image description here" /></a></p>
<p>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!</p>
<p>Kind regards
Sebastian</p>

CC BY-SA 4.0
2021-05-09T18:18:59.277Z
"How can I handle the situation of overlapping geometry in my ray tracer?" Offset your area light slightly.
lightxbulb
CC BY-SA 4.0
2021-05-09T19:46:19.307Z
@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
sschimper
CC BY-SA 4.0
2021-05-09T21:17:23.093Z
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.
lightxbulb
CC BY-SA 4.0
2021-05-10T06:03:57.763Z
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.
joojaa
CC BY-SA 4.0
2021-05-10T07:25:26.747Z
@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!
sschimper
CC BY-SA 4.0
2021-05-10T07:30:12.157Z
@joojaa thank you for your reply. As someone whose experience with rendering engines is somewhat limited (we implemented a toy ray tracer in class and I played around with some stuff), I appreciate you sharing your insights. I just thought maybe there is a way to address this issue which I am not aware of, and I thought it would be reasonable enough to post here.
sschimper
CC BY-SA 4.0
2021-05-10T07:39:00.477Z
@sschimper the problem is that when 2 faces are coplanar but not same face, The youy end up with rounding errors in intersections meaning its entirely up to gods of rounding errors. So your proposing to solve a issue that can easily be done in the source file in one operation with a solution that needs to be solved per ray. Its not that it couldnt be done, one still has to decide for the computer.  Theres nothing wrong with preprocessing the scene you know. Your example is not valid since the engines are tuned to avoid this particular usecase because it a requirement for multipass rendering
joojaa
CC BY-SA 4.0
2021-05-10T08:05:05.737Z
If you don't wanna offset, then you gotta put a hole in the wall. delete the geometry to make space for that rectangular light. As jooja said, this looks more like a modeling issue. No point in adding extra complications to the rendering portion when you can clean up during the pre-processing/modeling area.
gallickgunner
CC BY-SA 4.0
2021-05-10T08:08:47.603Z
@joojaa your comment is valuable to me, thank you. I did not mention it in my post, but what probably adds to the problem is that I am casting doubles to floats (our renderer uses doubles and Embree uses floats, so I need to perform the casting. This is maybe why the edges  between the ceiling and the 4 walls are not as detailed in the 2nd picture than in the 1st. Until now I am just compensating for this by considering intersections only in the interval [0.001, infinity]). In the future I will have a discussion with the developers of our renderer.
sschimper
CC BY-SA 4.0
2021-05-10T10:47:21.887Z
"what probably adds to the problem is that I am casting doubles to floats" - the issue is actually fairly simple, it is a mathematical problem after all. If you have two surfaces that intersect over some region it is not unambiguous which to pick. So you need to disambiguate that. The clean way to do this is to remove the intersecting piece of one of the two. Other approaches are hacks: the offset, splitting the scene in non-lights and lights, and other such techniques. As far as avoiding self-intersection, don't use [0.001, inf), instead offset along the normal, cf the ray-tracing gems book.
lightxbulb
<raytracing>
Ray tracing geometries with same position, translation and scale
sschimper
# Ray tracing geometries with same position, translation and scale

(Asked by: username_0 on 2021-05-09)

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](https://i.sstatic.net/qjJfD.png)](https://i.sstatic.net/qjJfD.png)

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](https://i.sstatic.net/ruuES.png)](https://i.sstatic.net/ruuES.png)

(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](https://i.sstatic.net/rX9Lk.jpg)](https://i.sstatic.net/rX9Lk.jpg)

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](https://i.sstatic.net/6uRaL.jpg)](https://i.sstatic.net/6uRaL.jpg)

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

**Tags:** raytracing

> **Comments:**
> **username_1**: "How can I handle the situation of overlapping geometry in my ray tracer?" Offset your area light slightly.  
> **username_0**: @username_1 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  
> **username_1**: 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.  
> **username_2**: 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.  
> **username_0**: @username_1 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!  
> **username_0**: @username_2 thank you for your reply. As someone whose experience with rendering engines is somewhat limited (we implemented a toy ray tracer in class and I played around with some stuff), I appreciate you sharing your insights. I just thought maybe there is a way to address this issue which I am not aware of, and I thought it would be reasonable enough to post here.  
> **username_2**: @username_0 the problem is that when 2 faces are coplanar but not same face, The youy end up with rounding errors in intersections meaning its entirely up to gods of rounding errors. So your proposing to solve a issue that can easily be done in the source file in one operation with a solution that needs to be solved per ray. Its not that it couldnt be done, one still has to decide for the computer.  Theres nothing wrong with preprocessing the scene you know. Your example is not valid since the engines are tuned to avoid this particular usecase because it a requirement for multipass rendering  
> **username_3**: If you don't wanna offset, then you gotta put a hole in the wall. delete the geometry to make space for that rectangular light. As jooja said, this looks more like a modeling issue. No point in adding extra complications to the rendering portion when you can clean up during the pre-processing/modeling area.  
> **username_0**: @username_2 your comment is valuable to me, thank you. I did not mention it in my post, but what probably adds to the problem is that I am casting doubles to floats (our renderer uses doubles and Embree uses floats, so I need to perform the casting. This is maybe why the edges  between the ceiling and the 4 walls are not as detailed in the 2nd picture than in the 1st. Until now I am just compensating for this by considering intersections only in the interval [0.001, infinity]). In the future I will have a discussion with the developers of our renderer.  
> **username_1**: "what probably adds to the problem is that I am casting doubles to floats" - the issue is actually fairly simple, it is a mathematical problem after all. If you have two surfaces that intersect over some region it is not unambiguous which to pick. So you need to disambiguate that. The clean way to do this is to remove the intersecting piece of one of the two. Other approaches are hacks: the offset, splitting the scene in non-lights and lights, and other such techniques. As far as avoiding self-intersection, don't use [0.001, inf), instead offset along the normal, cf the ray-tracing gems book.  

---

## 1 answers

### Answer by username_4 on 2021-05-10. Score: 0 | Accepted answer

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.](https://en.wikipedia.org/wiki/Constructive_solid_geometry)

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.

> **Comments:**
> **username_0**: 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 :)  

---

