Reading about those CSG classes makes me wonder how terrain will in the end be defined.
The volumedata / density function is just based on a single interface, Source. The CSG classes implement this.
This CSG stuff is actually just a nice-to-have and some easy way for me to create debug-data like spheres. They were easy to implement and every now and then, I add some classes here (somewhere in my idea notes: CSGMirror). The actual terrain data is coming from 3D texture files exported from Acropora  loaded via TextureSource.
One nice thing is: As the CSG classes just work on the Source interface, you can freely combine them with any Source implementation. This means, adding a sphere to your TextureSource is no problem.
I'm wondering if in the end it will be possible to stream data into the your component from some kind of sparse voxel data structure (like a grid, rtree or octree).
Should be possible, just implement the Source interface.
Where "stream" implies here to have terrain streamed in the runtime which sadly is not (easily) possible because of the loading process (for each chunk: generate octree, generate dualgrid, marching cubes on dualgrid). So a realtime editor is currently out of the scope of this project.
And if it would be a good idea to turn hand-modelled structures into some kind of higher frequency point cloud instead of keeping them independent from the terrain (I'm guessing they need to be separate models since the terrain uses triplanar texturing and textures can only change based on compass orientation and steepness).
Hm, this comes again down to "just" implement the Source interface. This implementation would be responsible for the higher frequencies. A CSGPerlinNoisePlane is totally possible. As it turns out, that this project makes a somewhat fast process without "search the corrupt pointer for one week"-bugs (yet...), this is a class I'd like to implement.
Time will show. Or a Mesh-to-volume converter (seen in an implementation of another isosurface algorithm). Subtracting some spheres from the Ogre Head would be nice. Or integrating him in the terrain like Mount Rushmore .
But those things are far away.
Material is currently this triplanar texturing, hacked together in a single shader without any configuration. This is one of the very next steps, making it more flexible. Don't know yet how. I'd like to have it like in the terrain component with it's gazillion fallbacks. But this would take a long time. I'd love to discuss this in a few days in a separate topic, how to make a simple, generic triplanar texturing material creation class. What fallbacks are needed, etc.
 http://www.voxelogic.com/index.php?opti ... &Itemid=21
 http://upload.wikimedia.org/wikipedia/c ... -2_new.jpg