Ray tracing geometries with same position, translation and scale 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:

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.
When I render the scene with the help of Embree, it looks like this:

(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.
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:

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.
This is what the Cycles renderer gave me:

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
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 &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.
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.