It seems that I’m completely unable to occlusion cull under production settings with Windows. No matter what cell size I set (1-10) I keep getting this error:
“Error occurred in PVS computation. This is probably due to running out of memory or a problem with the graphics card. Try decreasing the near plane value or defining smaller PVS Volumes. Don’t lock the computer during PVS computation.”
It’s almost insulting on so many levels, I mean to have 4gb of Radeon HD 6950 graphics power along with a I7 extreme Hex core and 16gb DDR3 RipJaw ram, yet this still fails and blames my computer? Also, I decided to actually put this error to the test and ran the occlusion cull process on my brother’s computer, but ran into the same exact error.
My near and plane view are equal to the main camera’s setup ( 0.3-1000, nothing outlandish ), and no target volume occlusion is set, only view volume.
Here is a quick video of my map and it’s occlusion area.
I don’t think this it is asking too much of the umbra / unity to occlusion, but I may be wrong: http://www.screencast-o-matic.com/watch/cXQrc4Zjy
Although I know the percentage of getting any help on this is very low (both topic and OS choice), I figured I would ask anyways and see if anyone else finds this error and or any solutions?
I hope the umbra process will be 64bit in 3.5 because big scenes really need more Ram to calculate ( exapt if the new PVS is the super new non ram eating process we are waiting for.)
Am I the only one that finds it morally dumbfounding that they sell the engine with the promises of great results from performance optimization tools such as occlusion culling, yet are fully aware that the tool is extremely broken and will hardly work as heavily promoted?
I mean I understand it would hurt sales if they promoted it as “Occlusion culling is a new feature of Unity3d that renders great performance optimization to your games levels, but is 32bit, so having 4GB or 16GB or anything more than 1.98GB is totally meaningless and may results in many PVS errors or glitches.”, but at least they would be honest to their paying customers.
So, do I dare ask how much more additional costs everyone will have to pay for the upgrade to 3.5 (when it finally comes out) so we can finally use this tool that we originally paid for under all our current versions?
I’m really sorry if this seems rude or harsh, I just can’t believe the awesome people who make this wonderful engine that I enjoy using, are do such a deceiving thing to their clients.
Interestingly for us it was able to get it to work after we setup the areas well enough.
In your case the problem is that the environment seems pretty complex yet you don’t heavily limit the areas where the cam can be in which at the time kills it cause the umbra process has a horrible data and memory management.
Its a problem that UT has been aware sicne the beta and it was always said that the umbra guys and ut work on it but ‘that it isn’t that easy’. I’m unsure if thats the truth as not even “hard like hell” justifies no 16+ months until it lands after the first large rampage over it being broken all the way, but so far I’ve been able to make it work with good setups.
There is only one general rule of thumbs: NEVER EVER MARK THE TERRAIN AS STATIC, EVEN LESS IF YOU PUT TREES AND DETAIL OBJECTS ON IT
Once you follow that you will commonly see it fly or work at least, with only very few exceptions (those are basically large outdoor scenes where you can skip umbra and where it won’t change either as pvs does not stream at all beyond the scene loaded with LoadLevel)
I am still a little curious about this “miniature” Umbra thing in general… So it allows you to define some static occluders and then automatically also have procedural objects being culled just that no procedural objects can themself be occluders? In that case it would even be acceptable for me… But I still hope that Unity 4 will bring a more dynamic solution, but maybe that hope stays a dream… I still don’t get it why it is so hard to add a PC switch saying “dynamic occlusion culling” and keep this static stuff for mobile only… Maybe Umbra itself was the reason… Maybe they didn’t want to sell their premium stuff for a one time fee…
who knows. For unity 3 it simply made no sense to have full dynamic pvs cause occlusion queries (the base to do any dynamic occlusion at all) are only supported on 3 of unitys soon 11 platforms, which could be barely less corss platformform, while the static PVS works on all 11 of 11 platforms
In my setup, the surrounding buildings are just 4 - 8 faces each (tops and back sides have been removed) and the collection of the surrounding buildings in a whole are made up of 3 large textures to cut down on draw calls.
Our occlusion area surrounds our parking garage (the only area the player is allowed to venture), so I don’t understand the statement of “environment seems pretty complex yet you don’t heavily limit the areas where the cam can be”.
We have no terrain in our level, just streets and building plots (only ones that are visible from all areas of the parking garage). I don’t know if we can make our scene be any less complex than this… it has been optimized to the point of no more optimization room left (except for a properly working occlusion culling).
I’m not interested in trying to occlusion cull our surrounding low poly prop buildings (frustum will take care of that), I’m just interested in getting the parking garage’s multilevel occlusion-ed (the only part of the level the player/cam can move around in.)
The number of polygons and textures unhappily have no impact on occlusion at all. Its the spatial seperation of space the objects generate that is causing it. With objects I mean the pure mesh (OC does not respect transparency, never mark anything with a transparent, cutout or nature shader as static!)
As for the statement: Right, you limit the view area to the parking garage. But you must keep in mind that this is the area from which the occlusion rays will be shot, not the area to which they are confined. So the whole world outside until an occluder is hit will be searched too by the PVS generation. There is no way to limit the pvs generation to the parking garage without having the rest outside being permanentely occlude (ok there is one, see at bottom). As such it none the less impacts it.
But if its really that simple and if it is as limited in “view through tunnels” geometrically as the screenshot implies it should be no problem out there. Question is if the parking garage generates such a large amount of data. Whats your explicit settings and do you really need to generate OC for a range of 1000 units if the parking garage is what, 100-200 units in length and the rest is of no OC relevance anyway? I personally doubt it, it only raises your calculation time by a factor of 4-10
Solution to have the parking garage occluded but the rest outside not (not tested but should work)
Create a box that inward oriented and around the parking garage, mark it static - this will be the Occlusion Culling limiter basically
Calc OC
Setup the parking garage to be in 1 layer and the rest outside to be in a 2nd layer
Setup a second camera that you do NOT tag as Main Cemra, make this camera only see the layer outside. Set your main camera to not see this layer outside
