Jump to content

Perf on mobile


GameMonetize
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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;
                }*/
            };
Link to comment
Share on other sites

@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();

Link to comment
Share on other sites

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)  

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 :P

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :P

 

That's the same results that I get.

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...