5 ms·

> None of these techniques is relevant anymore given that all the hardware has Z buffers, obviating the need to explicitly order the polygons during the renderi

• dicroce 4y ago
  yeah this didn't seem right to me either
• Jasper_ 4y ago
  That's known as "occlusion culling", and it's still a bit of an open problem [0]; a lot of games do indeed just send all draw calls inside the frustum. Turns out a good Z-prepass is pretty free and helps a lot with things occlusion culling would normally help with. And deferred rendering helps even more with things like quad overdraw from disparate objects, as long as your material mask is mostly the smae. The Source Engine still uses has a pre-built BSP for surface visibility. Source 2 has replaced this with a world-aligned visibility octree [1]. [0] The common solution these days is a low-resolution depth buffer rasterized on the CPU with SIMD, because doing it on the GPU would have noticeable latency... you've probably played a game where you turn into a twisty hallway and the walls/object in there only show up after a few frames... that's GPU occlusion culling at work. [1] https://developer.valvesoftware.com/wiki/Half-Life:_Alyx_Workshop_Tools/Level_Design/Visibility#Best_practices.2Fcommon_issues https://developer.valvesoftware.com/wiki/Half-Life:_Alyx_Wor...
• teraflop 4y ago
  It's a bit more nuanced than that. The parent commenter is correct that modern game engines don't need to sort polygons to render them correctly (with some exceptions e.g. transparent objects), and doing so at a fine-grained level is generally not worth the CPU cost. Especially since the bandwidth between the CPU and GPU can be a bottleneck, so if possible you want to only upload the level geometry once instead of having to rearrange it on every frame. Game engines can of course still do their own coarse-grained occlusion culling, in order to reduce the amount of geometry that needs to be processed per frame. And there can still be a benefit to approximately sorting objects: if you draw objects in approximate front-to-back order, then a shader can do "early depth testing" and skip the expensive shading computations for pixels that are occluded by already-drawn polygons.
  • gary_0 4y ago
    Even for modern games that don't care about depth ordering, they still tend to render first-person weapons or third-person characters first, and the sky last, just because it's an easy way to skip a bunch of overdraw, so why not?
• hmry 4y ago
  Source was released 18 years ago. The current Source 2 does not use BSP anymore.
  • gary_0 4y ago
    I think BSP was kind of obsolete even when it was used in Source 1, but was left in because removing it would have required changing a lot of code for no real benefit. The blocky brush-based level geometry system from GoldSrc still remained, but they added a lot of higher-fidelity features on top of it. IIRC, the level editing pipeline code for things like PVS and baked lighting were still based on code from GoldSrc. Better, newer techniques existed but what Valve had wasn't broken, so why fix it?
• dmbaggett 4y ago
  Occlusion culling is still relevant and of course BSP trees help with that as well. What I meant is there is no value in sorting polygons any longer. (As far as I know; the last time I worked on a game was 1997.)
• CyberDildonics 4y ago
  I’m not an expert but I’m sure that’s not true If you're not an expert why are you sure it's not true. Most games render a lightweight pass to do all rasterization to a g-buffer, then do the expensive shading later. This separates visibility from shading. If fragments are already occluded by the z-buffer they can be skipped as soon as they can test their z value against the buffer.
  • chrisseaton 4y ago
    Do you have my comments bookmarked or something? You reply to me with something negative to say far more frequently than if you came across them randomly. Can you give it a rest if you can’t manage to tone down the snide please? As other comments say, including the original comment author, game engines actually do still rely on their own space partitioning to reduce draw calls. Source 2 just does it quad rather than binary. Source is still used in actively developed games and is still BSP, so it’s not true that the techniques are not relevant.
    • CyberDildonics 4y ago
      • chrisseaton 4y ago
        Just give replying to me a rest will you, if you don’t like my comments.
        • CyberDildonics 4y ago
          The person you replied to made an informative comment and you seemed to want to poke a hole in a generalization that people could learn from, which a lot of other people have pointed out, so I don't know why you would get upset at me for explaining more about how rendering works.
          • dang 4y ago
• gary_0 4y ago
  It should be noted that virtually all renderers do frustum culling, meaning anything in the game world that is guaranteed to be out the camera's viewing volume is not rendered. Frustum culling is quite simple. Occlusion culling is usually done after frustum culling and is more complex, and the method tends to vary depending on the scene type and game engine, or is sometimes not done at all (modern GPUs are so powerful that smaller or simpler game areas render fast enough without occlusion culling).
• skocznymroczny 4y ago
  From what I've seen in the modern game engines, the current state of the art seems to be executing a compute shader which does frustum and occlusion culling on GPU and dynamically generates an indirect argument buffer which gets drawn in several or a single indirect draw. This article contains a basic implementation of such idea in Vulkan - https://vkguide.dev/docs/gpudriven/gpu_driven_engines/ https://vkguide.dev/docs/gpudriven/gpu_driven_engines/