Context
PR #3025 brings the current engine-side PhysX integration much closer to the semantics exposed by galacean/physX.js. While reviewing it against the local physX.js binding, a few worthwhile follow-ups came up that are not merge blockers for #3025 and are better handled as separate work.
Follow-ups
-
Expose PxRigidBodyExt::addForceAtPos in physX.js and route DynamicCollider.applyForceAtPosition through it.
Reason: physX.js currently binds addForce / addTorque, while the addForceAtPos binding is present but commented out in ActorBinding.h. Engine-side torque calculation is correct today, but pushing this operation back to the PhysX extension reduces long-term maintenance risk around center-of-mass, coordinate-space, and scale semantics.
Acceptance direction: expose the binding in physX.js, add/update engine-side adapter support, and keep the existing applyForceAtPosition behavior tests passing.
-
Add an offline/pre-cooked mesh collider path for static imported assets.
Reason: runtime mesh cooking is useful for editor preview, hot updates, and dynamic/generated meshes. For production static collider meshes, PhysX recommends offline cooking and loading cooked streams to avoid runtime cooking cost and first-use stalls.
Acceptance direction: imported/static model collider meshes can reuse cached cooked data, while runtime cooking remains available as a fallback for dynamic meshes.
-
Make PhysX scene/filter contact and CCD reporting configurable.
Reason: the current physX.js default scene desc enables CCD, keeps kinematic/static filtering pairs, and the filter shader emits contact notifications, contact points, CCD contact detection, and CCD touch notifications by default. This is a useful engine default, but projects that do not need full contact reporting should be able to avoid that overhead.
Acceptance direction: expose engine-level PhysX options for contact/CCD reporting policy without changing the current default behavior.
Non-goals
Context
PR #3025 brings the current engine-side PhysX integration much closer to the semantics exposed by
galacean/physX.js. While reviewing it against the localphysX.jsbinding, a few worthwhile follow-ups came up that are not merge blockers for #3025 and are better handled as separate work.Follow-ups
Expose
PxRigidBodyExt::addForceAtPosinphysX.jsand routeDynamicCollider.applyForceAtPositionthrough it.Reason:
physX.jscurrently bindsaddForce/addTorque, while theaddForceAtPosbinding is present but commented out inActorBinding.h. Engine-side torque calculation is correct today, but pushing this operation back to the PhysX extension reduces long-term maintenance risk around center-of-mass, coordinate-space, and scale semantics.Acceptance direction: expose the binding in
physX.js, add/update engine-side adapter support, and keep the existingapplyForceAtPositionbehavior tests passing.Add an offline/pre-cooked mesh collider path for static imported assets.
Reason: runtime mesh cooking is useful for editor preview, hot updates, and dynamic/generated meshes. For production static collider meshes, PhysX recommends offline cooking and loading cooked streams to avoid runtime cooking cost and first-use stalls.
Acceptance direction: imported/static model collider meshes can reuse cached cooked data, while runtime cooking remains available as a fallback for dynamic meshes.
Make PhysX scene/filter contact and CCD reporting configurable.
Reason: the current
physX.jsdefault scene desc enables CCD, keeps kinematic/static filtering pairs, and the filter shader emits contact notifications, contact points, CCD contact detection, and CCD touch notifications by default. This is a useful engine default, but projects that do not need full contact reporting should be able to avoid that overhead.Acceptance direction: expose engine-level PhysX options for contact/CCD reporting policy without changing the current default behavior.
Non-goals