Fix surface receiver vertex corruption and Flatpak resource path resolution

[diegotonetti99]

Summary

Fixes #425 and #420.

Surface receiver vertex corruption (#425)

baseReportManager.cpp populated t_FaceRS::sommetsIndex (an Intb[3], i.e. int32_t[3]) via memcpy(..., sizeof(ivec3)). ivec3 stores its three components as long, which is 8 bytes on LP64 (Linux/macOS), so the memcpy wrote 24 bytes into a 12-byte field. In practice every triangle's second vertex index (b) got overwritten by the low half of the third vertex's value, and every triangle's third vertex ended up reading zeroed/adjacent memory — visible in exported .csbin files as the vast majority of triangles sharing vertex 0. This corrupted every surface receiver's colormap and iso-contour rendering on Linux/macOS (Windows was unaffected, since long is 4 bytes there). Fixed with element-wise index assignment at all 4 call sites.

Verified by parsing a real rs_cut.csbin before/after the fix: before, vertex 0 was referenced by 121 of 360 face-vertex slots (all faces had sommetsIndex[1]==0); after, vertex 0 is only referenced by its legitimate ~2-3 corner faces, and the receiver renders as a smooth, correctly-triangulated grid.

Two related rendering bugs found and fixed alongside it, both required to fully clear up the broken colormap on Linux:

• Recepteurs_surfacique.cpp: the smooth-color per-vertex energy average divided by quantFacesLinked without checking it was non-zero, producing NaN (and visibly corrupting the shading of every triangle sharing that vertex) whenever every face touching a vertex recorded zero energy.
• Recepteurs_surfacique.cpp: iso_curves was never cleared before being recomputed in LoadRecepteursSFile, so stale contour lines from an earlier Refresh() call stayed rendered on top of the current, correct set (visible as tangled scribbles over the colormap).
• std_rsbin.cpp: FINDMINMAX_RSURF never checked the first triangle vertex (x0) against min/max, only the other two.

Flatpak resource path resolution (#420)

Older/template projects can carry a bare relative default .gpl palette path (e.g. Bitmaps/iso/jet.gpl) baked in from before this was fixed to store an absolute path. LoadGplFile now resolves such a relative path against the app's resources folder instead of relying on the process' current working directory, which Flatpak does not guarantee is set to the app's install directory.

Test plan

• Rebuilt the Flatpak locally (flatpak-builder --user --install --force-clean --ccache build org.noise_planet.i-simpa.yml)
• Ran a fresh SPPS calculation and confirmed the surface receiver (rs_cut, TR15, TR30) now renders a smooth colormap with clean iso-contour lines, no missing/overlapping triangles
• Parsed the exported .csbin with a small script to confirm vertex indices are no longer corrupted
• Existing surfaceReceiverTest1 unit test only checks header metadata (nbTimeStep, recordType), not face vertex indices — worth extending in a follow-up to catch this class of bug in CI

🤖 Generated with Claude Code

[nicolas-f]

Hello,

Thanks for your contribution.

There is some duplicate fix here than in the other pull request #418

[nicolas-f]

You are invited to agree with the Contributor License Agreement:

Entity Contributor License Agreement, for institutions

Individual Contributor License Agreement, for individual contributors

Contributors must fill one of these forms and send the signed version by mail at: I-Simpa@ifsttar.fr

If contributions are accepted in a new release, Contributors will be added in the 'About' dialog box of I-Simpa.