Using drawVertexPrimitiveList efficiently

[ItsBritneyBitch]

Hi everyone, my application has a lot of low-poly meshes (mostly blocks made of 12 triangles), and I want to render them efficiently performance-wise. Right now I'm calling setMaterial and drawVertexPrimitiveList per face, every single frame, which is quite slow (90fps using ~20 cubes). I was wondering how to speed up this, and whether Vertex buffers could give a significant performance boost. Note that the vertices and materials (the data itself) are being changed every once in a while, and I need to apply different transformation matrices to the driver every single frame.
Any ideas?

[hendu]

No, using VBOs for four verts each makes no sense. There is some overhead in switching a VBO, so it's likely not any faster than sending those four verts over the bus.

Six draw calls per cube... That's extremely inefficient. Examine your environment, how you need things to change, and find ways to batch them together.

ps: YAMC? (Yet Another Minecraft Clone)

[ItsBritneyBitch]

No, using VBOs for four verts each makes no sense. There is some overhead in switching a VBO, so it's likely not any faster than sending those four verts over the bus.

Six draw calls per cube... That's extremely inefficient. Examine your environment, how you need things to change, and find ways to batch them together.

ps: YAMC? (Yet Another Minecraft Clone)

Nope. Just a CSG based editor. But I really need to find a way to speed up this. :S

[hendu]

Well for starters, why one call per face. What prevents you from doing one per cube.

[ItsBritneyBitch]

Well for starters, why one call per face. What prevents you from doing one per cube.

Because each face has its own material.
Is there any way I could store all the geometry in the video card, reference it each frame for rendering (instead of sending the data over the bus), and update it every time the user applies a transformation to it (translation, scaling, rotation) which is *far* less frequent? I still don't get how let's say Hammer has a consistent frame rate with huge maps.

[Mel]

Well, first, the fastest way is to set textures the least times posible, and draw all the triangles that use that single texture at once, then go for the next texture and so on. This should give a small speed up.

When you don't need to update the triangles frequently, all the unchanged parts of the mesh can be stored in meshbuffers, and these can be stored on the video card. The good thing is that they can be stored statically, and flagged as such, so they will never change, or they can be set to be changed on demand. you can modify a meshbuffer, and flag it so it gets updated on the videocard. this could improve the performance more.

[ItsBritneyBitch]

Well, first, the fastest way is to set textures the least times posible, and draw all the triangles that use that single texture at once, then go for the next texture and so on. This should give a small speed up.

When you don't need to update the triangles frequently, all the unchanged parts of the mesh can be stored in meshbuffers, and these can be stored on the video card. The good thing is that they can be stored statically, and flagged as such, so they will never change, or they can be set to be changed on demand. you can modify a meshbuffer, and flag it so it gets updated on the videocard. this could improve the performance more.

That's what I thought at first, although hendu mentioned there's some overhead from switching to a VBO. I'll try to switch everything to mesh buffers and then compare the results.
If anyone has some experience with this, is using VBOs worth it with such small number of polygons rather than sending all the geometry every single frame?
BTW, I can't really have the geometry sorted by textures, it would require to refactor huge amounts of code, but in the worst case, if the material used in the last setMaterial() call uses the same texture as the next one, is said texture sent to the graphics card again?

[hendu]

There's a reason irr by default doesn't use VBOs for less than 500 verts

For your one cube example. What prevents you from writing a shader and sending six textures? One for each side.

[Mel]

Any comunication with the video card requires a small stall, so, calling it as less times as posible is a way to gain performance, the textures aren't sent twice, but just the check requires a small time, which is something we don't want to lose.

[hendu]

Expanding on that idea, if there are no mirrors, you can only see at max three sides of any cube. So you'd only need to send three textures.

[ItsBritneyBitch]

Expanding on that idea, if there are no mirrors, you can only see at max three sides of any cube. So you'd only need to send three textures.

I guess i could do a backface culling check of my own before sending geometry, although I don't think that's going to improve performance a lot.