Occlusion still with some problems, it seems...

Just checked a solution and I see without any doubt that a wall that is BEHIND the camera is being rendered.
So not only it is not occluded, but it's out of the FOV of the camera and it's still being taken into account!
Very strange. I understand that occlusion solution is not something easy to do, but things like this are really strange!

Screenshots attached

 

Nobody agrees?

 

Hi, I checked oclusion and did work for me in an scene where previusly did crash. To see the oclusion you shold be in thevisualizatin tab of the oclusion plugin, it is one of the tabs available when you load the plugin. Still a bit slow.

 

I started to bake OC for our complex scene (hundreds of objects). It automatically offered me OC for whole terrain tile, positioning was OK, so I said OK boys, you seem to be quite sure with new implementation, so I kept default settings and lets bake. Here are rusults :

a) it is 64bit process (great)
b) it uses all cpu cores (great)
c) it is manytimes faster (great)
d) it crashed on cca 97% on out of memory bug - Run out of memory in processTile() (FAIL!)

I was carefully watching memory alocation during whole process and it was growing like 4MB per second (6MB up, 2MB down), when it reached 4,2GB it crashed. It looks like typical memory leak behaviour. I have 16GB of memory.
This is classical case of not testing on some real production data/heavy projects. You should fire all your betatesters (whole 1000), it seems like nobody there has something more complex. You want to be part of beta? OK, you should have at least 3000 materials, 2000 unique meshes, 10GB+project and sent us pictures of your scenes (and check, if it looks at least like 2007 game). With such criteria you would have 50x-100x less betatesters, but quality would be totally different. And it will be even better managable.

Anyway bug report sent.

 

I did it. You can see in the screenshots that I am in visualization mode.
The camera FOV is visible and you can easily spot that a wall that's BEHIND the camera is being rendered.
I know how to use the tool

 

Agree. I don't have such large projects so I don't have these problems, but can you spot the problem in the screens I posted?

 

I have a very very big project with hundreds of objects and it works fine for me. New OC is very fast and works better. Your problem is interesting...

 

Probably not complex enough to crash. Test rule use very simple. If production TOP on top HW is for example 10k drawcalls (without OC) and 4m poly, I prepare 50k drawcalls and 20m poly scene to do testing. With this kind of rule you can eliminate almost any memory leaks/performance bugs. I was using it in past for various SW and it ALWAYS paid out.

 

50k drawcalls is very high for a game. I have very big level (city) and 24k-40k drawcalls without OC, but I have optimized all my materials textures. Each material causes a drawcall. Before, I had more than 50k drawcalls.

 

Sure it is. Read again what I wrote. I was speaking about designing extreme test case for fast bug finding. You should always test on cases far heavier than production, or you will never find majority of bugs.
And this is exactly happening Unity. I found memory leak after first run of new Umbra. This shouldnt be happening.

 

Demostenes if you have no idea what you talk of you should stop talking like you have a freaking plan really. you are no beta tester and with your attitude you hopefully do never become one either as you are loud, unprecise and are losing competency with all your grumpiness. You should focus on what you want to say and do it in a focused way so its taken serious again cause we both know that you have valid points so for the hell of it, use them professionally.
Do you want to be the next hippo? Cause thats where your level of focus and expertise is heading towards.


1. The beta testers can't be fired as we are neither payed nor do we have any form of benefits
2. I reported it already for my customers on 3.0, waited 20 months for 3.5 betas and I reported the bugs again on the 3.5 betas as OC is a constant thing I check for my customers, the ongoing projects I'm on widely rely on it finally working as we had to do massive trade offs and cuts cause OC can't bake much more than dummy, quake and web projects.
But unluckily its up to UT and the decided amount of dev resources to fix the bug or not fix it and finally get Unity Studios involved in it with some serious scenes, cause beta testers can't do much more about it than normal users do, namely report them again and again. (UT should do what other big engine devs do too, 'eat their dogs food' and have a AA+ project ongoing that uses their engine so it gets direct inhouse feedback from their fellow work friends, thats 10 times more effective than us starting to throw virtual molotov cocktails or meeting with fork and torch to walk to their HQ )
You can't do anything against a PVS builder for which umbra finally should revoke the right to use their name on the PR material until it works for scenes for which it was meant for right from the start (complex stuff where you need to occlude something, not scenes where the delta is in the 20% range) due to its state 20 months after release in its second full rewrite as its hurting their reputation seriously if it takes UT 20 months to bring a new version that works basically as bad as before if not worse (I have more scenes that stopped working vs 3.4 than scenes that finally build)

And you need no complex scene. Frogames ProtoPack - Car Scene + build with automatic portals for example kills it with the processTiles error too on an 18GB win7 64 ultimate installation with over 12GB free at start and that scene is trivial, not complex.
Especially the portal based building is seriously broken (but the normal one isn't much better), anything thats not 'quake style level' with confined portals will more sooner than later F*** it up.

 

I didn't had time to test it with complex scenes yet, but from what dreamora wrote, UT should consider to invite professionals from Umbra to help implement OC .

 

2dreamora: I know that betatesters are not paid. But what is point in having 1000 of betatesters, if there are critical bugs left anyway? It can mean only two things, UT team ignores bug report (bad), or bug is reported by very few testers, so they decide to ignore it as not important (bad testers + bad UT management).

"thats 10 times more effective than us starting to throw virtual molotov cocktails or meeting with fork and torch to walk to their HQ" Well, I am not quite sure, somebody should try it, there is lots of lessons from history, that forks and torches work well.

Actually this is only option left, because reporting again and again does not work in case of Unity. Virtual molotovs usually works too, because managers are really afraid of getting such problems public. And if these problems are publicly known, it can easily happen, that there is some article on gamasutra (or whatever) about Unity ignoring critical bugs, some big AAA customer tells, that he heard about ignored bugs, etc...And this always means tornado inside company and problems are solved very fast...(i know it from both sides, this really works). Unity is big company and it means, that management really does not care about something not working, if it does not influent sales or brand awareness.

So report and be quiet is unfortunatelly no solution.

 

In the pictures, I don't see what is supposed to be occluding the wall. There's nothing blocking it. Just it being behind you won't make it occluded. I don't know how the occlusion culling works internally, but if it's a tree/node structure, likely just being in or near a node is enough to make something "visible" in systems I've worked on. That's a job for frustum culling, and it may or may not get something that close, depending on bounds checking.

 

Jaimi, let's talk straight: there's A WHOLE LOT MORE OF OBJECTS behind the camera that are not being rendered because they are out of frustum and occluded (you can't see them exactly because they are behind the camera, out of frustum).
But there's that wall there.
So just please don't waste words trying to say that it's all normal and closing your eyes.
It's NOT normal. That wall is OUT OF FRUSTUM and shouldn't appear at all. DOT.
And it's a really HEAVY bug having something out of frustum being rendered, something that should NEVER happen IMO.

 

If it is really out of frustum then it is normally not rendered. The problem with the screenshot is that it does not show well what of the geometry is one object and what not cause culling (independent of frustum or occlusion) operates on meshes and if the mesh bounding box somewhere hits the view frustum it will be rendered unless OC cuts it. it does not matter if the whole geometry is behind the cam, if there is an orphan vertex in front so the bounding box expands to the front of the cam it will render, point. Keep in mind that unity does not use nor support triangle level occlusion in any form, thats why static batching can be that relevant and why its an epically bad idea to use the combine children script for more than objects very close to each other

 

+1
So it's a massive memory leak ?
And worse than before ? UT seriously...

 

I am not sure if it is a memory leak (thats Demostenes interpretation) or if its actually a problem with a too deep occlusion querying tree from the scene graph that goes too deep down which naturally makes the datasize explode exponentially. What I though can say is that the baked 3.5 OC data normally are significantly larger than the pre 3.5 ones

 

Exponential data explosion would mean, that before crash it eats all memory, than swap file will grow and grow..., which is not this case.

 

A program with a memory leak will cause a crash only when all available memory is consumed. The behavior would be similar to if the datasize was just really big. I'm not saying there isn't a memory leak, but its impossible to tell just going off the thing crashing. There can be artificial memory limits imposed upon processes by the OS / configuration. What OS are you using?

 

And how would that differ from memory leak if 10GB of RAM of 18GB are still free and untouched?
No my actually assumption is that it rockets up its memory usage and around that point a bug in the pointer arithmetic (32bit vs 64bit) hits in. Its a problem that happens on osx (8gb machine) and windows (the 18gb machine), which is a reason I doubt the memory leak nature of it as it would otherwise behave inconsistent between the two as OSX manages that stuff fundamentally different.

But I would have to hook up the osx instruments to really check it (thats how I normally hunt unity bugs that seem fishy: Shark or Instruments - but I at the time have no project where OC usage is payed so I have no incentive to hunt it down as back in the past where I hunted down some other bugs like crash bugs due to the tree perlin noise function on wind on osx and alike)

 

What do you mean by that? I back up everything I do with actual results on the appstore, and finished products. Why you mean to poor hippo?

Yeah but considering some beta testers were just spreading beta copies around the net and blabbing about it, plus most of the bugs being found by unity staff, I have to say that open beta .... is the future of unity testing. Stuff gets found fast. So much for the special beta club. I think it's a great concept and a forward-thinking concept to have an open beta.

Having been part of several beta programs in the past, I notice that everyone is enthusiastic when they join a beta, feeling special, then after a while they can't really be bothered (this isn't their fault, especially bigger developers, because there's products to ship and so on, and less time to fiddle around with betas), so an open beta is a cool concept for bug hunting

 

Hunting bugs in such way should be work of Unity team anyway. But lately I am really doubting kungfu quality of "ninjas" inside UT, they are not able to realease anything near functional. Actually it reminds me one classical comic:

http://galactanet.com/comic/view.php?strip=4

 

Again, your problem might be entirely related to your OS. For example, Windows 7 in some cases explicitly enforces a 2GB process limit even on a 64 bit process. But don't let my facts get in the way of your rage.

 

If you read my post carefully, you would notice, that it crashed with cca 4,2GB of memory allocated. It does not look like enforcing 2GB limit. Anyway I really dont care, why it does not work. I dont care if it is fault of OS, or not. It crashed, it is bugged. It is problem to understand this?

 

Yes, its Unity's fault that certain OSes under certain configurations impose memory limitations on user-space processes. You're complaining about vague crashes, affecting only you, in a beta software under absurd conditions? Well I submerged my computer in water and it stopped working. Herp derp, its the manufacturers fault!!

Why don't you submit a bug report and be that great beta tester you want others to be?

 

I always submit bugreports.

"affecting only you, in a beta software under absurd conditions? "

1) Really? I am, not only one, read carefully this thread.
2) Absurd conditions? No, it is exactly kind of scene, for which was Umbra meant (and for which is normally working in other engines). We dont need OC for light scenes.

So stop behaving like fanboy, your "arguments" are quite silly.

 

The problem in this thread is not of Umbra crashing; that's your problem that you interjected into this thread.

Take your own advice on reading.

 

I am always curious, if fan boys are also pro users. My bet would be, that majority not. But maybe I am wrong. Are you pro user?

 

Demostenes: start your own thread.

megmaltese: could we get a screenshot of the vertices in this mesh from your modeling program? Make sure it shows "floating" verts, if any, in addition to the ones that are actually connected to the mesh triangles.

 

Well dreamora has been a bit moany recently. I forgive him because surely he must be human

 

One other avenue I encountered with Umbra, and I don't know if it is relevant but here it goes;

- In my scenes Umbra tends to just freeze into an infinite CPU loop randomly. What I mean is that sometimes it get stuck calculating the PVS for dozens of minutes, consuming more RAM instead of just finishing in a couple minutes. To get around this I just cancel the calculation and restart it (it resets my settings too.. so I have to re-apply them).

It's as if it starts on the wrong foot and you have to reset it to get on track right...

I'm using Win7 64bit 24gb RAM, i7 950 OC'd @ 3.8Ghz.

 

It also crashed for me on a not really that big scene (it's an ios scene, it's big for ios standards, but yeah that's pretty small). I was wondering if there is a problem with "open" geometry? Since I usually delete polys on the underside of objects (if they are supposed to rest on the ground) and I think the new umbra implementation is trying to voxelize the scene (they said that in the video presentation, right?) and maybe that causes some errors? I'm really just guessing here. If I narrow it down I'll do a bug report.

 

So I should only make occlusion areas where the camera can go? everything (static) outside an occlusion area will still be culled?

Thanks,

 

Hmm okay i baked the occlusion and it all seems fine in visualize but when i run the game theres no difference in performance or very little if that but atleast i can bake the occlusion now lol

 

Yes, the Occlusion Area should be roughly where the camera can go. Every cell that is computed that the camera never enters is useless data.

 

Any news about trying to make it work on multiple scenes? (LoadAdditiveScene)

 

I think there is one workaround. Load scene to your main scene, bake occlusion, unload scene. Load other scene, bake occlusion, etc...So all oclusion data will be baked in main scene. Anyway I am waiting for this too, because this is very limiting and occlusion is meant primary for large worlds and heavy scenes and who is using streaming? Large worlds and heavy scenes....

 

I tried that but it is very limited and more complex a scene is, more Umbra has trouble creating portals for indoor/outdoor worlds...

It's also very un-optimised as the PVS data for possibly unused scenes will still have to be loaded/downloaded.

As it is now, Umbra is a GREAT tool for optimising small / simple projects with 1 scene, which kind of defeats the purpose of it doesn't it?

 

Hi, I just tried to bake OC with the city model included with the 3.5 beta and the process gets up to like 4 gigs and then crashes with "Run out of memory in processTile()"

What's up with that? Is anyone aware of this issue? It seems like making a reasonably good sized city is totally out of the question due to some kind of memory issue?? That's a pretty serious limitation! I wonder if I'm doing something wrong because I'm using the assets shipped with the demo and I could have sworn in the keynote they showed that city model occluding correctly

 

They were probably running on a very high spec system, you can adjust the settings for OC isn't there a cell size property, for a 3d volume doubling this would mean a 8 times reduction in cells.

 

Is there any way to get an official response on this issue? maybe we're doing something wrong ? Maybe it's a known issue? workarounds/documentation?

 

All recent OC demos (Unite 11 etc) have either been baked on Joachim's crappy MacBook Pro or my crappier MacBook Pro ;-)

This is a beta version. In our tests the new OC works in almost all cases. Those issues we find we're fixing. And of course if you have run into a bug then please send us a bug report with a reproducible project.

The documentation for OC can be found here. If you have specific questions about OC set-up please feel free to ask them.

 

I run out of memory bak8ng a not very big scene. Ive 16Gb Ram under xp 64. I Hhad very litle Hd spafe at th momentt, something like 200mb. The largest elements, roads, did work ok yesterday.

 

Also noticed that cell size is no shown correcty from a size like 400 and beyond, they retain their visual size, does the size value taken in account for calculus?

 

I got it to not crash by setting the view cell size to 4 in the bake tab of OC, however this makes for pretty poor OC in general so I'm not sure what to try next, this is for OCing a city where buildings have internals

 

And if you guys would finally stop using OSX for testing so you see all threading and memory bugs (which you don't see as the osx code is worlds more correct than the windows one (my osx machine although its on 8GB ram only bakes more than my 18GB RAM win7 64bit machine) that would be a real blast. Or simply decide to not touch OSX at all for the OC on 3.5 tests from now on to get a feeling for the growing number of bug reports we send in, as OSX gives a really wrong impression in case of OC

We all know that OSX works better, it already did before cause umbra on osx could use 4GB on 3.4 and only 1.99GB on Windows, but now with 3.5 it another world worse cause on windows it simply eats something beyond 4GB ram and then blows, which for a 64bit app on a 18GB RAM system simply must not happen

I am aware that the relevant devs know this all already but I just want to write it to ensure that there is no wrong picture on how well it works simply cause you 'were lucky due to using the less broken OSX version'

 

Is there any change in supporting dynamicly loaded terrains/assets? Old version of OC was not supporting this.

 

@Demostenes;
So far I havn't seen anything sugesting this in 3.5.

I would love to have an answer from Unity too. Like I said above, unless you use 1 scene / project (the one where PVS are baked), Umbra is quite simply useless when using scene compositing.