[HN Gopher] Babylon.js 6.0
___________________________________________________________________
Babylon.js 6.0
Author : q_andrew
Score : 36 points
Date : 2023-04-20 20:31 UTC (2 hours ago)
(HTM) web link (www.babylonjs.com)
(TXT) w3m dump (www.babylonjs.com)
| janosdebugs wrote:
| Babylon is amazing, the documentation and backwards compatibility
| is quite something. Just finished a project with it, while the
| learning curve is steep, it doesn't blindside you.
| q_andrew wrote:
| Yes, I'm a big fan of the documentation. According to the
| release blog, they are re-organizing the docs for 6.0 --
| hopefully a further improvement:
|
| https://babylonjs.medium.com/announcing-babylon-js-6-0-dcb5f...
| q_andrew wrote:
| 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.
| nerdchum wrote:
| hey this is total side tangent but what software do you use to
| develop your 3D art?
| q_andrew wrote:
| 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.
| looklookatme wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| yodon wrote:
| >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.
| ajdoingnothing wrote:
| 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).
|
| Good to see that Babylon.js is doing well.
| jalino23 wrote:
| this is so nice! I shall be making my game with this! just
| kidding I need to learn - linear algebra first - then that
| opengltutorial - learn 3d modeling, animation, rigging, uv,
| texturing.
___________________________________________________________________
(page generated 2023-04-20 23:00 UTC)