Perf on mobile

[GameMonetize]

Can you also use the very latest version from http://www.babylonjs.com/babylon.max.js ? I did some tiny updates

 

Your benchmark was really helpful

[jerome]

I'll test all this too as soon as I get back my old laptop 

[GameMonetize]

and please call mesh.convertToUnIndexedMesh() as well on root obejct

[GameMonetize]

I wrote a doc about all these updates I did recently to help performance:

http://doc.babylonjs.com/tutorials/Optimizing_your_scene

 

Please feel free to complete it or fix it:

https://github.com/BabylonJS/Documentation/blob/master/content/tutorials/03_Advanced/Optimizing_your_scene.md

[mightymarcus]

and please call mesh.convertToUnIndexedMesh() as well on root obejct

 

Ok, but this didn't change the framerate.

 

Can I see what parts of the code you've changed? Because I want to update the BabylonHx port if the author is too busy.

 

Preferably in the typescript code.

 

UPDATE: Got it on github.

[GameMonetize]

DId you update the two pages to reflect the changes? I would like to keep investigating

[mightymarcus]

this I don't understand, young Jedi.

[jerome]

Ok, I understand better the differences between 3js and bjs on this topic : 3js doesn't use indices. So I guess they duplicate some vertices from a geometry before passing it to the GPU.

This could explain why they have less light artifact on surface edges as they could appear : http://www.html5gamedevs.com/topic/17040-the-mystery-of-computenormals/?hl=mystery

In the other side, our computeNormals() method should be far more faster (less data to iterate on, direct access with the indices) and can be easily used to dynamically morph shapes.

 

@DK :

1 ) does convertToUnIndexedMesh() add some vertices in the positions array, a bit like convertToFlatShadded() does ?

2) I just read the nex doc "Optimizing your scene" what is really great.

 

Usually, a lambda BJS user has no idea about the geometry of the mesh he is using, so when would you suggest him to convert a mesh to unindexed ? 

And when not to do it ?

 

Maybe the user could just test if he feels some lack of performance. This is not simple because he may not have every kind of devices to test.

[Vousk-prod.]

 

Usually, a lambda BJS user has no idea about the geometry of the mesh he is using, so when would you suggest him to convert a mesh to unindexed ? 

And when not to do it ?

 

Maybe the user could just test if he feels some lack of performance. This is not simple because he may not have every kind of devices to test.

 

That's right. And also in real prod, scenes contains tons of meshes, would be a tedious process to check performance gain for a user who don't understand the concept, which one to convert, which one to keep ?...

 

It's the same for the shader optimisation section in fact. What is an "immutable" material ?

[GameMonetize]

@Jerome: does convertToUnIndexedMesh() add some vertices in the positions array, a bit like convertToFlatShadded() does ? Yes this is the process, flatten the indices into geometry buffers

 

@Vousk: the question is almost impossible to answer because it depends on GPU processing power. I would say that most of the time using indices is the best option (hence this is the default bjs behavior)

 

AN immutable material is a material frozen, locked. You cannot change a single property.

[GameMonetize]

Can you guys check again the fps on both tests?

[jessepmason]

I am confused to which links we are comparing?

 

this oneee??

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

 

andd???

[prvi_treti]

Not sure if you'd like to hear mobile performance on a Lumia 920 which is

 

5 FPS for babylon at worldsnews.org , 6 FPS for 3js and stable 2 FPS for catuhe.com one

[mightymarcus]

Not sure if you'd like to hear mobile performance on a Lumia 920 which is

 

5 FPS for babylon at worldsnews.org , 6 FPS for 3js and stable 2 FPS for catuhe.com one

 

If the mobile browser doesn't support webgl it's rendered by the cpu ...

[Dad72]

If the browser does not support webGL the scene just is not rendered.

[jerome]

@DK :

Something I don't really get ...

When Markus used instances instead of standard boxes, he got a big improvement, but this improvement wasn't really noticeable when he switched to UnIndexedMesh, according to the previous posts.

 

On my side, on my old laptop, when I used the SPS versus standard boxes, I got a huge improvement as expected because it's one draw call instead of 1000. It could even manage almost 2000 boxes at 60 fps 

If I used UnIndexedMesh boxes instead the standard boxes, there was still an improvement but not that big : bjs was then just at the same speed than 3js... around 50 fps for 1000 boxes/instances on my old laptop. This was important, because bjs, for thuis very scene, multiplied its speed by two on my machine and reached the 3js perf, but it was still lower than the SPS. 

 

The SPS is an indexed mesh. What I mean is that there are as many vertices and indices in the SPS with 1000 boxes than in 1000 individual boxes, only the number of draw calls differs.

 

So, I'm wondering if the indexed/unindexed stuff was the only reason about the initial performance difference ? 

Or is there another lead to dig in ?

[mightymarcus]

@DK :

Something I don't really get ...

When Markus used instances instead of standard boxes, he got a big improvement, but this improvement wasn't really noticeable when he switched to UnIndexedMesh, according to the previous posts.

 

On my side, on my old laptop, when I used the SPS versus standard boxes, I got a huge improvement as expected because it's one draw call instead of 1000. It could even manage almost 2000 boxes at 60 fps 

If I used UnIndexedMesh boxes instead the standard boxes, there was still an improvement but not that big : bjs was then just at the same speed than 3js... around 50 fps for 1000 boxes/instances on my old laptop. This was important, because bjs, for thuis very scene, multiplied its speed by two on my machine and reached the 3js perf, but it was still lower than the SPS. 

 

The SPS is an indexed mesh. What I mean is that there are as many vertices and indices in the SPS with 1000 boxes than in 1000 individual boxes, only the number of draw calls differs.

 

So, I'm wondering if the indexed/unindexed stuff was the only reason about the initial performance difference ? 

Or is there another lead to dig in ?

 

The initial performance difference reason was that the 3Js demo didn't use specular color. And material.freeze() gave some fps more.

[jerome]

ok,

But regarding the perfs on my own old laptop, the gain was 100% for the initial bjs demo by adding material.freeze() and UnindexedMesh.

This bjs demo reached then the same perfs than 3js.

 

If I use a SPS (so one mesh instead 1000) with no other optimization (material or indexes), the gain overtakes widely the 3js perfs from the initial specifications.

 

I understand that the material freezing and the no-index method give some improvement for this very scene, but I notice that a not optimized mesh (single draw call) gives more gain. That's why I'm wondering if the index vs array, or material check vs no-check, is the only lead to dig in to get still better perfs.