+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Refactoring Tree Generation (/thread-2487.html)
Refactoring Tree Generation - SamJBarney - 08-03-2016
So, for my next trick I will be working on refactoring tree generation, specifically implementing a simple way for server admins to add variations of tree types.
One thing is bugging me, though. When I was testing out converting tree generation to a more OO approach, I had to check whether there was space enough for the tree to grow. However, I had to write 2 different variations of the checking method because we have two different ways that trees can be generated: Through chunk generation, where cChunkDesc is used, and the cWorld::GrowTree* methods, where the world/chunk map is used.
I know this would take a big refactor of generation code, but shouldn't we be using a single generation path?
I mean cChunk is a data object, and when generating anything into the world the code needs to know information about the surrounding chunks, if available. Why not just use cChunk? I'm assuming it's a efficiency thing, but the way we are doing it right now, at least for trees, leads to then growing right next to each other, in separate chunks.
RE: Refactoring Tree Generation - NiLSPACE - 08-03-2016
@xoft wanted to refactor tree generation for quite a long time, he probably has some ideas for this
RE: Refactoring Tree Generation - xoft - 08-03-2016
I had an idea that instead of generating the tree images on the fly, we would actually use .cubeset files with tree images in them. Unfortunately, I didn't do the math then, and when I did, I found out it was pretty much impossible, the cubesets would be really, really large to contain all the tree variants already in the code (I counted the number of trees to be on the order of thousands)
The problem with dual checking is that while the trees are being generated, there is no cChunk for the generated chunk yet (and there cannot be - it is created only after the data for it is known). And also, there needn't be cChunk instances for the neighboring chunks. The easiest idea for refactoring would be to use an interface, ChunkDataProvider, that would have the virtual methods to access individual blocks and query neighboring chunks; and the generator and the world both would provide a descendant with this interface, implemented on the underlying data.