Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extending Physx API Bindings - exploration of options. #15

Open
diarmidmackenzie opened this issue Mar 15, 2023 · 2 comments
Open

Extending Physx API Bindings - exploration of options. #15

diarmidmackenzie opened this issue Mar 15, 2023 · 2 comments

Comments

@diarmidmackenzie
Copy link
Member

I've been looking at extending the available PhysX API bindings.

My immediate goal was to experiment with Projection on Fixed Joints to solve a problem where walls of bricks joined together with fixed joints become wobbly above a certain size.

For future reference, this issue documents my progress on a couple of fronts.

  1. Rebuilding the existing WASM build, using the approach described here.

This is the "obvious" approach, and should have been straightforward.

I made some minor updates to enable a couple of new API calls here

Rebuilding should be pretty straightforward, but I had a few issues

  • running natively on Windows, the npm scripts hit errors
  • so I ran WSL so that I had a linux environment on my Windows PC
  • I was able to set that up with Docker following these instructions and to set up node on WSL using these instructions
  • Having cloned repos within Windows, I found I had some problems with file format (CRLF vs LF). Simplest solution was to delete the repos I had cloned in Windows, and re-clone from the WSL command line.
  • That was enough to get things going, but I hit a couple of compiler warnings, which stopped the build from working, as described here.
  • Potentially I could work around those issues by either changing the compiler flags so it's more tolerant of warnings, or fixing up the cpp code. But it seemed odd that I should have to do either of these. At this point I paused & looked at a 2nd option.
  1. Migrating to physx-js-webidl

This is used by PHY, a Physics library for Three.js that I've been looking at.

Benefits of using this WASM build include:

  • it's already updated tp use PhysX 5.1
  • it seems to aleady expose more of the API (e.g. projection tolerance settings above).

I've been making some changes on this branch to try to get this working. Unfortunately it's not staightforward.

The way the PhysX CPP API gets translated into a JS API is quite different for this alternative build.

Working through the differences has basically been a matter of:

  • running examples to see what errors are hit
  • comparing bindings defined for the perviosu version of PhysX here with the web IDL bindings here
  • making updates & testing again.

If made a bunch of fixes & hit a number of errors, but still hitting problems inside the physics simulation:

physx-js-webidl.wasm:0x11b817 Uncaught RuntimeError: null function or function signature mismatch
    at physx-js-webidl.wasm:0x11b817
    at physx-js-webidl.wasm:0x11bc19
    at physx-js-webidl.wasm:0x9ff13
    at eval (physx-js-webidl.js:969:22)
    at PxScene.simulate.PxScene.simulate (physx-js-webidl.js:30889:50)
    at i.tock (physics.js:746:16)
    at bind.js:12:17
    at i.tock (index.js:127:7)
    at v.tock (a-scene.js:724:36)
    at e.object3D.onAfterRender (a-scene.js:52:34)

Presumably something has been initialized incorrectly due to the change in API, but it's not straightforward to find out what.

I'm wrapping up this investigation for now. While I had wanted to experiment with projection of Fixed Joints, I only thought there was a small chance of it solving my problems, and think a better solution is likely to be by following the advice in the API docs and use a single actor with multiple shapes...

Note All joints are enforced by the dynamics solver, so although under ideal conditions the objects will maintain their spatial relationship, there may be some drift. A common alternative, which is cheaper to simulate and does not suffer from drift, is to construct a single actor with multiple shapes. However fixed joints are useful, for example, when a joint must be breakable or report its constraint force.

Nevertheless, it's likely that we'll want to extend the exposed parts of the PhysX API and/or move to 5.1+ at some point, so with that in mind, I've documented my investigations so far here.

@kfarr
Copy link

kfarr commented May 9, 2023

Wow thanks for this writeup and sharing this repo! https://github.com/fabmax/physx-js-webidl

  • I notice webidl bindings include vehicles :)
  • For the error at eval (physx-js-webidl.js:969:22) I notice that js file is minimized, is it possible to see the context of the error in a non-minified version?
  • Another approach could be to step through the logic in this js example: https://github.com/fabmax/physx-js-webidl/blob/main/dist/helloworld.html and see if there are any obvious steps missing?

@enzofrancescaHM
Copy link

Sorry to write on this thread 1 year after last communications, but it would be nice to have Physx migrated to physx-js-webidl because it have support for vehicles and this is a big point, useful for a-frame + physx.
So, just a manifestation of interest!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants