Much higher CPU load than Three.js?

[BurtGummer]

I'm evaluating webgl frameworks for some projects and I've noticed a much higher CPU load for babylon.js demos than three.js demos, even ones that aren't updating anything!  Even the basic scene in the playground  is running at 40% CPU, nothing moving, in a hidden tab! (I'm not sure why that's happening, I though requestAnimationFrame was supposed to not run in background, maybe its a chromebook thing.)

I can make a few guesses as to why, maybe since babylon.js is a 'game engine' its doing a lot more in the loop, or maybe there's just something wrong with it running on my chromebook.

If everything is in fact acting normally maybe its acceptable for this higher load since a game would have the users undivided attention anyway.

Does this mean that Babylon.js would be a poor choice for things that run on the 'side', like a graphical tool or demo?

Can I trim things out of babylon.js that might be contributing to the load?

[NasimiAsl]

@BurtGummer hi and welcome 

thanks to start this post

actually some samples can't be compared each other but if you tell 2 exact sample we can notice that  and tell exact reason 

but anyway i wanna  share my experience about loading and rendering in webgl (in browser not mobile) 

4 resource available to use   GPU , CPU  , Ram (SmartArray,Js default array) ,  Storage (indexed DB)

and 3 different state   First time Load , Load ,Live Render (frame render , bone  & rig, physics,morph , Live Reflects,shadow , PostProcess )

some time we use WorkerProcesser  for load and cache in background for have more stable and fast load 

so you most compare all this stuff and notice how much heavy 2 compared scene from each others  (textures and polygon vertex count)

i am sure all engine have flexibility tools for make user wanted optimize and resource using but this is important witch have more tools and flexibility and community for support

so if we have exact samples we can find any bug and fix that 

 

*if you wanna do anything in GPU ping me i promise you have my best try for that

regards Naz.

[jerome]

Could you please show us some comparable demos ?

[GameMonetize]

Hello!

I'm not experiencing the same thing as you but here are a few pointers:

- By default Babylon.js relies on a engine.runRenderLoop which internally will use the RequestAnimationFrame (which is supposed to be called only when tab is active :))

- This way, the rendering will be executed 60 times per sec. If your scene is simple the CPU should be around 0.5 to 3% due to scene traversal mostly.

- You can at any time decide to render only when you want by NOT using the runRenderloop function but instead call manually scene.render()

- Even with the runRenderloop function we provide a boolean to stop rendering if the tab is not focused with engine.renderEvenInBackground =  false (true by default)

 

For instance here is the PG running on my computer:

[BurtGummer]

Its a little confusing since I'm using a chromebook.  The window manager and desktop manager are also chrome, or something like that.   

Comparing demos and the top two CPU threads with guessed averages as I stared at htop for about 10 seconds.  Maybe its a clue that the second chrome process in both these examples (the 18% and the 23%) have a command line switch "--type gpu-process"  and are fairly equal, but the top processes (also chrome) might be the 'window' or 'window render' process.  Note that I picked a three.js demo that appears more elaborate.

https://threejs.org/examples/#webgl_lights_pointlights

20% CPU

18% CPU

https://playground.babylonjs.com/   (basic scene in pulldown)

40% CPU

23% CPU

 

[GameMonetize]

The problem is that the playground contains the editor which is doing a lot of stuff 

can you try with this one?

https://www.babylonjs-playground.com/frame.html#PPC2HF

[BurtGummer]

Yea that editor is a hog.

It knocked about 10% off the CPU, but we're still at about 20% for Three.js and 30% for Babylon.js. 

And maybe its just a chromebook thing. ( a really ghetto chromebook too )

Looks like what I have to do now is  rewrite that babylon.js demo in three (or vice-versa) and see how they compare.

[GameMonetize]

I'm pretty sure it is related to DOM update because of the FPS

Can you try this one: https://www.babylonjs-playground.com/frame.html?noui#PPC2HF

[BurtGummer]

Yea that fixed it, thanks

But now I don't know if Three.js got an unfair advantage because the example was inside such a "simple" webpage.

I won't be making a full screen game but more of a 3d tool inside a complicated website, so I have more experimenting to do.

[Witek]

Ok, this is my scene:

and this is my processor:

97% is a GPU.
Can you explain this? 

there is just one box with standard material mesh, and 2 meshes with ground.
Whole code actually:

// ground    
const subdivisions = Math.min(width, height);
const ground = Mesh.CreateGround("ground", width, height, subdivisions, null, false);
const groundMaterial = new StandardMaterial("ground-material", null);
groundMaterial.specularColor = Color3.Black();
ground.material = groundMaterial;

const grid = ground.clone("ground-grid");
const gridMaterial = groundMaterial.clone("grid-material");
gridMaterial.diffuseColor = Color3.Gray();
gridMaterial.wireframe = true;
grid.material = gridMaterial;
ground.addChild(grid);
this.scene.addMesh(ground);

// box
const color = Color3.FromHexString("#2196F3");
const transparent = color.toColor4(0);
const mesh = MeshBuilder.CreateBox(`box`, {width, height, depth, faceColors: [color.toColor4(), transparent, transparent, transparent, transparent, transparent]});
mesh.position.y = box.dimensions.height / 2;
mesh.edgesColor = Color3.White().toColor4();
mesh.edgesWidth = 1;
mesh.enableEdgesRendering();
const containerMaterial = new StandardMaterial(`material`, null);
containerMaterial.diffuseColor = color;
containerMaterial.zOffset = -10;
containerMaterial.specularColor = Color3.Black();
    
mesh.material = containerMaterial;
mesh.addBehavior(new PointerDragBehavior({dragPlaneNormal: new Vector3(0, 1, 0)}));
this.scene.addMesh(mesh, true);

Please notice that I am using angular, but runs outside ng zone:

this code is invoked once, subscribtion added with this.addDescribtion is called also once on component destroy.
BTW: notice that I made all, except one, walls transparent, but they aren't. Why?

[Witek]

Ok, I solved the problem by reduce the number of ground's subdivision - it was in numbner of 500 as you may notice. Used grid mesh instead (much better experience btw)