Add barycentric coordinates to ray vs. triangle collision results

[Copilot]

Ray-triangle collision results (CollisionResult) had no way to retrieve barycentric coordinates of the contact point, making texture-coord interpolation and surface-parameter lookups impossible without redundant re-computation.

Changes

• CollisionResult: Added contactBaryCoords (Vector2f) field with getter/setter. Convention: (u, v) where u = weight of v1, v = weight of v2, 1-u-v = weight of v0.

• CollisionResults: Added requiresBaryCoords boolean flag (default false) with setRequiresBaryCoords(boolean) / isRequiresBaryCoords(). Barycentric coordinates are only computed and stored when this flag is enabled, avoiding unnecessary allocation and math for callers that don't need them.

• Ray: Added intersects(Vector3f v0, Vector3f v1, Vector3f v2, Vector2f baryCoords) overload that computes barycentric coordinates alongside the hit distance in a single pass. Updated collideWith(AbstractTriangle) to populate contactBaryCoords on the result only when the flag is set.

• BIHNode: Updated intersectWhere() leaf loop (mesh collision path) to use the new overload and store barycentric coords on each CollisionResult only when the flag is set.

Usage

CollisionResults results = new CollisionResults();
results.setRequiresBaryCoords(true); // opt in to barycentric computation
ray.collideWith(geometry, results);

CollisionResult hit = results.getClosestCollision();
Vector2f bary = hit.getContactBaryCoords(); // (u, v); w0 = 1 - u - v

// Interpolate a vertex attribute (e.g. texture coords) at the hit point
Vector2f texCoord = texCoord0.mult(1 - bary.x - bary.y)
                 .add(texCoord1.mult(bary.x))
                 .add(texCoord2.mult(bary.y));

getContactBaryCoords() returns null when the flag is disabled (default) or for collision types that don't involve a triangle (e.g. bounding volume hits).

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[riccardobl]

Can you add a boolean flag to CollisionResults to enable barycentric coordinate computation? So that it is done only when the developer need them? @copilot

[Copilot]

Can you add a boolean flag to CollisionResults to enable barycentric coordinate computation? So that it is done only when the developer need them? @copilot

Done in commit 16a97ce. Added requiresBaryCoords boolean flag (default false) to CollisionResults. Barycentric coordinates are only computed and stored when results.setRequiresBaryCoords(true) is called before the collision query. No Vector2f is allocated and no extra math is done when the flag is off.

[jaime-jmebot]

Nice — the (u, v) values produced here match the convention already used by intersectWherePlanar() (u = weight of v1, v = weight of v2), so the two APIs agree and the javadoc is accurate.

One maintainability note: this new overload is a line-for-line copy of the existing intersects(Vector3f, Vector3f, Vector3f) method (which in turn mirrors the private intersects(...)), so the same ray/triangle math now lives in three places and can silently drift apart when one copy is fixed. Since intersects(v0, v1, v2) is still public API, it could simply delegate:

public float intersects(Vector3f v0, Vector3f v1, Vector3f v2) {
    return intersects(v0, v1, v2, null);
}

Same behaviour, one implementation to maintain. (Couldn't attach it as a one-click suggestion because those lines aren't part of this diff.)

[jaime-jmebot]

This BIH leaf is the branch real geometry.collideWith(ray, results) calls go through, but the new tests only exercise the direct Ray/Triangle API. A small test that builds a Mesh/Geometry, enables setRequiresBaryCoords(true), and asserts the coords on the returned CollisionResult would guard this path too — including the world-transform case just above.

[jaime-jmebot]

Nice work — the feature is tidy and the opt-in flag addresses the earlier request well.

• The (u, v) convention is consistent across Ray.intersectWherePlanar, the new overload, and CollisionResult, and the weights line up with what the BIH leaf loop stores, so the documented usage (interpolating per-vertex attributes) is correct.
• One maintainability nit inline: the new Ray.intersects overload duplicates the existing three-argument method, so the ray/triangle math now exists in two more copies.
• The added unit tests cover the direct triangle path; a mesh/Geometry-level test would also exercise the BIH branch (inline note).

Nothing blocking from my side.