Babylon X: Discussion topic

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.

Working compute shaders, raytracing.

What do you mean by working compute shaders? We already support compute shaders:

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…

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;
    // getters & setters for _x/_y/_z, dirty mechanism, etc

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

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

I will run some tests and get back to you!

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:


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

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?)

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

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

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.