Jump to content
The Dark Mod Forums

Occlusion culling using world geometry


MirceaKitsune

Recommended Posts

This may have been discussed long ago on Discord and I since forgot the details. It's an option that seems so simple and effective it kept itching me to ask in more detail. The latest dev version increases performance by +20 FPS which has me excited to know more on what seems like it could be a final huge optimization.

At the moment we have view frustum and visportal culling but no form of occlusion culling. I wonder how much FPS we'd gain if we also used world geometry to derender what the player can't see. Would it be worth the effort to add this even as a hidden setting to experiment with? Given it was never attempted in all those years (to my knowledge) I imagine there's a reason and I may be excited for nothing, I'm sure @stgatilov and other devs can offer more insight but I'm happy to hear what anyone thinks. Here's my exact proposal:

Occlusion culling would be done after portal culling (which wouldn't change in any form) ensuring only entities and geometry in the same room are compared. Only world geometry (solid brushes) are used to mask: A counter-argument was that calculating this mask will be costly... world geometry is almost always very simple, checking a few boxes should cost almost nothing compared to the gain of hiding every light / model / portal behind any wall. We can probably iterate through all world surfaces facing the camera within a distance limit if necessary, then use the resulting rectangles to preform the same overlap calculation as portal faces but in reverse (they close behind them instead of opening); Especially now that we have entity scissors and efficient 2D detection of 3D projections this could be huge :)

My reasoning is no matter how well you portal your map, you'll always have many entities hidden behind a wall but not a portal, the engine still renders so much stuff you can't see: To even try getting close to this level of efficiency, every single edge and corner would need to radiate portals in each complementary direction, an impossible nightmare for the mapper to even attempt which would destroy dmap if they tried (I got close with limited success). Visportals will always be the simplest and most effective form of culling, but they're ultimately markers to separate rooms and represent openings thus can't cover all situations: If on top of that we also masked by world brushes the gains could be remarkable.

Edited by MirceaKitsune
Link to comment
Share on other sites

Occlusion culling is not as easy as it looks.

For instance, if you simply check entity's bbox against individual brushes, then most of the entities behind walls would pass the check because no individual brush covers a whole entity completely. Also, there are dozens thousand brushes on large maps, you cannot iterate through them naively.

On the other hand, this is close to the concept of "antiportals". That's when mapper puts an "antiportal", ensuring that everything behind it is occluded, and the engine takes it into account whenever it works with portals. But this requires work from mapper, and I don't think it would provide much help.

To get serious benefits, you need to recognize the whole wall consisting of many brushes as a single inpenetrable surface, at which point you necessarily have something really complicated.
I thought about doing Umbra-like occlusion culling on brushes (with automatic portals and conservative rasterization inside), but I realized it's ton of work. There is always something else to do.


By the way, the recent change is not about what player does not see, it's about what light don't see/hit. Just rendering a surface is very cheap because of depth prepass, but light interactions are costly with all the textures, soft shadows, etc. Realizing that you don't need light interaction on something you see is quite beneficial.

The problem with original Doom 3 engine is that it basically lights up all objects within light volume. With the exception of static shadow-casting lights, portals are just ignored! I have expanded usage of portals to dynamic lights.
It might sound funny, but there is still some room for improvement in this area...

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Old topic:

SteveL had most of the basics of func_occluder \ antiportal working but was struggling with shadow handling and a few related concerns. Quake mappers would probably love the feature since they've already been using it for years but it's hard to say whether TDM \ Doom 3 folks will really want to add another optimization workflow? Admittedly func_occluder seems to be easier to visualize than portal closure behavior so it might not be as error prone.

  • Like 2

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

The problem I have with antiportals is that using them is too hard.

If the obstacle is small, then antiportal won't help much.
If it is huge, then it's probably some building and you try to optimize outdoors area.

The antiportal over whole building makes sense, but:

  1. Rectangular antiportal is not enough: you need something that fills as much of the building's volume as possible, at least a box or two crossing antiportals.
  2. Are you really 100% sure player cannot open doors and look through the whole building? Are you sure you would set antiportal in such a way that it won't block something visible?
  3. Your antiportals cannot affect all areas like visportals do, because when player is indoors, the antiportal will block his visibility. You want antiportal to work only when player is outdoors, so you need some filter with locations.

It becomes so messy that if a mapper wants to optimize his building, he just better place all the portals around and hope for the best.

  • Like 1
Link to comment
Share on other sites

Thanks for the clarification! I had no idea antiportals were a thing, I can't find an antiportal texture or entity in DarkRadiant so I presume it comes in another form? This means the behavior I'm imagining is already coded in there somewhere: Only change then would be automatically treating every solid brush as an antiportal, of course without having it derender itself only what's behind it... at least that's what I'd initially think, reality is always more complex.

Obviously we don't check all world surfaces on the map: Visportal culling acts first so any wall that isn't in an open room doesn't exist from the start, same for surfaces that don't poke into the view frustum and are outside your FOV... if a smart approach is possible we could even check walls in order of distance from the camera so the mask masks itself and even walls covered by other walls are dropped. Only if a front-facing brush surface that wasn't portal-culled pokes into view it's calculated as an occluder; The engine then checks all entities that weren't themselves already culled by portals / frustum and removes those found to be completely covered by a wall's projection.

This could be a big success is it could do all of 3 things: Hide models that don't poke beyond the mask, disable lights who's radius box is fully covered by the wall, and close portals that are fully covered by a wall meaning whole rooms can get hidden when their doorway is masked by an occluder. (Anti)portals do all of those things I believe, so it's a matter of somehow getting all surfaces to act as such in an optimal way.

Edited by MirceaKitsune
Link to comment
Share on other sites

I was thinking about this the other day, after seeing that Source engine add a func_occluder entity, while idTech4 has not, Valve at lest thought they were still useful for something, I bet they are used to help optimize the HL 2 outside areas, that game has plenty of those.

That lead me to search about the subject and saw this two links, imo they have some useful info.

https://www.gamedeveloper.com/programming/rendering-the-great-outdoors-fast-occlusion-culling-for-outdoor-environments

https://bazhenovc.github.io/blog/post/gpu-driven-occlusion-culling-slides-lif/

 

  • Like 1
Link to comment
Share on other sites

I investigated the topic, and I still think it is too hard.


Precomputed visibility is perhaps the best thing for us. So we can split space into cells, and precompute whether cell A and cell B have unoccluded straight line connecting them.

We can limit occlusion only by brushes: there is no need to take models/patches into account.

Precomputed visibility should be done on per-area basis. When we compute the visibility data for one area, we consider all visportals and all other areas opaque. In other words, we only check for direct visibility within the area. If such information is available, it can be combined with existing visportal&area traversal code.


The main problem is how to precompute visibility on per-cell basis.
A solution must:

  1. Be conservative: you don't want to occasionally see small holes into nowhere
  2. Do perfect occluder fusion: otherwise a big house would not occlude most of the stuff behind it.
  3. Have sane build times for brush geometry of our scale.

This inevitably leads to pretty complex algorithms.

 

If mapper can add a special brush and say "this is major occluder in visarea N", then we can probably (not sure yet) verify that he is correct in saying that, and simply raytrace this occluder during visportal traversal.
But realistically... I don't think mappers would really use this tecnhique, except maybe for a very few people/missions.

  • Like 1
Link to comment
Share on other sites

I was just thinking if a conventional depth pass may also do the trick: Render world geometry as an untextured unlit Z-buffer at a small cheap resolution (eg: 256x128 default)... knowing each entity's distance from the camera, an entity is discarded when its projection doesn't touch at least one pixel darker / further than its own location. Could that work?

3 hours ago, wesp5 said:

Honestly, I have an old computer with an Intel i5 2500 and a Geforce 1050Ti and TDM runs just fine. I have to lower antialiasing and such maybe, but TDM is all about the gameplay and not so much about the graphics in my opinion!

Something worth noting: If you own a relatively modern video card (last 5 years or so) and use an 1080p @ 60 Hz monitor, you may get the maximum performance... even that requires lower quality settings (absolutely no MSAA) but now it's possible to get a constant round 60 FPS. The big problem is playing on either a 4k or 144 Hz screen and hoping to reach anywhere near your VSync limit, god forbid both at once. Most of us don't want more pixels in our monitor so 1920x1080 is still the expected standard, unless we have TDM players who play on a large TV which wouldn't surprise me. Yet we are going for 144 Hz... once you get used to it and can't go back, anything under 120 FPS starts to feel like you're lagging. At the moment I get +80 FPS in most areas, +100 in some, +120 very rarely when I'm lucky... the full 144 only if I'm literally staring at a wall and of course in the main menu.

Edited by MirceaKitsune
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • OrbWeaver

      Does anyone actually use the Normalise button in the Surface inspector? Even after looking at the code I'm not quite sure what it's for.
      · 7 replies
    • Ansome

      Turns out my 15th anniversary mission idea has already been done once or twice before! I've been beaten to the punch once again, but I suppose that's to be expected when there's over 170 FMs out there, eh? I'm not complaining though, I love learning new tricks and taking inspiration from past FMs. Best of luck on your own fan missions!
      · 4 replies
    • The Black Arrow

      I wanna play Doom 3, but fhDoom has much better features than dhewm3, yet fhDoom is old, outdated and probably not supported. Damn!
      Makes me think that TDM engine for Doom 3 itself would actually be perfect.
      · 6 replies
    • Petike the Taffer

      Maybe a bit of advice ? In the FM series I'm preparing, the two main characters have the given names Toby and Agnes (it's the protagonist and deuteragonist, respectively), I've been toying with the idea of giving them family names as well, since many of the FM series have named protagonists who have surnames. Toby's from a family who were usually farriers, though he eventually wound up working as a cobbler (this serves as a daylight "front" for his night time thieving). Would it make sense if the man's popularly accepted family name was Farrier ? It's an existing, though less common English surname, and it directly refers to the profession practiced by his relatives. Your suggestions ?
      · 9 replies
    • nbohr1more

      Looks like the "Reverse April Fools" releases were too well hidden. Darkfate still hasn't acknowledge all the new releases. Did you play any of the new April Fools missions?
      · 5 replies
×
×
  • Create New...