max 65536 indices

[sodandk]

core::array<u16> Indices;

is there a way to use a u32 for indices ?

[polylux]

Given you quite short question I can only guess that you talk about the indices of a MeshBuffer being limited to 16bit range.
If this is the case, have a look at IDynamicMeshBuffer's implementation (being CDynamicMeshBuffer.h).
Its constructor has the following signature:

Code: Select all

CDynamicMeshBuffer(video::E_VERTEX_TYPE vertexType, video::E_INDEX_TYPE indexType)
                {
                        (...)
                }

...allowing you to specify to use the 32bit index type.

Cheers,
p.

[sodandk]

arh. Thanx!
Is there a limit on the hardware, to have max 65536 indices? So if I make an object with 200.000 indices, it will fail or be slower (ie. cant be cached on the graphics card) or other problems ?
I there a way to specify QUADs, without making my own node renderer? Are Quads supported on all platforms ?
thanx in advance for these newbee questions.

[hendu]

Both AMD and Nvidia recommend to use less than 65536 indices. Whether more is only slower or entirely unsupported depends on the card. All current gens should support them though.

[hybrid]

Quads are only supported for OpenGL driver.

[dejai]

0 - 65535 is the range of a GL_UNSIGNED_SHORT which can be used to retain the indices of exactly 65536 vertices. So you have 2 bytes to work with which is plenty for a lot of things. It is totally valid to have more if you need them as hybrid mentioned.

[Mel]

Don't concern with the 65536 vertices per meshbuffer limit too much. It is fairly hard to reach such amount of vertices in a single meshbuffer, and you can add another meshbuffer to a mesh to have more vertices, the only drawback is that it forces another drawcall.

Also, think that storing 16 bit indices uses less memory than storing the same indices but in 32 bit, it is better to have 16 bit indices, imo.