[RELEASED] SECTR VIS: Dynamic Occlusion Culling

Hey again,

Is it possible to have a Culling Camera exist in multiple sectors at once?

The reason why I ask is I'm splitting my game world into large chunks, and I've come across a problem I'll detail below.
Chunk 1 and Chunk 2 are right next to each other, separated by a huge portal (works fine) and there's a building in Chunk 1 that is it's own sector and has two large doors (both with portals). The result is that everything works fine, if I look from Chunk 1 through both doors of the building and into Chunk 2, I can still see Chunk 2, but if I walk inside the building, Chunk 2 disappears despite still in view. I believe having the Camera exist inside both Chunk 1's sector and the Building's sector would fix the problem but I'm not sure if VIS is compatible with this approach, is there any way of achieving this or otherwise fixing this particular problem?

Thanks again for any help, and please let me know if there's anything else I can provide (I can screenshot the results described above if it helps).

 

Yes, that is supported. If you have a culling camera on its own, it'll be in every sector that contains the near plane. If the camera has a member component the culling will use whatever sectors that member is in. Anything in any one of the base camera sectors should be visible and unaffected by culling.

 

Ah apologies then, it must be something else causing the problem as it happens regardless of whether or not a member is attached to the camera. In that case, would you be able to describe what might be causing the issue shown in the two screenshots I've uploaded? Inside.png shows the camera looking from inside the building, through it's door portal and through the portal between Chunk 1 and 2, Outside.png shows the camera looking from outside the building (in Chunk 1) through the portal between Chunk 1 and 2.

Thanks again man, let me know if there's anything else I can provide, or if there's a more appropriate place to be asking these questions.

 

Not sure. Can you make a package and email or send a link to support@makecodenow.com?

 

For sure! I've unfortunately got an errand to run for around an hour and I've got to strip down the scene to the bare minimum needed to reproduce the effect, so I'll have it to you within 1-2 hours hopefully, can't thank you enough for the help!

Oh and just in case, I'm using Unity 4.5.4f1 alongside SECTR Complete 1.1.4a

 

Well, I created a new project entirely and created a basic scene to reproduce the issue but it didn't show, I later found out that adding a Sectr Member to the camera causes the issue to happen, but it also showed me that my main project didn't actually update Sectr Complete for some reason (looks like Unity either failed to import, or refused to overwrite somehow)! So I deleted it and reimported, took off the Sectr Member on my player camera and it all works fine now.

Apologies if this isn't correct (or it's intended), but adding a Sectr Member to a Camera and then moving it inside 2 sectors at once causes the Culling Camera to only think it's inside one of them even though the Editor's light blue lines clearly show that the Member thinks it's inside both.

I'll not bother sending a package as the problem's totally resolved for me now, apologies for wasting time and thread space, hope at least some good came of it.

And again, thanks for the very timely, helpful responses and making an overall solid Asset, really gives peace of mind knowing you're working with a tool you know isn't going to permanently screw up in any way, looking forward to completely integrating Sectr Complete in my project.

As a side note, thank you very much for making something of this quality that is completely dynamic, I'm a major supporter of non-static design, it's awesome to see others out there thinking the same way.

 

I'm glad that your issue is resolved, but I think there may yet be a bug. Certainly if the Member is in both Sectors and the Camera without the member is in both Sectors but the Camera with the Member is only in one Sector, that seems like a bug for sure.

Would you mind sending me that scene anyway? I'll take a look and see if there are any outstanding issues.

 

PS - Very happy to help. Glad you are enjoying working with SECTR. Post more pictures as the game gets further along!

 

Apologies for the delay, I've sent the package as requested via email, any further details are in the email itself. Let me know if there's any other way I can help out.

 

FYI to anyone following along, there was a real bug here. I have a fix off to some folks to test and then will be pushing 1.1.4b live asap (probably 9/21).

 

Just posted 1.1.4b. Now live with the last known VIS bug fixed.

 

Just purchased this and integrated into our game. The game fits rather well with a portal system, since it's divided into rectangular rooms with small corridors between them.

I've correctly set up the system to generate all the sector / portal information programatically (took a while, and for some reason the game was crashing when I set the Bound update mode to Start. I took out some conditions in the LateUpdate() method and it worked).

The culling is properly done, and the debug shows it clearly. However, the FPS are much lower with the Culling camera enabled than without.

The reason is that the method CullingCamera.OnPreCull().Apply() takes 25% of the frame time, and OnPostRender() another 15%.

I've checked their insides and it's mostly because ALL (or most) MeshRenderers and lights in the scene are traversed, setting the enabled value to true or false, depending on their cull state.

Our scenes have thousands of objects and meshes, so this is a no go. Until now that wasn't an issue, since most objects were outside the frustum and merged with static batching, and it didn't drop performance too much.

I suppose there's not much that can be done, it's mostly Unity's fault that you can't hide objects in a hierarchy and have to individually disable each renderer. I should have thought of this before purchasing the plugin :\.

 

I'm having a similar problem to WaaghMan, as my scenes are getting to their proper level of complexity I'm getting a drop in FPS with the culling camera enabled. Draw calls and polies per frame drop significantly, but the two processes that he mentions more than make up for it. Is there a smarter way to be doing this? Should the scenes be set up differently? If I turn on multithreading on my 12core system to 2 threads I get major stuttering, so that doesn't help... Any thoughts?

 

Good questions. Of course there are some fundamental limits to VIS performance. It takes a certain amount of time to hide or show an object in Unity, and if you have a ton of objects, there will be a base required time. Still, there are a few things you can do:

1) STREAM is a nice complement to VIS in that sections of the level that are unloaded don't consume any resources at all. You can think of STREAM as a kind of gross culling and VIS as a finer culling system.

2) VIS culling is hierarchical and you can control the granularity of the culling to reduce time spent in OnPreCull. For a quick, very coarse demo, enable Simple Culling in the Culling Camera, which just does a frustum check of all Sectors. For more fine grained control, you can try marking Sectors or Members to cull as a Group instead of Individually. Finally, you can add Member components at the top of hierarchies and mark them as Group culling so that they cull as a group and not individually.

3) On the PostRender() time, the best technique is to remember that culling isn't all or nothing. If you have a bunch of small objects that you can afford to render, then don't make them children of Sectors/Members. CullingCamera will only touch objects that you tell it to, and anything not part of a Sector or Member will be left unharmed.

4) It's possible that I can improve the PostRender time for scenes with only one CullingCamera. I'll take a look at that, but it'll be weeks away at least.

Finally, if none of this works for you and you want a refund (or a refund before upgrading to COMPLETE) please email support@makecodenow.com and reference this thread.

 

Also, I should mention that Threading stuttering is apparently an artifact of a bug in Mono 2.6. I'm hoping it's fixed in Unity 5, but we'll see...

 

Thanks for the reply. No need for a refund really, but the offer is appreciated.

I don't think we'll be able to fix it in any way unless Unity changes something on the scripting API.

Our scenes are created via extensive use of Prefabs: We have room tiles, wall pieces, etc. and put them together in the editor. They are 8 meters wide so they aren't specially small, but still there can be a total of ~100-200 prefabs per room.

When instantiating the room, we apply a Static batching (StaticBatchingUtility) process, so the whole room can be drawn in just 20-30 draw calls (limited to materials).

The problem is that even if we use static batching, to disable rendering of those objects from scripting, you have to disable the renderer of each prefab manually ( In other words, to save 20-30 draw calls, you need to disable 100-200 renderers).

A way to save performance would be to not disable/reenable the renderers on every frame, and just wait for the time their value really changes, but that could break support for multiple cameras, and could get messy to handle new and deleted gameobjects, hidden gameobjects from other scripts, etc.

The ideal solution would be for unity to have the equivalent of activeSelf/activeInHierarchy to hide all nested renderers in one call without messing up the scripting and physics.

 

Thanks for the detailer explanation. Sounds like you know the options. I will eventually look into the single camera only change deltas approach but as you say there are a lot of corner cases to track which is why I'm not sure how long it'll take.

 

one thing you could do is crunch the meshes down into new meshes, though it might not be ideal depending on your needs with the levels. You'd end up with just 20-30 renderers as opposed to the hundreds. For example, find all the mesh renderers within each sector and combine them, so you end up with a chunk of meshes associated to each sector.

If you don't need to dynamically generate any of the levels at runtime, look into the OnPostProcessScene() callback, that's a nice way to bake down your levels when they build and do all the heavy lifting there instead of Awake / Start. The nice thing is the new meshes will just be saved with the built scene file (i think), and it will never affect the editing of scenes.

this is a little interface for baking things when the scene builds:

Code (CSharp):

1. using UnityEngine;
2. #if UNITY_EDITOR
3. using UnityEditor.Callbacks;
4. #endif
5. using System.Collections;
6.  
7. public class BakeFunction
8. {
9. #if UNITY_EDITOR
10.     [PostProcessScene(-1)]
11.     public static void OnPostProcessScene()
12.     {
13.         foreach(MonoBehaviour mb in UnityEngine.Object.FindObjectsOfType(typeof(MonoBehaviour)))
14.         {
15.             IBakeable ib = mb as IBakeable;
16.             if(ib!=null)
17.             {
18.                 ib.Bake();
19.             }
20.         }
21.     }  
22. #endif
23. }
24.  
25. public interface IBakeable
26. {
27.     void Bake();
28. }

 

Super cool idea! I may add that as a feature for Sectors!

 

nice! I actually have something like this working for my project (based on the question of splitting meshes from much earlier).
I'm currently using ProBuilder as a quick way to create axis-aligned boxes/bounds for sectors.. and then during PostProcessScene it slices my static meshes along the 6 planes of each sector bounds, creating a combined chunk of meshes for that sector. Then it goes through all the sectors and finds bounds that overlap, creating portals connecting them.

The limitation right now is I have to always be on the grid with sectors (no intersecting) and can't have angled sides of the sector bounds, but it works well for my needs. Hoping to look into supporting angled sectors, though it will still need to be 6 sided and only work on co-planar sides for portal creation.

I'd paste my code for the mesh slicing but its super messy right now, maybe in the future though if I can pull out the relevant parts. For the 6 plane slicing I used the same method I've seen people use for creating decal projectors, basically check if a triangle's verts are all on one side of the plane, if not, insert a new vert on the 2 edges that cross the plane etc.. + lerp for getting the appropriate new UV coordinate along the edge.

For the portal creation it's a bit more straightforward, here's part of the create portal function, the code is basically duplicated for the Y and Z axis:

Code (CSharp):

1.     //NOTE, no multi portals connecting sectors, just use occluder if important
2.     public void CreatePortal( Sector other )
3.     {
4.         //make sure the other sector isn't already connected to this sector
5.         if( this != other && !other.connectedSectors.Contains( this ) )
6.         {
7.             //this seems to work fine for co-planar bounds, it detects it as an intersection
8.             if ( this.bounds.Intersects( other.bounds ) )
9.             {
10.                 this.connectedSectors.Add( other );
11.                
12.                 //detect axis by checking distance = size of both
13.                 Vector3 dist = this.bounds.center-other.bounds.center;
14.                 Rect rectA, rectB;
15.                 Rect rectC = new Rect();
16.                
17.                 if ( this.bounds.extents.x+other.bounds.extents.x == Mathf.Abs(dist.x) )
18.                 {
19.                     //plane normal along X axis
20.                     rectA = new Rect();
21.                     rectA.xMin = this.bounds.min.z;
22.                     rectA.yMin = this.bounds.min.y;
23.                     rectA.xMax = this.bounds.max.z;
24.                     rectA.yMax = this.bounds.max.y;
25.                    
26.                     rectB = new Rect();
27.                     rectB.xMin = other.bounds.min.z;
28.                     rectB.yMin = other.bounds.min.y;
29.                     rectB.xMax = other.bounds.max.z;
30.                     rectB.yMax = other.bounds.max.y;
31.                    
32.                     if ( rectA.Overlaps( rectB, true ) )
33.                     {
34.                        
35.                         float xmin = Mathf.Max( rectA.xMin, rectB.xMin );
36.                         float ymin = Mathf.Max( rectA.yMin, rectB.yMin );
37.                        
38.                         float xmax = Mathf.Min( rectA.xMax, rectB.xMax );
39.                         float ymax = Mathf.Min( rectA.yMax, rectB.yMax );
40.                        
41.                         rectC.min = new Vector2( xmin,ymin );
42.                         rectC.max = new Vector2( xmax,ymax );
43.                        
44.                        
45.                         //create the portal
46.                         GameObject portalO = new GameObject("Portal");
47.                         GameObjectUtility.SetStaticEditorFlags( portalO, StaticEditorFlags.BatchingStatic );
48.                         SECTR_Portal portal = portalO.AddComponent<SECTR_Portal>();
49.                         Mesh mesh = new Mesh();
50.                         Vector3[] vertices = new Vector3[4]{
51.                             //clockwise
52.                             new Vector3( rectC.xMin-rectC.center.x, rectC.yMin-rectC.center.y, 0f ),
53.                             new Vector3( rectC.xMin-rectC.center.x, rectC.yMax-rectC.center.y, 0f ),
54.                             new Vector3( rectC.xMax-rectC.center.x, rectC.yMax-rectC.center.y, 0f ),
55.                             new Vector3( rectC.xMax-rectC.center.x, rectC.yMin-rectC.center.y, 0f )
56.                         };
57.                        
58.                         int[] triangles = new int[6]{
59.                             2,1,0,
60.                             3,2,0
61.                         };
62.                        
63.                         mesh.vertices = vertices;
64.                         mesh.triangles = triangles;
65.                         mesh.RecalculateBounds();
66.                         mesh.RecalculateNormals();
67.                         portal.HullMesh = mesh;
68.                        
69.                         portal.transform.rotation = Quaternion.AngleAxis( 90f, Vector3.up );
70.                        
71.                         //TODO can provide 2d rect with forward axis to rotate rect onto
72.                         if ( this.bounds.center.x > other.bounds.center.x )
73.                         {
74.                             Debug.Log ("rect overlaps on axis X, x+ "+this.name+" "+other.name);
75.                             portal.transform.position = new Vector3( this.bounds.center.x-(this.bounds.size.x*0.5f), rectC.position.y+(rectC.size.y*0.5f), rectC.position.x+(rectC.size.x*0.5f) );
76.                             portal.FrontSector = visSector;
77.                             portal.BackSector = other.visSector;
78.                         }
79.                         else if ( this.bounds.center.x < other.bounds.center.x )
80.                         {
81.                             Debug.Log ("rect overlaps on axis X, x- "+this.name+" "+other.name);
82.                             portal.transform.position = new Vector3( this.bounds.center.x+(this.bounds.size.x*0.5f), rectC.position.y+(rectC.size.y*0.5f), rectC.position.x+(rectC.size.x*0.5f) );
83.                             portal.FrontSector = other.visSector;
84.                             portal.BackSector = visSector;
85.                         }
86.                         else
87.                         {
88.                             Debug.LogError("[Block] sector min max was equal, this means 2 sectors are at the same position somehow");
89.                         }
90.                        
91.                         //portal.Compute();
92.                        
93.                         Debug.Log (portal.Normal,portal);
94.                         portal.transform.parent = block.transform;
95.                     }
96.                 }
97. //else if ( this.bounds.extents.y+other.bounds.extents.y == Mathf.Abs(dist.y) ) etc!

 

New SECTR update out now. Includes improvements to terrain splitting and culling, plus some Unity 5 updates.

 

Can moving enemy units be occlusion culled? If so, possible to see an example?

I tried this with the InstantOC asset but the enemy tended to "pop" onto the screen, especially if they were moving fast.

 

Yeah, no problem. Check out the moving objects in this demo. SECTR VIS uses a geometric approach, not a stochastic approach like InstantOC, so you'll never get popping, no matter how fast the objects or camera move.

 

In the demo, it looks like the moving units don't get occlusion culled if I am standing close to them (or possibly in the same room) even though I turn around completely and don't face them at all? (in other words, they are still rendered even when completely off camera)

Can they be set to be occlusion culled the moment they go off camera, no matter how close I am to them?

EDIT: it also looks like some rooms also get rendered even though they are completely blocked from view by intervening rooms

 

The culling is more complex than you might expect because there are many dynamic shadow casting point lights, which is a worst case for dynamic occlusion and I wanted the demo to show that VIS can handle it. If the capsule didn't cast shadows or the dynamic shadows were only cast by a directional light, then it would look the way you expect.

 

1.1.4e is out now. Includes API fixes for U5 Beta 13.

 

1.1.4f is now live on UAS. Includes fixes for U5 b14.

 

SECTR 1.1.5 is now live on the asset store. Includes an open world VIS optimization and various bug fixes.

 

Hi there,

Have you tested Occluder Draw in unity 5 RC2? Is pertty slow and I cant draw occluders plus I cant use custom meshes cause they are allways detected as concave ( inclusive the default cube mesh ).

 

Not yet but I'll download tonight.

Occluders need to be planar so the quad should work but the cube never will. Did you mean quad or cube?

 

I can repro this bug in Unity 5 RC2. I've filed a bug with Unity including repro steps using SECTR VIS. Hopefully they can fix it before release!

 

Bug is 673600.

 

Very thanks!

So I cant use a cube as occluder? I need to add 4 SECTR occluder to one bulding on all 4 faces?

 

VIS occludes must be planar. For a building you can use one quad placed in the center set to auto orient around the y axis. You can also use two at right angles to one another in a plus shape. That's not perfect occlusion but it's often more than good enough.

 

Well, its ok, but anyways I will need to add 4 Occluders, the building is rectangular and its verly large from X axis. Adding 1 occluder at center of the building facing to the camera will not be optimal.

 

If it's a square building, try two occludes making a plus sign when viewed from above.

Also remember that occludes have some CPU cost so make sure that the cost of additional occludes is worth the gains from more precise occlusion.

 

SECTR 1.1.5a is now live on UAS. It includes some bug fixes and a major reduction in garbage generated by Member update.

 

SECTR 1.1.5b now live on the UAS. Includes a critical bug fix for 1.1.5a.

 

I am having some issues with SECTR VIS & Stream.

Here is what I trying to do:
I make 4 different LOD's, simple shapes with different colours for easier verification.
http://gyazo.com/08db28c181506b0c5cf663532b6f7586
I wish to have have a mesh always on show even when the sector is off. So I also have a proxy mesh ready.
I used SECTR_LOD to create the necessary gameobject to be culled by the SECTR_CullingCamera. I also set the threshold of the last LOD to ZERO so it's never cull's the last mesh, unless the sector is unloaded but then the proxy mesh kicks in. Therefore the setup is like so: ProxyMesh>>(LoadSector)>>LOD03>>LOD02>>LOD01>>LOD00. All good.

The problem is that on run time I see all meshes at once. So I never get the benefit of the LOD.
http://gyazo.com/3cb6740502d31940fd59bd9c2391b0ce
Am I missing something on the setup of the LOD Component?
http://gyazo.com/c2df314d1fbddaedc0c7f32af5265044

Now for the strange behaviours:
Sometimes I export all sectors and one or two get "stuck", it never exports everything. See in the image bellow how Part_01 still has a dropdown with all the elements inside?
http://gyazo.com/74cc0e24de010ec8024bcaa8eb28afec
Once this happens that is nothing I can do. It simply sticks to that configuration. I tried to delete chunks, delete the levels on BuildSettings, tried to delete the SECTR_Sectr and re-added it to no avail.
I basically have to redo all scenes.

 

Your lod setup seems fine. Can you send me a copy of that project? Email support@makecodenow.com.

I have a fix for the bug where not all doctors export. I'll send you that fix directly if you email me.

 

When loading the Sectr Vis demo AdvancedCulling or BasicCulling scenes (I have SECTR complete 1.1.5b, Unity 5.0.0p3), everything works fine playing in the editor. On webgl, the doors in the scene aren't visible, but the culling works fine. As I walk past the invisible door, things on the other side become visible as the culling works. The culling works, but the doors don't show up. The same thing happens on the default Sectr Complete CompleteScene. I'm not using lightmaps on either.

 

Hi. This is sadly a known bug with Unity's WebGL implementation. I've tried to work around it in SECTR but so far no luck. I hope Unity will fix it soon!

 

SECTR 1.2.0 now uploaded to the UAS. Includes an Open World demo (finally!) and a native Unity 5 build.

 

I am having some issue with uFrame after installing SECTR VIS. My collection is not working. I have coins laid out in different rooms but it is not detecting any coins at all. Coin count is always coming out 0. Do you have any suggestion or something I am doing wrong. Thanks

 

Hi, I'm not sure. Certainly installing SECTR VIS won't break anything in uFrame. Did you setup culling or LODs in your scene? If so, which ones and how? LODs will actually activate and de-activate object, but culling shouldn't have any impact as it just turns the render components on and off before and after the camera renders.

 

OK. It may not be related to SECTR VIS. I am still trying to figure out. Thanks anyway.

 

Issue is fixed. It was not related to SECTR VIS

 

got a question about overlapping Sectors, I'm noticing that if my camera is in one sector (A), and another sector (C) has bounds which overlap the current sector (A), once the camera enters the overlapping bounding box of the other sector (C), sector C gets drawn, even though there is no line of sight through the portals into that sector. (because the portal from A to B can't see the portal from B to C)

Is there something I can do to stop this from happening, or is it just a side effect of overlapping sector bounds?
I was expecting that it would try to walk through the portals to see if the sector is actually visible from the camera's location, but it seems like it is bypassing that step if in the bounds?

 

Your understanding is correct. By default, the camera is in all Sectors whose bounds overlap the camera and any objects in those rooms could be visible.

There is a good workaround, though. Add a Member to the GameObject with the CullingCamera and set Portal Determined bool to true. Then set the start Sector field that appears. In this mode, the CullingCamera will only change Sectors when it passes through a portal, not when it overlaps the bounds of the Sector.

 

excellent, thank you, that seems to help cut down on what is drawing, had no idea members could be added to culling cameras!

Now having sectors only change when passing portals is a bit trickier in my case because the object the camera is on (the player) can be teleported in to multiple locations within the environment, so it's possible to skip past portals.

I fixed that now though, it detects the destination Sector when teleporting & updates the start sector field. In the case that the player is in multiple sectors when teleporting, i have it do a second check where it looks at stored information about the collider the player is standing on, and checks which sector it is parented to (the collision is split up with sectors along with renderers)