Thank you for the video, it is clear and informative.
I have just one question.
Is it possible to let occlusion culling work on top of each other?
I mean i. e., can i make a skyscraper game for the iphone with it?
Or a dungeon with some caves over the others?
As I understand though, if your scene was just a fairly empty open area then this would be pretty useless, correct? Is there anyway you can restrict rotation and not just position?
If there are no occluding objects in the scene then yes, occlusion culling is useless.
I’m not sure what you mean about restricting position or rotation, but if you mean restricting the rotation of the Camera then there are many ways to accomplish this.
What’s the overhead of the occlusion culling script? For example, would it be worth adding if it occludes just a couple of fairly simple meshes in an attempt to wring out the last drops of performance?
I imagine there’d be a point at which it becomes ‘profitable’ to use?
I can’t imagine there would be much overhead at all. All it has to do is check whether your camera is inside a box (cheap) and then not draw nodes that are on that box’s cull list.
If it saves a couple of draw calls then it’s probably worth it.
It’s always worth seeing if occlusion culling can improve performance in a scene where it would make sense. The only draw back is the file size increase of having to store the occlusion data… unfortunately I don’t have any hard stats to say how much of an increase it causes in general.
Thanks very much. Well-done video tutorials like this are the most effective method of learning, for me.
I’m still unclear on a couple of things, however:
We’re not supposed to have the view areas intersect with walls, but you used view areas that go underneath stairs in the demo. What exactly is the rationale for all of this?
What exactly happens when multiple cameras are involved? Is it the same thing, in terms of automation of enablement, as having the main camera be in multiple cells at once? Or are there any extra things we can do in terms of camera/layer-specific occlusion?
I have a rather unrelated question: what modeling/rendering package is being used to bake the textures/lightmaps for the scene in this video as well as the warehouse occlusion culling demo?
depends on the setup.
You normally would have one per room / corridor to cover the largest visually enclosed area but still one that is somewhere locally restricted.
If its outdoor then it will be much harder to setup occlusion culling efficientely or might even be impossible.
@Jessy: In which way a performance hit? Unless you have a multiplayer splitscreen there shouldn’t be a case where it would have an impact.
As for the quote: Thats for the enclosing statics that form the rooms / the world, where it makes sense, as you must not have unenclosed areas where the camera can move and where its view is not blocked by static objects which would disable the occlusion culling. But that does not prevent you from having static geometry that intersects actually if it is fully within the room like the stairs, which are part of the room and fully within the same.
I guess the documentation wouldn’t suffer from clarification there though, as users new to the topic might missinterpret that as “I need many many subareas to not intersect with my static level interior”
I don’t want to divulge the details yet, because I haven’t seen what I’m doing done before (which is funny to me, considering it works great even on the iPhone…it would just run better if occlusion culling worked for multiple cameras), and I’m scared that someone who works faster than I do will make something cooler than I can, before my game is ready for the Unite contest!
See, I think I understand what you’re talking about, in terms of making sure all places that the camera can go are enclosed in a View Area, but I don’t understand why we’re being told not to go outside the boundaries. I would think that it’s a little inefficient, but it would be faster in terms of setup to not worry too much about “going outside the lines”.