Irrlicht Engine

the problem here is once again, that many of those structures will be fed into the gfx APIs. So at some point we need to make a decision whether the data might meet the gfx API, or never in its whole life time. For all the latter, another container could be used. But due to reuse and simplification ...

To be honest, this is just the result of certain laziness in the implementation of the octree structures and related issues. It's probably quite wrong to use just one array for this thing, as it would be much more efficient to organize this with some other conditions and requirements to be met. But ...

The problem it's not the memory allocation of an IrrArray at mesh level since it's divided into mesh buffers of fixed size, requiring a continuous memory allocation of 65536 (triangles) * 9 (float / triangles) * (4 bytes) = 2.36 MB.

It's the composition IMesh <>---- IMeshBuffer that allows the ...

Such arrays are the fastest (and probably only sane) way to send data to OpenGL/DirectX (the hardware API's). Which is in a realtime 3D engine a more important design consideration than trying to design for a special case which can be solved otherwise anyway.

And it's not really nice to come new ...

The idea of an array is just that - one large block of memory. Basically the same as the stl::vector. And yes - it expects that the OS does indeed deliver the memory (I think you get an std::bad_alloc exception otherwise). For your needs using a list might be the better solution. That structure ...

I would like to raise some important design issues in the Irrlicht engine. First, you must understand that we use Irrlicht for engineering, it involves the creation of tens of millions of triangles, all selectable. Unfortunately, poor implementation of the IrrArray class does not properly manage ...