Programmable vertex fetching and index buffering

Discussion in 'Rendering Technology and APIs' started by sebbbi, Feb 17, 2016.

  1. Ethatron

    Regular Subscriber

    Joined:
    Jan 24, 2010
    Messages:
    856
    Likes Received:
    260
    LOD would prevent many of those pixels being rasterized which are culled post-rasterizer pre-pixelshader. The triangles can be larger and can also receive more circular footprints, so that sliver triangles and micro-triangles which linger between the raster-points occupy sufficient lanes. Microgeometry and quad-overshading can clogg the GPU.
     
  2. LeCommandeur

    Joined:
    Feb 15, 2017
    Messages:
    1
    Likes Received:
    0
    Hi everyone!

    Please pardon my inexperience but there is something I don't understand in this trick.
    If we get two indices in the vertex shader from SV_VertexID how can we access three typed buffers (position, UV, normals for example)?
    Is one of the indices bitpacked as well? Or is there a way to arrange data so that some data could be accessed by the same index?
    Or did I understand the concept wrong?

    This part is confusing to me and it prevents me from implementing this trick in my engine.
    Thanks in advance.
     
  3. sebbbi

    Veteran

    Joined:
    Nov 14, 2007
    Messages:
    2,924
    Likes Received:
    5,288
    Location:
    Helsinki, Finland
    It is impossible to perfectly LOD arbitrary geometry. As an object goes 2x further away, the pixel count drops by 2x2 = 4x (x^2). In order to reach constant cost per covered pixel, you would need to drop triangle count by 4x for each 2x increase in distance. This is not practical, unless the mesh is a simple continuous smooth surface (such as a grid). The problem is that you can't reduce silhouette outline polygon count as quickly as you reduce the interior polygon count. The outline pixel count only scales down linearly, so the outline polygon detail can only scale down linearly. As the objects are 3 dimensional and can be looked from any distance, you simply need to threat most polygons as potential silhouette edges. Thus the triangle screen space density actually increases when an object goes to distance, even when it has very well done LODs. Higher draw distance also generally result in more overdraw. Occlusion culling helps more. GPU can do occlusion culling faster (and more energy efficiently) than CPU for massive data sets. Thus GPU based culling will likely get more popular in the future.
    My example used only two indices. One for position and one for {UV, normal}. It is quite common that both sides of a sharp edge and/or seam have both different UV and different normal. There are of course some cases where you end up storing replicated UV or normal data (but never both), but you still are in better situation, since you never need to replicate the position data as well.
     
    tinokun and BRiT like this.
  4. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    So it's similar to inverted Z: higher LOD gradient closer to the camera is preferable... Though if there's only, say, 3 LODs, then there aren't that many gradients!
     
  5. sebbbi

    Veteran

    Joined:
    Nov 14, 2007
    Messages:
    2,924
    Likes Received:
    5,288
    Location:
    Helsinki, Finland
    I remember the times when 3 LODs were enough. When we moved to GPU-driven rendering, the first thing we noticed was that triangles are the bottleneck. When draw calls are free, the level designers will spam much more objects. If you add 100 thousand rocks to a small patch of terrain, most of them must be rendered using very low poly count. Thus LODs become very important. You need 10+ LODs for all props, if you are going to have hundreds of thousands of them visible at once. And artists need to carefully optimize the poly counts and the LODs need to be very well done. When you solve one big bottleneck, you hit the next one after that. Fortunately, GPU-driven rendering is capable of zero latency fine grained occlusion culling, reducing the triangle count versus traditional CPU-based coarse culling. You basically only pay for the visible triangles. But that doesn't help much when you are on top of a mountain looking at large scale terrain below you. There's not much occlusion and there will be huge amount of visible rocks, foliage, etc. The only way to combat this is to either have some maximum distance to less important objects (all games do this), and/or use impostor system that renders objects as textured (alpha clipped) billboards after certain distance. Geometry LODs simply aren't good enough if you need view distances of 10+ kilometers.
     
    chris1515, Kej, tinokun and 4 others like this.
  6. milk

    Veteran Regular

    Joined:
    Jun 6, 2012
    Messages:
    2,907
    Likes Received:
    2,446
    Another great use case for trials-like virtual textures. Small rocks on the terrain can be baked into the terrain texture as decals at runtime after a certain distance.
     
    #26 milk, Sep 14, 2017
    Last edited: Sep 14, 2017
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...