I’m not going to say it’s crap, nor endorse your call that it is… however it is true that it needs work.
Frankly, when taken in context with Beast, Tree Creator and the hundreds of other things Unity 3 does, I’m not surprised some features work better than others.
So, I call on all of us to help the gals and guys at Unity make Umbra a better tool than it is. Cause once it’s working right it will really enhance our projects.
It should be utilizing more cores, because right now it’s pretty slow.
I’ve also encountered the cache problem with Umbra. I’m rebaking my scene (was baked with a previous version), and will see if that fixes the problem. If not, I’ll go yell at them.
That behavior is a long standing problem with Unity and MP.
On osx it uses all, cause osx handles the stuff.
On windows, UT would need to implement a corresponding parallel execution handling which was neither with U2 nor now with U3 present.
on beast it shocks me a bit though cause that should out of the box run in parallel but I’ve so far only used it for iphone stuff, not done much with u3 on the desktop so far
The bake finished at 2 AM last night. 10 hour render for a small level. Pfff.
Anyway, building to the desktop even after a rebake still presents the objects disappearing problem. So I’m gonna go yell at UT. Make sure to send a bug report, I actually WANT Umbra to work on final release!
This especially means placing the view areas so umbra does not calculate pvs for the whole world and not using unreasonable camera ranges like near range < 1
Keep in mind, its an oct tree datastructure, so going from 1 to 0.1 far range raises the amount of nodes at worst by a factor of over 256, including the corresponding time required to calculate it
Umbra baked the scene successfully, it just took a long time. The build of my game however screws up the bake data and objects are popping in and out.
Umbra calculated the whole world, but the level itself isn’t all that big. It’s the scene from my windmill town game. The occlusion area in the bootcamp demo is only a little smaller than my level.
Are you kidding? Using a near clip plane of 1 or higher is absurd. Just try it on the fps controller and you’ll see how odd it is. Normal near clip ranges are 0.1-0.5, which is actually decent enough.
Far clip is at 1K. Which is the default. Far clip at 1 or 0.1 basically means you can’t see your hands in front of your face. I’m guessing I missed something. Are you talking about the view cell size in the bake settings? I have that set to 0.1 which is actually more than the cell size that is shown in the manual. But according to the manual, view cell size is a tradeoff between accuracy and storage size, not speed. Or is a drop in speed a given?
Look, Umbra is great (when it works), it just takes a long time. If Umbra were faster, it would be appreciated a lot more.
So you didn’t put in view areas.
In that case it will normally take eternities, right, thats cause it will calculate the whole area
I can’t comment on the degree of OC thats used in the bootcamp.
But what I know is that it heavily bases on the good old “distance culling” script from the warehouse example for iphone 1.x (the whole decoration etc in the level), this is also the root behind some interesting anomalies it has in some places
1 and higher absurd? Sure if you want to bake for XX hours for a normal level, then naturally 0.1 is reasonable. Question is also what you have as far range cause if that one is 1000 or higher, then you will need a long time and would reconsider if you need millions of nodes just for the sake of it cause the size of the occlusion data will raise quite some too (U3 gives you the size of it actually)
Don’t know what you mean with the normal fps controller thing. Occlusion culling especially on the near range has little to no impact visually at all because you normally have the camera within a collision volume and that distance you have there from cam node to collider is what you should use for the near, not the cam setting.
And yupp, 1000 is the default but that does not mean that it is optimal for your case.
And yes smaller view cell size means also longer times to calculate because more cells means also more distinct points to calculate from.
Generally you can keep a simple relationship in mind: More data means that someone has to generate this more data and the more computional power it requires to calculate the data the longer you will wait.
Umbra is fast, if you think its slow you don’t do any iphone development (iphone 1.x occlusion system and its calculation time)
But Umbra can’t compensate for unreasonable setups where a total overkill amount of data are meant to be calculated.
Also I would assume that it might use GFX Queries to calculate the OC (I at least hope) and if that would be the case, the performance of the gpu would have a significant impact too. But only UT and users with Intel GMA 950 and older can verify that
So why don’t you load up the supplied bootcamp demo, clear the umbra cache and rebake, post back how long it takes.
*should only take a day or two
I Think we can assume they know how to setup a scene correctly with umbra right?
Bake times are unreasonably SLOW
Somebody needs to recode it so it’s multi-threaded.
Did they buy the cheap version or something of umbra?
watch this video:
What do you see at :25 secs
“NO VISIBILITY PRE-PROCESSING”
But the real problem right now is if you do wait for umbra to bake, it does not work correctly in builds. That is a bug, and it makes umbra useless in it’s current state. Slow baking is just an annoyance.
I’ve loaded the Bootcamp demo to check out fully what the differences are between it and my level.
The level makes use of several (quite large) occlusion areas. However, the Umbra areas when put together are much bigger than my level! What’s more interesting is that all the areas are at the “extremely high” settings. View cell size is 1 so I might change that to see if it improves speed (at a loss of accuracy), and near clip, far clip and bake quality are set to 0.1, 1000 and production. Just like mine.
Considering the size of all the occlusion areas and the fact that they are at extremely high, I’m actually afraid to find out how long it will take (I suspect it will take several days at these settings!). Dreamora, Umbra is slow. And rebaking the bootcamp level will take an eternity that I don’t want to spend.
Right now, I at least want UT to fix the Umbra build problems.
Umbra takes long time to calculate, but umbra isn’t slow.
Freeform PVS offline calculation just takes its time.
That being said its very well possible that umbra offline processing isn’t meant to calculate such detailed data but less detailed ones, because Umbra technically has GFXOcclusionQuery too from what I’ve been told by a programmer that worked with it, and when you use that in realtime there is no need for high detailed offline data commonly.
But that query based calculation could be used for generation too so if its not used I hope it will be used (not some funny offloading to threads because the graphics chip, even if only a 9600GT, will blast nearly any cpu you can have aside of the money tree intel extrem i7. If you give it a real gpu, the cpu will looks like some toy from a decade ago …)
I just tried to rebake the bootcamp level, and just as it was finishing (after 14 hours) umbra crashed with a VS runtime error. Has anyone else seen this? I’m not sure I really want to try it again, as it does tie up my computer somewhat.
I think what my issue with the bake time/speed is related to progress update. With the progress bar there is no way to tell if it’s actually doing anything. Mine has been baking for over 24hrs and now when I check in Task Manager, both the CPU and Mem useage are not changing (and haven’t been for more than 3 hrs), and the progress bar has not moved. NO way for me to know if it has silently frozen or crashed… after this much time invested in baking, it would be nice to know if I should cancel this process or not.
Since my laptop has 8 cores it would be nice if this was MT’ed and finished a bit quicker. Alternately even a numeric display of % complete (down to two decimal places) would be nice so I can see if it has frozen or not.
(iphone 1.x occlusion system and its calculation time)