Hi Roland,
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.
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. :-)
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.
With shaders, the shader uses a special RGBA value as a place-holder for "use the current color" - the mesh can thus encode the part as it is in the library: red wheels and "current color" plate. Only one VBO is needed, and thus that VBO can be used twice as often, resulting in fewer VBO binding changes (those aren't cheap) and higher instancing counts. It also simplifies the code a bit.
cheers
Ben
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.
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. :-)
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.
With shaders, the shader uses a special RGBA value as a place-holder for "use the current color" - the mesh can thus encode the part as it is in the library: red wheels and "current color" plate. Only one VBO is needed, and thus that VBO can be used twice as often, resulting in fewer VBO binding changes (those aren't cheap) and higher instancing counts. It also simplifies the code a bit.
cheers
Ben