Perf on mobile

[GameMonetize]

The problemis that our shader handle light range, light attenuation, specular over alpha, we are using index where 3js does not here, etc... 

[jerome]

Yep

In other words, the scenes aren't comparable under the hood, because our standard material does much more by default than the 3js phong material. Am I right ?

(btw, as I learnt a bit 3js, I believe they have the light attenuation) 

 

Now, I'm playing the devil's advocate ...

The problem could be then : a newcomer that doesn't see nor know the differences (I sincerely can't on this specific scene) will wonder why there is such a performance difference about a so simple example ? 

 

I have no argument to answer this.

I don't even know if provinding many many parameters to make the standard material behaves lightly is really worth it ? Who will tune this ? This won't be simple ... so not "simple and powerful"

This is the 3js approach : something is provided, then you can set plenty of complex parameters to improve it.

 

Another question (mine this time, not the devil's advocate's one).

On my old laptop, I had these results :

- Marcuse's 3js scene with 1000 boxes : 55 fps

- DK's optimized bjs scene on catuhe.com with 1000 boxes : 50 fps

- current bjs ol'good PG with a sps and 1700 boxes : 60 fps (near 58 fps with 2000 boxes)

 

So if the SPS can so easily handle similar object instances whereas it uses the same underlying shader, material, rendering than any other bjs standard mesh, isn't there a lead to investigate into the way the draw calls are done or the geometries are buffered ?

I know it's a naive question.

Just wondering how to meet this challenge.

[mightymarcus]

hey marcus, thanks for this!

There is a typo: Can you please rename checkOnlyOnce by checkReadyOnlyOnce? (and can you reference directly http://www.babylonjs.com/babylon.max.js ?)

Ok, did it. Now bjs 11 fps and three.js 15 fps for me

 

It's getting better and better. I'd love to stick with Babylon, I should try to get more into it. I'm pretty new to 3D stuff at all.

 

One thing that I noticed is in the scene class when I comment out the mousemove pick test it gets some fps more. So when I dont want to be able to pick any mesh maybe it'd be good to not pick test at all.

 

        // Pointers handling

        Scene.prototype.attachControl = function () {

            var _this = this;

            this._onPointerMove = function (evt) {

                var canvas = _this._engine.getRenderingCanvas();

                _this._updatePointerPosition(evt);

                /*var pickResult = _this.pick(_this._pointerX, _this._pointerY, function (mesh) { return mesh.isPickable && mesh.isVisible && mesh.isReady(); }, false, _this.cameraToUseForPointers);

                if (pickResult.hit) {

                    _this._meshUnderPointer = pickResult.pickedMesh;

                    _this.setPointerOverMesh(pickResult.pickedMesh);

                    if (_this._meshUnderPointer.actionManager && _this._meshUnderPointer.actionManager.hasPointerTriggers) {

                        canvas.style.cursor = "pointer";

                    }

                    else {

                        canvas.style.cursor = "";

                    }

                }

                else {

                    _this.setPointerOverMesh(null);

                    canvas.style.cursor = "";

                    _this._meshUnderPointer = null;

                }*/

            };

[GameMonetize]

@Jerome: Correct. And you are right, we want to stick to "simple and powerful". But I also want to provide advanced controls for people who want them. For instance, advanced users can call material.freeze() to get more performance.

Being simple to use force us to, sometimes, have complex behaviors under the hood.

 

Regarding what you said with SPS, the problem with the test that Marcus did is that cubes in 3js do not use indexing and instead send plain buffers where bjs always use indexing. 

 

Indexing here is counterproductive because it is more efficient to send 32 vertices instead of 24 vertices and 36 indices. Obviously this changes with bigger objects where indexing becomes quickly a must have to save bandwidth

 

@marcus: you can ask the scene to avoid checking mouse states with scene.detachControl();

[jerome]

cool ... material.freeze() stays a simple thing to do for anyone 

 

Capice about indexing...we were here in a very specific case.

So such a specific challenge could then have a specific answer : 3js and bjs don't behave the same in the way they pass stuff to the GPU, so please don't try to reproduce exactly the same code from the one to the other, but use the best tool of each to reach the goal (in this very case, this might be instances or sps for bjs)  

[mightymarcus]

@Jerome: Correct. And you are right, we want to stick to "simple and powerful". But I also want to provide advanced controls for people who want them. For instance, advanced users can call material.freeze() to get more performance.

Being simple to use force us to, sometimes, have complex behaviors under the hood.

 

Regarding what you said with SPS, the problem with the test that Marcus did is that cubes in 3js do not use indexing and instead send plain buffers where bjs always use indexing. 

 

Indexing here is counterproductive because it is more efficient to send 32 vertices instead of 24 vertices and 36 indices. Obviously this changes with bigger objects where indexing becomes quickly a must have to save bandwidth

 

@marcus: you can ask the scene to avoid checking mouse states with scene.detachControl();

 

Ah, ok. Or perhaps no attachControl at all ...

 

Will try it with some more complex meshes than cubes.

[JCPalmer]

On the mouse thing, you could just not attach it in the first place, instead of detaching it afterward (oh see a reply saying that too).  I remember saying that to someone, but they said the wanted to still move the camera with keys.  Maybe optional args on attach like 'notMouse' and 'notkeyboard', but not important for me.

[mightymarcus]

Ok. I updated the uh benchmarks. Now three.js meshes has specular color too, both use indiced vertices.

 

500 Objects.

 

Three.js ~40 fps

BJs  ~36 fps.

 

Everything is all right. Thanks for the patience. I did not knew some things before.

[GameMonetize]

are you using latest 2.3 version?

[mightymarcus]

I think so.

 

http://www.babylonjs.com/babylon.max.js

 

My game-prototype runs very well now. I really don't care about some fps more or less.

 

I have a terrain mesh with 1700 vertices in the background and a bump-map and it performs good on my phone with that low-end graphics card.

 

The real problem was updating a 2D canvas every frame with fillText. So I thought it had something to do with babylonjs and made some noobish tests and tried out the HexGL game on my smartphone which is using three.js and came to wrong conclusions. I'm really satisfied now and can continue with my game. Cheers!

[jerome]

on my old laptop, the Marcuse's updated scene (uboat) runs at 40 fps now for both 3js and bjs !

exactly the same framerate :-)

[MarianG]

I have 25 fps in babylonjs scene, and 28 fps in threejs scene, but in threejs, nothing show, ....white window.

I used Chrome on ASUS tab. 

[Vousk-prod.]

I saw your commit about this param set to false by default, but I think he had not updated yet the version on the test site because still same results for me on Galaxy S4, Chrome android : BJS 17 fps average, 3JS 40 fps average.

 

EDIT : forget about this message, a stupid manipulation on my phone made me publish this post many hours after I wrote it

[mightymarcus]

Ok. I updated the uh benchmarks. Now three.js meshes has specular color too, both use indiced vertices.

 

500 Objects.

 

Three.js ~40 fps

BJs  ~36 fps.

 

Everything is all right. Thanks for the patience. I did not knew some things before.

 

Just for the record, i made a little mistake (again) ...

 

The Stats fps in the babylon scene showed more fps than it actually was.

 

Now with 200 objects the fps in the three.js scene is ~55, in the babylon scene it's ~35.

 

With 500 meshes three.js scene was 40fps, babylon.js actually not 36 but only 19 fps.

 

EDIT: Now that's strange. When I use instances instead of clones I get just 3 fps more ...

 

My guess is that BJs is using many method calls which burdens the CPU if there are many objects. The differences in fps are growing with the number of objects. Have to test this with BabylonHx, where functions can be inlined by the haxe compiler which often gives a significant performance boost if it's done right. (or are functions inlined with typescript anyway?). Unfortunately inlining for the javascript target is working not very well because it produces anonymous functions which can make it even worse than not inlining.

 

I think I'll have to do 2 versions of my game-prototype to get a more realistic insight, but this should be not much work.

[mightymarcus]

I saw your commit about this param set to false by default, but I think he had not updated yet the version on the test site because still same results for me on Galaxy S4, Chrome android : BJS 17 fps average, 3JS 40 fps average.

 

EDIT : forget about this message, a stupid manipulation on my phone made me publish this post many hours after I wrote it

 

That's the same results that I get.

[GameMonetize]

Can you share both scenes with FPS counters?

[GameMonetize]

Other interesting finding: bjs is clearly faster on my PC (by nearly 20%) using your current demos.

 

I also detected that 3js version still uses non indexed content which is fairly more efficient when vertices are simple (only position and normal here) and vertex reuse low. I will work on a feature to convert a mesh to a non indexed version on demand

[jerome]

cool !

 

[EDIT] @DK : do you mean they don't use indices at all ?

https://github.com/mrdoob/three.js/issues/6926

 

[EDIT2] : or has it to do, behind the scene, with the glDrawArrays vs the glDrawElements use ? 

[mightymarcus]

Other interesting finding: bjs is clearly faster on my PC (by nearly 20%) using your current demos.

 

I also detected that 3js version still uses non indexed content which is fairly more efficient when vertices are simple (only position and normal here) and vertex reuse low. I will work on a feature to convert a mesh to a non indexed version on demand

 

That's because I used instances for babylon, where the three.js demo doesn't share the meshes geometry. If both using clones with 5000 Meshes 3Js get 21 fps and BJs 13 on my PC.

 

But if both use instances (share same geometry and material) Bjs have 20 fps and 3Js 22 fps.

 

Hehe.

[mightymarcus]

Can you share both scenes with FPS counters?

 

I don't know why, but the babylon stats show more fps than the chrome fps counter ...

 

But I noticed that with gpu-z both demos have only like 20% gpu load and 420 Mhz GPU Core Clock (three) or 460 Mhz (babylon) from 1075 Mhz.

 

Hm... If the chrome stats are wrong babylon is faster than 3js (in that case). But it's not, firefox shows the same fps like chrome.

[GameMonetize]

@Jerome: Yep, no indices at all

 

@Marcus: can you still turn FPS on to see why this is different?

[mightymarcus]

@Jerome: Yep, no indices at all

 

@Marcus: can you still turn FPS on to see why this is different?

 

Yes, maybe you need to clear the cache.

[GameMonetize]

Here is my new version with the new mesh.convertToUnIndexedMesh():

 

http://www.catuhe.com/trash/perf.html

[GameMonetize]

@Marcus: Beware BJS version is rendered twice: There is a call to render in the assets loaded function and one outside hence two call to requestFrameAnimation  

[mightymarcus]

The first call starts the loop function. Inside the loop function it's rendered once. If that like you say then it would be in three.js the same.

 

UPDATE: You're right.

 

Oh my god ...

 

Now Bjs with instances is really faster. I'm such a fool sometimes

 

Now 3Js 22 fps

Bjs 39 fps

 

With clones, not intances

 

both 22 fps.

 

And in smartphone with less objects, let's do 500. (I'm cooking right now ...) and clones not instances:

 

Bjs 25 fps

3Js 28 fps

 

Puh ... great news.