This technique is sometimes called "immediate mode" instancing because we're using immediate mode to jam our instancing data down the pipe quickly. If we draw one brick many times, we can avoid a VBO bind, avoid uniform change, and just alternate glVertexAttribute4fv, glDrawArrays repeat. Vertex attributes are very cheap to change (via glVertexAttrib4f) and it allows us to draw one brick many times with no uniform change (and thus all of that uniform work by the card gets skipped). One trick we can do to lower the cost of matrix transforms is to store our model view matrix in vertex attributes rather than in a uniform. If you model all of the modular houses and you just want to see them in realtime, that's 17,090 parts - that's a lot of draw calls! But 5000 bricks is only one or two big lego models. Remember, 5000 draw calls is "a lot" of draw calls for real-time framerates. Either way, that's a lot of work to do per draw call, and it's going to limit the total number of draw calls we can have. That uniform buffer will then either be in AGP memory (requiring the card to read over the PCIe bus at least at first to draw) or it will have to be DMAed into VRAM (requiring the card to set up, schedule, and wait for a DMA transfer).
Ldraw vs bricksmith driver#
The driver doesn't know that you're only going to touch transform, so it can't be efficient. Thus each time you 'touch' the matrix state, the entire set of built-in uniforms including the ones you haven't messed with (your projection matrix, lighting values, etc.) get copied into a new chunk of buffer that must be sent to the card. The problem with this technique is that it is CPU expensive the built-in matrix transforms are uniform state, and on modern cards this uniform state has to live in a buffer where the GPU can read it (I believe we would get a performance boost by indexing vertices, but only if smooth shading could be employed with flat shading virtually all vertices have different normals and cannot be merged.)Ī naive way to draw part meshes would be to use glPushMatrix/glRotate/glTranslate sequences to push transforms to the GPU. The VBO is loaded as STATIC_DRAW (because it is virtually never changed) for maximum speed.īecause LDraw models are currently flat shaded, BrickSmith does not attempt to index and share vertices all VBOs are non-indexed, and a distinct set of GL_QUADS is maintained to avoid vertex duplication. Thus a part is typically a single set of tris, lines, and draws, all stored in a single VBO, with no state change. This is important because it means that I can use a single mesh (with color) for any given part regardless of color changes (the mesh doesn't have to be edited) and I don't have to draw the mesh in two batches (which would cost CPU time).īrickSmith "flattens" parts in the standard LDraw library into a single simple representation - in other words, the 'stack' is simulated and the final output is consolidated. I represent these meta-colors that come off the stack as special RGBA quadruples with A=0 and RGB having a special value the shader can then pull off the current stack state and substitute it in. The shaders understand the LDraw concept of a "current" color (which is the top of a stack of color changes induced by the inclusion of sub-parts/sub-models) vs static hard-coded colors a given part might be a mix of "this is red" and "fill in the blank". Because of this, I was able to program one or two LDraw-specific tricks into the shaders to avoid CPU work. The new renderer uses shaders, not the fixed function pipeline. (Consider: even though the lego 'studs' are only broken into octagon-prisms, you still have 1024 of them on a single baseplate.)
Ldraw vs bricksmith full#
The vast majority of drawing tends to be colored lines and polygons while texture support was added to the format, it's not yet in wide-spread production.The file format effectively turns into something like a push-down state stack and individual line, tri, and quad primitives.If you aren't familiar with LDraw's simulation of lego bricks, here are the operative points to a graphics programmer:
0 kommentar(er)
