[WIP] - interaction surface points

[aclegg3]

trafficstars

Motivation and Context

This PR contains a prototype viewer.py application for computing "interaction surface points".

Context:

In many scenarios a heuristic of unoccluded point to surface distance is desired.

• Checking against a single point is prone to edge case errors and unreliable (e.g. when an object conveniently blocks the center).
• Using the full mesh is intractable.
• Using a reduced representation like AABB is error prone for complex shapes (imagine the classic L shaped couch and this becomes obvious).

Instead, "interaction surface points" provide a pre-computed set of points which cover the surface of an object allowing distance and occlusion checks against a set of points in order to reduce the likely-hood of edge cases.

Implementation:

Concretely, we use horizontal raycasting from the AABB boundary to collect a set of exterior surface points. We then cull the point set by removing points with lowest pairwise distance until a configurable maximum number of points remain. This provides a heuristically uniform distribution. We cache the points in MarkerSets and serialize to template metadata such that pre-computed points can be re-loaded from the SceneDataset rather than re-computed at runtime.

TODO: migrate to a util, pre-compute over dataset

How Has This Been Tested

Viewer application demo code. Try it out:

• run viewer.py on your scene of choice.
• right click an object to compute the interaction surface points (displayed in yellow)
• 'r' increments radial samples (+shift to decrement)
• 'v' increments vertical samples (+shift to decrement)
• 'c' increments max points after culling (+shift to decrement)
• alt-'c' to toggle culling
• 't' to toggle ray debug drawing

Example:

https://github.com/user-attachments/assets/6d69586c-541f-4a7c-ab08-fe833e7d9c32

Types of changes

• [ ] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• [ ] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have read the CONTRIBUTING document.
• [ ] I have completed my CLA (see CONTRIBUTING)
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.