Bounding volume hierarchy

[akuten1298]

Fixes/Closes napari#5755

Closes napari#5755

Before vs After:

Before_Get_Status.mp4

After_Get_Status_BVH.mp4

Description

This PR consists of required changes to optimize get_status execution that gets called during cursor movement on a the surface layer. get_status execution time has been brought down by 80% with a one-time construction cost of data structure named "Bounding Volume Hierarchy". The average get_status runtime was around 200ms and with this updated change, this is around 40ms on average. These enhancements aim to improve the performance and efficiency of the existing system by optimizing triangle-ray intersection detection by reducing the total number of comparisons possible for a surface layer.

Bounding Volume Hierarchy (BVH) is a data structure that organizes objects or elements into a tree hierarchy. In this implementation, BVH is utilized to accelerate ray-tracing and complex spatial queries within the system. The BVH structure allows for efficient culling of objects and reduces the number of intersection tests required, resulting in significant performance improvements.

Axis-Aligned Bounding Boxes (AABB) are used as the building blocks of the BVH structure. An AABB is a rectangular box aligned with the coordinate axes (X, Y, and Z), where each box encapsulates an object or a group of objects. By representing objects with AABBs, we can quickly assess spatial relationships and perform intersection tests during traversal of the BVH tree.

Motivation:

User Experience:

When users interact with the application, they expect immediate feedback and updates. Users should be able to interact with the application seamlessly, enjoying a more fluid and engaging experience.

Enhancing GUI responsiveness:

100ms is about the limit for having the user feel that the system is reacting instantaneously. By enhancing GUI responsiveness, we aim to eliminate any delays or stutters, allowing users to navigate through the interface effortlessly and enjoy a more immersive and engaging experience.

Faster Performance:

Initial profiling on the model in the example indicated that get_value takes around 170-200 ms, with limited potential for substantial improvement. However, micro-optimizations managed to reduce the time to approximately 150 ms. The focus now is to explore further optimizations and assess their impact on performance. Identifying the major areas where execution time is spent will guide our optimization efforts.

Profiling:

References

Type of change

• 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 not work as expected)
• This change requires a documentation update

How has this been tested?

• example: the test suite for my feature covers cases x, y, and z
• example: all tests pass with my change
• example: I check if my changes works with both PySide and PyQt backends
  as there are small differences between the two Qt bindings.

Final checklist:

• My PR is the minimum possible work for the desired functionality
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• If I included new strings, I have used trans. to make them localizable.
  For more information see our translations guide.