Search Unity

Isnt it time for a new occlusion middleware?

Discussion in 'General Discussion' started by AndersMalmgren, Oct 1, 2019.

  1. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,358
    Unity have used Umbra for a long time now, and its pretty underwhelming.

    Example, here it renders almost parts of the entire map within the camera frustrum

    upload_2019-10-1_23-20-38.png

    First you mightj think its this door that causes it,

    upload_2019-10-1_23-24-4.png

    But if we look from the view of the corridor

    upload_2019-10-1_23-24-40.png

    Its fails to hide everything behind that metal arc wall. And before that arc wall you hoped this large wall would occlude something too

    upload_2019-10-1_23-25-50.png

    I guess if you are on SRP you dont need to bother with occlusion because of the excellent batching there. But on built in and with lightmaps that makes batching harder its important with occlusion
     
    Peter77 likes this.
  2. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,151
    I wouldn't be surprised if there were a couple of occlusion middleware solutions that are performant enough to benefit SRP based projects.
     
  3. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,175
    I believe you just answered your own question seeing as the SRPs are the future of this game engine. :p
     
  4. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    6,493
    I'm just wondering if we can do custom sorting with srp, I want to do it per large room tile rather than per object type only.

    Basically if I have a dungeon there is 3 main opaque, say enemies, decorations and wall. The room are rather convex, so enemy in a room will cover the room visually because the tend to be in the middle, also they get close to the player so cover a lot of thing. Decorations happen generally at edges of rooms covering them. Room take the biggest space on screen but is covered by everything else inside it, but close room cover everything in other room.

    Sorting by room first and you get a lot of early culling of distant fragment, but then you get overdraw with elements inside the room. Sorting enemy first, you potentially reduce overdraw on the close room but enemy in other room get covered after the room pass, enemy tend to have more expensive fragments. If it's procedural you can't preprocess the culling anyway. Undifferentiated front to back does not guarantee the room to be sorted after close enemy due to its scale and enclosing nature it depend on player position and orientation.

    What I want really is to create room tile group, sorted front to back, then each room sorted from dynamic to room geometry.

    Haven't found a way to do that in srp yet.
     
    Martin_H likes this.
  5. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,358
    I was a bit sarcastic, offcourse occlusion is needed even if you have a near perfect batching ;)
     
  6. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    Baking occlusion is really past gen.

    This is what I'm currently using instead of built-in one. Works better than default one and no baking involved as well. Best of all - it works with procedural content.
    https://assetstore.unity.com/packages/tools/utilities/gdoc-dynamic-gpu-occlusion-culling-139079

    It has some rough estimations when it comes to transparent meshes, but that's fine I guess for such technique. Not every platform is supported (yet), but its good enough for PC.

    To be honest, baking anything is past gen. Unity is way behind in its lighting / render department comparing to the current state of the game dev industry.

    HDRP will probably going to solve this in a ten years or so, but really?

    Occlusion baking takes ~50-100MB per large scale scene and impossible when using procedural level generation. Lightning probes are awful. Progressive GPU baking doesn't work because it cannot fit large scenes in vram even on smallest res. CPU one takes ages to bake.

    And realtime shadows? Well, even with a lot of instancing they eat a crapton of passes.
    Oh the GI. Not even going to discuss this as will definitely derail the thread.

    Anyway, sorry about offtopic.
    Occlusion is not the worst part. But its sure an artifact from the past that will not fit every need / quality.

    Good thing its not that hard to make your own / use something from the store that's better.
     
    Last edited: Oct 3, 2019
  7. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,358
    Have looked at it, you would say that it is good even if you are on baked lighting like me? They talk about Realtime directional lights etc.
     
  8. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    Plugin itself works by disabling / enabling rendering via Mesh Renderer and its shadow casting property.

    So if those do not mess around with baked shadows then yeah, it should work just fine.
    Realtime directional light is there to figure out how lights / shadows are occluding, e.g. calculating what can produce shadows in realtime and what can be disabled. Perhaps you won't even need that for baked lighting.

    But the plugin above is definitely works way better for me than a built-in in procedural / realtime lighting setup.
    Although its C# wrapper can be optimized a lot (has some editor overhead, build is less affected).
     
    Last edited: Oct 3, 2019
    AndersMalmgren likes this.
  9. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Ouch. That's potentially a significant amount of main thread cpu time. Would absolutely not work in our game.

    Not occlusion but the new DOTS hybrid renderer is worth looking at because it moves frustum culling to the job system and is significantly faster at that then the built in frustum culling. And it would likely be fairly simple to convert that asset to use the hybrid renderer, and all that enabling/disabling would be in a job.