Sure, I'll try. It can be a bit hard to explain though........ We have an octree of voxels divided into chunks. A chunk is basically some point in the octree and everything below it. The depth of leaf nodes for a chunk is determined by the distance the chunk is from the player. However we don't build down to our leaf nodes unless there is a sign change, (i.e. mesh data) otherwise it would defeat the purpose of the octree. So most parts of a chunk's octree or even the whole octree will not go all the way down to it's leaf depth, and it's leaf depth could be several levels down from a bottom voxel.......The problem is as you approach an area of terrain, the leaf node level will increase to provide more detail, and we can not assume that just because a voxel has no data it's children will not have data also. A good example of this is if you have some floating terrain in the middle of a voxel. However this can also happen without floating terrain. For instance if some geometry pierces the side of a voxel but doesn't contact any of it's corners the voxel will appear empty, but after you subdivide it you might find data.
So for build iterations we have to go all the way down to where leaf nodes should be, just to check if there is data. We need to do this because our terrain functions accept X,Y,Z coordinates and we don't have those until we have built the octree down. So it's kind of a chicken and egg problem. We need the octree to find the data, and we need the data to figure out where the octree should be. Instead of building the whole octree down however, we use a lightweight tree without all the faces edges and nodes, just to find coordinates to feed to our functions. Since our coordinates are on the surface of a sphere we need to subdivide an icosahedron and that's really what our unit sphere is. Then to calculate the position of a given voxel vertex we just multiply it's corresponding unit sphere vertex by it's altitude to get our final voxel vertex X,Y,Z coordinates. We are really dong this for virtual vertexes since they don't exist yet. The ghost-tree code handles this stuff. Also we don't un-subdivide the unit sphere on every iteration. We use it to cache the sphere related part of our coordinates between build iterations, in addition to height related components of any terrain functions we are using. We therefore don't need to recalculate all that stuff on each iteration. We just recalculate the height part when we do our ghost walking which is a simple calculation..... Our ghost walking is implemented by recursion and on the way back up we throw away any parts of the ghost tree with no data, so we are left with a map of how to build the actual tree. Note this whole processes is only done on cells that appear empty. Cells that already have a sign change will be at the current leaf level, and when we increase the level we can just subdivide them normally. This handles the vast majority of cases. However as I said you can't make the assumption because for anything but the simplest cases it won't hold true very long. Generally you won't have to ghost walk very deep but there are cases where it's possible. For instance say you have a long thin spike that avoids all nodes up until the last level of LOD.
There is one more feature I didn't really talk about yet but I'll add it in here. if we have simple height-map data, we can store those terrain function values in the unit-sphere vertexes no problem. However when we start getting into caves and stuff like that, you really can't do that. So now there is another problem. As as you build your ghost tree down to find your data, you are running terrain functions on 3D coordinates and those can be expensive. Note that each voxel vertex is used by 12 voxels ( just like for cube voxels, each for vertex is used by 8 voxels). Since during the ghost walk process there are no voxel vertexes built yet, there is no place to store calculated terrain function values. Ostensibly you would have to calculate the same terrain function value 12 times, but that would be a disaster. Instead we have a 3D matrix cache that we use for temporarily storing terrain function values as we search for data, and there is a special "chunk address" that we index it with so we can quickly see if we have already calculated a needed value. Since our voxels are prisms it uses something akin to barycentric integer coordinates. In fact there is a partially implicit addressing system that assigns each voxel a unique ID.
I call it GNOLLS coordinators
If you you start at the top, the world is constructed from an icosahedron. That's twenty faces. we can combined those into pairs to a get a diamond shape which we call a "Group". The group has two axes one that points roughly "North" and the other is at an "Oblique" angle to it. That gets us to a pair of voxels which we call "Legs" (a term I stole form investment jargon, there is a one "up" Leg and one point "down" Leg). Then we have the altitude of the a voxel which we call a "Level" and finally we have the "Subdivision" as defined by our octree. So its:
GNOLLS! (Yes I had to think a while to make the acronym work )