star-phor

commit 46e0ec243da62bcdefee4e080fdc107808433ec0
parent aba7e50b586998d548fa314d6b90188361a22f4f
Author: Eduardo Fontana Lazzari <edufonlaz@gmail.com>
Date:   Wed,  9 Jul 2025 16:47:23 +0200

Orient source normals toward emitting direction

In sphor, the source struct contains only the scene view (used later
to sample positions uniformly on the source) and the identifier of the
corresponding sphin_surface. If triangles are registered in the
scene_view as-is, this is insufficient to determine which side emits
radiation, since the side information no longer exists after this step.

Since only one side of a triangle can belong to a given source
(as required by sphin), a simple solution is to orient all triangles
such that their geometry normal indicates the emitting side.

This is achieved by flipping the normal direction according to the
geometry side during pre-processing. During path sampling, one can then
simply retrieve the normal and, following the normal convention,
initiate the path accordingly.

Diffstat:
M
src/sphor_sources.c
 | 
34
++++++++++++++++++++++++++++++++++

1 file changed, 34 insertions(+), 0 deletions(-)
diff --git a/src/sphor_sources.c b/src/sphor_sources.c
@@ -57,6 +57,40 @@ register_surface_geometry
 
     setup_triangle(&geom_desc, itri, &tri);
 
+    /* Reverse triangle normal if side is back:
+     *
+     * In direct algorithms, the depart position of each path is sampled over
+     * the sources using a custom scene_view of each source. The custom scene
+     * view is different of the one composed by all triangles in the scene that
+     * is used in the rest of the path sampling.
+     *
+     * It means that, even though the sampled primitive of the source scene_view
+     * certainly has a corresponding primitive in the global scene_view,
+     * currently, there is no way of associating the sampled primitive in the
+     * source scene_view to the one in the global scene_view. Futhermore, the
+     * association s3d_primitive <-> sphor_interface does not exist for the
+     * source scene_views.  Thus, it is not possible to correlate the
+     * geometrical data to the physical data as we do with the global
+     * scene_view.
+     *
+     * One of the consequences is that its not possible to retrieve the side
+     * (front or back) of the sampled primitive in the source_view that
+     * corresponds to the source. To overcome this issue, since a geometry can
+     * only be declared with one side at a time in sphin for the same source,
+     * the strategy taken is to store the triangle in the scene view in such a
+     * way that its normal points always to the hemisphere corresponding to the
+     * emitting side. In such a way, during path sampling, one can simply
+     * retrieve the normal of the sampled primitive and it will correspond to
+     * the emitting direction (subject to the convention: left or right-hand of
+     * each library)
+     */
+    if (SPHIN_SIDE_BACK == geom_desc.side) {
+      double tmp[3] = {0};
+      d3_set(tmp, tri.vertices[0]);
+      d3_set(tri.vertices[0], tri.vertices[1]);
+      d3_set(tri.vertices[1], tmp);
+    }
+
     res = suniq_register_triangle(suniq, &tri, NULL);
     if (RES_OK != res) { goto error; }
   }