I’ve followed the video and set up occlusion culling view areas, set all the rooms to static, etc.
I’ve generated the occlusion and switched to occlusion display.
And - nothing. See screenshots below. Given that this is a very simple scene, you would assume that the far areas would disappear from view. But they don’t. In fact, occlusion doesn’t hide a single game object.
What am I doing wrong? I must be missing something.
Edit: Though you can’t see them due to backface culling, the scene is entirely enclosed, i.e. there are ceilings and walls around every corridor.
Yes, they are all part of one .jas (Cheetah 3D) file, but individual meshes. See screenshot of the model hierarchy attached.
Funny thing is: If I do at least Preview Build (instead of just preview), I can get the columns and the wall torches to disappear. But not the rooms themselves.
I’m wondering if this is because the rooms have no outside-facing polygons or something?
I haven’t gotten into anything about occlusion culling so I won’t have anything but a guess.
Are those green boxes defining regions of geometry, then the camera can omit any geometry inside a green box?
If that is the case then perhaps you have to make the green boxes larger to encompass the room. If the green box is perfectly on the edge of the room then the room may not be considered to be inside of the green box (floating point), and wouldn’t be occluded.
Nope, tried that and it changes nothing. Also, the docs and video say the view areas have to cover the regions the camera can move into, not the geometry. I also have a demo from another thread that clearly shows that objects not in any view area are correctly occluded.
More experiments. I (at this time) believe that Unity does not consider the outside walls of the room you are currently in as blocking the view.
Look at the attached screen shot. The large block to the left does correctly occlude the view towards the room on the far left (if I remove the block, the room is not culled!).
However, it should be culled itself, always. Since the geometry of the map is 100% closed, there is no way the player would ever see this block. Funny thing: The block does occasionally get culled out. As I move the camrea around, it plops in and out. I’ve not been able to find out what makes it so.
Sound a lot like slightly missaligned block thats causing this.
The occlusion area from what I remember needs to end in / behind the wall, if you stop it in front of the wall there will not be an existing occluder in the area you defined and it will break the occlusion with that area.
There should be a thread about a very simple corridor based setup where this and more things were discovered on the behavior of the occlusion and its requirements.
I’ve run a few experiments with an empty, new scene.
I can confirm that the static meshes do not need to be inside any View Area. The View Areas are only relevant for the camera, nothing else. You can duplicate this: Create a number of cubes. Put one(!) View Area only immediately around the camera itself. Calculate occlusion. You will notice occluded cubes disappearing, even if they don’t even touch the View Area.
So I ran another experiment. My tunnels are exactly 2.0 by 2.0 so I changed my View Areas to 1.99 by 1.99 and a cell size of 2. Thus I made sure that the tunnel walls are outside the view area. And - bingo - occlusion is happening.
So, as I understand it now, the occlusion calculations will ignore anything that is inside the View Area (or maybe just the cell?). Makes sense, because the player could theoretically move around/behind it without leaving the View Area (or cell).
This does, however, also mean that for most setups you absolutely need overlaps because the space you need to leave at the walls means they don’t meet at intersections. But that’s manageable.
First, make sure that your View Areas do not touch the walls. I reduced their width and height to 1.99 each in my 2.0x2.0 tunnels. At the same time, make sure you leave no gaps where the View Areas meet. I did that by slightly enlarging their length (so instead of 6.0 for example, I used 6.2).
Two, I added a few “view blockers” - the huge blocks you see in the screenshot. This is due to the View Areas always being cubes, while my stair down is angled. Which led to the problem of the part outside the stairs being able to “see” the whole level from atop, thus no occlusion at all. The View Blockers solve that, as you can see. I marked them as Editor Only so they’ll not be exported. Since occlusion data is generated in the build and stored, I figure (but haven’t yet verified!) that this gives me the proper occlusion data without any additional game objects or tris or draw calls.
In fact, I quite like the idea of “editor only view blockers”. That might solve a lot of occlusion problems. Now if I can find a way to have them calculated without actually obscuring my edit view, that would be perfect.
Yes, the reason the walls were not disappearing in the occlusion culling calculation is because the Viewing Areas were touching/overlapping the walls. Therefore in the calculation the walls could be seen from every cell.
Check out how the occlusion is set up for the warehouse demo:
Ah so it was exactly vice versa, must be inside, not outside
Sorry about that, was unsure which side it is thus the reference to the old and very informative thread on the topic.
No offense, but you say that a lot, and it doesn’t provide answers to several of my occlusion culling questions. The demo has been quite helpful to me, but it really needs some documentation to tell us why it was set up like it was. Having to guess about why things were done is a waste of time, and can lead to inaccurate beliefs.
That video you made about it is definitely a great help too, however. But still, incomplete.
What is the video missing that you would like to have included? What else about the Occlusion Culling system needs to be explained? I’m genuinely asking because we definitely do want to make it more understandable and easier to use.
The documentation/video doesn’t explain how occlusion culling works. Some questions that are left up to testing + inference are:
Does occlusion culling have any concept of front/backfaces?
We’ve been told that occlusion culling is a GPU process. Do shaders have anything to do with occlusion culling? Alpha testing shaders are the most obvious ones to question, I think, because with those, some pixels don’t get written to the depth buffer, and some do. But anything “transparent” is questionable without a better explanation.
The documentation mentions “[disabling] rendering of objects that are not currently seen by the camera”. What camera? What happens when multiple cameras are involved?
The documentation says to “create cells large enough that there aren’t too many, but small enough that some of them can share the same occlusion data”. It also says that it will “make more sense after we generate occlusion”, but I haven’t found that to be true. I understand needing small cells, to account for various viewing angles through doorways and such, but I don’t understand “too many”. There is certainly a time penalty for generating occlusion with more cells, but what I care about is what kind of impact each cell has on the game (memory, etc.). Finally, the docs say, “This requires a bit of trial and error”, but that needs clarification. Is the “trial” just decreasing the size of the cells until you’re pleased?
What is the difference between “Preview, Build Preview, and Build Release” modes? The documentation gives guidelines for when each mode should be used, but knowing what is not computed will help to give a better idea of what we need to do with occlusion setup (because we can make predictions about what the better generation will bring), instead of trying a more time-intensive mode and not getting good results.
Occlusion Visualization Settings is a mystery. This script is attached to a game object called “Visualization”, but that game object isn’t mentioned in the documentation or video. Also, the script is in the Edit menu, but isn’t attached to a game object, which is unlike all the other scripts I’ve seen. The help button there just takes you to the MonoBehaviour page. Even though I feel comfortable with most of the rest of Unity’s classes and documentation, I don’t know what any of the properties mean.
Finally, while trying to watch the video again, I noticed another problem that is unrelated to content: It won’t play in Safari, Firefox, or Camino. I didn’t have a scroll bar in Firefox either. Also, I hate watching tutorial videos at 1x speed. You’re a very good speaker, but I haven’t heard anybody yet that I didn’t want to speed up to at least 1.75x.Please just let us download the video. I can’t imagine there are many people who will download it, especially over a length of time, and it’s not as huge a file as many other videos on the site.
And I genuinely appreciate what you have done. I have no problem at all with what’s already there. It’s great; it’s just not enough.
I agree there. The warehouse demo is very useful, but to understand some basic concepts, the very simple example I downloaded from another thread was more helpful.
A simple demo scene with 5-10 objects and 2-3 View Areas would probably a great help.
Thanks Jessy for the list of things that need better documentation. I just assigned that list as a bug to myself so I don’t forget to do this after the holidays
I don’t believe you’ll find it because the Umbra occlusion culling system has been incorporated into Unity since then, and the Unity 3 documentation isn’t done yet.
