star-phor, branch HEAD

Increase of the tolerance of the errorbar in test

2026-04-07T08:36:29Z

commit 3055a9c4b91775e5ab1bc82f1e68521773227e2c parent f352adc50b527c831c9b0b3daafc35fc74166cb3 Author: Thomas Vourc'h Date: Tue, 7 Apr 2026 10:36:29 +0200 Increase of the tolerance of the errorbar in test Use 3 sigma instead of 2 comparing star-phor results to analytic solution.

Fix: Add missing instructions to Makefile

2026-04-07T07:49:37Z

commit f352adc50b527c831c9b0b3daafc35fc74166cb3 parent f704905ae0be661e2f432f55ac54b8d3be80e511 Author: Eduardo Fontana Lazzari Date: Tue, 7 Apr 2026 09:49:37 +0200 Fix: Add missing instructions to Makefile

Improve text style and fix typos in README and man pages

2026-04-06T15:49:08Z

commit f704905ae0be661e2f432f55ac54b8d3be80e511 parent 17725ded63f3bb869670747b45ed00b3c0ec08f3 Author: Eduardo Fontana Lazzari Date: Mon, 6 Apr 2026 17:49:08 +0200 Improve text style and fix typos in README and man pages Special thanks to Dr. K. Loubiere for proofreading and for the suggestions.

Clamp variance to avoid negative values

2026-04-06T11:15:41Z

commit 17725ded63f3bb869670747b45ed00b3c0ec08f3 parent 5bde959937eaf8935c9a775544a26db3282b4272 Author: Eduardo Fontana Lazzari Date: Mon, 6 Apr 2026 13:15:41 +0200 Clamp variance to avoid negative values In zero (or near-zero) variance cases, floating-point rounding errors can produce small negative variance values. Clamp the result to 0 to prevent propagating invalid values to the standard error computation, specially considering it depends on the square root of the variance.

Replace standard deviation by standartd error in outputs

2026-04-06T10:56:19Z

commit 5bde959937eaf8935c9a775544a26db3282b4272 parent 78e6b89f34cc0cf007dbe1c2cc42d9f43360d60c Author: Eduardo Fontana Lazzari Date: Mon, 6 Apr 2026 12:56:19 +0200 Replace standard deviation by standartd error in outputs The standard deviation measures the spread of individual samples, while the standard error measures the precision of the estimated mean. Since the outputs report mean values, the standard error is a better uncertainty metric. It is also more consistent with the edstar ecosystem.

Fix: Ensure SSF direction convention in star-sf function calls

2026-04-06T08:16:57Z

commit 78e6b89f34cc0cf007dbe1c2cc42d9f43360d60c parent 78fb646db0002954a6eccd63b3627c047f506467 Author: Eduardo Fontana Lazzari Date: Mon, 6 Apr 2026 10:16:57 +0200 Fix: Ensure SSF direction convention in star-sf function calls The star-phor ray directions were already consistently treated to comply with the SSF API for calculations. However, in some star-sf function calls when computing Fresnel terms for interface-ray interaction samples, the raw, untreated normal directions were used. This resulted in potentially incorrect Fresnel term calculations and physically inconsistent reflectivity and transmissivity values. This commit corrects this issue by using the treated normal direction consistently within star-sf functions and includes a check to ensure physically plausible reflectivity and transmissivity values.

Remove OpenMPI dependency from the project

2026-03-31T09:03:15Z

commit 78fb646db0002954a6eccd63b3627c047f506467 parent 45429811b5b7c03fc09eaf307671877e8be78d85 Author: Eduardo Fontana Lazzari Date: Tue, 31 Mar 2026 11:03:15 +0200 Remove OpenMPI dependency from the project

Merge branch 'feature_brdf_btdf'

2026-03-06T17:01:41Z

commit 45429811b5b7c03fc09eaf307671877e8be78d85 parent fc4dfff17129da72a2d3408571d6d18418c74141 Author: Eduardo Fontana Lazzari Date: Fri, 6 Mar 2026 18:01:41 +0100 Merge branch 'feature_brdf_btdf'

Add tests for internally defined BTDF models

2026-03-05T16:27:36Z

commit f65b00ea6f4468e2ce4d02b1dd7aa9cce7c4b325 parent ec361da113dfe30dda367335e435cd7905113d6e Author: Eduardo Fontana Lazzari Date: Thu, 5 Mar 2026 17:27:36 +0100 Add tests for internally defined BTDF models Implement one test for each internally defined BTDF: KEEP_CURRENT_DIR, LAMBERT, and SNELL_DIELECTRIC. Each test builds a three-surface configuration (emitter -> transmitter -> absorber) where the photon density reaching the absorber can be computed analytically. The Monte Carlo results, computed with the LOSSES reported by the MVREA algorithm, are compared against the expected solution within statistical tolerance.

Implement SNELL_DIELECTRIC BTDF and update path sampling

2026-02-27T17:33:24Z

commit ec361da113dfe30dda367335e435cd7905113d6e parent 717573681135dff7085564931f353d23e6530bd9 Author: Eduardo Fontana Lazzari Date: Fri, 27 Feb 2026 18:33:24 +0100 Implement SNELL_DIELECTRIC BTDF and update path sampling Yet another BTDF. Always samples the Snell refraction direction, computed using the real part of the refractive indices on each side of the interface. Heavily inspired by what is done in ssf for dielectric interfaces, but here we leave the possibility for the caller to explicitly instantiate its Fresnel struct instead of having it implicitly computed during sampling, so one can use whichever Fresnel model they want. The new BTDF is integrated into path tracing.

Implement KEEP_CURRENT_DIR BTDF and update path sampling

2026-02-27T15:41:01Z

commit 717573681135dff7085564931f353d23e6530bd9 parent caff45f6a6d99beeeff7c85b0ed9bbbeac7e1933 Author: Eduardo Fontana Lazzari Date: Fri, 27 Feb 2026 16:41:01 +0100 Implement KEEP_CURRENT_DIR BTDF and update path sampling Implement a KEEP_CURRENT_DIR BTDF in which the transmitted direction wi is identical to the outgoing direction wo. Although this behavior could be handled as a special case without needing a dedicated bsdf, we define it as a proper BTDF to ensure consistent integration with the existing workflow (i.e., instantiating and setting up an ssf_bsdf struct and using it to sample the outgoing direction). The new BTDF has been integrated into the path sampling routine.

Implement LAMBERT BTDF and update path sampling

2026-02-27T13:10:06Z

commit caff45f6a6d99beeeff7c85b0ed9bbbeac7e1933 parent a3f743987d61709209ed359eba7b2c1cf7d55208 Author: Eduardo Fontana Lazzari Date: Fri, 27 Feb 2026 14:10:06 +0100 Implement LAMBERT BTDF and update path sampling Implement an internal Lambertian bidirectional transmission distribution function (BTDF), inspired by the Lambertian reflection model in the star-sf. Integrate the new function into the path sampling routine.

Prepare internal API for extended interface optical handling

2026-02-27T07:40:54Z

commit a3f743987d61709209ed359eba7b2c1cf7d55208 parent 934e3783f95d2e5b0f6aa5a3bb05f645f4404554 Author: Eduardo Fontana Lazzari Date: Fri, 27 Feb 2026 08:40:54 +0100 Prepare internal API for extended interface optical handling This commit refactors the way interface optical properties are handled during ray–primitive intersections in path propagation, in order to comply with the new star-phor-input configuration specification and the updated sphin library, which now support extended BSDF features, including more detailed BRDF models and explicit BTDF definitions. The configuration file specification now explicitly enforces the conceptual separation of the BSDF into BRDF and BTDF components. This differs from the current Star Scattering Functions (ssf) library, which is used to sample interface scattering in star-phor and does not fully reflect this separation at the API level. As a consequence, an intermediate abstraction layer has been introduced. This layer: 1. Samples the interaction type (reflection, transmission, absorption) according to the interface optical properties. 2. Instantiates the appropriate ssf BSDF object. 3. Samples the outgoing direction. Since ssf does not yet cover the complete set of BRDF and BTDF models supported by star-phor, some models will need to be implemented internally in future work. The BSDF sampling code, which was previously embedded in sphor_compute_mvrea.c, has been extracted into a dedicated compilation unit (sphor_ran_bsdf.c). This change reinforces the star-phor architectural principle of clearly separated abstraction layers. New functions have also been introduced to query reflectivity and transmissivity from primitive properties. These quantities are handled as spectral properties and evaluated at the current wavelength. The analytical test has been updated to consider the reflectivity a spectral property.

Print the number of failures (if any)

2026-02-25T18:16:54Z

commit fc4dfff17129da72a2d3408571d6d18418c74141 parent 934e3783f95d2e5b0f6aa5a3bb05f645f4404554 Author: Eduardo Fontana Lazzari Date: Wed, 25 Feb 2026 19:16:54 +0100 Print the number of failures (if any) The star-phor output file contains only the average and standard deviation for each estimated observable, which is not enough information for users who want to perform further statistical analyses with their results. The missing piece of information is the effective number of realizations. Up to this point, this could not be determined, since realizations may fail silently. This commit addresses this issue by printing the number of failed samples (if greater than zero) at the end of the realization loop as a warning.

Add a project overview to the README file

2026-02-24T16:58:03Z

commit 934e3783f95d2e5b0f6aa5a3bb05f645f4404554 parent 8c3cf4dd8bbce9f255888a039a0ad7c3bef8a42d Author: Eduardo Fontana Lazzari Date: Tue, 24 Feb 2026 17:58:03 +0100 Add a project overview to the README file

Add short description in the star-phor(1) man page

2026-02-24T13:02:42Z

commit 8c3cf4dd8bbce9f255888a039a0ad7c3bef8a42d parent 6fe52fb5e5171088d647dabe6f13d66824a90817 Author: Eduardo Fontana Lazzari Date: Tue, 24 Feb 2026 14:02:42 +0100 Add short description in the star-phor(1) man page Add some general information about star-phor in its manual page description section.

Add manual page for the output file specification

2026-02-24T10:41:51Z

commit 6fe52fb5e5171088d647dabe6f13d66824a90817 parent 48d5d94b5f5afc8f47e3b8b71eca12cc3685bb36 Author: Eduardo Fontana Lazzari Date: Tue, 24 Feb 2026 11:41:51 +0100 Add manual page for the output file specification Create the star-phor-output manual page in section 5, describing the syntax used in the output file.

Add an example to the star-phor command manual page

2026-02-24T11:21:10Z

commit 48d5d94b5f5afc8f47e3b8b71eca12cc3685bb36 parent 2c3690c61a1c9abaeca5677c5260fb5b8025f650 Author: Vincent Forest Date: Tue, 24 Feb 2026 12:21:10 +0100 Add an example to the star-phor command manual page

Update the text formatting in the star-phor man page

2026-02-10T10:55:25Z

commit 2c3690c61a1c9abaeca5677c5260fb5b8025f650 parent eeda8ee20c0afeea81be9b77de4b820aed21b1dd Author: Vincent Forest Date: Tue, 10 Feb 2026 11:55:25 +0100 Update the text formatting in the star-phor man page Format the text according to the Linux manual page convention, i.e., bold the command name and options, and emphasize replaceable arguments.

Correction of the README file layout.

2026-02-10T10:19:37Z

commit eeda8ee20c0afeea81be9b77de4b820aed21b1dd parent 132d0fb771c93f9671486148aea2f5ec68d09ccf Author: Vincent Forest Date: Tue, 10 Feb 2026 11:19:37 +0100 Correction of the README file layout. A literal block was not correctly indented according to Markdown syntax. Its HTML formatting was therefore incorrect. Two spaces are added after the copyright owners, as long as another owner follows. This is the Markdown syntax to force a line break after conversion to HTML.

Update the copyright year range

2026-02-10T10:16:46Z

commit 132d0fb771c93f9671486148aea2f5ec68d09ccf parent 446659c3864c49195b7c371b0c8ef8d89f2de3e7 Author: Vincent Forest Date: Tue, 10 Feb 2026 11:16:46 +0100 Update the copyright year range

Uninstallation instructions in README.md

2026-02-10T10:04:49Z

commit 446659c3864c49195b7c371b0c8ef8d89f2de3e7 parent 0eb0bcb452a2d8324f4f6afe57cf3b7193969d73 Author: Jeremi Dauchet Date: Tue, 10 Feb 2026 11:04:49 +0100 Uninstallation instructions in README.md

make install instructions more explicit in README.md

2026-02-10T09:04:51Z

commit 0eb0bcb452a2d8324f4f6afe57cf3b7193969d73 parent 634507724af9edfb9ed5cc5ca08eaf3c731ae54a Author: Jeremi Dauchet Date: Tue, 10 Feb 2026 10:04:51 +0100 make install instructions more explicit in README.md make install instruction requires root privileges, but library path for root user may not include appropriate libraries.

Add analytical test case to the MVREA algorithm

2026-01-29T09:29:48Z

commit 634507724af9edfb9ed5cc5ca08eaf3c731ae54a parent 34cfdb97f8eb4e6ee8245ec04f67197cb29f4051 Author: Eduardo Fontana Lazzari Date: Thu, 29 Jan 2026 10:29:48 +0100 Add analytical test case to the MVREA algorithm Previous tests checked only the behavior of the library, without actually running a simulation. This commit adds a new test using a simple configuration and compares it to the analytical solution. It verifies whether the analytical result lies within the 95% confidence interval of the simulated value and also verifies the conformity of the output file with the star-phor-output file format specification.

Fix: ensure correct emission hemisphere by tracking surface side

2026-01-28T16:42:51Z

commit 34cfdb97f8eb4e6ee8245ec04f67197cb29f4051 parent dc7eb4e681146cc588ae724c857f3ce6fb3fc964 Author: Eduardo Fontana Lazzari Date: Wed, 28 Jan 2026 17:42:51 +0100 Fix: ensure correct emission hemisphere by tracking surface side The source direction sampling logic previously assumed scene geometry normals were always oriented toward the emission direction. Since scene normals are arbitrary, this resulted in incorrect emission hemispheres for "back-facing" triangles. Fix it by checking the scene normal against the source reference during position sampling and conditionally inverting it during direction sampling.

Extract weight update logic into a separate function

2026-01-28T14:59:36Z

commit dc7eb4e681146cc588ae724c857f3ce6fb3fc964 parent 94a5f9e25a3f1859ec2113a70bf5fe17cdcac3f9 Author: Eduardo Fontana Lazzari Date: Wed, 28 Jan 2026 15:59:36 +0100 Extract weight update logic into a separate function Weight updates were previously implemented directly in the realization function, leading to two main issues that hinder readability: (i) the update logic spans many lines, obscuring the intent of the surrounding block and disrupting the flow of the function; (ii) lower-level implementation details appear at a higher level of abstraction.

Fix absorption handling after BRDF ray-intersection

2026-01-23T11:19:35Z

commit 94a5f9e25a3f1859ec2113a70bf5fe17cdcac3f9 parent bc2abf06454e245f12a300a471eb982b61e7e542 Author: Eduardo Fontana Lazzari Date: Fri, 23 Jan 2026 12:19:35 +0100 Fix absorption handling after BRDF ray-intersection Previously, the code assumed that ssf_bsdf_sample would return a TRANSMISSION flag based on the reflectivity of the BRDF. This assumption was incorrect: rays that should have been absorbed could continue, leading to incorrect path termination. This commit corrects the behavior by explicitly performing a Bernoulli trial using the BRDF reflectivity. The ray is either reflected or absorbed according to this probability.

Implement a function to sample a direction according to cos^n radiance

2026-01-23T10:33:43Z

commit bc2abf06454e245f12a300a471eb982b61e7e542 parent 8b22ce94b0c23100006ffff1a25ec132ef8b92ed Author: Eduardo Fontana Lazzari Date: Fri, 23 Jan 2026 11:33:43 +0100 Implement a function to sample a direction according to cos^n radiance Sample a source direction for a ray assuming a collimation degree n of the source. The direction is sampled according to the solid angle PDF: pdf(Omega) = (n+2) / (2 * pi) * cos^(n+1)(theta) using the inversion method on the cumulative distribution function (CDF). The model assumes azimuthal independence: phi is sampled uniformly in [0, 2 * pi). The function returns the sampled direction in the global coordinate system and optionally the corresponding probability density function value.

Move sphor_config function prototypes to a separate header file

2026-01-17T13:47:45Z

commit 8b22ce94b0c23100006ffff1a25ec132ef8b92ed parent 78550d4bf7830c8c1db643f79b393c8334be39ea Author: Eduardo Fontana Lazzari Date: Sat, 17 Jan 2026 14:47:45 +0100 Move sphor_config function prototypes to a separate header file Ensure that each .c file has its exported symbols declared in a corresponding header file. sphor_c.h, which previously contained symbols from sphor_config.c, now contains only those corresponding to sphor.c.

Test: ensure config definition follows the sphin rules

2026-01-16T16:27:30Z

commit 78550d4bf7830c8c1db643f79b393c8334be39ea parent ac075b7a5d6c7be763d0128c1eae6c1f5fa34a2b Author: Eduardo Fontana Lazzari Date: Fri, 16 Jan 2026 17:27:30 +0100 Test: ensure config definition follows the sphin rules Star-phor-input has evolved to handle spectral property descriptions. This commit makes the photoreactor configuration used in test_sphor_lib.c compliant with the new rules by adding a simple emission spectrum to the source defined in this file.

Set more restrictive rules in the filter function

2026-01-16T16:08:19Z

commit ac075b7a5d6c7be763d0128c1eae6c1f5fa34a2b parent 8f0c06484abee2a53a1e250d9604f08c936fe802 Author: Eduardo Fontana Lazzari Date: Fri, 16 Jan 2026 17:08:19 +0100 Set more restrictive rules in the filter function Add a new rule to the filter function to prevent photons from being trapped at a given position when they are too close to a triangle edge. This type of self-intersection cannot be filtered by the previous rules, since the intersected primitive is different from the one where the photon originates. Now, rays that intersect a given primitive are discarded if the intersection distance is below a given epsilon and the intersection point is too close to one of the edges. The intersection point is evaluated using the barycentric coordinates of the hit on the primitive, which always range between 0 and 1, making the test independent of the characteristic size of the geometry. Also ensure that the ray distance respects the defined range.

Improve code style consistency

2026-01-14T16:43:58Z

commit 8f0c06484abee2a53a1e250d9604f08c936fe802 parent be688d494a1d919d71f9683f1193386d1b9402ca Author: Eduardo Fontana Lazzari Date: Wed, 14 Jan 2026 17:43:58 +0100 Improve code style consistency Standardize tabs, spaces, and includes across the codebase. Ensure lines do not exceed 80 characters.

Continue refactoring of realization function

2026-01-14T14:13:16Z

commit be688d494a1d919d71f9683f1193386d1b9402ca parent a51410c83da1e972f0c26bb9f7316e566d0bc822 Author: Eduardo Fontana Lazzari Date: Wed, 14 Jan 2026 15:13:16 +0100 Continue refactoring of realization function This commit makes a series of minor modifications in the compute_MVREA_realization function in order to improve semantic clarity (sort local variables, explicit ambiguous inputs and outputs in function calls, simplify error handling...). Also, the wavelength is no longer a member variable of the ray structure, but is a local variable in the realization function. This makes the ray a purely geometry-related structure, used exclusively in the intersection search procedure.

Refactor ray–interface interactions to rely exclusively on ssf

2026-01-09T15:21:40Z

commit a51410c83da1e972f0c26bb9f7316e566d0bc822 parent 4e881934e3b6593e2ff6219bc34133f78548dfbb Author: Eduardo Fontana Lazzari Date: Fri, 9 Jan 2026 16:21:40 +0100 Refactor ray–interface interactions to rely exclusively on ssf This commit unifies the handling of all ray-interface interactions by sampling them entirely with the star scattering functions (ssf) library. Previously, ssf was used only for dielectric-dielectric interfaces, while interfaces involving user-defined sphin_brdf s implemented their own logic for reflectivity tests, interaction type selection, and outgoing direction sampling directly in star-phor. This resulted in duplicated implementations of Lambertian and specular reflection models, since ssf is also capable of doing these computations. The code has been refactored to construct appropriate ssf BSDFs for sphin_brdf based interfaces as well. All interactions are now sampled through ssf_bsdf_sample, regardless of the interface type (dielectric-dielectric, specular, Lambertian).

Introduce new abstractions for path tracing

2026-01-06T08:29:36Z

commit 4e881934e3b6593e2ff6219bc34133f78548dfbb parent afaa3d054ff2f714dc6af62bb5f57041e3635e21 Author: Eduardo Fontana Lazzari Date: Tue, 6 Jan 2026 09:29:36 +0100 Introduce new abstractions for path tracing Up until this point, path tracing abstractions were mostly inherited from previous computation steps as well as from the supporting libraries used during path tracing. As a result, these abstractions were often only partially aligned with the physical concepts manipulated by the algorithm. In several cases, different elements were describing the same underlying entity from distinct perspectives, such as s3d primitives and sphor interfaces, which both refer to the same scene element but describe its geometry in the former case and its physical properties in the latter. This overlap caused lower-level abstractions to leak into the path tracing algorithm. In other cases, the available abstractions were simply not expressive enough to fully capture the physical concepts they were intended to represent. These restrictions motivate the introduction of new abstractions in star-phor, especially in the realization function. These abstractions, introduced by this commit, address these issues by either encapsulating related lower-level structures or complementing existing ones with missing semantic information. The newly introduced abstractions are ray, intersection and primitive. As a consequence of this refactor, the realization function now relies on fewer local variables, and function interfaces are simplified, requiring fewer arguments while conveying more explicit meaning. This commit also introduces a set of getter functions to access the physical properties associated with a given (sphor) primitive. These functions provide ad hoc error handling adpted to the star-phor context by abstracting direct calls to star-phor-input functions. In particular, some conditions that are acceptable in star-phor-input are considered errors in star-phor, and this distinction is now handled consistently at this abstraction layer.

Add program options to the man page

2026-01-12T12:11:08Z

commit afaa3d054ff2f714dc6af62bb5f57041e3635e21 parent efcfe09e6e9255dfd6e9222170639eec104f51d9 Author: Eduardo Fontana Lazzari Date: Mon, 12 Jan 2026 13:11:08 +0100 Add program options to the man page Also add the correct reference to the French ANR project funding.

Update all accums during realization

2025-12-16T13:46:28Z

commit efcfe09e6e9255dfd6e9222170639eec104f51d9 parent c9622ff2e17c935a0b63ff5434d5fa83221422ed Author: Eduardo Fontana Lazzari Date: Tue, 16 Dec 2025 14:46:28 +0100 Update all accums during realization In star-phor the same algorithm can compute different quantities in a single run. This is done using the struct accum abstraction (and more precisely a list of such structs) that can be used to update the sum of weights and the sum of the squared weights for the different quantities that are estimated as expectations of random variables. This implementation enables the possibility of calculating quantities that are combinations of these other quantities. In the MVREA algorithm, for instance, we can compute the volume-averaged rate of photon absorption per unit volume in a given region and combine these to compute the total volume-averaged rate of photon absorption in the volume (and then combine the per-volume rates of photon absorption to get the scene mean volumetric rate of photon absorption). The strategy previously used to achieve these computations was to, during the algorithm, store only the accum corresponding to the finest level of granularity and to construct the accums corresponding to the quantities that are combinations of these a posteriori, after the MC algorithm was executed. This works fine for the expectation of the accums and to compute the variance in some cases. However, when we need to combine dependent random variables that are updated with non-zero weights within the same realization, the variance of the combined variable requires covariance terms that depend on the cross-products of weights from the finer-level random variables. These cross-products cannot be reconstructed a posteriori from the individual weight sums alone. This imposes a new strategy to handle these accums. We choose to update the weights of all accums at the end of each realization, regardless of the level of granularity of the corresponding random variable. As a consequence, all accumulators must be initialized prior to the start of the realizations. The writing to stream is simplified, since now no accums sum is required and a simple loop over all accums suffices.

Fix: normalize geometry normal before sampling source direction

2025-11-27T19:22:55Z

commit c9622ff2e17c935a0b63ff5434d5fa83221422ed parent fbfd67ead297ae300eccba37297e738a1b98c207 Author: Eduardo Fontana Lazzari Date: Thu, 27 Nov 2025 20:22:55 +0100 Fix: normalize geometry normal before sampling source direction

Integrate geometrical optics into the MVREA algorithm

2025-11-27T18:41:02Z

commit fbfd67ead297ae300eccba37297e738a1b98c207 parent bc76ac9eb5f4857790fe903308a467459115e066 Author: Eduardo Fontana Lazzari Date: Thu, 27 Nov 2025 19:41:02 +0100 Integrate geometrical optics into the MVREA algorithm This commit builds on the input file and star-phor-input evolution (which is now able to handle refractive indices) and integrates it into the Monte Carlo computation when a photon intersects an interface. As BRDFs were already supported in the input file, star-phor prioritizes user-defined BRDFs. Possible outcomes for ray–interface interactions with a user-defined BRDF are either reflection or absorption (the latter stopping the path). If no BRDF is defined for a given interface, star-phor will then try to retrieve optical indices from each side of the interface and compute the ray–interface interaction outcome using geometrical optics (Fresnel and Snell–Descartes laws). This is done using the star-scattering-functions library, which is added as a new dependency of star-phor in this commit. If no refractive index is set for a given volume, default values of 1 for the real part and 0 for the imaginary part are set.

Refactor output stream handling

2025-11-27T18:11:24Z

commit bc76ac9eb5f4857790fe903308a467459115e066 parent ae9d40be46e3d4d0e06d706261bc2db1da08dfe4 Author: Eduardo Fontana Lazzari Date: Thu, 27 Nov 2025 19:11:24 +0100 Refactor output stream handling Open the output stream during the sphor_creation step (instead of after the Monte Carlo algorithm execution as done previously). This ensures that any error related to opening the stream occurs early in the runtime, rather than after the algorithm has finished, which may take considerable time in some situations and would likely result in loss of work. Protect existing files from being overwritten by introducing a new program argument -f, so overwriting only occurs when explicitly requested by the user.

Write estimators to output file

2025-10-22T14:43:30Z

commit ae9d40be46e3d4d0e06d706261bc2db1da08dfe4 parent 722272532c4d654562730ce686b88e90441ea6f7 Author: Eduardo Fontana Lazzari Date: Wed, 22 Oct 2025 16:43:30 +0200 Write estimators to output file The introduction of accums and accum lists in sphor enables the estimation of multiple random variables within a single algorithm. Each random variable corresponds to an estimator that must be written to an output file, either specified by the user or directed to the standard output. This commit implements this functionality by iterating over all accums produced by the algorithm and, when necessary, combining certain accums to construct others. This is required for random variables — such as the total MVREA in the MVREA algorithm — that do not have directly accessible accums during a realization, but are instead obtained as sums of multiple accums. All resulting estimators are then written to the output file. In addition, this commit extends the internal accum API with several utility functions and introduces the darray_accum_list structure and programming interface, which facilitate the management of lists of darray_accum objects (for instance when doing multi-thread computations).

Refine error handling in the realizations loop

2025-10-21T15:22:21Z

commit 722272532c4d654562730ce686b88e90441ea6f7 parent 226cb3f14e393e9186ecb67d85b20a6e6e0d9035 Author: Eduardo Fontana Lazzari Date: Tue, 21 Oct 2025 17:22:21 +0200 Refine error handling in the realizations loop Previously, if a call to the realization function returned an error, all subsequent realizations were skipped and no results were written. This behavior could be counterproductive and lead to unnecessary data loss, especially when errors arise from isolated edge cases while other realizations remain valid. This commit introduces a more robust error-handling strategy. A dedicated error code (RES_UNKNOWN_ERR) is now reserved for fatal errors. Calls to the realization function that return any other error code are skipped, allowing the loop to continue processing remaining realizations. If no fatal error occurs, results are written regardless. A counter tracks the number of rejected realizations, which can be used later to assess the overall validity of the simulation.

Setup darray_accum to handle weight accumulation in MVREA computation

2025-10-15T14:17:06Z

commit 226cb3f14e393e9186ecb67d85b20a6e6e0d9035 parent 27df4af5d16d6ed2fd96afbaa246d94e58a95c1a Author: Eduardo Fontana Lazzari Date: Wed, 15 Oct 2025 16:17:06 +0200 Setup darray_accum to handle weight accumulation in MVREA computation This commit refactors how sphor_compute_MVREA handles weight accumulators. The introduction of the struct accum and associated data structures enables the management of multiple random variables within the same algorithm. The list of all possible accumulators can now be easily created and initialized by iterating over all sensors in the scene. A separate copy of this list is created for each thread involved in the computation, removing any responsibility for multithreading from the realization function. The aggregation of per-thread accumulators into the global accumulator is performed at the end of the realization loop, in the same spirit of what is usually done when the weight is a simple scalar (double). This commit also extends the internal API of the accum module by extracting logic that may be reused in different contexts, such as: 1. Aggregating per-thread accumulators into the main accumulator (accum_threads_aggregate) 2. Registering new accumulators with custom string fields (register_accum) 3. Updating accumulator values dynamically using an on-the-fly constructed accum_key (update_accum)

Setup accumulator data structures to manage observable-weighted sums

2025-10-14T17:09:48Z

commit 27df4af5d16d6ed2fd96afbaa246d94e58a95c1a parent 2d3d4b9b09b31b6a75327546737b39520f0bc1b8 Author: Eduardo Fontana Lazzari Date: Tue, 14 Oct 2025 19:09:48 +0200 Setup accumulator data structures to manage observable-weighted sums Up to this point, no dedicated structure was implemented in star-phor to manage weights in algorithms. In the current implementation of compute_MVREA, the weight is stored as a single real number. This approach is quite limiting, since a single realization can lead to different path endpoints that, in turn, increment distinct weight sums. In other cases, it may be necessary to update multiple weights in a same realization function call. This commit introduces a more robust method for storing and managing sums of weights. We define an elementary structure (struct accum) to store: 1. the sum of the weights (sum), 2. the square of this sum (sum2), and 3. the number of realizations of the random variable associated with the accumulator. Each weight is characterized by a unique triplet of keywords that represent the physical quantity being estimated: observable, sensor, and component. An example of possible keyword usage is as follows: 1. observable: the type of physical quantity to be estimated (e.g., “MVREA”); 2. sensor: where the photon was absorbed (the name of a volume or a surface); 3. component: additional information related to photon absorption (chemical species, wavelength interval, etc.). The choice of which keywords to use depends on the algorithm. Defining three levels of description reflects an attempt to make the structure as generic as necessary for all possible applications, while staying within the conceptual perimeter of star-phor. This commit also introduces a dynamic array (struct darray_accum) of these structures to manage a list of different estimators, which is expected to be the typical use case. While this array solves the problem of storing weights, it raises a new question: these weights are updated many times during a simulation, so it is necessary to establish an efficient way to access the weight corresponding to a given physical situation using the information available during path tracing. Given the computational intensity of the algorithms and the need for a general, reusable solution for future developments in star-phor, we introduce a hash table (htable_accum2id), which accelerates the access to the accumumulators, by establishing a constant-time correspondence between a key and a value. It allows retrieving the identifier of an accumulator within the dynamic array using a key. The key (accum_key) is composed of: 1. the sensor type (either volume or surface), 2. its identifier, and 3. an optional third argument representing the component. This design ensures key uniqueness and makes the key easily constructible on the fly under different circumstances.

Start refactoring the realization function

2025-10-06T10:23:21Z

commit 2d3d4b9b09b31b6a75327546737b39520f0bc1b8 parent b9bdd278372b200207ee9de1d61c1fceabcbea9f Author: Eduardo Fontana Lazzari Date: Mon, 6 Oct 2025 12:23:21 +0200 Start refactoring the realization function Although functional, the realization function was originally written as a single block of code, with little concern for separating different levels of abstraction. This is far from ideal for two main reasons: i. A Monte Carlo algorithm is composed of a set of elementary gestures (sampling a position, sampling a wavelength, tracing a ray, etc.) that, when chained together, return a weight used to estimate an observable. These gestures are not specific to the MVREA algorithm. The star-phor philosophy naturally gives rise to an architectural pattern where such gestures are abstracted as functions internally exposed within star-phor. This makes it easier for newcomers to get started, as the separation between the Monte Carlo algorithm layer and the rest of the code becomes clearer (one can directly use these abstractions when coding a new algorithm or study/modify them as desired). ii. The algorithm is a numerical implementation of an integral formulation representing the same physical problem. The correspondence between the two should be straightforward, reinforcing the need to abstract parts of the numerical representation into separate functions. As the core of the star project, the algorithm should consist of readable, self-explanatory code so one can easily establish this correspondence. Low-level details mixed into the main logic would harm readability for certain audiences. This commit rewrites part of the realization function following this philosophy. Future work should continue both within the algorithm and in the architecture of the newly created functions.

Implement spectral computations

2025-09-08T09:48:51Z

commit b9bdd278372b200207ee9de1d61c1fceabcbea9f parent 59b76e8ff5019cafa97baf2eeb4c65c604cb3712 Author: Eduardo Fontana Lazzari Date: Mon, 8 Sep 2025 11:48:51 +0200 Implement spectral computations The spectral properties implemented in star-phor-input provide the foundation for wavelength-dependent computations in star-phor. This commit introduces the structures and functions required for this type of computation, as well as their integration with some of the functions exposed by star-phor-input, in order to retrieve spectral properties during path tracing. For the data processing required by these computations, the normalized discrete source emission spectrum provided by sphin is transformed into a probability density function (PDF) using star-sampling. Each spectrum is modeled as a piecewise linear function, and the resulting PDF is included as part of the source_view structure.

Fix: Sample direction using source primitive

2025-09-08T08:26:02Z

commit 59b76e8ff5019cafa97baf2eeb4c65c604cb3712 parent adffac8b7f4ab05a33187a784bb8580e404975c7 Author: Eduardo Fontana Lazzari Date: Mon, 8 Sep 2025 10:26:02 +0200 Fix: Sample direction using source primitive In compute_mvrea, the source direction was being sampled using a primitive retrieved from the global scene view. This was problematic, as it bypassed all the geometrical preprocessing applied to the sources during sampling. In particular, issues arose whenever a source emitted from its back side, since the normal was reversed in those cases. The fix consists of sampling the direction using the primitive from the source scene view instead, thus benefiting from all the preprocessing performed on these primitives.

Create correspondence between primitives

2025-08-01T08:02:22Z

commit adffac8b7f4ab05a33187a784bb8580e404975c7 parent 21cbf052694441408f10480ae68508cf0a2da64a Author: Eduardo Fontana Lazzari Date: Fri, 1 Aug 2025 10:02:22 +0200 Create correspondence between primitives This commit introduces the src2scn dynamic array as a member of the source view structure. This array maps each prim_id from a source view to the corresponding prim_id of the primitive in the global scene view that shares the same vertex coordinates. This correspondence is useful in several steps of path tracing. For instance, it enables efficient self-hit checks between primitives from different scene views. Previously, this required costly comparisons of all vertex coordinates; now, it can be done by simply comparing the prim_id of a source primitive to its counterpart in the global scene.

Add source to test case for discrete distribution setup

2025-07-31T17:51:55Z

commit 21cbf052694441408f10480ae68508cf0a2da64a parent fbe60e6000694c1cf95afed6521719449e74736f Author: Eduardo Fontana Lazzari Date: Thu, 31 Jul 2025 19:51:55 +0200 Add source to test case for discrete distribution setup The test case lacked a source, causing ssp_ranst_discrete_setup to return RES_BAD_ARG due to an empty powers array. This is unintended behavior, as sphor should handle systems with no sources independently of ssp. A source has been temporarily added to the test case. The underlying physics issue requires further discussion and a proper error handling policy in sphor.

Implement first Monte Carlo algorithm

2025-07-09T16:00:04Z

commit fbe60e6000694c1cf95afed6521719449e74736f parent 46e0ec243da62bcdefee4e080fdc107808433ec0 Author: Eduardo Fontana Lazzari Date: Wed, 9 Jul 2025 18:00:04 +0200 Implement first Monte Carlo algorithm This commit implements a Monte Carlo algorithm that computes the fraction of photons emitted in a scene that are absorbed in a volume acting as a sensor. This type of algorithm is particularly useful for computing the Mean Volumetric Rate of Energy Absorption (MVREA). This quantity is related to absorptivity via its product with a factor that accounts for the source power and the specific illuminated surface. Several useful abstractions are also introduced, such as functions for sampling path departure directions according to a directional distribution, and handling reflections on BRDF surfaces. The realization loop is parallelized. As a result, this commit introduces a dependency on the OpenMPI library.

Orient source normals toward emitting direction

2025-07-09T14:47:23Z

commit 46e0ec243da62bcdefee4e080fdc107808433ec0 parent aba7e50b586998d548fa314d6b90188361a22f4f Author: Eduardo Fontana Lazzari 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.

Attach a hit filter function to the global scene view

2025-07-09T12:20:09Z

commit aba7e50b586998d548fa314d6b90188361a22f4f parent 430ae867b63ad4aaaf3535edd76d6e6359fb4992 Author: Eduardo Fontana Lazzari Date: Wed, 9 Jul 2025 14:20:09 +0200 Attach a hit filter function to the global scene view During path sampling, the hit function is responsible for discarding ray-geometry intersections that should not be considered valid. Currently, only self-intersections are discarded. A hit is considered a self-intersection when the primitive from which the ray originates is the same as the one it intersects. Self-intersections are usually detected by comparing the IDs of the primitives, assuming they belong to the same scene_view. However, in star-phor, there are multiple scene_views: one containing all primitives, and one scene_view per source used in sampling. Therefore, ID comparison is not sufficient. Instead, self-intersections are detected by comparing the coordinates of the three vertices of the departing and intersected primitives, which allows filtering out self-intersections even across different scene_view contexts.

Add nthreads and samples to sphor struct

2025-07-09T08:57:09Z

commit 430ae867b63ad4aaaf3535edd76d6e6359fb4992 parent 103e9e700a02cb3993467b07ee786b118905b7c5 Author: Eduardo Fontana Lazzari Date: Wed, 9 Jul 2025 10:57:09 +0200 Add nthreads and samples to sphor struct The nthreads and samples fields are now part of the sphor struct, as they are required during calls to the run function. Although these variables originally belong to the sphor_create_args struct, we intentionally limit the use of that struct to the sphor_create function. By consolidating all necessary runtime information within the sphor struct, the code becomes clearer and less ambiguous during subsequent computation steps.

Fix: update surface count when adding new interface surface

2025-07-09T08:39:50Z

commit 103e9e700a02cb3993467b07ee786b118905b7c5 parent 08c0275e93e70fc4af24e8a2b529bd73ca878d70 Author: Eduardo Fontana Lazzari Date: Wed, 9 Jul 2025 10:39:50 +0200 Fix: update surface count when adding new interface surface Previously, when a new surface was added to an interface side, the corresponding counter was not incremented. This caused the surface_count to remain at its initial value, potentially leading to errors during subsequent Monte Carlo calculations.

Setup source views and power distribution functions

2025-06-10T15:18:30Z

commit 08c0275e93e70fc4af24e8a2b529bd73ca878d70 parent 582c23ab75fdc47c01005dac784bb318443235aa Author: Eduardo Fontana Lazzari Date: Tue, 10 Jun 2025 17:18:30 +0200 Setup source views and power distribution functions This commit introduces intermediate data structures and functions to enable sampling of sources in different ways within a given configuration. Two new member variables are added to the sphor struct: - a list containing the total power of each source. This list is used to sample a source among all sources in the configuration, weighted by their total power. Sampling is handled by the star-sampling (ssp) library, which provides API functions for sampling discrete probability distributions as well as other sampling functions which will be used in this project. - a list of scene views, where each scene view corresponds to a distinct source in the configuration. These scene views are managed by s3d, which accelerates sampling of positions within a list of triangles using the S3D_SAMPLE mask. Additionally, functions to sample a source relative to its total power, to uniformly sample a position within a given source, and to sample a source position across the entire scene according to each source’s total power are introduced for internal use in the library. This commit adds a new dependency on star-sampling.

Use suniq library for associative structure construction

2025-05-27T14:17:04Z

commit 582c23ab75fdc47c01005dac784bb318443235aa parent 38eac9d4227b52ebedb20b5f06a771f72dd4526a Author: Eduardo Fontana Lazzari Date: Tue, 27 May 2025 16:17:04 +0200 Use suniq library for associative structure construction When the associative structure construction was first implemented (see commit 59f137b), the suniq library did not exist. This library now abstracts most of the functions and data structures used during the construction phase, allowing this logic to be centralized and reused in other projects. As a result, the code in star-phor is now simplified, since these functions are exposed by the library with the same functionality as before. Additionally, support data structures (such as hash tables and dynamic arrays), which were previously implemented specifically for this processing step, are now fully handled by suniq.

Add cube geometry to sphor API test and disallow empty geometries

2025-05-21T16:15:01Z

commit 38eac9d4227b52ebedb20b5f06a771f72dd4526a parent 2bd9dcdd439f288642ea4c9248b4d22108b2bbd5 Author: Eduardo Fontana Lazzari Date: Wed, 21 May 2025 18:15:01 +0200 Add cube geometry to sphor API test and disallow empty geometries The previous test was failing because it used an empty input file. While this is currently accepted by star-phor-input, the s3d library explicitly disallows it by checking the number of triangles before creating the acceleration structure and returning an error if none are present. This commit resolves that inconsistency by adopting the s3d behavior: a valid system must contain at least one triangle, and an error is now returned if the geometry is empty. Moreover, using an empty input limited the usefulness of the test, as it prevented the sphor struct from being instantiated. To address this, the test has been updated to include a minimal input file defining a cube geometry. This simple yet complete input allows the sphor API to be tested in several contexts.

Fix segmentation fault in function register_triangle

2025-05-20T07:12:13Z

commit 2bd9dcdd439f288642ea4c9248b4d22108b2bbd5 parent 2cfa86f5719871b978b41bc70f43fd4fa64434f7 Author: Eduardo Fontana Lazzari Date: Tue, 20 May 2025 09:12:13 +0200 Fix segmentation fault in function register_triangle

Set up accelerating structure for geometrical data

2025-05-20T06:58:57Z

commit 2cfa86f5719871b978b41bc70f43fd4fa64434f7 parent 8375b3d244cb0355e7cb17f25d6468f82bc958f7 Author: Eduardo Fontana Lazzari Date: Tue, 20 May 2025 08:58:57 +0200 Set up accelerating structure for geometrical data This commit introduces the code necessary to restructure the geometrical data, adapting it to the algorithms that compute intersections between rays and triangles. In this step, the geometrical data, which was temporarily stored in a dynamic array of triangles, is transformed into a structured scene view. This structured view is a member variable of the sphor struct and can be used during computation. This commit also adds a dependency on star-3d, the library responsible for the geometrical structuring. This same library also provides several functions useful during Monte Carlo sampling.

Refactor: Extract triangle setup logic into separate function

2025-05-07T16:17:07Z

commit 8375b3d244cb0355e7cb17f25d6468f82bc958f7 parent 10a6ce8ccb080889a085891725a57ebce05ba3f4 Author: Eduardo Fontana Lazzari Date: Wed, 7 May 2025 18:17:07 +0200 Refactor: Extract triangle setup logic into separate function Avoid code duplication by extracting the repetitive logic for retrieving vertex coordinates and populating the triangle struct when processing surfaces and volumes into the setup_triangle function.

Refactor struct interface: remove front/back from member names

2025-05-07T14:49:37Z

commit 10a6ce8ccb080889a085891725a57ebce05ba3f4 parent b7504bb3d4c029ffb3c32116302fc52f7435a116 Author: Eduardo Fontana Lazzari Date: Wed, 7 May 2025 16:49:37 +0200 Refactor struct interface: remove front/back from member names Once the correspondence between geometrical and physical data has been established, the notion of "front" and "back" from star-phor-input becomes irrelevant. Triangle orientations may be reversed during this process, making those original labels misleading. This refactoring also makes the data more suitable for Monte Carlo sampling, where orientation semantics are mostly unnecessary except in a few specific cases. Using static arrays to store volumes and surfaces—indexed by a symbolic constant for each side—provides a good compromise: it removes hardcoded orientation assumptions while preserving the ability to reinterpret the data where necessary (e.g., using SPHIN_SIDE_FRONT, SPHIN_SIDE_BACK).

Remove trailing whitespaces in end of lines

2025-05-05T12:28:05Z

commit b7504bb3d4c029ffb3c32116302fc52f7435a116 parent 774b0d5f9137d222f2976afda0614d878854013d Author: Eduardo Fontana Lazzari Date: Mon, 5 May 2025 14:28:05 +0200 Remove trailing whitespaces in end of lines

Add tests for sphor struct management

2025-05-05T12:08:33Z

commit 774b0d5f9137d222f2976afda0614d878854013d parent dc6b45cd3ef2a93a8a0d1a500c4ada8ed98f729a Author: Eduardo Fontana Lazzari Date: Mon, 5 May 2025 14:08:33 +0200 Add tests for sphor struct management Adds unit tests for the sphor creation and reference counting functions exposed by sphor.h.

Fix: Decrement sphor->config reference count on release

2025-05-05T11:46:42Z

commit dc6b45cd3ef2a93a8a0d1a500c4ada8ed98f729a parent 59f137b6fa631401044c07d5e0ba340a510d6c24 Author: Eduardo Fontana Lazzari Date: Mon, 5 May 2025 13:46:42 +0200 Fix: Decrement sphor->config reference count on release Sphor holds a reference to dynamically allocated config data. Releasing sphor now decrements the reference count to prevent memory leaks.

Add associative structure linking triangles to physical properties

2025-04-30T16:14:23Z

commit 59f137b6fa631401044c07d5e0ba340a510d6c24 parent ae8ff2a771b302742beedb1eeff88a7201ac56f0 Author: Eduardo Fontana Lazzari Date: Wed, 30 Apr 2025 18:14:23 +0200 Add associative structure linking triangles to physical properties This commit introduces a system that maps each triangle of the input geometries to its corresponding physical context (front/back volumes and surfaces). Motivation and rationale: Once a photoreactive system configuration is loaded by star-phor-input, there is a direct correspondence between volumes and surfaces on one hand, and geometry files on the other. This correspondence stems from a deliberate choice in the way such systems are described in star-phor-input files, which aim to provide a syntax allowing for a clear (scientifically readable) description of a well-posed radiative transfer problem applied to photoreactors. However, during the computation phase, this existing correspondence proves insufficient. In a Monte Carlo calculation, the focus shifts to querying the physical properties of the geometry (requiring a reversal of the correspondence direction previously defined in the input file). Moreover, the geometry must be handled more granularly: we consider individual triangles rather than whole geometry files. Therefore, in order to access the physical properties of a given surface or volume during a Monte Carlo calculation, it is necessary to associate the triangles composing the geometry of a given photoreactive system with the volumes and surfaces each triangle belongs to. Strategy: We first define a structure called interface which holds the identifiers of the front and back volumes, as well as the list of surface identifiers the triangle belongs to (on both sides). Each interface structure represents a single triangle, and each triangle is represented by a unique interface (there is a bijective relationship: triangle <-> interface). To describe the entire photoreactive system, we use a dynamic array that contains all interfaces corresponding to all unique triangles from the geometries in the input file (see darray_interface). Note that the coordinates of each triangle's vertices are not included in this structure. During computation, that information is managed by star-3d, which is responsible for building the acceleration structure used for intersection queries during ray tracing and already possesses all necessary geometric data. To avoid storing the same data multiple times in memory during the same computation stage, star-3d remains the sole owner of this data. However, a temporary dynamic array of triangles with vertex coordinates does exist in star-phor during the construction of the associative structure (see darray_triangle). This array is discarded once the coordinates are transferred to star-3d (i.e., ownership of the geometric data passes from star-phor to star-3d once the correspondance triangle->physical properties has been built). To establish the equivalence between the dynamic triangle and interface arrays, we use a simple strategy: a triangle in the darray_triangle array and its corresponding interface in the darray_interface array share the same index i. This means that to access the physical properties of a given triangle, one simply retrieves its index in the triangle array and accesses the equivalent element in the interface array. Moreover, since S3D preserves triangle indices during geometry structuring, this approach ensures we can retrieve triangle indices during the Monte Carlo calculation. Two challenges arise during this phase: 1.How can we efficiently retrieve the index of a triangle in the triangle array, considering that a linear search can become expensive as the number of triangles grows? 2.How can we ensure the uniqueness of a triangle, given that the same triangle can have 3! valid representations depending on the vertex order? To answer question 2, we adopt a convention for triangle representation that normalizes all possible descriptions to a single canonical one: we arrange its vertices in lexicographic order (https://en.wikipedia.org/wiki/Lexicographic_order, see the triangle_key_setup function). Once a triangle is reduced to its ordered representation, we use the hash table tri2id (see rsys/hash_table.h) to map vertex sets to indices in the triangle array. This structure enables key-value access (key: three lexicographically sorted coordinates, value: index of the corresponding interface in the dynamic interface array - and index of triangle in the darray_triangle ; and later triangle id in s3d). Accordingly, we define the function register_triangle, which both registers a triangle in the tri2id hash table and retrieves the triangle’s index based on its coordinates. Just like the triangles dynamic array, this hash table is temporary at this stage of the computation. Once the mapping from geometric data to physical data has been established for all triangles in the scene, the table is discarded. Once this structure is in place, we iterate over all surfaces and volumes in the configuration, then over each geometry of each surface and volume, and then over each triangle of each geometry, decorating the corresponding interface with its front volume, back volume, and lists of front and back surfaces. This association step has a subtle complexity: a triangle may be defined multiple times with different orientations in the star-phor input, each time following the valid left-hand orientation convention. For instance, a triangle might initially have a front facing one direction, and later be redefined with an opposite vertex order, reversing the front direction — both valid interpretations. Thus, if a previously defined triangle is encountered during the geometric-to-physical data association, we check the already registered interface description and compare it to the one at the triangle level. If the triangle normals point in opposite directions, this must be handled before recording the volume or surface in the corresponding interface.

Project setup: build system, core features, doc and tests

2025-04-17T13:56:57Z

commit ae8ff2a771b302742beedb1eeff88a7201ac56f0 parent 2e98424c36a4246da39385c02decd5826ea45952 Author: Eduardo Fontana Lazzari Date: Thu, 17 Apr 2025 15:56:57 +0200 Project setup: build system, core features, doc and tests This commit implements several features for the star-phor project: - Setup build system; - Implement core features for the library (memory management and logging); - Begin implementation for the main program and for library tests; - Begin writing documentation

Start implementing star-phor

2024-10-01T07:58:44Z

commit 2e98424c36a4246da39385c02decd5826ea45952 Author: Eduardo Fontana Lazzari Date: Tue, 1 Oct 2024 09:58:44 +0200 Start implementing star-phor Added README file and applied GPLv3+ Licence