Trying to understand the babylon paradigm...

[Zephos]

Hi all,

I am really liking Babylon.js as it has a great community and it is a powerful framework. I am pretty new to graphics programming though and not an expert in JS/TS. Since starting with Babylon, I have run into many scenarios where the most intuitive solution was not the supported way of doing things. I am trying to understand why this is - I actually want to start contributing to the project once I am more comfortable with it - but I can't seem to understand why it is built the way it is. Anyway, I have often found that my frustrations are more due to a lack of understanding than something wrong with the design... so I want to improve my understanding. I have a few questions about why babylonJS is built the way it is, and I am hoping it will reduce the frustration level I am experiencing. I appreciate any answers I can get here.

1. Why are camera controls integrated with the actual camera? This seems counter intuitive because it requires a new implementation of the camera for every different control scheme, instead of just providing easy ways to transform the camera and letting the user define their own control scheme or else use a built in control system that is not dependent on the type of camera. This would allow changing control systems on the fly (without changing view) without trying to sync camera positions, etc. (free camera controls to arc rotate, for example is very difficult without a jarring view change) If there are benefits to doing it the other way that I don't see, please tell me. 

2. Why do meshes, etc have to be put in the scene to load them? In my current project, I want to load meshes into memory so I don't have latency when I want to use them, but I don't want them in the scene immediately. After researching, the only solution seems to be adding them to a different scene, which would cause a lot of overhead seemingly, or adding them and then removing them or disabling them. All of these solutions are "tricks" so to speak and I feel like this is a common enough problem to not have to use tricks to solve it... I think it is pretty intuitive to pre-load assets, but there doesn't seem to be a supported way of doing this. It also makes it difficult to have objects just for cloning that you never actually add to the scene, etc.

Now, I am uneducated on the inner workings and design patterns that are intended to be used with babylonJS. I bet most of my confusion and frustration is due to this, and if I can gain a better understanding here I will gladly update the documentation to help fellow newcomers avoid some of these pitfalls. I have absolutely no problem with a framework that expects you to do things a certain way, as long as there is a way to do it and it's easy to learn. I think my problem may be that I don't know the proper way of using babylon, so I rely on my intuition that leads me down the wrong path.

I also get that it is an open source project. If there is no reason why things are the way they are other than "that's how it was built" then that's fine. I am just trying to understand the babylon paradigm so I can use it effectively. I know there are a ton of great helpful people here who know a lot more than me so please chime in and help me understand!

I suppose more specifically I want to know how to pre-load assets that I can then clone and add just the clones to my scene. AssetContainer seemed like the solution until I realized you still have to remove all the stuff from the scene, and can't load stuff directly to the container.

 

[JohnK]

Interesting question and from my point of view it is a bit like asking why does Picasso paint faces with both eyes on the same side of a head when they are clearly on opposite sides. Answer because he wanted to. Developing any system depends on the life experiences and views of the developer and since these are different for us all we all see things dfferently. When I first started with Babylon.js my expectations often led me down the wrong path until I learnt not why things were done in the way they were but how things were done. 

When you are learning it is too easy to look for the pieces you expect to find so you can put them together to build the system you want. However these pieces might not exist. You need to think about what it is that you want to build and what pieces are available that will allow you to build it. For example an alternative way to approach your number  2 could be to load your mesh and then use mesh.setEnabled(false) to keep it out of the way until you need it or even just mesh.isVisible = false. If you need lots of copies of the mesh then perhaps the SPS system might be a better way than cloning. 

Keep learning and there are many contributers here to help. 

[JackFalcon]

John is correct.

Also, an ah-ha moment was reading the principles in the contributing.md of the source code:

## Golden rules

**Babylon.js** is built upon 3 golden rules:

1. You cannot add code that will break backward compatibility
2. You cannot add code that will slow down the rendering process
3. You cannot add code that will make things complex to use

Cheers,

[Zephos]

30 minutes ago, JohnK said:

Interesting question and from my point of view it is a bit like asking why does Picasso paint faces with both eyes on the same side of a head when they are clearly on opposite sides. Answer because he wanted to. Developing any system depends on the life experiences and views of the developer and since these are different for us all we all see things dfferently. When I first started with Babylon.js my expectations often led me down the wrong path until I learnt not why things were done in the way they were but how things were done. 

When you are learning it is too easy to look for the pieces you expect to find so you can put them together to build the system you want. However these pieces might not exist. You need to think about what it is that you want to build and what pieces are available that will allow you to build it. For example an alternative way to approach your number  2 could be to load your mesh and then use mesh.setEnabled(false) to keep it out of the way until you need it or even just mesh.isVisible = false. If you need lots of copies of the mesh then perhaps the SPS system might be a better way than cloning. 

Keep learning and there are many contributers here to help. 

Thanks John. You make an excellent point. 

Regarding your proposed alternative, does setEnabled apply to all of a mesh's clones or can the 'master' mesh be disabled while all of its clones are enabled? And what is the difference between enabled and isVisible? Lastly, can you clarify what SPS means? Thank you.

[JohnK]

setEnabled takes the mesh out of the rendering loop and so does not consume processing time. Whereas isVisible hides the mesh but keeps it in the rendering loop. As always the best way to find out if something works is to try a simple example in the playground https://www.babylonjs-playground.com/#6W0A00

When cloning the geometry is copied but you can change materials. An alternative is createInstance this copies the geometry and the texture, so an instance cannot have its material changed.

My preference is SPS solid particle system  this takes a single mesh and allows you to group copies, as a particles, into a single mesh, so one draw call, but still allows a number of aspects to access individual particles.

[JCPalmer]

16 hours ago, Zephos said:

Thanks John. You make an excellent point. 

Regarding your proposed alternative, does setEnabled apply to all of a mesh's clones or can the 'master' mesh be disabled while all of its clones are enabled? And what is the difference between enabled and isVisible? Lastly, can you clarify what SPS means? Thank you.

As far as clones, these are just meshes sharing geometry.  Disabling one has no effect on others.  Also, there is no such thing as a MASTER clone, which means the first mesh can also be deleted with no effect on others.

In general, these "tricks" as you call them are due to people perceiving that they are operatiing on meshes.  In the GPU / reality however, the primary thing be operated on is materials which translate into a vertex / fragment shader pair.  This difference of what is really being done to how you THINK you are operating, is causing your disconnect of what should be the way "things should be".  For instance, having vertices in the CPU does not mean anything to the GPU until a material is created for them to be used as data.  This compiling of shaders / GPU programs is what causes the latency.  As @JohnK says, adding a mesh & disabling gets the shader programs compiled, so everything is ready when you want that mesh (really material) to be seen.  Not straight forward, unless you look at it from the GPU's point of view.