- Home /
If I script something to render, can it be frustrum culled?
I was wondering, since I'm not entirely sure how Unity's frustrum culling works, if I tell an object I need it to render, when it is out of camera view, will it still technically be unrendered? Sounds weird, but I ask for good reason..
I'm not sure if frustrum automatically turns off render components, or if they just aren't rendered simply because there is nothing to render.
oh, and to tack on a similar question, do you happen to know if frustrum is going by the position of the pivot(where ever the move tool shows up) or where the actual mesh is?
It can't go by the pivot, or else objects would blink in and out of existence when they were near the edge of the screen. It uses the bounds.
Answer by Fattie · Oct 14, 2013 at 08:36 AM
"if I tell an object I need it to render, when it is out of camera view, will it still technically be unrendered"
I don't know what "technically" means! but that's correct, it will not be rendered, when out of the frustrum, if you are using frustrum culling. even if you "tell it to" render it
i believe it does not really "turn off" renderer components. it just, err, doesn't render them in it's list you know?
i would imagine that if you furthermore "manually" literally turned off the render component, that would be an additional (but very likely only small) saving.
In answer to your final question: I'm pretty sure now in 2013 Unity uses the "AABB" axis-aligned bounding box, to determine if the object is "in" the frustrum. The center, or pivot, is not used in any way.
Note that there is sometimes confusion about the AABB. it's not the bounding box as a human would think of it. it's the let's say "wasteful" or "flat" bounding box.
I've noticed this causes some confusion w/ questions on here, so perhaps ensure you get the idea of an "AABB".
I'm guessing the question in your head is, "If I 'manually' cull it by turning off the object if the center is totally out of view (because you know that in your particular paradigm, that is good enough), is that any faster than just letting Unity do it using the AABB?"
I think the general answer to this question tends to be "just let Unity do it." After all it's super-fast to cull based on the AABB, it just looks at the 8 points (and I believe some sick cases).
However another general answer: culling tends to be really situation specific. Imagine a game with a view of a field 10km on a side and you see (say) about 1x1 km at any time in the camera. In your scene for some reason you have let's say 2000 objects each of the scale of a meter.
In contrast imagine the same scene and frustrum size, but you only have 20 objects (space ships!) each on the order of 2km long.
it is a hugely different situation.
So it's a really tricky one. I'm often doing little simple tests back and fore to test "just let Unity do it" versus "make an effort to do it yourself". So it's a big issue. i would say the broad general answer is, the culling in a modern game engine is awfully good almost all of the time; but be aware it's one of these annoying "situation specific" things.
(indeed, so many issues in video games are like that, because, the very paradigm of video games varies hugely, tremendously. You'll often deal with a client who swings wildly between wanting in their head a totally 3D mecanim-driven like game and a totally flat 2d puzzle game. To a civilian they're both "computer games about chickens" but of course the engineer is wholly different. Similarly like in my example of many-small versus a few-large objects to worry about culling, the problems involved are hugely different in each case. Don't even mention are these things moving, what other processing is going on, etc etc.)
Finally - a big thing is always culling your ground surface. So your first problem is writing software to cut up the large field in to small chunks. But then you immediately have the question, what size chunk is best. When you first sit down to tackle the problem you think "holy crap, I have to cut up this mesh in to chunks automatically." But then that is actually just the easier problem! You have to make a system to use during development that tries that with different size chunks (perhaps on different hardware) and then figures out which one runs fastest in practice during gameplay. So it's a real pain really.
wow thanks for this! I was actually trying to be meticulous with a occlusion culling system, by first checking if the objects will be rendered anyway, before adding them to an array to be casted and things. And since this isn't the most efficient, I thought, it would be better to render a few extra things that frustum might take care of, than to have terrible popping. Theres more to it but.. I won't bore you haha. I was also wondering about that too though; weather it would be better to do frustrum myself or not.
Answer by Eric5h5 · Oct 15, 2013 at 04:48 AM
Frustum culling goes through all the active objects with renderers, and if the bounds are in the camera frustum, then they are rendered. Otherwise, not.
Your answer
Follow this Question
Related Questions
Set renderable objects on camera without Layers 2 Answers
Render group of objects in front? 0 Answers
Camera frustums + custom field of view 2 Answers
Render White Pixels as Transparent 2 Answers
Shuriken won't render off camera bounds 0 Answers