Irrlicht Engine

I've been wondering if it would be possible to add such a method on the video driver of Irrlicht, so the geometry instancing was possible directly, without any other alteration to the engine. A method such as, or similar to this:

void drawMeshBufferInstances(meshbuffer* mb, u32 numberOfInstances, matrix* transformationMatrices);

which rendered a variable amount of meshbuffers, using each of them one of the provided transformation matrices.

Would it make any sense or is it better to look for other solutions?

The internal changes are the same no matter if you add new calls or add a num param to old ones like here:
https://github.com/clbr/seirr/commit/f6 ... b51e558ac9

I was referring to using something like the setStreamSourceFreq thing of DX9, the instance buffers of DX11 or the glDrawElementsInstanced from OpenGL, is it too complex, or too trivial to be added to the video driver?...

Yes, I already did it in that branch in 2013. If you take a look, the total was a bit over 1000 lines.

Instancing support for D3D9 and D3D11 is available in shader-pipeline branch.

But instancing using the shaders is more limited than being able to create separate buffers, one for the original mesh and the other for the instancing data. I think that a method that drawed instanced meshbuffers on its own, independent of the materials and that didn't modify the original meshbuffer, would be more flexible. It wouldn't limit the amount of drawn meshes, or would limit it less.

I'd like to look into Instancing for Irrlicht. Is it available in the latest version of ShaderPipeline? I haven't worked with it yet so I can't say anything about your proposal.

Mine doesn't fake it with shaders? I doubt the shader-pipeline one does either, haven't checked.

What do you mean fake it with shaders? I was just trying to see If that particular trunk or version has the abilities yet not use shaders or some cheap work around.

What he means is a trick used when the true instancing isn't available (DX8 for example...) which consists on building a large mesh which contains several copies of the same mesh, just with a small change on the vertices so they can reference later, using a shader, a transformation matrix that will place each copy on its correct location. But the drawbacks of such a method are:

1.- The vertex count limitation. If the source model is more or less complex, copying it will result in filling the 64Ki vertices that a 16 bit index buffer may support.
2.- The increase in the index buffer size. If we are to have several copies, the index buffer will become a 32 bit one, something less desirable than 16 bit for storage and speed reasons.
3.- Uses a shader, disabling, or limiting the usage of other kind of shaders. (i.e. the true instancing would allow to use shader skining and replicate it several of times later on very complex models)
4.- Limits the amount of copies to the amount of space the shader constants buffers may use(which is very low on DX9...) It is, for instance, the difference between drawing 64 or 128 copies of a really average object to 4000 or 5000 copies of a single object, which can be really complex, on the fly
5.- It has to be static. Compared to true instancing, where the only dynamic buffer would be the one containing the instance data (the vertex buffer and index buffer may remain static) the shader instancing would need to rebuild (and upload to the video card) the large mesh each time the amount of instances changed, resulting in a very poor performance, while using true instancing, the uploaded dynamic buffers can be pretty small, compared to the mesh data, allowing for them to vary the amount of drawn copies

Obviously, the instancing can't do miracles either, the rendering still takes place, and consumes time, but with the instancing, the amount of time can be reduced if we have to draw many copies of the same objects (trees, leaves...) or we want to swap them on the fly (LOD meshes...) or we want to alter the amount of drawn meshes on a per frame basis. (shoots, debris, complex particle systems...)

Mel take a look at the shader-pipeline branch there is no shader instancing there it's all real instancing using stream source setStreamSourceFreq

we don't even need to add a new method as the draw frequency is included in the vertex descriptor


The sample from the shader pipeline include code to do shader instancing as an example for the drivers that don't support native instancing bu I think it should be broken by now

Granyte is there an example in the latest shader pipeline version or is it just added in but no created example. I would like this feature for foliage something pretty straight forward.

@The_Glitch
Example is available - 31.HardwareInstancing.

So, there is no other way to have instancing than using a shader? Or said other way Is it possible to use custom materials that don't care about instancing, and yet, still have instancing?

If you need hardware instancing you have to use shaders (instancing need a dedicated materials).