I think Havoc physics will be a very welcome addition. Threejs has an adjacent library based off of bullet physics -- a solid library, but one that can be a bit finicky to set up. Although, physics engines are inherently difficult to work with in the first place.
As a technical 3D artist, Babylon has been a great way to dive into web dev, and it parallels with standard game engines just enough that I can easily find my way around the documentation.
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.
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.
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?
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.
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.
>I think Havoc physics will be a very welcome addition
No kidding. The "Physics" in Babylon.js is at the inexcusably "my first game engine" level of incompetence. Velocity and acceleration are treated as if they have the same dimensions. All kinds of deeply embedded movement code lacks any understanding of world time. You can definitely get a little game going quickly in it because you don't have to think about any "hard" things, but when you try running your game on systems whose frame rates differ wildly you suddenly understand why real game engines care about the fact that velocity is measured in units of m/s and acceleration in units of m/s^2, and that it matters whether you build your art assets at meter scale or centimeter scale or etc.
To be clear, you are only talking about the previous implementation of physics in babylon, now called V1?
Do you have insights, into whether the new havoc port is better designed? They seemed to have reimplemented the whole physic architecture which they now call V2:
Havok physics is certainly an interesting addition! Especially since Cannon.js & Oimo.js are not being maintained anymore. Ammo.js (port of Bullet) seems to have some updates here and there (IIRC, it was easier to setup using Babylon considering that it used a wrapper across all physics libraries).
Blender is definitely the weapon of choice. Substance 3D is almost required nowadays for proprietary rendering, and the occasional Autodesk+VRAY combo for older established clients.
Edit: On the coding side, python is great for pipelines (especially now that blender has its own module). Imagemagick is great for formatting textures and huge .tiff files. ffmpeg is the king of video formatting.
As a technical 3D artist, Babylon has been a great way to dive into web dev, and it parallels with standard game engines just enough that I can easily find my way around the documentation.