Are OnBecameVisible and OnBecameInvisible named poorly?

I'm running some tests, and it seems to me that these functions don't take into account occlusion by geometry. That is, they're behaving more like "OnEnteredCameraFrustum" and "OnExitedCameraFrustum". They do at least take culling masks into account. Is that a more accurate description of what they really do?

I mean, I guess it's asking too much of Unity to know if you're using any sort of transparency in the shaders that lay between the renderer and any camera, eh?

I still haven't gotten a chance to work much with occlusion culling, either. I'm thinking maybe occlusion culling does not have the ability to take transparency into account either. Is that accurate?

 

They are named correctly because there is no occlusion at all (with the exception of Unity iPhone, where it works correctly too by triggering when the object becomes visible to the cam basing on correctly setup occlusion)

Unity has only Frustum Culling, anything that enters it becomes visible, anything that leaves it becomes invisible.
And visible means its beeing rendered, independent of if you see it at all or not.

 

They may be named correctly to the computer, but they're not named correctly to me. I don't see the stuff with my eyes, so it's not visible. If something leaves the frustum, and I could not see it anyway, that's not becoming "invisible".

 

For you yes, but not for Unity and you program for Unity, not for your head and/or eyes ^^

Unity makes no difference between the two cases, because it isn't invisible to the camera even if behind something. Its visible to the camera at any time independent if you can see it or not with your current material setups and thats what the callback is about, "became it (in)visible to the camera" or more precisely "did the renderer become (in)visible to the camera"

It actually really does that, checking visibility for cams, not frustum culling. this can be seen on the iphone when you use the occlusion culling capabilities and setup the scene correctly so it works.

 

No, this is something I've brought up before. For whatever reasons, some people love to think like this. That philosophy is completely the opposite of how I feel about software and computers. Computers and software work for me, not vice versa. And I use Unity, because for the most part, I feel that it is designed with this good human engineering in mind.

These functions do have poor names, and their documentation does not help with understanding.

 

The computer works for you, right.
But the code you write works for Unity so Unity can work for you. As a programmer you are a teacher to a virtual environment to let it use the learned stuff correctly for the goofs 40cm in front of the screen ^^

The naming is logical and do what it says, its just that the expectations from the users are not on the same level as the technical level Unity on the desktop offers at the moment as it has no occlusion culling.
So I agree that the documentation requires a few clear lines to make clear that it happens on view frustum base only.

Once Occlusion Culling in, it will work as you already expect it (see Unity iPhone) and thus does its job without requiring any change to the code at all.
But at the time, the only occluders on Unity Desktop are the 6 planes of the view frustum.