The docs don’t seem to say, except that they’re optional:
Is it not going to work if I don’t pass a scene in? If I load assets, which create scenes, is this going to unexpectedly add my nodes to some random scene if I don’t pass a scene in?
Here’s what it does
https://playground.babylonjs.com/#NCL89C
If isPure is false, it will not push to the root transformNodes of the scene.
I’m guessing this means it will not render anything (none of its child content will render)?
What happens if we load a scene, and then make a transform node without specifying a scene? Will the new transform node be placed into the loaded scene instead of the main scene?
If we make a hierarchy of nodes, do we need to always provide the same scene to every node?
node’s scene is scene || EngineStore.LastCreatedScene
and transform’s scene is super(node's scene) === Nullable<Scene>
That is, if the transform parameter has a scene, it will be attributed to that scene.
- maybe you not create scene it will be attributed to that null.
- If you create a scene but the parameter doesn’t have a scene, it will still be attributed to the last applicable scene.
If you have a hierarchy of nodes that you only want to know about in the same scene, you should put the scene accordingly and isPure should also be true.
If you don’t want to see it in the hierarchy, you can set isPure to false.
So confusing. I don’t get why this even works.
Or why this works:
It seems to all work the same. What is the difference? Why do all objects in Babylon need a scene? And why do they need a scene if they seem to work regardless?
In Three.js it is really simple:
const mesh = new Mesh(geometry, material)
const node = new Object3D()
node.add(mesh)
// that's all.
with no need to have special parameters and pass scenes everywhere.
In Babylon we need to pass scenes everywhere (or else it default to the “last scene”), yet the above examples all work with or without passing a scene, or even creating a new scene so that we have a new “last scene”.
So confused. 
1 Like
We don’t fully understand the logic of three js, so we don’t know the full relationship to its code, but we know that the
const scene = new THREE.Scene()
…
const mesh = new Mesh(geometry, material)
scene.add(mesh)
…
function render() {
…
renderer.render(scene, camera);
…
}
check this basic structure, maybe expect node to copy the mesh’s scene.
https://threejs.org/docs/#api/en/core/Object3D.parent
As for why you need a scene in that structure, I can’t answer that.
This becomes a question about the overall structure of the engine as to why we made it this way, which is too difficult for me to answer (the shields next to the names are direct development staff).
The only helpful thing I can say is
engine contains the scene and scene contains other things
I can only assume that these rules are in place because it’s reasonable to assume that creation and destruction are largely managed in such a structure.
in babylon
I also had a hard time transitioning from unity to the world of babylon. 
1 Like
Try Three.js or PlayCanvas. You’ll find they are both way simpler to develop with. The feature comparison may be different, but the development experience in the other two is way simpler.
Yes, I know what you mean, and in general, in terms of ease of use, three and playcanvas are definitely simpler. I also realize that there is a relative lack of developers and interested users because of that.
but.
As a result, I have to make the implementation I want myself (which means I can make it with any engine for now, even if it is prohibitively expensive) and
I’m sure that once I get good at it, the simplicity of the concept won’t make a difference.
There are obviously advantages and disadvantages, but I don’t think the simplicity you’re talking about is a problem for developers at a certain level.
I apologize in advance if this sounds like an attack on you. It’s just an opinion based on what I’ve experienced.
the difficulty is less between Babylon the three OR play canvases than it is between Unity and Unreal Engine. so you should be able to narrow it down pretty quickly.
2 Likes
re “optional”: Default parameters - JavaScript | MDN
re “scene”: https://github.com/BabylonJS/Babylon.js/blob/e94100614e23affdd641bad1f4604b6589e777ab/packages/dev/core/src/node.ts#L351 | where Node is parent class of TransformNode (see previous link)
re https://playground.babylonjs.com/#NCL89C#4 / https://playground.babylonjs.com/#NCL89C#5: Why is it important to you whether your TF nodes are in “scene.transformNodes”?
re “Why do all objects in Babylon need a scene?” This is a wrong statement. The objects in question give the option to provide a scene.
re 3js: Just posting this for comparison purposes.
// https://threejs.org/docs/#manual/en/introduction/Creating-a-scene
import * as THREE from 'three';
const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera( 75, window.innerWidth / window.innerHeight, 0.1, 1000 );
const renderer = new THREE.WebGLRenderer();
renderer.setSize( window.innerWidth, window.innerHeight );
document.body.appendChild( renderer.domElement );
const geometry = new THREE.BoxGeometry( 1, 1, 1 );
const material = new THREE.MeshBasicMaterial( { color: 0x00ff00 } );
const cube = new THREE.Mesh( geometry, material );
scene.add( cube );
camera.position.z = 5;
function animate() {
requestAnimationFrame( animate );
cube.rotation.x += 0.01;
cube.rotation.y += 0.01;
renderer.render( scene, camera );
}
animate();
1 Like
That’s from a pure dev’s perspective, is it? Because all I can say here is that ‘I’ - as a simple designer and PM - would never have made it as far doing things myself with code in a real-time 3D engine if it wasn’t for BJS. Simple enough, I have been piloting 3D projects for 20+ years - with Unity, Unreal, Cry, three.js… and I never went to the point where I would have even thought of starting to code (rather complex) interactions myself. This until I discovered BJS. So ‘Yes’, the approach is different but things like the doc, the pg, the community make the learning just so much more accessible and enjoyable (my opinion only). And where the ‘versatility’ of the engine may add a level of complexity in steps that true dev (like I believe Yourself) consider as ‘a base’, an immutable base… at later stages, taking new approaches, trying new methods, overall making new ‘attempts’ (as I call’em), BJS starts to really stand out towards what you can (potentially) do and what you will never be able to do. Now I’m not gonna lie: The level of additional ‘efforts’ of course needs to be related towards your resources and the importance of reaching your goal using what some could call an ‘un-conventional’ approach/method.
And finally, honestly, ‘Yes’ there are still gaps and a lack of ‘normalization’ in BJS. But everyone here does his best to catch-up and things are moving fast. Very fast considering the resources available. Three.js is how many employees?…
2 Likes
I know JavaScript well, but it isn’t obvious why the parameters are optional (the API docs don’t really say). Why give a node a scene? And why not give a node a scene?
They seem to be required: if you don’t provide it yourself, then Babylon goes and gets the LastCreatedScene, so no matter what, every node is apparently required to have a scene (just not always provided by the constructor).
But even so, I tried previous examples (above), including creating a new scene before making new TransformNodes without specifying scenes for them, which supposedly means they should get the LastCreatedScene that I made, yet the examples work the same, so I don’t get what the difference is. Either that, or there’s really a difference and it has caused some sort of weird memory leak where nodes are used in one scene but state is stored for them in the second scene. Its confusing, and means I’d have to really dig deep into the code to understand if I’m shooting myself in the foot or not.
Yes indeed, I’m writing code with Babylon, and was referring to the software developer experience.
PlayCanvas has a UI out of the box, just log in and jump right in to the full editor (more like Unity/Unreal than Babylon it seems to me), and f.e. see the docs on the visual node-based material editor. Besides having this, PlayCanvas code is clean.
As an example, in Three.js and PlayCanvas it has turned out to be way easier than in Babylon to load an asset into a particular node in a scene graph. I’m surprised at how difficult it is to do some simple things in Babylon. I find the code to be a bit disorganized compared even to JS libs in general, while Three.js is very well organized compared to JS libs of any kind (not just 3D libs).
These are just my opinions and thoughts. No offense intended to anyone. I hope contributors might see this and have a desire to simplify Babylon, as competition benefits everyone (even the non-Babylon users).
I understand. As I said, not a dev, but I can still hear you on that.
That’s likely (at least partly) correct. I believe it must be partly due to the way BJS is building-up, for a larger part than others, through the Community and also for one of its goal which is to keep with backwards compatibility (eventually at the cost of added complexity/disorganization, as you say).
Sure. I always give just my opinion. It’s the only opinion I can give 
…and things can evolve only when sharing and confronting ideas and opinions, isn’t it so? No offense taken at all. At least, not by me.
Absolutely. And as @bghgary said in your other post, your skills would certainly be warmly welcomed if you wanted to help us with your contribution towards ‘simplification’. I can already assure you that ‘simplicity’ is definetely part of the philosophy and something we (I believe the Team and Community) are willing to build on.
Of course, as I said, my opinion only and meanwhile, have a great day 
1 Like
Babylon’s community is known for its high levels of friendliness and welcomeness. That’s definitely worth a lot. 
1 Like