To all,
As you saw with my reply to @Evgeni_Popov , I will begin work on creating a large separate .js file that we can pull bits and pieces from as needed in each scene’s dedicated shader. This will hopefully greatly reduce the shader size for each different demo/scene that you want to create.
Speaking of this modular approach, @PichouPichou had suggested earlier that we could modularize some of the .js setup code so that the whole Babylon.js library would not have to be included in every small demo/scene, and that we could just pull in relevant parts of the Babylon.js library that we needed in order to set up the almost non-existent main Babylon scene (all the heavy lifting and geometry processing will be done in the path tracing shader library parts).
Although I think that this would be a neat idea, I’m afraid I am not the one to tackle this job, as I have never used typescript, and I am still somewhat of a newbie to Babylon.js and its inner workings, so far as modules are concerned. In the past, even with three.js (the library I am much more knowledgeable in), I have naively just included the whole three.min.js file in my HTML script tags, without ever trying to load in modules in the more modern style of front-end web programming.
That being said, if anyone feels comfortable enough with Babylon to take my current .js setup/init part and somehow modularize it, please have at it! The good news is that, as I previously mentioned, the main usual Babylon scene is almost non-existent at this stage, with just a couple of effect wrappers and a camera - that’s it, literally! Now in the future when we want objects in the scene to be able to be transformed, (position, rotation, scale), like the 2 boxes in the famous Cornell Box scene, I will use Babylon.js’ built-in Object3D(at least that’s what it is called in three.js, but I’m sure there is an equivalent), to use as a transform place holder, kind of like a 3d editor gizmo, to feed into the path tracer, which will take care of transforming all the objects for us automatically by first transforming the intersection rays by the objects’ inverse matrices (ray tracing’s greatest secret trick of all time!). So I will eventually need a way to init and specify different Babylon transform matrices place holders for every different object that is not a simple sphere.
In the near future, I need to load in a texture, an RGBABlueNoise texture to be precise (to use in smoothing out random noise), as well as any material textures (like the wood surfaces in my billiard table demo). But I’m sure that will be a trivial matter with Babylon, as it is with Three.
Much farther down the line, when we want to start tracing glTF triangular models, I will have to pull in Babylon’s glTF loader, which could be another module as needed. I will also have to pull in my custom .js BVH acceleration structure builder, that sorts the complete arbitrary list of the glTFs triangles and creates a compact data texture containing an efficient bounding box heirarchy for the GPU to chew on when tracing the scene. But we can cross that bridge later.
So in summary, the amount of Babylon.js setup code for each main scene (as long as it doesn’t contain glTF models) is pretty much complete and what you see now on the repo. The other details come when we want to have simple object transforms and when we want to load in triangular models eventually.
better render quality while at the same time (not!) eating into the overall FPS of the user-facing scene?
