gazebosim / gazebosim/gz-rendering
Ogre2 CPU implementation of RayQuery skips over geometry whose AABB contains the origin of the ray
- Dominant language
- C++
- Stars
- 81
- Forks
- 90
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 10
Description
## Environment
* OS Version: Ubuntu 22.04
* Source or binary build? Binary, from apt for my version of Ubuntu
* If this is a GUI or sensor rendering bug, describe your GPU and rendering system. Otherwise delete this section.
- Rendering plugin: ogre2.
- [x] running in Docker/Singularity
Omitting some details since the bug is within the CPU code
## Description
This is specifically when using the CPU implementation of Ogre2RayQuery
In [Ogre2RayQuery](https://github.com/gazebosim/gz-rendering/blob/gz-rendering10/ogre2/src/Ogre2RayQuery.cc) , `ThreadedTriRay::execute` will skip over any object whose intersection distance is `<= 0`. Unfortunately, in [OgreMath.cpp](https://github.com/OGRECave/ogre/blob/master/OgreMain/src/OgreMath.cpp) which OGRE's ray-scene code uses under the hood, `Math::intersects(ray, box)` will return 0 when the origin of the ray is within the bounding box. The interaction of these two systems leads to the described bug: if the object's AABB contains the origin of the ray, it is skipped for consideration within the CPU implementation of Ogre2RayQuery.
I think this check should just be `< 0` instead of `<= 0` on `ThreadedTriRay::execute`, but I'm not sure what considerations were at play when this code was written (and I have not been able to successfully build gazebo, so I only have access to the binary versions).
Best I can tell, this bug affects my version (7) all the way through the version on master.
## Steps to reproduce
Use the CPU implementation of RayQuery within OGRE2, command a query that _should_ intersect valid geometry, but starts within the AABB of that geometry, observe that it does not.
Contributor guide
Assessment
This issue has not been assessed yet.