Disable Objects by distance to camera?

Hi there,

i am trying to find a fast way to disable objects wich are further away from the camera then x units.to optimize speed in a scene. my idea was to use the camera.isInFrustum() functionality by adding a maxZ value to the camera first.
since i only need to clip certain elements i dont want to use a global clipping plane.
but it seems that the isInFrustum() only checks left/right/top/down, not maxZ from the camera.

Is there any other fast way to remove objects wich are over a certain distance to the camera?

cheers and thanks!!


I suppose fast means without implementing more complex scene logic, is it? :wink:
Well, I used a couple of tricks recently for that.
You can cast a ray from the cam with a distance and setEnabled(false) everything that’s beyond it. And then of course, re-enable when in-reach. In order to reach your target without casting tons of rays, you can form groups of objects parented to an invisible intersect mesh that bounds the group. When the ray touches this mesh, trigger the hit fonction.

Another thing is if you are working with rooms or closed environment. Where it cannot be seen from the camera unless you enter it (i.e. open a door). In this case, you can set enable/disable all descendants of ‘room’ when opening or closing the door (or whatever else makes this area visible/invisible).
I hope this helps and gives you some ideas. Meanwhile, have a great day :sunglasses:

1 Like

Hi, thanks a lot! With fast i actually meat literally fast :wink:
my current situation is, that i am trying to render a city. this city is made of lets say 5000 meshes, in total around 2mio vertices.

there is two problems with this scene: too many drawcalls and / or too many vertices.
up to now (with less data) i merged the meshes to reduce drawcalls wich gave me kind of a good result. to further reduce the vertices, i want to disable buildings wich are out of frustum and too far away. the problem here is, that the merging (wich i now would have to do) process is kind of slow so i have to decide right now to have more drawcalls or more vertices. both are not the solution, because both slow down the scene.

i will look into your idea grouping the meshes into on invisible intersect mesh… lets see how far i can get.

if there are any other ideas, i am more than happy to hear them!!

Thanks a lot!

PS.: i have read (but cannot find it anymore) that there is some kind of an asyncMerging possibility… is this real?

I see. To be honest building large environments is not my speciality. I know of occlusion queries and LOD. Also may be use instances and thin instances where applicable. If your buildings are more then just static, consider tree shaking. In the end, I suppose the best approach is likely a combination of techniques and with a level of ‘compromise’: IE: number of meshes VS drawcalls. Note that merging meshes with multimat increase drawcalls and merging meshes with both opaque and alpha blended materials increase draw calls even further. Not much more I can say. Not really my domain.
Let me call in some people who might have more insight (or know of projects and posts dealing with this subject). Cc @Evgeni_Popov @labris

Occlusion queries could help, indeed. This video could also give you some ideas (but I don’t know if everything is implementable in the Web context):