inexorgame
Invent a consistent terminology for "cube", "octree", "world", and others
Is your feature request related to a problem?
We currently have the problem that these terms are ambiguous:
-
Cube -
Octree -
World
In addition, there is also the problem that Octree does not incorporate the heightmap on each surface, meaning that people from outside of the project might misunderstand it. Maybe inventing a new word for octree+heightmap would be nice. As far as I know, cube-engine goesn't do this either.
Also, since we will be rendering multiple octrees (either multiple different ones or for example the same one in several instances...), we need a more consistent terminology for all of this. Any ideas? This should also be applied to the docs.
Note that this terminology problem is related to the code, the docs, the stuff we will present in the user interface and even the ticket category on GitHub.
The source code uses only Cube afaik.
Cube is a single cube, which can have other children who are also Cubes.
Octree is mentioned in the documentation, but describing the structure how we save the Cubes. So it is the cubes with their including children.
World describes the root cube afaik or where all cubes live in.
- I think "root cube" would be a good idea.
- I would personally prefer if "world" would be viewed as "where all cubes live in".
- One problem with Cube is that is is very ambiguous with just a normal cube. Just "Cube" does not say anything about the octree it could have if it is an octant or the heightmap on each surface.
What do you think?
Note: From the rendering architecture, any cube could be used for rendering, not only root cubes. Since each cube does have its own vertex cache, we could for example use only one of the 8 child cubes of a root cube and render it.
One problem with Cube is that is is very ambiguous with just a normal cube. Just "Cube" does not say anything about the octree it could have if it is an octant or the heightmap on each surface.
This is a matter of personal preference, but from what I feel this is my biggest concern.
* One problem with Cube is that is is very ambiguous with just a normal cube. Just "Cube" does not say anything about the octree it could have if it is an octant or the heightmap on each surface.
If you go with the existing documentation we have:
The current documentation is especially sometimes exchanging cube and block.
I would define them as the following:
Block
A block is either a cube or an octant.
Every block has corners, faces and edges, which all have an ID.
Cube
A cube can be either:
- an empty
cube - a solid
cube - a normal
cube(indented)
A normal cube can indent each corner along each axis by 8 steps.
Octant
An octant is a block which is sub divided into 8 other blocks.
Each sub block has an ID.
Octree
The octree is the structure itself. How we arrange the blocks in a tree like structure.
Each octree has exactly one root block.
Root Block ~~/Cube~~
The wording root block is a bit complex. If a block, is a root block depends on the scope.
If we take a given octree, we can define which block is the root one. But this does not mean that our root block is not part of another octree. Where it would not be the root block.
World
Where all octrees (and other stuff?) lives in.
This is a really cool summary! I also agree that we should stick with this.
Maybe something like world layer would be a bit clearer, since we want to support an arbitrary number of root block.