Clamp Ogre2 GPU lidar cubemap sampling at face edges

[bigboateng]

🦟 Bug fix

Related to gazebosim/gz-sim#3475

Summary

GPU lidar scan directions on cubemap face boundaries can produce a normalized texture coordinate of 1.0. The Ogre2 GPU-rays second pass uses point filtering, but its sample-table and cubemap textures previously retained Ogre's default wrap addressing. An endpoint lookup could therefore sample the opposite texture edge.

This is observable with a partial-FOV scan using 900 horizontal rays from -45 to +45 degrees. Before this change, endpoint samples can select the wrong cubemap edge and produce an incorrect range or point. After applying clamp addressing, endpoint coordinates remain on the intended cubemap edge.

This PR:

• sets tex_address_mode clamp on the sample table and all six cubemap-face textures used by GpuRaysScan2nd;
• adds an Ogre2 integration test using a 900-ray partial-FOV scan;
• places deliberately asymmetric targets at the two endpoint directions so wrap addressing cannot pass through scene symmetry.

The change affects sampler state only. It does not change the GPU-rays API, point-cloud layout, scan angles, or interior texture coordinates.

Validation:

• The deterministic endpoint calculation produces a normalized cubemap coordinate of 1.0f for both endpoint directions.
• Removing the clamp declarations causes the endpoint regression test to fail.
• Restoring the declarations makes the test pass.
• Linux Resolute CI passed.
• Homebrew ARM64 and Windows CI passed.
• DCO passed.

Backport Policy

• This is safe to backport to the following versions:
  • Jetty
  • Ionic
  • Harmonic
  • Fortress
• This should not be backported
• I am not sure
• Other (fill in yourself)

The original report's exact Gazebo release is still unconfirmed. Maintainer guidance is requested on which supported versions contain the affected Ogre2 material path.

Checklist

• Signed all commits for DCO
• Screen capture or video is not needed; the regression is numerical and covered by an Ogre2 integration test
• Added tests
• Documentation update is not needed; no public behavior or API is added
• Migration guide update is not needed
• Python bindings are not affected
• codecheck passed
• All tests passed
• Bazel updates are not needed; no new source files were added
• While waiting for review, help review another open Gazebo pull request
• Was GenAI used to generate this PR? The required disclosure is included below.

Assisted-by: OpenAI Codex

[bigboateng]

CI note: the failing Resolute job is an infrastructure failure rather than a
test failure from this change. The GPU container failed to start with
failed to initialize NVML: Driver/library version mismatch, and the existing
automatic recovery logic did not recognize that spelling.

I opened gazebo-tooling/release-tools#1522 to address
the detection gap in both the Naginator retry and post-build recovery paths.
The job will still need to be rerun on a healthy GPU worker to validate this
PR's Ogre2 fixture.

[azeey]

Thanks for the contribution @bigboateng. Could you please fill out the PR template?

[bigboateng]

@azeey Thanks for pointing that out. I’ve updated the description using the Gazebo bug-fix PR template, including the reproduction, validation, backport status, checklist, and required disclosure.

[iche033]

changes look good to me. Thanks for the contribution

[iche033]

verified test fails without the changes