[RELEASED] SECTR VIS: Dynamic Occlusion Culling

and for the solar system is possible as that to do?

 

It's possible but I don't recommend it. The solar system is mostly empty space. Frustum culling is very efficient as it is, and if you want to be more efficient than that you really need a very custom solution.

 

Hey, been using the plugin for the last week, and when it works it's really nice, so I'm hoping you might be able to help iron out the last of these issues;

So we have some Sectors added dynamically, but objects contain (static) Members already. Once the game loads and applies the Sectors, all the static members are occluded, and refuse to change.
I've taken to creating the Sector manually on some rooms, and it all works fine for Portal Group Culling, however objects behind occluders do not get occluded, which is slightly frustrating.

I've had instances where "Fix Shared Children" would share objects in adjacent scenes, and no longer occlude the rooms once the portal had be closed. I fixed this by using the Portal Determined variable. (Just didn't know if it's worth limiting occluders to certain sub-scenes with Unity Multi Scene stuff. Although it should all be childed... I don't know, just spit balling. )

I'm using Unity 5.4.0.b19, and just to re-iterate, my main issue is Static Members not being occluded behind an Occluder.

 

This is pretty puzzling. When you say "static" members you mean that they are checked as static in Unity in the editor or something else? One of the assumptions SECTR makes is that Members marked Static in Unity only need to be setup when they are first created, and they never do anything after that unless you call ForceUpdate() on them. I suspect that's the problem you are having, so try calling ForceUpdate after creating the dynamic Sector.

I'm not sure why you are having the Occluder problem. The most likely issue is that Occluders are quite conservative. The entire AABB of the Member must be occluded by the Occluder otherwise it will not have any effect. Also make sure that the normal of the Occluder is facing towards the camera (orientation matters for Occluders).

Fix Shared Children just does the most conservative thing possible, which is to add the Member to all Sectors whose bounds overlap the Member bounds.

For Members that never move, Portal Determined is functionally equivalent to making them a Child of a given Sector.

 

Hey, thanks for getting back to me.

Yeah, to solve some of my issues, I realised what the Fix Shared Children thing was doing, and as soon as I set all the relevant objects to Portal Determined, it worked out okay. Most of the SECTRs are no longer dynamically created, but that's okay.

But Occluders are still not working unfortunately. I don't know why, also objects aren't being occluded once off-screen either. I know Unity does that by default, but I noticed SECTR_VIS started doing it on some objects temporarily, then that stopped happening.

I've tried mutliple occluders, and I'm still slightly baffled as to why the objects aren't being occluded. The Camera shows the generated Frustrum behind the occluder (showing what should be occluded), but they're all still there being rendered.

I've set up a demo scene, and tried everything individually there and that seemed fine.

Could it be that the SECTR is set to group culling, as well as are the members inside?

 

It sounds like you are basing this on watching the in edit view of culling. For that to work, to have to have the culling camera selected and be in play mode. You can also look at the draw call stats anytime.

In general, I'd recommend you make some simpler test scenes. It sounds like your main scene is pretty complex and it'll always be hard to go from nothing to full occlusion culling in a big scene.

 

I'm not basing it purely on the video. I mentioned that I've set up test scenes as well where things worked, so I know nothing is broken in the basic VIS side.

I've tried implementing things one at a time and bit by bit as well. Occlusion has worked for culling full sectors, which is great and already been a great boost, but now I'm trying to occlude smaller objects. ( Mainly tables, so the objects placed on them get occluded ).

I've override the bounds and can see the white box. They're all set to static bounds, as they never move, and set to Group culling. They're also portal determined by what room they're in.

I've selected the camera, and those tables are just not occluded at all. Not even when they're off camera, or behind an occluder. (And I said before, I can see the blocked occlusion bounds using the gizmo.)

 

Is simple culling checked in the culling camera? That doesn't work well with occluders currently.

 

It is not.

 

Strange. It's hard to do much more in text. If you are willing to share a repro please email support@makecodenow.com.

 

Unfortunately the project is much too large (and private anyway.. ) to share, and I can't quite figure out how to reproduce it.

What would be the conditions for objects not to be occluded by an occluder?

 

To be occluded, the sector that contains the occluder must be visible, the occluder normal must be pointing toward the camera, and the object's aabb must be fully contained behind the occluder.

 

Hey.
So I did some investigating and I have a feeling it's to do with lights. We have quite a few dotted around in a small environment. Turning off Shadow Culling will occlude the objects correctly, however this leaves some undesired effects (you can probably guess.)

However I'm a bit confused, I've turned off _every_ light in the scene, and yet the objects are still not occluded unless I turn shadow culling off.

However some objects are occluded over others, which is strange.

Our environment has two "states". The building is static and only changes material, but the objects are toggled between group A and B.

Weirdly, group B is always occluded correctly with no issues, shadows or not.
Group A however, never occludes unless shadow culling is off.
The second weird thing is, if I put all the objects in Group A into group B, they'll become occluded correctly.

Is there something to be wary of with lights? Is there any known issues with deferred rendering?

 

Sounds like some very good investigation.

The issue with lights is expected if they cast dynamic shadows. The problem is that if a light casts shadows any object that's inside the light is effectively visible as long as the light is visible (ie you can see the shadow even when you can't see the object). Disabling shadow culling skips this logic and so looks more like what you expect if you don't take cast shadows into account.

Does that explain the behavior you are seeing?

 

I understand all that, but I seem to have the issue even when I disable all the lights in the scene.

So the objects aren't occluded once I select every t:Light to off. Not sure why.

Also what is the Dir Shadow Caster? I read the tool tip but I'm not 100%, or if it could help. Is there a way I can only test the lights per room?

Edit:
Okay, adding members to lights seems to have helped. However when I toggle a bunch of child objects to be enabled/disabled, some sectrs no longer get occluded, even if the portal is closed.
Is this because it's potentially grabbing objects from other scenes when objects change?

Edit2:
We also have a bug where portals are occluded after an actual build

 

When you add member components to objects they can be part of multiple sectors (whether ones overlap the AABB of the light). That probably explains part of what you are seeing.

Not sure about the build specific bug. SECTR has relatively little editor only code.

 

Thank you! for answer

 

Hey, we are looking to buy SECTR VIS, but I have a question.
Is there a way to close and open portals manually? We are developing a open world scene and we need to open and close portals manually.

Thanks

 

Yes, there is via the portal flags. Just set the closed flag on or off.

 

I bought this asset, I think it is really neat and good.

However, I just cant see any performance increase, instead my script performance worsen. Maybe I am missing something.

1. I set sectors in my open world ( terrains and objects )
2. I attached the main camera script.
3. I see all the culling in the editor it works good, however there is no performance update.
4. Extra question how can I set the distance of culling ? ( I mean distance of how far objects will be rendered )

( Note I also tested your open world demo, it works great, hides terrains however I do not see any performance increase no draw call decrease, no fps increase, no less mesh vertices ? )

Any idea ? regards.

 

Hi. Glad you like SECTR

In general occlusion culling requires spending CPU. The cost of occlusion culling is, ideally, lower than rendering those objects, but it isn't guaranteed to be. Especially in wide open scenes, occlusion culling may cost more than it saves. In open areas, you really want to look into streaming (ala SECTR STREAM) as well as LODs (which SECTR VIS includes).

 

Thank you. Can I use STRESM and VIS at the same time ? Because when I assign sector attachments to objects, VIS auto culls them and STREAM also does its thing. ( I mean it will not be problematic ? )

 

You can use them at the same time, but for on open world game I'd just focus on steam. Add VIS later if you see significant amounts of occlusion.

 

Out of interest, what does Bounds Override actually do? The docs don't explain it very well.

I assumed the bounds added padding from objects being culled?

EDIT:
Had a poke around in the code, I'm guessing Bounds Override just detects if an object is in another Sector?

Is there a way to increase an object's "render bounds"? So it doesn't get frustum culled straight away, we can add some padding?

Basically, we have a fireplace, creating a nice effect, but if you look up, the fireplace becomes culled, and the light will now cast a shadow of the objects ontop of the fireplace.


Separate question:
Also is it okay to have multiple Sectors on one object? I have some rooms that aren't uniformly square, and more like an L shape, but if I use a full cube, it will overlap the adjacent room. It's really an issue, just curious.

 

Bounds override simply let's you manually specify the size of a sector. By default the sector is as big as all of its children combined.

SECTR should be aware of lights and shadow casters (unless you explicitly disabled shadow culling in the culling camera component) or you are using some kind of nonstandard light.

Member components can certainly be in more than one sector at a time.

 

Hey, thanks for getting back to me.

Just wanted to ask this again: Is it okay to have multiple Sectors components on one object? I have some rooms that aren't uniformly square, and more like an L shape, but if I use a full cube, it will overlap the adjacent room. It's really an issue, just curious.

Shadow culling is disabled for us, as we have a small interior house everything is done in, and unfortunately shadows end up being cast on all objects throughout the house, causing the occlusion not to work very well when calculating shadows. So I'm guessing it'd be nice to have a way to increase the renderer bounds in this situation, unless there's a way to help limit the shadow culling?

 

You should not have multiple sector components on a single game object. That will definitely cause problems.

You can use the bounds override to explicitly set the bounds of you need to, but I recommend you use that judiciously.

 

We've tried adjusting the bounds to cover the shadows, but because it doesn't overwrite the render bounds, the fireplace still gets occluded to early.

 

I think you just found a bug. I've added it to my internal tracker. Will try to get it fixed for the next version.

 

That's great, thank you! Do you have a rough guesstimate on when the next release might be?

(If it's going to be a while, We'll just add in a hack for now)

 

It'll probably be a week or so. There's some trickiness to in this particular fix.

 

That's fine, thank you! Was wondering if it was more in the range from a day to a few years, haha! Good luck!

 

Hi, ttchance. On further reflection I actually think this is a dangerous change to make in SECTR by default. However, the change is easy to make. In SECTR_Member.cs just change this:

Code (csharp):

1. if(OverrideBounds) {
2.   totalBounds = BoundsOverride;
3. }

to this:

Code (csharp):

1. if(OverrideBounds) {
2.   totalBounds = BoundsOverride;
3.   renderBounds = BoundsOverride;
4.   lightBounds = BoundsOverride;
5. }

 

Okay will do, thank you!

Any particular reason why you think that this is dangerous? Should we be aware of some potential bugs just in case?

It's a shame as this is a good plugin, but for some reason it's making very small interiors difficult! (We've just announced our game by the way, if you wanted to have a look)

 

It's actually not dangerous at all for your game. The issue is that this specific change isn't optimal for all scenarios where bounds overrides are used. For example, bounds overrides are used in the terrain splitting system, but in that case you really do want to render bounds to not change.

One other thing you might want to look at is the "Portal Determined" behavior in SECTR_Member. This allows you to set an initial sector for an object and then only have that sector change when the object goes through a doorway.

 

Yep! We've already done the portal-determined, it solved a lot of issues.

Is there any debug stuff we can use to figure out where the issues with lighting we're having? I'd very much like to try and make use of shadow culling, but if not then no worries, the render bounds increase should be great alone.

 

There's not really anything else beyond what you're already using. Glad to hear is generally working out.

 

**EDIT**
Actually I tested it in a build and it works, though its stalling a lot (just saw this is a Mono/Unity issue)
Not quite a huge issue for me, I was mainly curious how much threading might reduce the cpu time (but it's not that much to begin with )

---

I'm noticing that if I try to use threading on the Culling Camera it hangs Unity.

Noticed it 1.2 but I just upgraded to 1.3 and have the same issue. Testing in a blank project with the basic culling scene, I set the threads to 1 (instead of 0) and it freezes unity when in play mode, CPU sits at 17% usage on the Unity process.

(This is in Unity 4.7)

 

Yeah, the specifics depend on which version you are using, the number of threads, and the system you are running on, but in many cases you run into that bug in the mono runtime.

 

It seems the newest version of SECTR VIS is no longer working with DunGen. By not working I mean it is culling very strangely, mostly not at all.

 

There is a new flag in Culling Camera called Multi Camera Culling. Can you check it? If that fixes it, do you have multiple active culling cameras in the scene?

 

Sorry couldn't test it til now. Yes the multi camera box is checked. The error I get doesnt happen in the previous version. It says:
MissingReferenceException: The object of type 'MeshRenderer' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
SECTR_CullingCamera._HideAllMembers () (at Assets/SECTR/Code/Vis/Scripts/SECTR_CullingCamera.cs:1725)
SECTR_CullingCamera.OnPreCull () (at Assets/SECTR/Code/Vis/Scripts/SECTR_CullingCamera.cs:559)

This error shows up and the count just keeps climbing. Nothing culls except strangely objects in the starting room and the 1st wall separating the 1st room from the 2nd.

I'm going to revert to the previous version for now as my game is going through store review right now. I was just hoping for some of the CPU enhancements of the new version for a lil performance boost. It's worth noting my game is VR and perhaps that is complicating things. Also I am on the latest patch of Unity 5.4. Either way I love your product and I will just periodically check future updates for compatibility perhaps the next version of Sectr VIS and DunGen as maybe it is on that end too.
Thanks for your time.

 

This is my bug, but it's easy to fix locally. Just add if(child.renderer/light/terrain) checks in HideAllMemebers and ApplyCulling, just like I've already done in UndoCulling.

 

I do appreciate all the help but I couldn't find if(child.renderer/light/terrain) in UndoCulling to reference for adding it to HideAllMemebers and ApplyCulling. I am not a coder and made my game entirely through Playmaker. I am comfortable waiting for a later version. Thanks once again though.

 

If I use Occlusion Culling system do I need to use stream system too? I mean when I use occlusion culling why should I stream my game?

 

You don't need to, no, but usually the question is more "if I'm streaming do I need to use OC". Streaming actually removes entire chunks of the world, saving memory and CPU and GPU. OC only hides objects that aren't visible, which can save CPU and GPU but won't save memory and is, of course, view dependent. Basically, if your game is amendable to streaming, you want to do that first, and then layer on OC if it makes sense.

 

Hey! I'm back again

The efficiency updates were quite nice and noticeable, so thank you for that.

However there have been a few issue since updating and has broken some of our visual effects.
We've managed to get around some of them by ticking the "multi-camera" option, so even though we're not using multiple cameras, it's still fixed some of the issues.

The biggest issue we have at the moment, is that you cannot manually enable/disable Light components.
If you create a basic Sector, add a light inside it, if you look at the light and disable the Light component, it will instantly re-enable.

Unfortunately this is quite troublesome, as we have a light switch that toggles the enabled state of the Light as a mechanic. Is there a way to cache if a light was enabled/disabled before running the occlusion on them? We've had a few issues with renderers in this case as well. I can try and supply a test scene if you need it.

 

Hmmm. Tricky problem. I'm thinking about a more automagic solution, but until then here's something you can do - add a Member component to each object that needs to be toggled. When you disable the light (or renderer) component, also disable the Member component. That will basically tell SECTR to ignore that object while the Member component is disabled. Lmk if you have any issues w/ that.

 

I just posted 1.3.2 which fixes this issue.

 

Ah just saw this. Thank you going to test out tonight.