I am experiencing strange result when the model has overlapping triangles with different materials. The input model is from Sketchup and it comes with 2 set of overlapping triangles for a face. One set of triangle has normal towards the room and the other set has normal away from the room.
However, the result comes as if the rays from the room always hits the triangle with normal away from the room. I conclude this based on results when there is same material on front and back facing triangles. This is also confirmed with rpict image which shows the material for the face with normal away from the room.
Does anyone have any similar issue/experience with overlapping triangles.
Many thanks in advance
Welcome to the forum. You ask an important question.
Radiance was never really designed to handle overlapping surfaces. In fact, the returned surface in such cases used to be random. Recently, at the request of Peter Apian-Bennewitz, we made the decision consistent, but it does not consider surface orientation. It only considers whether one or the other material is transparent, i.e., trans, glass, dielectric, interface, mist, glass, or aBSDF type.
If one of the two surfaces is transparent, then the non-transparent surface is returned. If neither or both are transparent, then the one whose modifier appears earlier in the input is returned, so the result is at least consistent.
While it might make sense to consider the surface normal, that is not computed by some of the surface types until after this decision is made, so it would incur additional costs during rendering to check for it. A better solution is to separate surfaces with different materials in your model. If you really need the surface to have different materials front-and-back, consider using the mixfunc primitive.
Actually, I determined that it wasn’t difficult or costly to test for which side of a surface was hit in the case of flat geometric primitives (polygons and rings). For these, the preference is based first on which (if either) is transparent, then which side was hit by the ray, then modifier definition order. Spheres and cones do not consider which side was hit by the ray, but I don’t think overlapping spheres and bubbles or cones and cups are really a thing, so it hardly matters.
P.S. The latest head should include this change, provided it passes all the unit tests this coming weekend.
Thank you very much for your prompt and detail reply.
I understand the problem better now. I have started looking into mixfunc option and it looks promising as a solution.
The objects are all triangles in our case. We are using version 5.2 at the moment. I will try the latest version when I get time.