[bug] Count Active meshes, Active indices, Draw call in debuglayer

[Dad72]

Salut,
 
Je vais faire le signalement en français pour expliquer correctement. 
 
Je constate un petit soucie sur le calcule des meshes et indices actif et draw call dans debuglayer lorsque l'on est au dessus d'un objet (genre un terrain par exemple) est que l'on oriente la camera vers le haut.
 
- quand la camera est horizontal a quelque chose prêt et ne voie plus le terrain il retire 1 meshes actif et draw call puisque la camera ne voie plus le terrain (là c’est ok)
Mais si on continue de monter la camera plus haut, 1 est rajouter au meshes actif et draw call comme si le terrain était visible de nouveau (ors qu'il ne l'est pas). et si on vas jusqu’à l'extrémité du haut (que l'on regarde le ciel au plus haut), il retire 1 de nouveau au nombre de meshes actif et draw call (il y a donc un tres large moment ou il compte tout les objets que que la camera ne voie pas si elle ce trouve au dessus d'objets.
 
cela veux dire que le terrain seras toujours calculer même quand il est pas vue par la camera et si jamais la camera est sur un personnage qui est sur la selle d'un cheval qui est sur le terrain et que l'on, oriente la camera vers le haut. 4 objets serons toujours calculer (le perso, selle, chevale et terrain).
 
J’ai reproduit cela sur le playground au plus simple (une camera sur un cube et un ciel.).
 
http://www.babylonjs-playground.com/#1RRK96#1 ( ENGLISH: orient the camera up and see number of active meshes and et draw call)
 
par contre si on n'est pas au dessus d'un objet, cela fonctionne correctement.

[Ahiru]

Yes, the same I noticed, too.

 

http://www.babylonjs-playground.com/#1SC4YB

 

I was wondering, why the FPS-Rate did not raise when being UNDER the ground, where the Spheres should not be rendered.

Wouldn't it improve Babylon a lot if all of the objects that are not seen by the camera are not rendered any more?

 

Had the same effect when playing with fog. In times of C64 and Amiga we used the distance-fog to let sprites disappear, so the FPS-rate would raise. In the example here with fog, a high dense sphere still lowers  the FPS even she is deep inside the fog and not visible any more.

[JCPalmer]

I do not speak french, so I could be wildly wrong.  There is an isInFrustum test in scene._evaluateActiveMeshes.  If out of camera ranges, will not get put on the active list for the current frame.

 

As far as meshes being blocked, you can write an after render that is customized for your scene, which can decide to call setEnabled(false) on any mesh you wish.  This is cuts off as much processing as you can get.

[Dad72]

In made, if you look in my example and you point the camera up slowly, you can see that active meshes and drawcall displays 2 early, then 1 some time and 2 again or it should stay 1 because ground/box is not visible by the camera.

 

I think Deltakosh to view this bug.

 

http://www.babylonjs-playground.com/#1RRK96%231

[GameMonetize]

definitely strange...working on it

[Dad72]

And there is the same problem as when it is below an object, and you look down.

 

I feel that the camera has eyes in the back. even when the camera is out of the sky and  turns her back, we can also see the problem.

 

Yes, it is strange. 

[GameMonetize]

Actually this is a limitation of how we compute the frustum.

 

The frustum is defined using 6 infinite planes and we consider an object is out the frustum when all points of its bounding box are behind at least one plane

 

But in this case because the plane is really close to the camera and really large, it sometimes intersects a plane even if we actually not see it

 

I have no idea how to fix it without using heavy calculation which will be counter-productive

[Dad72]

I understand. Maybe you find a solution one day if you keep this bug somewhere to keep that in mind.