Ben Supnik Wrote:For BrickSmith I am planning to move the new rendering code from glDrawArrays to glDrawElements after I implement part smoothing, so that the vertex sharing for draw-elements can be higher.
Isn't the amount of shared vertices too low to justify all the uniqueness tests with smoothed meshes ? Although it's only done once some parts (especially base plates) can take quite some time to determine all unique vertices. This becomes even more worrying when texture coordinates get involved.
Ben Supnik Wrote:I think that whether draw-elements vs draw-arrays is faster depends on which part of the GPU pipeline surrounding vertex/triangle processing is bogging down and how transformed vertices are cached. But either way if that's the bottleneck, the next answer is level of detail. Datsville turns into a 125,000,000 vertex model for 39,000 parts; when drawn in a window that's something like 125 vertices _per pixel_...not a good ratio. :-)
Yes, occlusion testing might help with this issue, but it isn't easy to implement as far I've looked into it.
Ben Supnik Wrote:One other note: before using shaders, BrickSmith had to compute a VBO for each part in each color that was used for parts that use the 'current' color. For example, for the 2x2 plate with red wheels there'd be a gray & red version and a black & red version stored in two VBOs if the user placed the part twice with different colors.
I use a single set of VBO's per brick (triangles, edges, indices), these have no color component at all. I just issue a plain glColor before the drawelements call. Only weird thing is the stock open source (readeon) driver on Ubuntu (10 .. 12) executes this wrongly for multiple colored parts some how. But I'm fairly sure that's a driver bug (AMD's own driver doesn't have this issue).