Babylon X: Discussion topic

Feature requests
22

Maybe rework the layer mask. Don’t use the 32 bits of number for the layer mask, but use a nicer API.
At the moment the default mask is 0x0FFFFFFF so there a only 4 bits left for hiding from default cameras. My problem here is that i have to change the mask of every mesh and camera to use more than the 4 bits left.
For example the camera and mesh could use a Set<SomeKindOfIdentifierType>. The Set# isDisjointFrom() method can do the intersection checks and should be fast.

23

Working compute shaders, raytracing.

24

What do you mean by working compute shaders? We already support compute shaders:
https://doc.babylonjs.com/features/featuresDeepDive/materials/shaders/computeShader

25

oh yeah, you are right. If you really do shrink it, perhaps, I’d just code what I needed instead of importing funcs. But that’s me…

26

I’ve theorized about creating a proper treeshaking algorithm in the past… but the work involved would be insane :smile:
I’m still hoping for it to be developed, these days maybe even AI assisted, imagine it traverses all your code from a starting point, simular to how a browser does and then excludes all pieces of code and functions etc that are never used :exploding_head:

cooking it down;
say you import only the Vector3 math library, and only ever access the x/y/z values in your code

quick and dirty, the exported result would be something like

class Vector3 {
    constructor( x = 0, y = 0, z = 0){
        this._x = x;
        this._y = y;
        this._z = z;
        this._isDirty;
    }
    // getters & setters for _x/_y/_z, dirty mechanism, etc
}
27

Well, my letter to Santa is this short list:

1.) Better, working GI like Voxel GI. The (cascaded) voxelization could be calculated as a worker, by chunks (groups of meshes), lighting by voxel tracing on GPU. A lot of examples exist now, for example:

2.) A good tutorial/series that shows how to make different types of games, from Blender and animated assets to rendering, setting up lighting, shadows, effects, particles, physics and game logic, also with some performance tips like instancing and batching.

That’s it. That is my list. :smiley:
BABYLON is already awesome! Thanks for all the years of work!

About the topic, I think there could be an LTS version that is backwards compatible, and a ‘New API’ that is the “Bleeding Edge”, that works for new projects. Like Vue 2 and 3, they are totally different API, fully rewritten, but there is no stress, You can still use Vue 2, but you start new projects with Vue 3.

1 Like
28

I guess I have outdated knowledge. Vaguely remember something was not ready or working.

I will run some tests and get back to you!

29

Refactoring the core async handling code like loaders to Promises, and impl the compatible layer of callback-based api on promise-based api, so no more async uncaught errors like this:

2 Likes
30

Also I think the side-effects needed for es6 imports with tree shaking feels very hacky. I would love if we could just import the stuff needed without needing to find the exact side effect in the doc or the code base in Babylon X

31

Taking Vector3 as an example, why do we need it to be a class? Surely it can be a type, simplifying compilation. I’m just thinking how many bundled exports that could be omitted/the value of doing this (probably minimal?)

32

Can you tell me more about your idea?
What would that mean in reality?

33

Some thoughts:

  1. If there are many class instances in memory, could we possibly improve performance by replacing with objects or functions. I haven’t benchmarked a typical BJS app so would need to, to back this up.

  2. Importing types or interfaces can avoid the need of tree shaking, as apposed to importing compiled functions. I haven’t thought this through yet but if primitive Tuples exist or if a transpiler could convert a property like this… position.x > position[0]

This is an interesting proposal:

I may be talking silly and jumping the gun, but I like challenging things

1 Like
34

Does this mean something like gl-matrix?
Also, Records and Tuples meant to be immutable, which in case of 3d rendering, can hurt gc performance. If arrays or pointers does not meet the requirement, have a look at proposal-structs , which is sealed but not immutable.

35

As a breaking change, I think gpu particle subemitter would be the most beneficial.

36

Some areas we’ve seen that could use improvement in terms of perf.

On the high level, anything that could speed up the time to that first paint would be amazing. That first paint being in a state where the scene is fully intractable thereafter (so not using a trick like a proxy image).

  • Speed up loading of .envs (we’ve noticed these can be slow at times)
  • Utilizing shader caching or find a way to split up PBRMaterial somehow to speed up shader compile times.
  • Explore geometry virtualization techniques and built easy to use tools around them (voxels, splatting,UE Nanite style virtualized geometry etc)

** Note: Im sure some of the above would only be possible via webGPU.

Developer experience related enhancements: (sorry, can move to a different thread if this is off topic)

  • Performance and debugging deepdive video on BJS Chronicles. Yes there are some docs on this but a in-depth discussion on performance considerations and debugging tools would be great. Discussing caveats to watch out for etc. Lots to unwrap here but just more education about performance would be good. There is some stuff out there but could use more.
  • More advanced shader tutorials using Material Plugins and working with raw shader code (not NME). Anything with examples or boilerplate code to work from is always handy. Almost feel like monthly ‘tech-art’ style vlogging on advanced effects would be good.
  • More indepth documentation on how the render pipeline works eg: when certain things occur, the order in which they occur, the architecture of the system as a whole (such as PostProcess pipeline). Supporting visuals, sample code, vlogs and videos would be welcome.

IMO, performance isnt always about optimizing code, a lot of times there are gaps in knowlege that lead to bad performance and therefore educating the developer to help them have a firm graspof the architecture is key.

1 Like
37

This could also make it possible for pre thin instance culling.

2 Likes