[RELEASED] SECTR VIS: Dynamic Occlusion Culling

I just purchased this asset today and am going to be giving it a try this weekend. I've been wanting to get this for a long time. My indoor scenes have always struggled due to the limitations of Unity's occlusion system. I'm really looking forward to improving performance for my game using this tool.

 

Awesome! My recommendation is always that you start simply and then build up once you have a foundation that's working. With VIS, also keep an eye on the profiler as occlusion culling requires CPU work and it's possible to spend more than you save if you set it up wrong.

 

One question. Is it recommended to also bake Unity occlusion in addition to using VIS or is it better to just use VIS?

 

VIS and the built in OC should not be used at the same time and solve different problems.

 

Building for VR, does adding a Culling Camera component on the main camera handle the two left and right eye cameras? (these are generated at runtime)

 

It should, but it depends on which VR platform you are building for and what unity/VR SDK you are using. I recommend you test it out in the profiler to be sure.

 

I've had no success with this tool. After getting sectors and portals set up, I found lots of glitches where things disappear when they shouldn't. I also saw a drop in performance of about 30 fps from what I was getting with Unity Occlusion Culling. So I went from about 60 fps to 30 fps. I'm regretting my purchase at this point.

 

Sorry you're finding it frustrating. On the glitches, I'd need to see a video to have a better idea of what the problem is.

On the performance, SECTR VIS is really designed for scenarios where the built in OC doesn't work, like games with procedurally generated worlds. If the built in OC works for you, then it's almost certainly going to be faster. Note that VIS also has controls that let you balance CPU overhead with culling granularity and those are described in more detail in the manual.

 

The tutorial videos show it being used for indoor environments with rooms and corridors that are not procedurally generated. So, the indication is that it is designed to improve indoor rendering performance.

 

I use SectrVis for VR and it does work properly.

 

Hi, I have a issue with occluders in Sectr vis , it works fine when culling other sectrs

but trying to occlude objects in the same sectr , it doesnt work.....

create occluders in a sectr and try to occlude objects in the same sectr

 

I'll take a look and see.

 

also it doesnt cullobjects properly,

1. create a fresh scene
2. create 6 terrain tiles and place then ajcent to each other
3. use terrain window to sectorize the terrain(dont split it and group)
4 place cubes on terrain and setup camera(make sure view distance is high)
5. notice how cubes dont cull properly, but its does when cam is really close to sectrs that cubes are in(buts thats only if you group objects to the sectr)

if there is a way we can communicate more closely i'm all for it

Sherrod Fletcher :skype

 

Thanks for the information. Do you think you could email me a scene that's setup in a way that reproduces the problem? Thanks!

 

Hi, can I check if this asset is compatible in VR? We have a procedural level consisting of 5 sectors and 4 portals lined up in a row (a series of rooms). However, there are noticeable CPU spikes when looking from one end to the other. In the editor, the culling works properly, just that there is alot more CPU cost then would seem necessary for the setup.

Culling mode for the sectors are set to Group, simple culling is turned off on the camera. Bounds update mode is set to Static.

 

https://imgur.com/a/isKVn

Here's a shot of the profiler and the CPU spike that occurs every now and then. I'll look further into the issue.

 

Looks like the CPU spike is due to threaded culling being enabled, which is a bug in the unity version of mono that I sadly can't fix or work around.

 

I am playing around with Vis, but I noticed some "pops" in regards to objects being culled that are supposed to cast shadows.

Take a look at this recording. Whenever the red object is culled, it of course doesn't cast a shadow. This looks very bad. Is there a way that I can make sure that the object is not culled, unless the light is culled? I tried giving the red object a SECTR Member component and increasing its bounds, but it doesn't seem to make a difference. Is there maybe a way that I can tell an object to never get culled by the camera?

 

Hmmm. Very interesting. SECTR tries to handle exactly that case when culling objects but there must be a case that I don't handle, probably either the animator or the combined mesh. If you can email a repro scene to support@makecodenow.com, I'll take a look.

In general, you can disable culling simply by making sure the object is not a child of an object with a sector or a member component.

 

Hello makeCodeNow,

I recently update a project to Unity 2017 and now, SECTR VIS crash when I launch a scene (even the example scenes). Does SECTR VIS support Unity 2017?

 

Can you post the stack trace of the crash here?

 

Sorry, I made a mistake. The project freeze (and not crash). So I dont have anything in the log file too.

 

Anything new concerning my problem?

 

I need more information than you've provided. Can you reproduce the problem in a fresh project with only SECTR in it?

 

I sent you by message a project.

 

Hello, I have a question about this asset. If I create objects dynamically inside a sector, will this objects be occluded? I ask this because my game creates objects dynamically, and the level is created procedurally, while the player is playing.

 

Yes, SECTR VIS is entirely dynamic. It doesn't really on any baked data so it should handle your use case just fine.

 

Hey, hope you're doing well! I've recently started trying out SECTR VIS in my project. How it works is I generate a maze of rooms from prefabs and place them in world.

In order to work with SECTR, I add the SECTR component to the room parent at runtime (after checking the static flag). However, I'm noticing that some rooms have blue bounds that stretch way past the room's boundaries - any idea how that could happen?




In addition, each room is separated by only a single door. This door is a single object with one mesh panel that opens and closes. Do I just need one portal on it, or do I need two - one for each room it's facing? I'll have to connect the portal to sectrs dynamically but I assume this is no issue

 

I'm guessing that it's due to a particle system or possibly something like a line rendered that unity returns odd bounding sizes for. You can use process of elimination of you have to in order to figure out which objects are the problem.

You only need one portal per doorway. Just make sure to set the front and back sector properties correctly.

 

Hey @MakeCodeNow, thanks for your quick support! That sounds good, we use volumetric lighting w/ particles via HX Volumetric so I bet that's what is causing the issue. As far as the portals go, does it matter which room is front and back?

EDIT: After further checking, it looks like we had some spot lights greatly extending past the room bounds to fake GI. I noticed that we could manually set the bounds of each member, but that could be cumbersome. Would it be possibly to easily implement a function that could reduce the bounds of all child members to be within a parent SECTR if they extend past it, maybe at runtime after I place my rooms I could call like foreach(Member m in members) { thisSector.ReduceBounds(m); }That might be a useful feature to have in general - if not something that you plan on implementing, would you mind pointing me in the right direction?

I appreciate your support!

 

Nevermind, I figured it out. What I did was create a parent Sectr MEMBER component for all objects extending past the room bounds, and modified the bounds to be within the sector. Then at runtime, my loader updates the bounds' position and rotation - problem solved!



I do have one question - in the screenshot, you might notice that my door objects are still visible because I read that portals can't be children of sectors - is it possible to change this, so that my doors can also be culled? Maybe a separate plane mesh for the portal and the door itself can be culled? They are in between sectors so not sure about the best way to handle this

 

Glad you got things working. That's basically what Member components are for. Another idea I could implement is a bounds filter that would let you choose if you wanted the bounds to be affected by renderers and/or lights and/or particles, etc. Lmk if that would be useful to you.

Regarding your doors, the solution there is to add a Member component to them. The doors (and portals) shouldn't be children of a sector because really they are a connection, and should be children of both of them. Of course an object can only have one parent, so the solution is that they should not be parented to either sector.

 

Excellent! If that filter would work on sectors not just members it could be very useful, my meshes stay within bounds automatically so it's really only lights, particles, etc - everything else conforms to a basic bounds shape nicely

Another question - I'm assuming members cannot be children of members, only sectors? Which is why sectors can be children of sectors?

 

Members can be children of other members. That's fine.

If you want an early look at the child bounds filter stuff email support@makecodenow.com and reference this thread.

 

Awesome, will do! SECTR has been really helpful so far btw, I've gone from 30 fps to 230 fps with a very basic implementation

 

Hey @MakeCodeNow, I have another question. As part of my workflow, whenever a player switches between dimensions, I disable the root game object containing all rooms, entities, etc in the old dimension. When switching back, I've noticed that SECTR seems to break - the only room that renders afterwards is the one the player returns to. Is there something I need to do to fix this? I checked and all of the member / sectr children (renderers, lights, etc) appear disabled even after I re-enable the parent game object
Thanks!

 

Are you calling load level yourself when you switch dimensions? Also is your disable logic in update, late update, or something else?

 

So everything is loaded into the same scene - no level load ever happens except when the game starts. How it works is a single call call is made:



This calls a coroutine that disables the old dimension:


And then calls another that enables the new one:


The root object is the one that all of the rooms (with their sectrs and members) are childed to

 

Hey @MakeCodeNow any update?

 

Sorry for the slow response here.

In short, SECTR VIS makes use of enabling and disabling components to do the culling. It's possible that disabling objects that SECTR is managing could cause problems for VIS. I'm curious, in your culling camera, is MultiCameraCulling set to true or false? False is faster but might be more easily broken by changes to the active state in the parent.

One other thing that you could try is to disable the culling camera before you swap dimensions and then re-enable it after the swap is complete. Can you try that and lmk if it works?

 

It's set to false

And that was a good idea, disabling it during the swap (before any disabling happens) seems to have fixed the issue except for the doors between rooms, which are sector-less members. I also set them to change their bounding updates to always while the dimensions are switching, and then back to static after the switch. Doing that caused them to also render correctly after switching dimensions!

So tentatively, it looks like that has resolved my problems! Thanks for your assistance, realtime rendering is a lot harder than static in Unity so I'm used to things not working 100% at first

 

Hooray!

 

Hey @MakeCodeNow, I've got a couple of questions for ya - I'll start with a (hopefully) easy one

I've got my rooms as sectors separated with door members in between with portals on them. I'm curious as to why the other sectors are being rendered even when the door is closed? For example, in this picture, my character is in the room on the left yet the rooms on the right are getting rendered:

 

My guess that it's todo with a light that has dynamic shadow casting enabled. To quickly see if that's the case, disable the Shadow Culling option in the SECTR Culling Camera component and lmk if that makes it behave more like you expect.

Also, to see culling in the editor viewport you need to have the culling camera game object selected and be in play mode.

 

Ah yup, that was it...yeah every single light in our game has to have dynamic shadows due to the nature of it (procedural)...disabling it instantly gave 50% more frames but I am noticing some flickering...do you have any recommendations? I really only need the lights in the current room to be culled, except in the rare case where we have lights extending into the next room

I noticed that light components in a sectr that I'm not in are enabled even though the sectr itself is not, I'm curious as to why that is

 

The way SECTR works is that if a light is visible and casts dynamic shadows, then every mesh that overlaps the light will be visible (because it might cast a shadow that is visible). If you know that lights only need to affect the meshes in a given Sector, then make them a child of that Sector and make sure they don't have a Member component on them. That will make sure that they are only considered when the Sector they are in is visible. For lights that really do overlap multiple sectors, giving them a Member component and making them a child of the overall scene is the only way to avoid shadow flickering.

 

Interesting! Okay that makes a lot of sense, so I was actually doing things backwards
So say I want lights to be considered a member only when a portal opens, would I just need to write some function to listen for that event, or is there some SECTR functionality I can use?

 

If a Light is a child of a sector, then when the door into that sector opens and is visible, the light will be considered, including the shadow casting behavior, so you shouldn't need to do anything special.

 

Okay...so I tried that, but I'm getting all these errors because lights are extending into the other rooms



I think that's why I added the member components, and I overrode their bounds to fit within the room, which is why I'm curious that they're being considered past the room - is it just a unity limitation?

 

Consider those warnings, not errors. If it looks good, it is good