Irrlicht Engine

Reallocate it first, then memcpy, that's what my code does.

So how would you do it, with greater efficiency?

This change reduces memory allocations afterwards from 2.4GB to 1.2GB and everything works well after cycle testing during hours.
I also free the keeptriangles using clear after the memcpy to protect system memory from running out on big meshes.
The mesh alone used in testing takes 380 MB.

I do this:

The bug is the memcpy, it copies the triangles over existing data, that was much larger, then reduces the size variable, but this does not free the overwritten larger data. I'm not sure how two allocation of different sizes sharing the same start address can get freed later. This results in the smal...

But the array is memcpied over without deallocating first, then the size is reset, but that doesn't deallocate the memory. Take a look at those array functions.

Bingo! That was a massive memory leak in constructOctree, the use of memcpy to nodes->Triangles then after using .set_used(0) doesn't free the memory.

On my big model, it's causing 1.2GB excess memory.

Sorry, I meant octants, and yes, each triangle should be only in one node specified for it's bounding box. This seems, sorry, a bit of a disaster, a fairly simple mesh with 12,522 triangles, like the little dragon, ends up with a whopping 395 nodes! Its looking like it really needs memory optimising...

I'd thought octree just split the mesh into octants, so just check which octant using it's bounding box, then check the triangles. Is the current method faster than that method would be?

I saw in iarray.h it adds 30 bytes or something extra for each allocation, but didn't imagine that there wasn't a method to tighten that down for each of the triangle allocations. With 440,000 triangles, any excess padding would hurt!

I have that clear, but what I'm uncertain about is the selector, because for a mesh that has 6 million primitives, it is using a triangle array that is consuming about 2 gigabytes of memory. The coctetnode is 80 bytes in size, with one for each primitive, and the buffer of kept triangles during a hi...

I'm finding that with large models, if I load the triangle selector, it uses twice the amount of memory as taken by the mesh itself!
I'm wondering why, as the overhead to sort the triangles into 8 groups shouldn't be more than a few %

Thinking about removing the time overhead to load octree sorted triangle lists, as larger meshes tend to have many meshes, couldn't we just scan the mesh buffers for a hit, checking the boundary box for each submesh?

Thanks, will sort it and post an HLSL version

Be nice to give Vulkan a test with Irrlich