The composite shapes object should be, ideally, a pointer or index into a separate array entirely. Such object should have a handle back to this object, and this would allow you to trivially ensure that your culling data is trivially iterable in a cache friendly manner without carrying along a lot of other baggage that you don't care about.

Other things that might end up getting moved around, if you do refactor with that in mind, is the transform3d object, which will likely need to be included (or at least the position and rotation for calculating bounding boxes) in the composite shape object for culling purposes.

Thanks for the suggestion about the shapes organization. A couple years ago when everyone was redesigning their entity systems for components, I was either unwilling or unable (due to time constraints) to the proper research myself. It has been a nice learning experience going through it now, so if there is any other ideas or strong suggestions I would appreciate them!

I don't necessarily recommend the "entity component" system, as it's a stupid idea (I can elaborate more if you care too desire more about why it's a stupid idea).

But having separate component systems with their own data storage mechanisms which then have handles back to the owning object is a much more manageable system and significantly more extensible (your parent object can then be just a name and the pointer is a shared handle between the different systems, if you want).

A good presentation on the culling scheme I suggested above can be found here, the important take-away from it I've already mentioned above, however just as an additional thing: Hierarchical culling is generally slower than brute force, simply due to cache misses and branching. Unless you have a SIGNIFICANT (i.e. probably greater than around 40k) number of objects, in which case you should generally group them into large chunks which you can brute force process at once, rather than attempting to cull them using a tree or similarly non-cache friendly structure. I.e. If you have a dynamic world of a hundred thousand objects, you might simply break it up into squares of say 20,000 objects each, and then brute force cull those.

I had a chance to go through the paper you linked to, and it was a nice read through. Most of the info coming out of the C++ community lately follows the same guidance - use a linear array of items to enable great cache usage and let the modern CPU pre-fetcher rip through the data.

I think I will follow your advice and come up with a separate 'system' that can house all of its data locally and just let the entity reference that object through a handle or pointer. If I make any significant progress I'll be sure to post it here!

I had a chance to go through the paper you linked to, and it was a nice read through. Most of the info coming out of the C++ community lately follows the same guidance - use a linear array of items to enable great cache usage and let the modern CPU pre-fetcher rip through the data.