Hey everyone
I have been struggling with this problem a while now and would like to know what's your thoughts and ideas about it.
This is not directly related to polyvox rather than voxels and procedural generation.

Well, the problem that I'm having is regarding my voxel trees, I can't figure out the right way to place the trees without them being cut off because of the terrain chunks border.

The terrain is currently infinitely generated, this is possible by using small chunks and load/unload them depending on the camera position. Every chunk is generated using the output of a noise function.

Im able to place a simple trees trunk with no problem, but once I do the leaves they got cut off.

Trees are placed randomly.

The current method i got in head is to keep track of the generate chunks, once a chunk has all its childs loaded then it will be eligible to hold a tree.

Does it really matter if the leaves get cut in half (I assume the same happens in Minecraft)? This should only be an issue in the distance, and as you get closer the next chunk will be loaded and the tree will be complete by the time you get to it. Of course this can depend on the kind of game you are making... could you provide a screenshot to give some context?

In Voxeliens I think we kept trees away fom the edge of the world, but this was easy because the world was a finite size.

Unfortunately this is not the case, once the tree is cut off it doesn't expand once the new terrain chunk is loaded it stays that way because I execute the tree generation function on every terrain chunk, so the next neighbor chunk doesn't know that it should load the rest of the tree because the tree generation function was already executed and done. I hope this makes a little more sense
The trees gets cut off basically because during the generation I limit its boundaries to the current chunk boundaries, if I don't do so the game simply crash because it tries to place voxels on an empty space.

please pics - a picture is worth a thousand words

how about caching the changes outside the current chunk? so when a new chunk loads, it checks for cached data belonging to it and somehow combines it with the generation/loading process.
I'm aware this will take up additional memory, but only on the generated borders which shouldn't be too bad.

That's a feasible solution, do you recommend using arrays to store the excessive data?

So how are you storing you volume data? Are you using the LargeVolume, or you have a manual approach based on multiple RawVolumes?

Anyway, I think you need a deterministic approach to tree generation, so that you can generate two chunks seperatly and know that the tree placement will be consistant between them. For example, lets say that you choose to place a tree exactly every 10 metres. In this case, when you generate a chunk you can iterate over each voxel and check if the voxel position is a multiple of 10. If so you draw a tree there, and if it's only half a tree then you know it will line up with the other half in a chunk you will create later.

Obviously every 10 metres is a boring example, but it's the deterministic property that counts. Perhaps you could instead use a noise function and place a tree whenever a certain noise value is returned?

This is obviously the correct approach, but how do you know there's a tree there, if it's position is not in this chunk? you would need to check all surroundings for possible tree positions and check whether those trees expand into your chunk (which will get very messy for large trees, if a tree can span more than one chunk)

In my game I could handle this as a separate layer from the terrain. In my game I have a custom volume implementation that is capable of wrap-arounds. I also pre-load a chunk beyond "visible" chunks. What I would do then is make another pass after terrain generation to generate the trees. On visible chunk borders since I have a constant volume with wrap arounds I just generate the tree into the "invisible" border (invisible but exists in memory). I could also skip the extra pass and just do it in the terrain gen pass, it would still work.

To get around parallel access issues you could create a deterministic distribution of trees. So in a neighbor chunk you could--somehow--access this distribution and figure out positions from that. In my game this is not really an issue because extraction is separate from generation.

Right, you would at least need to check a surrounding border area for each chuck to see if any trees are present.

Then again, maybe it doesn't actually matter? Let's say you generate a chuck (chunk 1) in the distance and it has no trees. As you get closer you generate chunk 2, and it turns out that this does have a tree and it overlaps with chunk 1. At this point you have to regenerate chunk 1 so the tree appears... but it's in the distance (on the threshold of viisibility) anyway. Maybe it doesn't matter if it suddenly pops into existance on an existing chunk?

I do agree that for large trees the system might fail or get messy. It's a bit application dependant at this point.