I was trying to bake very rough preview for my terrain. 2k2k, cell size 300, preview quality, med resolution. After few minutes umbra crashes.
I was baking such setup many times before without problems, this scene is different only by presence of city in one part of that terrain. So probably this is the reason, but why does it keep crashing? It allocates only cca 500MB of memory.
Attempt 2, 200250*50, cell size 10 (occlusion for city). Crash.
So what is this tool good for, if it crashes on first more complicated scene? Isnt this tool meant for more compicated scenes? It is nice, that I can bake occlusion for empty terrain, but nobody needs occlusion for empty terrain. And I cant add city after baking terrain occlusion, if will not work. I hope, this will be fixed soon, because in current state umbra is useless.
Unity works well for small projects, but bigger projects you have, there is more and more troubles, especially crashing.
Anybody experienced similar problems?.
How did you do it? Did you use a single occlusion object across everything, or smaller ones of various density depending on the locations (which I would imagine might work better).
Umbra certainly isn’t useless and does work fine, but like everything, it can be pushed beyond the limits of the PC it’s running on and break.
Also in most cases a terrain doesn’t really require occlusion, or make the best use of it. It’s really better for more enclosed spaces, while other methods are better for open area’s, such as lots of LOD levels and billboarding/distance fading.
I made one VERY rough arrea for terrain (cell size 300!). It worked without any problem, until I placed city in on of the map corners (I tuned settings with one box substituing city just for tests). It makes sense to use occlusion, because city has few millions of triangels and most of the time is hidden behind mountains (I am using LOD too). Crash.
In second case I made small occlusion arrea just for city, again very rough, cell size 10. Preview. Crash.
Of course that umbra is not useless, but current implementation IS. On light projects no problems (few hundred thousand of triangels), once you are doing some bigger city (which is IMHO the PRIME usage), you are not even able to bake simple preview. Yes, city from boxes works perfectly, when I change for real models, then CRASH.
I understand that most people here are hobbists with very simple scenes and models, but my studio is aiming much higher, we are trying to achive as much visual quality as it gets. This is reason, why we bought pro version, because umbra (or similar technology) is absolute must for modern game with higher visual quality.
If I have for some reason insufficient HW (which I doubt), it is proffesional not to crash application, but write message like “you have not enough graphic memory, you will need at least …”. Crashing without even showing reason is amateurism of WORST case. If there are some scene requirements, I expect manual/help, where are detailed information what can be done and what not. If you have more then 1m polygons, you should do this…Dont do this…Again, NOTHING. And this is case of almost everything (for example new water).
No manuals, no descriptions of proper usage, no description of limits, nothing. And dont tell me, that write down few paragraphs of text is big problem for somebody, who is implementing such system. It is not. It is only fault of management, that does not insist and ensure, that such documentation exists and is easily available. We are not oracles, to be able to instantly guess everything.
Thats why we are requesting 64bit editor - beast - umbra
please check the feedback system to support the move as well if you didn’t do so far.
I did it of course 
On the other side application shouldnt crash from low system/available memory. If application crashes, it means that there are bugs in code (memory leaks in case of C, or if you are extensively working with memory, garbage collector is not fast enough to free memory and application crashes (.net, especially when multithreading), so must design your sollution well and do serious testing. It is common mistake of modern unexperienced .net programmers, that they dont have to care about memory. They dont, until they are doing something what requires lot of system resources). 64bit version will only mask such problem, but according to my experience, it will not help much once the code is mess. If you have low memory, application can be slow but NEVER crash. Crash mean bad code.
I of course agree, that in 2011, when each desktop can easily have 16GB of memory is 64bit a must, especially for such high resource consuming tool. If have no problem to buy 128GB ram 12-core workstation, if it means higher speed and thus productivity. It is silly to occupy one licence (seat) and station just for umbra baking.