4 ms·

> Although, physics engines are inherently difficult to work with in the first place. Do you have any insights into why this is the case? What areas of simulat

> Although, physics engines are inherently difficult to work with in the first place. Do you have any insights into why this is the case? What areas of simulation or tooling are difficult to work with? Disclaimer: I'm on the Havok team and worked on the Babylon.JS integration.

capableweb 3y ago
Unrelated but related to Havok: I love Havok, and love to see a Bevy integration, is there one in the works? Doesn't seem like anyone in the Bevy community has yet to stepped up to the plate, and considering Havok is not FOSS, maybe it's unlikely to. But still wanted to ask.
- looklookatme 3y ago
  I haven't come across Bevy before, but it certainly looks very neat from the example demos. If there's a WASM runtime for Rust, I _imagine_ it's possible to take the HavokPhysics.wasm used by Babylon.JS and calling the functions it exposes - the physics functionality exported by that WASM is pretty general and does not make any assumptions about the engine it's running in.
q_andrew 3y ago
Hey! Congrats on the launch, the touted performance increases are mind blowing. I think physics engines are difficult for a few reasons: - They don't mesh with a lot of features that modelers take for granted (non-uniform scaling, concave meshes, lax model scaling) - It's hard know intuitively what values to use for things like acceleration, density, velocity, damping, friction. Especially because they are very inter-dependent. - Interaction with moving kinematic or non-physics objects is an undefined behavior that has to be tested pretty rigorously. - In gamedev, rigidbody physics are basically a trojan horse for gameplay bugs like clipping through the map and sudden bursts of high speeds (Which is both magical and frustrating). It's a non-trivial task to sandbox those behaviors completely. - Projectiles. There's no catch-all solution for small fast-moving objects, it's always a tradeoff. But that's mostly because big O dictates it to be so.
- looklookatme 3y ago
  Thanks for those insights! I think some of the things you mention (non-uniform scaling, concave meshes) are getting easier these days, thanks to tooling around things like convex decomposition and relaxed memory requirements, although, even without considering physics, it seems scaling causes huge problems for _everyone_ - feels like every Blender tutorial out there will say "remember to apply scale" to sidestep those scale issues. The other things you talk about feel very second-nature to me at this stage, so it's interesting to hear that kind of perspective. I think physics engines in general could certainly be doing a better job at documenting how the exposed physical parameters map unto use-cases.
  - throwaway17_17 3y ago
    Do you think the problems with scaling (particularly non-uniform) primarily arise because most physics, animation, etc., are biased towards uniform normalized scale? Or is there some other issue I am unaware of that causes the issues?
undefuser 3y ago
Not very relevant to the main topic here, but the site www.havok.com seems to have a SSL cert problem.

capableweb 3y ago

Unrelated but related to Havok: I love Havok, and love to see a Bevy integration, is there one in the works? Doesn't seem like anyone in the Bevy community has yet to stepped up to the plate, and considering Havok is not FOSS, maybe it's unlikely to. But still wanted to ask.

looklookatme 3y ago
I haven't come across Bevy before, but it certainly looks very neat from the example demos. If there's a WASM runtime for Rust, I _imagine_ it's possible to take the HavokPhysics.wasm used by Babylon.JS and calling the functions it exposes - the physics functionality exported by that WASM is pretty general and does not make any assumptions about the engine it's running in.

q_andrew 3y ago

Hey! Congrats on the launch, the touted performance increases are mind blowing. I think physics engines are difficult for a few reasons: - They don't mesh with a lot of features that modelers take for granted (non-uniform scaling, concave meshes, lax model scaling) - It's hard know intuitively what values to use for things like acceleration, density, velocity, damping, friction. Especially because they are very inter-dependent. - Interaction with moving kinematic or non-physics objects is an undefined behavior that has to be tested pretty rigorously. - In gamedev, rigidbody physics are basically a trojan horse for gameplay bugs like clipping through the map and sudden bursts of high speeds (Which is both magical and frustrating). It's a non-trivial task to sandbox those behaviors completely. - Projectiles. There's no catch-all solution for small fast-moving objects, it's always a tradeoff. But that's mostly because big O dictates it to be so.

looklookatme 3y ago
Thanks for those insights! I think some of the things you mention (non-uniform scaling, concave meshes) are getting easier these days, thanks to tooling around things like convex decomposition and relaxed memory requirements, although, even without considering physics, it seems scaling causes huge problems for _everyone_ - feels like every Blender tutorial out there will say "remember to apply scale" to sidestep those scale issues. The other things you talk about feel very second-nature to me at this stage, so it's interesting to hear that kind of perspective. I think physics engines in general could certainly be doing a better job at documenting how the exposed physical parameters map unto use-cases.
- throwaway17_17 3y ago
  Do you think the problems with scaling (particularly non-uniform) primarily arise because most physics, animation, etc., are biased towards uniform normalized scale? Or is there some other issue I am unaware of that causes the issues?

undefuser 3y ago

Not very relevant to the main topic here, but the site www.havok.com seems to have a SSL cert problem.