search

c-frame / physx

A-Frame physics using PhysX
MIT License
24 stars 4 forks source link

Stats improvements - to match recent changes to aframe-physics-system #7

Closed diarmidmackenzie closed 1 year ago

diarmidmackenzie commented 1 year ago

2 sets of changes in here:

  1. A bunch of infra stuff to allow inclusion of npm packages, which requires us to have a build process.
  2. Using aframe-stats-panel to display stats, similarly to recent changes to aframe-physics-system (https://github.com/c-frame/aframe-physics-system/pull/17)

Now we have npm builds, we could do more - e.g. break the single physics.js module up into separate modules for each component - which I think will help with future maintenance. But I didn't want to fold too much into one PR, so I've just set up some npm basics + the stats stuff.

Could split this into 2 PRs if preferred, for reviewing, but I think the 2 aspects are separate enough that this should be reviewable as one job lot.

diarmidmackenzie commented 1 year ago

I've now made this the live branch for my GitHub pages

HTTPS://diarmidmackenzie.github.io/physx

kylebakerio commented 1 year ago

link to actual example, as following link tree will lead to c-frame as per the issue discussed: https://diarmidmackenzie.github.io/physx/examples/pinboard/physx.html

kylebakerio commented 1 year ago

For reference/comparison with the other visualization benchmarks I've put up: image

(They're also giving me a good excuse to work with your code and test it and see how use case feels)

kylebakerio commented 1 year ago

same issue is in this repo as described here: https://github.com/c-frame/aframe-physics-system/pull/17#issuecomment-1319337504

kylebakerio commented 1 year ago

curious on your thoughts here: it feels like the eventual destiny of this repo is to end up in aframe-physics-system. Right now the example, stats, and so on are a significant amount of code duplication--lots to fall out of sync. Should we not just invest in migrating this over, even in its current state?

diarmidmackenzie commented 1 year ago

curious on your thoughts here: it feels like the eventual destiny of this repo is to end up in aframe-physics-system. Right now the example, stats, and so on are a significant amount of code duplication--lots to fall out of sync. Should we not just invest in migrating this over, even in its current state?

Good question, but I think it would be premature to do that:

Main reason is I'm not convinced that is the long-term future. I think the future of A-Frame physics might be just this PhysX repo. Performance-wise, it's way ahead of both Ammo & Cannon. API usability is ahead of Ammo. Key issues that I've identified so far are:

If I just want to use PhysX, I'm not going to appreciate a bloated library that also contains the entirety of Cannon + all the integration for Ammo, none of which I need.

So at this stage, I'd much rather invest in more functionality, documentation & demos for PhysX, and see if that gets us to the point where it can be all things to all people physics-wise. At which point we can consider deprecating aframe-physics-system, or perhaps lightweight maintenance for some very particular niche cases where PhysX isn't a good fit.

diarmidmackenzie commented 1 year ago

same issue is in this repo as described here: c-frame/aframe-physics-system#17 (comment)

Fixed it