Instancing, potential performance gains and issues?

[Cube_]

Okay, I'm not entirely sure what the performance gains of instancing is, since my game is built with a lot of blocks, which method would be faster at runtime:

Generating all blocks that are rendered as unique meshes (those with the same materials should still end up in the same draw call to my understanding) or to have each block of the same type be an instance, say of block.grass
that way I'd have an off sceen master list of all blocks and just use an instance of it whenever it needs to be drawn.

is this faster, equivalent or slower? (it should use less memory and make my material handling logic simpler)

Does this interfere with VBOs? What potential issues could using an instance of each block have? (non animated, mind)


I chose open discussion for this because I'm more interested in it from a conceptual point of view based on Irrlicht's implementation of the various concepts, beginner's help also feels somewhat appropriate but I opted for putting it here since it's not a coding question per se.


Anywho, here's a scenario for you in case you need to know the scale we're talking about:
Each chunk has 64^3 blocks in it, I have 64 loaded at any time, if we assume half are empty and half of the remaining are underground then we can assume that there are 16 chunks that are visible with blocks in them, then we can further assume that only 1/10th of the blocks per chunk are visible at any time (on average, this is actually a lot more than real life but we're assuming terrible case)
that'd yield 1258291.2 cube faces visible (assuming average 3 visible per cube, again worse than real life).

All these cubes are of one of these three types: Grass, Dirt, Stone.
In this case, would instancing improve performance or not? (I don't really understand how it works), if so would it interfere with VBOs? (perhaps one would put all cubes in the master list into a VBO since they won't change?).
This is mostly hypothetical at this point, I have no plans to implement instancing unless there's a significant performance gain over storing the meshes manually (since I could always figure out how to do greedy meshing to optimize out redundant faces)

[Granyte]

1 well there would be a significant improvement in memory usage because instead of storing 8 vertice + 12 indices per cube
so at least 60k * 8 vertice (assuming only half the faces on the cube are visible) * size of vertex+ 60k * 12 indices that's a whole lot of memory wasted there
with instancing you can have only 8 vertices +12 indices + 1 vertice per cube

2 Every draw call slow downs your game and will do so heavily until the next generation API are out
125829 draw call is impossible to do on dx11 or OGL I mean it's not even in a ball in the park it's 10 to 100 time more then you can do and expect a decent fps

also you can technically you can use texture array to draw every single block at once doing so can move your bottleneck from your cpu to your gpu and generaly gpu are much better dealing with those kind of operation

3 instancing is already implemented on the FVF branch so you only have to define the vertices you need and write your shader

[Cube_]

Right, I already knew memory would improve hugely (although my current memory handling already put me in my intended max range for mesh data).

I am aware that each draw call slows down memory, however unless I'm wrong things with the same material can be batched in the same call, no? (or is that impossible due to them having different meshes?), I am indeed aware that the example stated is insane if each voxel would have its own draw call.

My minimum supported gpu doesn't support texture arrays (only have GLSL1.2 support) but texture atlases are supported. (on said gpu I currently get about 20fps using two materials visible on average with 4x more faces visible than fully optimized (excl. greedy meshing which I haven't figured out how to implement yet)m instancing works in the FVF branch, eh? I'll have to have a look at that then... and figure out how to get a shader to do this.