Graphics GPU Occlusion Culling without baking and raycasting

most likely the 2.0 version will work on modern phones with vulkan/opengl es 3.2 (or maybe 3.1)

There is no special function for this, the general approach is to call GDOC.RemoveOccludee, change GDOC_Occludee's properties (movementMode in your case) and add it back with GDOC.AddOccludee

 

Hi!

Nice asset! When we can expect version 2.0 for mac, linux, DX12 and so on...?

Looking forward to that day!

 

I think in May or so

I have some ideas but no ETA yet

 

I bought this today to see how it would work on a very heavy scene I am working on. I only spent a short time with it so I can't be too harsh. However, after attaching it to the camera, setting the light source, the character and making sure all appropriate objects are static I saw 0% difference in FPS. Later today I'll look for the documentation and see if I missed anything.

 

Documentation is kind of W.I.P. and doesn't explain some things, so you better ask me on Discord

 

I bought this asset，And is the core code provided as a DLL and not open？

 

It will be available in one of the next versions, once I clean it up after the latest big refactoring
Note that it's written in C++ and uses native DX11 functions so it can't be used on other platforms
Also, a new engine without a DLL, written completely in C# and using only Unity's built-in functions, will be released in May or so

 

Will you also be supporting skinned meshes?

 

Yes, soon
Now you can make a Generic GDOC_Occludee and set its size to encapsulate all the possible poses
Also you need to set management mode to Without Shadows because Generic occludees currently don't support shadows.

 

Awesome! 200-300 AI in one area will need a performance boost.

 

I'm trying to think of a way to do this. When ground based meshes are removed behind the camera, except for the Skinned Meshes (AI), as there is no ground based mesh anymore they fall through to the terrain underneath. I could hibernate them when a 2nd camera view is not facing them, or switch off gravity. Any other suggestions?

 

Try to set fullDisableDistance to 10000 so game objects around camera won't be disabled completely

 

It helped. But I think it needs something else.. I'll work on it some more, maybe once skinned mesh option is added this will help, especially when customizing it to switch off certain features with AI.

Edit: for now I've excluded the ground.

 

A public bool on GDoc would be nice, that if set only disables all renderers instead of the whole GameObject.
That would also solve this Ground object.
And maybe it could get a list of Scripts/Components too that should be disabled.

Then if something should be disabled, you could just disable the renderer, and if it is for example a KI, you could add it's movement Maybe even it's rigidbody or something like that. Then it is not visible and also frozen, but does not disappear or fall into the void etc...

I have a big Problem when stuff just gets disabled, it's own Control mechanisms do not work anymore so it never gets deleted if it should.

thanks!

 

If I decide to use it in a project, I certainly want to have all the code to make sure I can make small changes and debug it at any time, looking forward to the new version！！！

 

There is no global bool, you can either increase fullDisableDistance to 100000 or control it per object by GDOC_Occludee's property allowFullDisable (set it to false after you add a chunk).
Callbacks for finer control will come in future versions

 

GDoc disables the GameObject, Right?
My idea was to disable the renderer(s) instead. And let the user decide by having a Checkbox from a public bool in Gdoc component.
Can I change it myself? My Problem is (I believe) because invisble stuff is also inactive Nothing gets destroyed anymore and I run into Memory Problems...

I have heavy Problems that only occur if I play a longer while. first everything is great.​

 

By default it disables renderers (unless it's Generic, which is not your case)
Game objects get disabled when they're further than fullDisableDistance from the camera
Setting it to a value like 100000 will prevent it from disabling game objects

 

Now I understood. Thanks!

 

Looking forward to broader platform coverage, especially Mac. Thanks!

tone

 

GDoc seems to work perfect with Unity 2019.1.0f1 (Release candidate).
Found no Errors until now. Even got a Little bit more Performance with Unity 2019.

 

@everyone
Not related to GDOC, just a random find — if you're using the built-in occlusion culling, check out your Library/Occlusion folder, it might be like this, slowing everything down

 

Is the enabling and disabling renderers as fast as the LodGroup under the hood magic?

 

I didn't try it — toggling renderers is fast enough

 

Any ongoing work on supporting OpenGL? (Mac, Consoles etc) Coz, to be honest, we've long surpassed the time when PC only indie games were the thing. I love the asset but it's not worth it if it's windows only.

 

My player falls through the terrain after about 20 seconds with GDOC enabled. Any ideas?

edit: I think disabling psOmnidirectionalBounds fixed it. My camera is 360 degree on the player, regardless of which way the player is facing.

edit2: no didn't fix it.

 

Most likely your player is added as a static occludee
Add GDOC_Occludee with default settings (excluded with children) to your player

Not sure about OpenGL, but Vulkan will be supported in the 2.0 version

 

Thanks. I did try that earlier, but it still did it - I also specified the layer to None. I switched off Auto Height, so far it hasn't done it. But sometimes it will drop through the terrain randomly, especially when no player movement - I'm guessing that it does this when GDOC scans. I'll add GDOC Occludee again on the player.

 

Maybe scanning causes a lag (i.e. high deltaTime and wrong fixedDeltaTime) which is not correctly processed by your movement scripts
Try to disable gravity until scanning is done

 

Good idea! I'll try that.

edit: difficult to disable Gravity. As soon as player jumps, gravity is enabled.

Not sure what else to try.

 

Hi, does LWRP support means that this tool will work with mobile devices ?

 

don't let him jump while it's scanning
actually I wouldn't even hide loading screen until it's done

No, this version is DX11 only
2.0 might work on high end mobiles

 

Sometimes it drops the player through the terrain after 2-3 minutes, I don't think waiting 3 minutes to play the game would be a good idea. When the initial loading takes 20 seconds so far for an open world. So for each streamed in chunk, it would do a scan which could potentially cause the same issue. I've not tested that theory though as most of my buildings are sitting on plane meshes. So the player wouldn't drop through them. This would have issues with AI on the terrains though. This means that GDOC is unusable in my case, but I will try a few more ideas to resolve it before I give up.

 

Scanning definitely shouldn't take 2-3 minutes, it's max 5 seconds for really dense scenes (10-15s in editor)
If you stream chunks from your scripts, you better disable the scanning (both methods) and call GDOC.ProcessNewObject whenever you load a new chunk

GDOC doesn't support terrains and if you also excluded the player object, it shouldn't affect their physics interaction in any way. Can you record a video?

 

ok, i will wait for that release for now.

 

I believe when the background scan starts (20-25) seconds that is when the player drops through the terrain, but could be wrong. I've excluded the player. I don't believe it's anything to do with the chunks as its the terrain or player that loses collision. I've turned off GDOC on the camera to see if it was anything else causing the issue, only when GDOC is on does this happen.

Why would GDOC have an impact on collision, does it turn it off while doing the scan?

Video on its way..

 

background scanning is limited to 50 microseconds per frame and can't cause lags unless you changed the limit
try to set fullDisableDistance to 10000 and see if it still occurs

 

the performance of setting fullDisableDistance if set to 10000 is really bad though. It's almost like not having GDOC on.

 

fullDisableDistance if set to 10000 also doesn't render everything in when you are looking at the buildings, some show up, but not all. It does fix the collision issue though - but it may just be delaying it or preventing it due to the distance.

 

I have an idea! Would GDOC be scanning a trigger and enabling it? I use a trigger to disable the terrain when using Microsplat - Terrain Holes https://assetstore.unity.com/packages/tools/terrain/microsplat-terrain-holes-97495

 

that's something really weird
if your're using the version from the asset store, try a newer one posted on discord

 

I'll try the discord one later. Run out of time now.

 

Well it turned out to be GDOC activating a trigger after adding a few debug logs on the triggers. Made a few script changes to only allow certain tags to access the trigger, and added an Occludee to the gameObject (covering all bases) - so far no dropping through the terrain.

 

There's no native Vulkan for MacOS, there are only third-party drivers... which don't work properly on anything earlier than 10.14 or iOS 12. So yeah whatever. This is basically Windows-only now and will become Windows / Android only with 2.0

 

Hi,
I have a couple problems with GDOC when i use it. Unity editor (2017.2.1f1) crash every second play, and after scanning GDOC didn't occuled objects only when i resize game window in editor and only for this frame.

Code (CSharp):

1. ========== OUTPUTING STACK TRACE ==================
2.  
3. 0x00007FFAF9F385D1 (GDOC) CompileShaders
4. 0x00007FFAF9F38B18 (GDOC) CompileShaders
5. 0x00007FFAF9F33F27 (GDOC) RequestResults
6. 0x00000001408A9C82 (Unity) GfxDevice::InsertCustomMarkerCallback
7. 0x0000000141D1AB1A (Unity) GfxDeviceWorker::RunCommand
8. 0x0000000141D1EE1B (Unity) GfxDeviceWorker::RunExt
9. 0x0000000141CFE042 (Unity) GfxDeviceWorker::Run
10. 0x0000000141D0B169 (Unity) GfxDeviceWorker::RunGfxDeviceWorker
11. 0x00000001407B4EF8 (Unity) Thread::RunThreadWrapper
12. 0x00007FFB57174034 (KERNEL32) BaseThreadInitThunk
13. 0x00007FFB59B03691 (ntdll) RtlUserThreadStart
14.  
15. ========== END OF STACKTRACE ===========

 

Weird, what version is this? I don't use CompileShaders now and I don't remember it ever being called from RequestResults

 

Version 1.2

 

Try with the latest version from Discord

 

Problem disappear in unity 2017.4.26f1 and VR render mode single pass, for now

 

Does this work on the latest XBox, too?
It works perfect for me in Windows Standalone PC with DirectX11, and I am thinking About UWP and Maybe even XBox support...

Thanks