[WIP] - interaction surface points

[aclegg3]

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:

interaction_surface_points-2024-08-07_17.16.46.mp4

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• 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.