Hardware instancing patch... please can we get it in 1.8.0??

[Granyte]

i was asking about how instancing works in OGL if there would be a way to create a uniform interphase with dx and it's per instance vertex data system

[Nadro]

Hardware instancing in OGL works in the same way as hardware instancing in DX10 (DX9?), so it's possible.

[hendu]

Yes, you can have per-instance data in GL. (look up instanced arrays)

[Mel]

DX9 on PS3 has some instancing abilities, though i am unsure if they work the same or not

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

[Granyte]

That's the interphase i hacked around to transmit instance ID in DX9 as the instance ID semantic is not yet availible.

But you would normaly have to use that interphase to transmit a matrix array stored in a vertex buffer.
That would be much faster then the current hack i use because it would not be limited to 62 instances per draw calls

[Nadro]

I have to add support for multiple vertex buffers in FVF (currently a mesh support just only one vertex buffer) to efficient instancing (second buffer will be usage for per instance data), but this is really easy modification, I'll add it after FVF will be merged with trunk.

[Granyte]

so that would be like a seconde meshbuffer type like instance mesh buffer.


And then the data that were missing in the vertex definiition like data origin stream and data frequency will need to be added to the vertex descriptor

[Nadro]

No second mesh buffer, but just vertex buffer (there is no sense to double other mesh buffer parts like an index buffer, vertex buffer will be enough for it). Yep, I'll add all required features to vertex descriptor.

[Granyte]

No i mean would we create second mesh buffer type that would hold two vertex buffer or would we have only one that could hold two vertex buffer wouldn"t the second one be causing a useless over head in ressources for the meshes that don't need instancing

[Nadro]

Only one mesh buffer will be exist, but it will be allowed to hold multiple vertex buffer (buffers will be stored on irr::core::array<IVertexBuffer*> VertexBuffer), so when someone will need two vertex buffers eg. for instancing he will be allowed to add them. I don't see overhead (only very small for iterate buffers by "for" instruction) of this solution for standard cases when only one vertex buffer is required.

[devsh]

why cant we have separate attribute lists???

they have best performance and scalability anyway

[Nadro]

What do You mean (simple attrib list per vertex buffer, like for example a simple matrix ID for each vertex buffer?)? More info will be helpful FVF is still in development phase, so we can add to it all usefull features.

[Granyte]

like linking the atribute list to the vertex buffer and composing the vertex definition at run time?

That could cause issue with dx9 unles there is a simple way of specifying the stream source.

Or with dx11 the stream frequency is even defined in the vertex definition

[Nadro]

I am not too much familiar with DX10, I prefer OGL, but I think that together we can prepare a good FVF system for both DX10+ and OGL3+ After FVF will be merged with trunk (I hope that it will be soon after 1.8 release date), we'll add to them all required features.

[FreeFrags]

Any progress on merging FVF with the trunk? Following this thread closely