Meshes with opacity map not properly layered/performance issues

[Convergence]

I discovered babylon.js last week, and its very good mostly Lets me finally take a crack at game design, since full environments like Unity are too daunting for me.

 

I started playing around with it, and one of the issues I encountered was that imported meshes with an opacity map are not displayed correctly in my scene, the meshes behind 'bleed through'.

I unfortunately cannot setup my scene in the playground since it loads .babylon meshes and is enveloped by php/mysql already, but I have a screenshot:

 

As you can see, I circled two areas where the bushes in the background bleed through the bush in the foreground. Also a bit to the right more foliage is bleeding through, which I didn't circle.

Oddly enough the grass, which obviously also uses an opacity map also doesn't suffer from this. But the grass is just a Plane, not an imported mesh.

 

[Convergence]

I have another question.. How are the statistics supposed to be interpreted?  When i point my camera downwards in the above scene I get decent to good FPS (30+), however when I point my camera upwards towards the forest canopy, the fps drops quite a bit. The tree meshes are really simple (3 cylinders for branches  and 10 planes for leaves), textures no larger than 512/512. However I can't seem to get more than about 20 FPS, which seems a bit stranger considering the number of indices/meshes/draw calls are less. Anything I'm missing? 

 

The only thing that I can think of is that the faces for the leaves are quite large, and large polygons take a lot more time to draw?

 

[Dad72]

you try to use "Octree" to optimize your scene. this could increase your fps.

 

To the first question, I think Deltakosh can help

 

Pretty scene also... 

[Convergence]

Thanks for the suggestion

 

Do you mean to use Octrees for selecting which meshes will be displayed? Hmm I don't think its mesh selection that is really the problem; with only the grass/building visible and the trees invisible, the FPS shoots up to 40+, and the trees number just 50. Most of which are in front of the camera anyway, so would need to be rendered..

[NasimiAsl]

maybe you must make a shader and use discard for hide leafs i think alpha is very big progress for webgl.

[Dad72]

Try use octree on your the scene you can try and see what that the result, it gives very good results on my scenes.

For trees, used the "instances"  to optimize.

[GameMonetize]

Hello your first problem is due to OpacityMap which generates mesh that does not write in depth buffer. For foliage or grass you should move your alpha in the diffuseMap and set hasAlpha = true like in this demo:

http://www.babylonjs-playground.com/?4

 

For your performance question: you can see that your potential FPS (only rendering) in around 145 when pointing up. So this is not related to babylon.js rendering engine. Do you have complex tasks running around? (in your own JS code)

 

In the meantime I suggest you to use the profiler of your browser to identify the bottleneck

[Convergence]

Thanks for the answers, they solved the problem

 

Changing to diffuseMap with alpha channel helped both problems coincidentally. No more alpha bleed and increased FPS. So separete .opacityTextures are indeed much more expensive for the GPU, apparently.

[GameMonetize]

Sounds weird but drivers are something behaving strangely

[Convergence]

Hmm, after trying to narrow it down, (because the FPS is better, but still not great), I found the Tree Instances demo at the http://babylonjs.com/ site to be very similar and having similar performance problems. (I can't link it because for some reason the individual demos don't have their own URLs), but this one:

 

In that demo, which is fairly simple, if you look down, the FPS is fine (up to 60), but when looking straight ahead having a bunch of trees in view, the FPS drops dramatically also. Since the renderloop in that demo is really simple, it can't be some scripting every frame.

 

 

 

Any thoughts?

[fenomas]

Any thoughts?

 

I think that's meant to be a heavy demo, isn't it? It's intentionally drawing lots and lots of trees, so naturally rendering takes longer when looking forward. Perhaps the debug info could make it clearer what's eating the performance though.

[Convergence]

I think that's meant to be a heavy demo, isn't it? It's intentionally drawing lots and lots of trees, so naturally rendering takes longer when looking forward. Perhaps the debug info could make it clearer what's eating the performance though.

 

Hmmm, well, even if you disable the ground mesh in that demo in the debug layer (which reduces the #draw calls to a mere 2!), the FPS is still mediocre for me. Also, the scene has way less indices/verts/mats/textures/draw calls than some other demos, IE. the Hill Valley demo - which has great FPS (50-60) on my laptop.  

 

The disparity between reported potential FPS and real FPS is just very big in the tree demo, and I wonder why . It couldn't be scripting in the render loop, because the render loop is near-empty code-wise.

[Ahiru]

Can't answer the FPS-drop question (though I hope you'll find the answer, because it's important for my project, too)

 

But I can help you with one thing:

 

Hmm, after trying to narrow it down, (because the FPS is better, but still not great), I found the Tree Instances demo at the http://babylonjs.com/ site to be very similar and having similar performance problems. (I can't link it because for some reason the individual demos don't have their own URLs)

 

http://www.babylonjs.com/?INSTANCES

 

You have to provide the name of the example behind it.

[fenomas]

Hmmm, well, even if you disable the ground mesh in that demo in the debug layer (which reduces the #draw calls to a mere 2!), the FPS is still mediocre for me. Also, the scene has way less indices/verts/mats/textures/draw calls than some other demos, IE. the Hill Valley demo - which has great FPS (50-60) on my laptop.  

 

The disparity between reported potential FPS and real FPS is just very big in the tree demo, and I wonder why . It couldn't be scripting in the render loop, because the render loop is near-empty code-wise.

 

Rendering different kinds of stuff has different kinds of costs. E.g. in the trees demo if you disable "Diffuse" you should see the performance shoot up, even though the # of draw calls, indices, etc. are the same.

 

Also, I think the "potential FPS" is misleading you a bit - all BJS is doing there is telling you the inverse of how long it took to execute its render() call. Effectively, that's the FPS you'd be getting if the render call was dominating performance. If the bottleneck is elsewhere (like the GPU), I don't think that number tells you much.

[Convergence]

Rendering different kinds of stuff has different kinds of costs. E.g. in the trees demo if you disable "Diffuse" you should see the performance shoot up, even though the # of draw calls, indices, etc. are the same.

 

Also, I think the "potential FPS" is misleading you a bit - all BJS is doing there is telling you the inverse of how long it took to execute its render() call. Effectively, that's the FPS you'd be getting if the render call was dominating performance. If the bottleneck is elsewhere (like the GPU), I don't think that number tells you much.

Good to know about the potential FPS I didn't find an explanation so far what it should be representing.

 

However in the quest to narrow down the bottleneck, that begs the question why this fairly simple scene with only some instanced low-poly trees is already bogging down the GPU; if you take any game from the last decade that tries to pass off as realistic, its bound to be more complex than this scene (there are a multitude of games with more complex/realistic forestscapes) and I don't remember this laptop having such FPS problems with it.

 

I, too, saw that disabling the Diffuse channel makes the FPS go up, but as a solution its not really viable, of course

[Dad72]

On my computer this scene is at 60FPS all the time. I think it is a problem of processor, graphics card or ram. a problem of the computer and therefore no Babylon.

Even your scene you submit runs well for me.

 

IT must be said that I turn with a good graphics card 'GTX560 TI 1G GDDR5',  processor: I5, 6 Go of ram

[Convergence]

On my computer this scene is at 60FPS all the time. I think it is a problem of processor, graphics card or ram. a problem of the computer and therefore no Babylon.

Even your scene you submit runs well for me.

 

IT must be said that I turn with a good graphics card 'GTX560 TI 1G GDDR5',  processor: I5, 6 Go of ram

 

Thank you for the response. Yes, I understand different setups will yield different FPS, but I'm still struggling to understand why forests are apparently so taxing for my laptop. BABYLON will be ran on a big variety of setups anyway.

 

Take these two demos as comparison both run one after the other:

 

The rather complex Hill Valley demo, with lots of meshes/mats etc and even multiple reflective surfaces: http://babylonjs.com/?HILLVALLEY

 

Instanced trees, i disabled the ground to reduce draw calls to 2: http://babylonjs.com/?INSTANCES

 

Looking at the #draw calls/verts/indices/mats the forest  should get much better FPS, but instead its getting much worse FPS. Perhaps you will get 60 FPS for both, but I want to find out why my laptop suffers on the forest scene.

 

PS. to even things out more - disabling collisions and fog on the forest scene helps a little bit, FPS increases to 24-26, still about half of the Hill Valley scene.

[GameMonetize]

Are you using big textures? This may break GPU cache and thus reduce drastically the FPS.

[Convergence]

512x512 max.. is that considered big? The ground heightmap is 1024.

[GameMonetize]

To identify the bottleneck, you should turn off every channel (in the texture channel block) using the debug layer and see which one is impacting your FPS

 

Then if this is not relevant, do the same with options bucket

[jerome]

just a lead : freeze the world matrix of all your immobile meshes also

[Convergence]

Thank for the help so far.

 

I think I isolated the problem more: 

 

In this demo: http://www.babylonjs-playground.com/#UB5PM#2 which is basically a plane cloned a thousand times (thousand polys sounds like a lot, but should be peanuts for a gfx card) with an alpha texture (representing the forest performance problem), I get the same bad FPS. (Increase numClones until your FPS starts to drop below acceptable)

 

Then, just decreasing the size of the plane (from 8 to 1) fixes the FPS issue for me.  Anyone else has the same experience or is it just my machine?

 

disabling hasAlpha also kind of fixes the issue. Also interesting is that changing the rotation axis from x to z (with the original size of 8) drops the FPS to 2, lol. Of course non of these changes affect draw calls, textures, mesh count, etc.

[GameMonetize]

Hello I have no issue on my machine but this seems to highlight an issue with alpha testing which is pixel dependant. So your issue seems to come from your gfx card here

 

If you turn diffuse off, does the problem disappear?

[Ahiru]

Get the same issue (Radeon HD 2600 Pro) - Size: 8 Instances: 50 - already down to 15 FPS (but the potential jump between 300 - 500 FPS)

 

Switching diffuse of or even textures of does not help - changing to wireframe does immediately jump to 48-56 FPS steady.

[Convergence]

Hello I have no issue on my machine but this seems to highlight an issue with alpha testing which is pixel dependant. So your issue seems to come from your gfx card here

 

If you turn diffuse off, does the problem disappear?

 

Thanks, I will just assume it is my crappy gfx card  Can't wait to be working on a decent desktop system again.

 

Turning off diffuse, the FPS increases to 30, still a while away from the desired 60.