I ve used close way to but with static amount of arrays.
if you use some alocated and dealocated chunks
you must reference through some pointers, ?
and this spoils a bit the image, what you got some
array of pointers to chunk-arrays, also managment of
alocating dealocating such chunk arrays seem to be
probably slightly complicated
The data in the container only uses indices - a node_index and block_index. The blocks are allocated and deallocated in the container and their pointers stored in an array (which can be of fixed size for many use cases). I can write up some simple example code at some point if there's interest.
I recall I used a rigorous system of forcing world chunks to stay in memory while a 'significant' object was adjacent (via subscription list/refernece count) and could use a chunk memory pointer directly. One of the more complex mechanism was having non-player 'significant' objects transition between 'realized' and 'abstract' operating modes ('abstract' would be the object operating while the chunks they resided in were rolled out and they moved on a 'abstract' simplified map of the entire world and behaved in an abstract manner)
'dumb' objects inside the chunks just rescanned their vicinity for interactions (at a lower frequency). The chunk itself had a 2D grid space partitioning system (link lists (indexees) in each grid cell for a list of chunk resident objects in that cell)
Many 'smart' objects scans likewise would do immediate scanning for interactions with dumb objects (there were such large counts that maintaining tracking lists for those was prohibitive (so they didnt require pointer links). Box searches in the chunks partioning grid...(and into any adjacent chunk the scanning object was close enough to)
again for efficiency most 'dumb' objects were fixed size data structures - facilitating the index+pool heap scheme (a similar expansdion to double/triple size blocks was possible if needed.
Some objects were containers and had other standard object inside them (link list using indexes) and the inventor items also were in the chunk's local heap.
Space saving a somewhat lesser issue ?? 2 byte index values (with flag values) versus 4 byte (or bigger on 64bit systems??) for each pointer??
Offsets within a chunk bigger than 64 KB ?? - just multiply by 2 or 4 bytes and have the inner objects aligned on those multiples
These chunks also were not overly large (still with potentially hundreds/thousand 'dumb' object within them), but I was using a 15x15 2D window of regular grid chunks for the players avatar active area.
Terrain data (3D mesh) was a seperate data chunk (because its full detail wasnt always required in-memory), while a simplified nav-mesh heightmap was part of the basic 'chunk'.
An added advantage was because this was a multiprocessor simulation an entire duplicate game world chunk could be sent to the AI processing nodes (where significant objects ran) with low overhead processing of the transfer (roll in and discard, similar to the basic scheme) and the event/update messages could use the same indexing system.