I'm just wondering what the best practice is with chunked terrains and component entity systems. Should each chunk be an entity in itself? Or should the whole terrain be an entity?
I'm trying to streamline and refactor my rendering process, and indeed, design parts of it that haven't been done yet. I have a sandbox project that doesn't use my new architecture and it has my terrain system in it, which is honed and extremely efficient. Porting it to my new game engine is throwing up lots of design decisions. My rendering engine essentially works sequentially through a vector of render 'tokens' which allow me to sort it on various criteria. My main question is "should" my terrain parts (i.e. chunks) be just another render token in the list or should I contain my specialised terrain rendering code in its own render method.
It feels wrong to keep it in its own method, but its quadtree and relational nature doesn't really lend itself to a linear list of completely unrelated render tokens. My set up is essentially like this at the moment:
Entity (contains standard orientation data)
---> RenderableComponent (there is a link to this object in each 'RenderToken' which just holds the sortable key, the material and link)
---> SkeletonComponent (this is just the skeleton data)
---> MeshComponent (this is just the mesh data)
---> AnimatorComponent (this builds skeletal poses based on animation data)
My entity system doesn't really have 'systems' that control the entities/components, rather the functionality exists within the components. This was an early design decision that I quite like but it's easily changable.
So how would you go about moving a quadtree-based terrain system into this architecture? Keep it a self-contained terrain system or integrate it into the pipeline properly?