InstantOC - dynamic occlusion culling + LOD

Well, the InstantOC LOD system is ray-based, the one of Unity is distance based.
Thus, if you have an object that is near, but occluded by another, InstantOC will render the low poly version, any other distance based LOD system will instead render the high poly version although not visible (because occluded).

Here is an explanatory picture:


That said, the 2 usecases proposed by @Olafson and @ronan.thibaudau are perfect examples where InstantOC makes sense also to Unity Pro users.

 

In other words, this IOC is extreme powerful by indoor scenes or scenes with many view obstacles.
I'm currently making a indoor scene and because of IOC, I'm able to use much more detailed meshes, than I first thought.

The distance based LOD make sense in big open world games where you can see a huge amount of different objects. In such a scene, you would need that much ray's, it wouldn't be performant at all...
But in the most cases, a ray based LOD is very effective.

Greetings
Chillersanim

 

If we are talking about the dynamic occlusion technique, I don't think you are right here, and the demo scene proves it.
This technique is good for any type of scene.
As for any occlusion technique to be efficient, you need, well, occluders.
In open scenes you have less area covered by occluders, compared to indoor scenes.
But this is valid for ANY occlusion system.

The main differences you have with Umbra is that IOC requires more power because it must be computer at runtime, while Umbra precomputes the system.
Umbra takes the toll in your workflow when you use it: long computing time is a thing that waste a lot of your time.
And there's also some memory space needed by the Umbra solution.
And on top of it, you can't move the occluders at runtime, which is a great plus too, depending on what type of game you are developing.
In example, large vehicles can give their contribution to occlusion even when they are moving.

 

I think, I did not explain my point of view clear enough. I only talked about the difference between IOC and a distance based lod system.
In the case of a huge open world game, you can have multiple thousands of objects at the same time visible. For a ray based system, this is way to much, you would get an enormous flickering and object switching. For that reason, you would need to remove the objects at a certain distance (distance based!), or set to "lod only", what in a case of an open world game not would be optimal.
For the difference between umbra and IOC, I did not find any easy examples, but there I think, it is like Olafson said: Static objects with umbra, dynamic with IOC.

 

I bought IOC because I consider the Umbra workflow a big waste of time.
I don't know what is exactly the overhead of IOC for those 1000 raycast, but it's still running sweetly on my laptop, so that's ok for me

 

You're still casting the same number of rays if there are more objects anyway, i don't know how this is implemented but i don't see why it wouldn't scale well?
Something that should be quick for something ray based is to know if an element is transparent, then take all elements ordered by how close they are to the camera, and for each ray stop at the first non transparent element you hit for that pixel, then boom just discard everything you didn't hit. Sounds to me like it'd scale very well with arbitrarily many models (only the original ordering grows longer pretty much)

 

How does the OC aspect of this compare in quality to the free "M2H Culling" system on the Unity Store?

 

It isn't about the steady amount of ray-cast. When you have a scene, where you don't see that far, there aren't that much objects, that get so small, that the chance to get hit by a ray-cast is very low. In a big open world game, you see very far, so many objects aren't that big (seen from the camera) ans so they get hit, lets say only all fife seconds. So they get turned off, and sometimes, they get back turned on. Because of that, you would need a larger amount of ray's what increases the CPU-overhead.

To the idea with the alpha. The ray-cast system needs colliders to work. It ignores the actual shape (including alpha) of the objects.

Can be, I don't know, because I'm a free developer.
I noticed a small difference in the CPU-overhead, when I switch from 400 to 800 Ray's. The difference was about 3ms. But that was only tested on a modern PC with enthusiast level hardware. I should test it on my laptop sometime to get a clear picture...

Ps.
I did just remember an earlier discussion with Frenchfaso about that problem with far away objects.
We were talking about a technique to determine if an object is truly invisible, before it is turned of. When this technique works, the problem I mentioned would be out of the world (with an increased amount of ray-casts though...).

Greetings
Chillersanim

 

No, you'd still need at most 1 ray per pixel, regardless of how large the world is and how far you see, and you always have more chance to hit something "close" than far, so most rays would hit very quickly.
Also i know it works on colliders, but hitting something with a collider doesn't mean you can stop the ray, if it's transparent then you don't want to occlude what's behind, which is why you should tag such objects to be ignored, so the quickest algorithm remains as such pretty much
Sort objects by distance from the camera
Drop all those that are behind
Ignore those that are transparent objects
then for each pixel cast a ray in the look direction and check items in closest to farthest order (even outdoor, like 1/3 of the rays would collide nearly immediately with close terrain, and another third usually should hit pretty close).
So it should scale well with many objects (not 100 000, but 1000 yea) even in an open world.

 

How do you mean a ray per pixel? I think when I send out a ray for each pixel, it would be a huge number (Window size 1920x1200 = 2'304'000 ray's...)

Now I understand what you mean whit ignore alpha objects. Would be a great addition though. It's not only for alpha objects good, but also for objects, which needs a simple collision mesh but have a complex structure... (like Plants without leaves...).

Greetings
Chillersanim

 

For both, looking for something that is a little more high performance than raycasting but it doesn't matter if it's not very accurate, just want to cull very far objects easily.

 

I just wanted to say, that I will not be able to come online for the next two or three months.
I hope, when I come back, that a new IOC awaits.

Greetings
Chillersanim

 

Multiple months without internet? I wouldn't survive that lol

 

I agree! How the f*ck is that even possible?
Is he going to a mission in Africa???

 

Wow!
that's a lot of time offline!
I'll make sure to bake an update to celebrate your return back from hell ;-)
(that's the only place without the internet, right?!?)

 

InstantOC is deeply based on rays, so the short answer is "no"
but take a look at the Android video or the iPad2 video, as you can clearly see, InstantOC makes the unbelievable possible on resource-constrained mobile devices.
The raycast "overhead" of InstantOC is insignificant, just tweak the parameters to find your optimal setup.
If you use IOC + LOD, the LOD part comes free of costs, because you already use rays for IOC
and if you use LOD only, then you need far less rays for accurate results 1/3 or max 1/2; just increase a little bit the "Hide delay" and you are good to go.

 

@frenchfaso does InstantOC support Stripping level: micro mscorlib ?

 

Hy spartan,
thank you for your interest for InstantOC!
It should work without problems, I have requested a Pro trial extension to test this out and will report back soon!

 

Hy Psyckosama,
thank you for your interest in InstantOC!
I haven't yet tested the M2H oc myself, but as far as I can see from the manual, the following should be the main differences:

M2H has no integrated LOD
M2H is a cell/area based oc system, so probably not compatible with dynamic/procedural scenes/content
M2H needs a more tedious setup to work correctly
M2H is very likely NOT compatible with dynamic shadows of Unity Pro

As I said, I've never used M2H, so if someone has experience with both systems, your bits are greatly appreciated!

 

Hi Frenchfaso, are there any other way instead of disable and enable the mesh Renderer, because it give me a little lag on android.
Thanks

 

Hy KirbyRawr,
that's strange, could you give me some more detail on your setup? What values are you using for IOCcam and/or IOClod components?
Could you take a short video/screencast to show me the problem?

 

Hello, Frenchfaso

Recently we have bought your product and it works pretty well, but we found that it would be really great if you will be able to add one more thing - Occluder objects.

In our case we have a procedural generated road with forest on the sides, hills and tonels. but we have not very pleasant visible road generation because every object with IOClod sricpts are not only occluded geometry, but also the occluders. So for us it would be great to make ONLY hills, tunnels, big rocks all this big objects as Occluders that can occlude trees (to decrease alpha test and overdraw), but trees will not affect each others.

Can you help us somehow with that?

Thank you!

 

Hy TribeWolf,
thank you for your purchase!
You can already achieve this with InstantOC, simply group a bunch of trees (for instance all trees in an area) together under an empty parent Game Object, then assign a single collider for the whole tree area (assign the collider and the IOClod component to the parent GO only).
Let me know ift this works for you.

 

Great product, thank you. Something you should consider adding in the next update (kinda surprised it wasn't already included) is when a renderer is hidden, it only does the first material of the renderer. Looping through all materials using renderer.materials would be the ideal approach here.

 

Thank you phato777

Yep, added to the todo list!

 

@frenchfaso sent you a PM with an issue with InstantOC

 

Hy spartan,
I've replied to your PM, try my suggestion and let me know if it helps.

 

Thanks for the awesome review!

 

You deserve it!

 

@frenchfaso have you compared the performance of Unity Pro LOD system and InstantOC?
Which one is faster? Considering the case that you are using InstantOC for occlusion culling.

 

Hy Spartan,
just updated Unity with a Pro trial, I'll do some tests and report back!
- check support of various stripping levels
- Unity LOD vs InstantOC LOD

 

Thanks Frenchfaso, looking forward to your test.
On a preliminary test, Unity LOD works faster, so I'm combining Unity LOD + InstantOC for occlusion culling.

 

I would expect Unity's LOD solution to be slightly better because it is written in native code.

 

It's pretty insignificant really, any measurable difference won't come from that. However unity's offline mode should always be faster than an online solution.

 

Hello everybody,
just completed some tests:
InstantOC is fully compatible with all stripping level options of Unity Pro!

in a little while, the LOD comparison results.

 

Keep up the great work Frenchfaso!

 

Thank you sir!

 

Hy everyone,
a bit about the LOD:

I have done quite some testing with the demo scene provided with InstantOC (raised the number of Logos up to 3000 and made the ground bigger)
and I found no performance difference between the Unity LOD groups and the InstantOC ray-LOD, whatsoever.
Actually, in some situations/camera positions, the InstantOC LOD, even performs a little better, for Instance when you set high values for Lod ranges/distances (better quality) and you are in front of a big occluder, the InstantOC ray-LOD performs better, because It renders the Lod_2 of a LOD if it is occluded (not visible), even if it's near the camera. In the very same situation, the Unity LOD would render the Lod_0 or Lod_1, wasting time (it's occluded, thus not visible!!!).

Also I would like to share a "trick":
If you need to cull a LOD with InstantOC also if visible from the camera (like the "culled" option of Unity LOD), just add to the LOD parent an empty game object and name it "Lod_2". Then set the Lod_2 distance, that's it! (Yes, the next update will have 4 Lod levels, like Unity LOD )

PS: I used 300 Samples and 50 hide delay and Lod only enabled (on the Logo prefab)

 

Maybe you should try with other type of scene and not in the Unity Editor. I have tried with mine on the devices, and there you see the difference

 

Interesting.
On a side note:
I did some more testing with Unity's built in terrain / tree system. I reported before that I generally got better performance when I didn't use the terrain system to handle trees, and let InstantOC handle the mesh visibility instead.

So...my testing isn't necessarily scientific and all documented, with test cases and such. It was pretty much...hmmm let's see what happens when I try this.

What I found is...at least for my projects where I want a lot of trees shown as full meshes and not billboards, I couldn't find a situation where Unity's trees handled by the built in terrain performed BETTER than if you just used straight meshes. And it doesn't seem to matter if you use InstantOC or not (I guess a scene with a lot of buildings, where InstantOC could occlude the trees, might be faster.)

Maybe others will have different results, though. I should probably do a more "official" test where I profile the system.

 

Would you mind sending me a screenshot of your scene, with some detail on the settings of InstantOC?

 

LOD 1: 150
LOD 2: 200
LOD MARGIN: 40

Keep in mind that it makes sense that Unity LOD should be faster: is built in the engine and is not in the Script layer as InstantOC. Unity LOD + InstantOC are a great combo by the way

 

Another great thing could be if you can provide an alternative IClod class without the LOD code. I've been removing all LOD code from IClod manually to optimise it and work with Unity LOD.

 

Thanks

 

Does InstantOC use Unity's cull layer distance functions as well?

Meaning that to save on performance, you could specify a "Props" layer which contains smaller objects that only get rendered when you're close to them. I've written parts of my own occlusion system for procedural generation stuff but I've been looking at this script to save me some time so I can spend it elsewhere.

Anyway, here are the docs on that feature:
http://docs.unity3d.com/Documentation/ScriptReference/Camera-layerCullDistances.html

 

Hy Rico21745,
thank you for your interest in InstantOC!
InstantOC is all ray-based, the dynamic occlusion culling and the LOD. It does not use "Camera.layerCullDistances".
You can early cull "props" with InstantOC this way:

If your game object does not have LODs, treat it as a 2-levels LOD with the 2° level being an empty game object and using the Lod_1 distance as the cull distance.

 

Is it possible to use InstantOC in a splitscreen game, I have yet to find somebody trying to use 2 or more cameras with this system.

 

Hy Boomsma1995,
thank you for your interest in InstantOC!
I haven't tried this yet, I'll do some tests and report back.

 

I've completed the tests, InstantOC works perfectly with splitscreen!
Just TAG one camera as "MainCamera" and set the global settings there, and all other cameras with a different TAG.

 

I'm thrilled to announce the very first Short Indie Game "Cold Fusion" powered by InstantOC, from HKFiftyOne Studios!
It's available for Win and Mac, and it's free to play, check it out!

Here is the Cold Fusion post on my blog,
and here is the official Cold Fusion launch trailer

[video=youtube_share;7mPv74v2toA]http://youtu.be/7mPv74v2toA