Decide whether physics should continue to run in a web worker
This requires some refinement around the purpose of @react-three/p2.
For websites that use p2 for secondary effects and interactions, running p2 in a web worker is advantageous as webpages will remain interactive - a long physics step won't block the main thread.
But for game-dev purposes, running physics in a separate thread can be a nuisance. Things like character controllers that rely on raycasting are difficult to write in with the hooks, and should ideally be run in the same thread as p2 for performance.
For maintainability reasons, offering both worker and non-worker versions of rt/p2 isn't easy.
Consider a declarative API, rather than the current hooks API
A declarative API should be considered, similar to the one that @react-three/rapier sports.
Some things to consider for a 1.0.0 release:
Decide whether physics should continue to run in a web worker
This requires some refinement around the purpose of
@react-three/p2.For websites that use p2 for secondary effects and interactions, running p2 in a web worker is advantageous as webpages will remain interactive - a long physics step won't block the main thread.
But for game-dev purposes, running physics in a separate thread can be a nuisance. Things like character controllers that rely on raycasting are difficult to write in with the hooks, and should ideally be run in the same thread as p2 for performance.
For maintainability reasons, offering both worker and non-worker versions of rt/p2 isn't easy.
Consider a declarative API, rather than the current hooks API
A declarative API should be considered, similar to the one that
@react-three/rapiersports.