Programmable vertex fetching and index buffering

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.
 
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.
 
One thing I'm struggling to understand here is why LOD isn't making a lot of this culling effort moot.
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.
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?
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.
 
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.
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!
 
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!
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.
 
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.
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.
 
Last edited:
Back
Top