[Interactive Drive] Add physics via Physx - #423
Conversation
Signed-off-by: Ariel Glasroth <aglasroth@nvidia.com>
…ame mode is opt-in
|
/ok to test |
@ArielG-NV, there was an error processing your request: See the following link for more information: https://docs.gha-runners.nvidia.com/cpr/e/1/ |
Greptile SummaryAdds a PhysX-backed mutable simulation and object graph to Interactive Drive, removes the Vulkan renderer, and introduces game-mode collision behavior, debug rendering, and collision flare presentation.
Confidence Score: 2/5This PR should not merge until the native buffer lifetime hazard and the unexpectedly enabled programmatic game-mode defaults are fixed. Exported NumPy arrays can outlive and access freed native vector storage, while direct Python API launches enable collision physics, speed limiting, and visual effects without opting into game mode. Files Needing Attention: integrations/omnidreams/ludus-renderer/ludus_renderer/_cpp/physx/bindings.cpp; integrations/omnidreams/omnidreams/interactive_drive/config.py
|
| Filename | Overview |
|---|---|
| integrations/omnidreams/ludus-renderer/ludus_renderer/_cpp/physx/bindings.cpp | Adds the native PhysX scene and fixed-capacity buffers, but its exported NumPy views do not retain their native owner. |
| integrations/omnidreams/ludus-renderer/ludus_renderer/physx.py | Wraps native PhysX synchronization and stable buffers; its public and compact-result views expose the native buffer lifetime defect. |
| integrations/omnidreams/ludus-renderer/ludus_renderer/object_graph.py | Adds graph topology, spatial selection, and bounded PhysX copies with no accepted correctness issue. |
| integrations/omnidreams/omnidreams/interactive_drive/config.py | Adds physics and flare controls, but defaults game-mode-only behavior to enabled for non-CLI construction. |
| integrations/omnidreams/omnidreams/interactive_drive/cli.py | Correctly maps --game-mode to collision, speed-limit, and visual-flare settings for CLI launches. |
| integrations/omnidreams/omnidreams/interactive_drive/runtime/loop.py | Integrates simulation, flare scheduling, pipeline submission, and presentation in a consistent frame order. |
| integrations/omnidreams/omnidreams/interactive_drive/simulation/game_physics.py | Builds and synchronizes PhysX topology, actor controls, collisions, and debug state without an independently accepted defect. |
Reviews (1): Last reviewed commit: "optimizations" | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| return py::array_t<float>( | ||
| {static_cast<py::ssize_t>(mCapacity), static_cast<py::ssize_t>(kStateWidth)}, | ||
| {static_cast<py::ssize_t>(kStateWidth * sizeof(float)), static_cast<py::ssize_t>(sizeof(float))}, | ||
| mStates.data(), | ||
| py::none()); |
There was a problem hiding this comment.
When Python retains any returned buffer after releasing its NativeScene or PhysXWorld, the array still references freed std::vector storage because py::none() does not retain the native owner, causing corrupted reads, writes, or a process crash.
How this was verified: All seven public buffer accessors construct arrays over member-vector storage with py::none() as their lifetime base.
| steer_return_rate_rad_per_s: float = 0.7 | ||
| steer_rate_rad_per_s: float = 0.55 | ||
| steer_return_rate_rad_per_s: float = 0.9 | ||
| speed_limit_enabled: bool = True |
There was a problem hiding this comment.
When InteractiveDriveApp or AppConfig is constructed through the Python API instead of cli.py, these defaults enable speed limiting, actor and static collisions, and collision flares without opting into game mode, causing programmatic launches to behave differently from the documented default.
Knowledge Base Used: Integrations
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
1 participant
Changes:
greencar to identify the ego on the BEV.--game-modeflag for the interactive-drive demos3, a physx-debug view. This view enabled viewing the colliders we setup on the backend of physx: vehicles, pedestrians, road-boundaries as walls, etc....