If I script something to render, can it be frustrum culled?

"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.