I’m trying to dynamically build an isosurface mesh in parallelized compute shader, which will then be rendered by vertex/fragment shader pipeline.
When the compute shaders insert new triangles into the VBO it can happen in any order, so the triangles which are inserted adjacent within the buffer array may be located in totally different (remote) locations in model/world/screen space. (said in another way, tris which are adjacent in the VBO may not be connected/adjacent in the model mesh)
Is this bad in terms of rendering performance?
Are there other possible reasons why this would be a bad idea?
as I’m thinking further about this, I’m feeling like it shouldn’t matter,
since each vertex gets its own independent vertex shader,
and after primitive assembly the rasterizer converts to fragments and instantiates fragment shaders to write the framebuffer independently for each pixel,
so the actual ordering of tris within the VBO really doesn’t matter. Is this true or am I missing something(s)?
A draw call will cause all vertices to be processed by the vertex shader. Frustum culling can only be performed once the clip-space coordinates are available, which is after execution of the compute shader.
It’s possible that “clustering” triangles so that spatially-adjacent triangles are close together in the rendering order may result in better cache coherence e.g. for reading/writing the framebuffer, but even if that happens to be the case the effect is likely to be minimal.
If you’re using an element (index) buffer (i.e. glDrawElements or similar), it might be preferable for the element array to be reasonably ordered, i.e. nearby elements contain similar indices. Again, because this may improve cache coherence for vertex fetching compared to “jumping around” the attribute arrays. But again, even if it is a factor it won’t be a major factor.
So if your algorithm ends up generating triangles in a random order, I’m fairly certain it wouldn’t be worth the effort of explicitly re-ordering them.