Babylon X: Discussion topic

Feature requests
1

Hey team!! As state in that other forum post, please use this post to list ideas / desires / suggestions for Babylon X (codename for the version of Babylon that will allow massive breaking changes).

Thanks!

Edit:
To clarify the goal of this post: I’m interested in exploring potential improvements to the engine that would enhance its speed and efficiency, assuming we are not limited by concerns about introducing breaking changes.

If you have any ideas that fit this criteria, I’d like to hear them. For any other suggestions that don’t hinge on making significant alterations to the existing architecture, there’s no need to wait for Babylon X; we, or the community, can start working on them immediately.

4 Likes
2

[Edit]] Remove off-topic

Otherwise for cleaning I think that everything that is BABYLON.Mesh can be deleted and keep only BABYLON.MeshBuilder. But I think it’s already planned.

3

Please start a dedicated thread for features requirement. I would like to keep this thread focused on Babylon X:)

4

Yes everything flagged as @deprecated will be removed

5

I think that a new “fork” could be created for Babylon X and that would leave room for a Babylon LTS. That would help those that want to either stick with the older version or migrate over time.

6

Totally the plan. We will have a LTS version for people who want to take it slow

7

Perhaps i am going too far here, i’m not sure :slight_smile:

But one particular thing that has been bugging(annoying) me for years,
ever since it became a thing really, (time flies :astonished:),
it is that babylonjs is left-handed and GLTF, the big web format for 3D, decided on being a right-handed format and all we could do was stand by… slap a root node on it, and say “we gotta settle for that”

TLDR;

scene.useRightHandedSystem = true; by default
no more GLTF root nodes
maybe an offline/inspector tool to convert old babylon files to right-handed.

5 Likes
8

Yeah this one is hard. I would rather prefer invest in improving support for rightHanded mode. Because if we swtich the default mode, the breaking change will be massive (all code will break in all customers mode)

1 Like
9

What it could be great and one of my own needs, of course, would be to improve the lights managements (include light areas, increase the max number of lights available…)

3 Likes
10

API wise, I feel that the postProcessRenderPipelineManager could use a fresh coat of paint as it often involves querying render pipeline by name and not by reference for example. Also the fact that the order of post processes inside a pipeline cannot be changed without destroying the pipeline and recreating it.

Moreover, when using a PostProcessRenderPipeline, PostProcess are created with the camera argument set to null, which in turns makes the _scene parameter undefined (see here), which can create hard to debug situations. Maybe changing the signature to include explicitely the scene could help with that.

More generally, some methods/constructors have a ton of optional arguments, creating very long lines of code sometimes. Maybe using the same approach as MeshBuilder with an option object would make it cleaner.

Also most modern engine enable shadow rendering by default on all objects (in Unity and Unreal at least), whereas it has to be added manually in BabylonJS. I think the shadows should be enabled by default with the option to disable them, not the other way around.

3 Likes
11

erm, honestly, I don’t know where to start. So in no particular order, off the top of my head:

a) Scene observables. Working with observers/observables(obs) feels like looking at the abyss. I do not know how many obs my scene has, or is currently running, or inactive, or perf hungry. Its not transparent and debugging is largely trial and error. I remember when obs was first introduced, the onus was on the dev to track and manage them. But after all these yrs, I have to say that, having to manually register and remembering to remove registered funcs are a real hassle. One reason why I moved from custom materials to material plugins was not having to manage obs!

b) Assets on third party hostings. When I need to work with bjs, my day starts with firing up the PG, logging in to a third party hosting, uploading my assets to it, switching back to PG tab and start coding. What I really want is to fire up the PG, go to my assets folder, select my assets and drop into my PG and go from there! Kinda like Sandbox+PG! Wouldn’t that be cool!

c) Inspector. I’m so in love with this feature since it came out. I had a bjs gui debugging info box template back in 2015ish. Shift-delete it when the inspector came around. Largest gripe with it? Not showing shared stuff. A little icon to show a material is shared on mesh A or that skeleton is shared with mesh B etc. Why the need? So users don’t dispose the wrong stuff during development and then having to sift thru long codes to discover that a material was shared or a vector wasn’t cloned. Heck I guess, we could extend this further to mesh geo as well? Shrugs…

d) CSM. CSM is CPU driven shadow calculations. Its resource hungry and a simple mesh with a material uses more than twice the resources of the traditional method. I love it still but with webgpu unlocked, I’m looking forward to major upgrades in the lighting department. There are so many methods to choose from, gee, I don’t know which I want. This isn’t a feedback I guess, its more a wishlist for BX. A drop down menu with options for gpu based lighting/shadow in a demo scene would also be a very nice selling point.

e) Vfx. Recently, I’m working on vfx heavily for a feature in Seedborn. And I realize, we really only have barebones api in the particle system. If I need more than linear gradient control, I have to spend time coding the curves in custom functions which is where I don’t want to spend time on. vfx devs generally spend time modifying their textures back and forth, focusing efforts in visual style/look/timing etc. Coding is essential but typically the codes used are generic. Which means its better to have a dedicated vfx sandbox. Also, vfx is a key selling point for a 3D engine.

Apologies, I do have a long list of wants and wishes. But I can’t remember them all. After almost a decade, its hard not to see the most annoying stuff day in day out. I confess, I have not worked with ALL bjs features. If my feedback is incorrect, feel free to correct/ignore.

PS: I work at scale, all above thoughts are wrt scale. So, observables refers to tens/hundreds of observables, assets means tens/hundreds MB worth etc…

Sorry for posting on a weekend. =) Hope it helps.

1 Like
12

WEBGL_multi_draw

storing key frames in typed arrays

GLB export with original image and vertex types

Babylon serialized format with deduplicated texture

multi threaded rendering (for the same scene)

Baked trs animation

multi draw indirect (draft)

GPU picking

SIMD

Compute Shader rasterization

3 Likes
13

A lot of excellent ideas!! Please keep going. Also this is not a letter to Santa:) so please folks feel free to consider contributing as well:) Babylon core team for the engine is less than 5 individuals :slight_smile:

2 Likes
14

I don’t feel like a lot would required braking changes but I could be wrong. You should consider contributing :slight_smile:

1 Like
15

To clarify the goal of this post: I’m interested in exploring potential improvements to the engine that would enhance its speed and efficiency, assuming we are not limited by concerns about introducing breaking changes.

If you have any ideas that fit this criteria, I’d like to hear them. For any other suggestions that don’t hinge on making significant alterations to the existing architecture, there’s no need to wait for Babylon X; we, or the community, can start working on them immediately.

2 Likes
17

I will when I can, hope to get out of devhell sometime in q4 this year.

I gonna presume its all related to this PR: Remove WebGPUEngine dependency on Engine by deltakosh · Pull Request #14931 · BabylonJS/Babylon.js · GitHub

Need to find time to take a closer look. My first thoughts are that the current typical use of engine (using seedborn as example) is:

this.engine = new Engine(this.viewport, true);
this.scene = new Scene(this.engine);

We have the usual suspects associated that consume bandwidth, iirc, evalueActiveMeshes? picking? etc.

So in BabylonX, I would expect

this.webGPUEngine = new webGPUEngine(this.viewport, true);
this.webGPUScene = new webGPUScene(this.webGPUEngine);

or some equivalent. From user perspective, I can port over my scene from webgl to webgpu based. Downstream functions will be different but any impact is still relatively isolated, with the option to switch back anytime. The usual perf hungry funcs will need rework to gpu equivalents.

Am I on the right track here?

18

The work to extract webgpuengine is done with that PR. Meaning that webgpu is no more pulling any webgl data at all (reducing the size of that engine by a lot).

Scene API and everything will remain the same as this PR is not breaking backward compat:)

So your point stands. The only difference for now to switch to webgpu is to instantiate WebGPUengine instead of engine:)

But this is where this post enters the stage. What are we ready to change internally (inside scene, inside the core part of Babylon) to make faster or smaller if we are ok to not be backward compatible anymore?

One topic I’m breaking my head against right now is Math. It is a 250kb monolithic baby that I would love to change into something far leaner. The only way I can think of is to only keep the structure and force the users to manually import every function they need. But is it worth the pain??

Other reflections I’m having right now:

  • can we make the renderinggroup dispatch automatic? For now we are going through the list of all active meshes and we are dispatching them through the rendering groups per frame. Can we do better?
  • evaluateActiveMeshes: can we do that better ? Faster?
  • rendering pipelines and prepass needs a complete rework

And this is just the tip of the iceberg:)

Babylon X will take times for sure:)

1 Like
19

Letter to Santa:

  1. Move to a side-effect free, ES architecture that doesn’t assume a Node.js environment with a bundler. Runtimes like Deno and Bun have native TypeScript support, so it should be possible to run Babylon.js without bundling. Deno even has a “Bring Your Own Window” system for making desktop apps with WebGPU, I would like to use Babylon with that out of the box (there is an example, but it doesn’t work for me).
  2. WebGL2 backend for WebGPUEngine and node materials that generate wgsl or glsl based on the backend.
  3. Plugin system for both engine and inspector kind of like Bevy with the engine internals also implemented with these plugins. I’m pretty sure this is the reason why Bevy has a big ecosystem even though it’s a code-only game engine right now.
  4. Declarative GUI like this library for React Three Fiber but without using an external JavaScript framework like React. Using JSX/TSX and some signal library like Preact signals is a good idea though.
  5. (May not require a breaking change?) Publish the React components used to make the inspector as a library, this is useful for making apps with custom editors. Maybe publish as web components too.
3 Likes
20

ok, understood.

If user instantiate WebGPUengine(), the expectation would be that its a whole different engine specifically utilitzing the gpu. And therefore the WebGPUScene would/should be drastically different from Scene. The entire scene level code should be two very different beasts, ie, the codes that render 1 frame in the webgl Scene and codes that render 1 frame in gpu-based WebGPUScene would be very different or have little to no overlap. That would be my understanding, which is intuitive, as cpu !== gpu.

What you want (based on my understanding) is:

this.webGPUEngine = new WebGPUEngine(this.viewport, true);
this.scene = new Scene(this.webGPUEngine);

whereas my expectation is

this.webGPUEngine = new WebGPUEngine(this.viewport, true);
this.webGPUScene = new WebGPUScene(this.webGPUEngine);

WebGPUScene !== Scene, so it operates differently. Was this part of your consideration? Cos I was totally expecting WebGPUScene or some equivalent.

fwiw, across my files, most times I’m using general math imports (no idea why color is in math, was this due to historical reasons? hmm…). Impact on final bundle size isn’t significant, I can further trim if needed. Not sure about other users.

import { Vector3, Color3, Color4, Matrix } from "@babylonjs/core/Maths/math.js";
import { Vector3, Matrix, Color3, Color4, Axis, Space, Quaternion } from "@babylonjs/core/Maths/math.js";
import { Vector3, Color3, Color4, Quaternion, Axis, Space } from "@babylonjs/core/Maths/math.js";

Hope it helps.

1 Like
21

If you import say vector3 you are adding the whole library. The thing is that a lot in Babylon is importing the math library so you don’t see a difference because it was already imported