Hello. So I have a planet renderer that is going to render voxels when you get close enough to the surface. The planets are to scale, and so the volume is as follows.

1 block = 1 meter
1 planet =1 Cube of 12 million meters ^ 3 = 1.728 x 10^21. I obviously cant create one large volume to handle this. I was wondering if there was another way using the LargeVolume class or something similar. Chunks are only created when the camera is within a certain range of them. Is there a way to dynamically add on to a volume, or rather just create a bunch of simple volumes as you need them? Thanks.

In theory you can and should use the LargeVolume for this, as it is supposed to allow near infinite volumes (up to 4 billion for the side length as I recall) because it can page data to disk when it's not in use. In practice I've never pushed it this far and I don't know if anyone else has either.

It's probably your best starting point though. We are intending to switch to it for our next project (Voxeliens just used the RawVolume) and in my mind I'm planning a volume of 4096x4096x256. This is a long way short of what you want but it does mean the LargeVolume will be getting some attention.

If it doesn't meet your requirements then a custom volume implementation is you only real option.

In regards to the size of a large volume, if I defined a 12,000,000x12,000,000x12,000,000x volume,
would this take up a large amount of size all at once, or is there a way to make it so the size/volume grows only when I need it to(i.e as people explore the planet). I don't need to load that many voxels into memory at once(since 99% of the planet is always invisible to the user), I just need to be able to get the surrounding data from the total planet volume.Thanks.

Also, from what I can see the LargeVolume constructor side length can only take a uint16. Does this represent the max length of a size that can be in memory and not the maximum region? I am a little confused at how the the region is defined for paging. Or is it just redefined with the callbacks everytime you need new data?

There are callbacks for loading an area that isn't in memory, so you would use this to either feed newly generated data, or data stored on disk. You don't really define a volumes size with large Volume, you only set or request regions to be extracted. So with Large volume if you request a 32x32x32 region to be extracted, callbacks (which you provide) will be called and you can fill it up with data. So even if your game world is 12000K^3 in size, but handle things smartly it won't take up much size (think minecraft, and its relatively small world size).

I'm explaining this badly, but I think you would get the gist of it.

The way I've done it for testing purposes is by getting the player position, and then blindly adding the surrounding voxel data, then I extract that region. I'm not using the callbacks yet, so when there are too many voxel regions stored in memory they are lost, but I'm able to explore very large areas of the game world.

That was what I was understanding from reading the class file. Thank you very much for the info that makes a lot of sense. So is the sidelength used internally to tell WHEN to call the callback?

[Edit] Sorry, I ended up repeating myself (I forgot that I already said most of this.) But there are some more concepts regarding sidelenght that you might find useful.

The callbacks will only be called when the voxel it is trying to access isn't in memory. Voxels aren't stored alone, but rather in memory blocks, often referred to as chunks.
The sidelenght is basically the amount of voxels it will store in a chunk, by default this is 32 voxels in a chunk. So when it tries to load a voxel at [10,10,10], and it isn't in memory, the callback will be called with the region of [0,0,0],[32,32,32] (where 32 == sidelenght). Your callback is in charge of (I haven't done this yet so I might be wrong) filling a chunk with the density/material values. This can be from disk, or a algorithm. It also works in the other direction too, when there are too many blocks in memory it calls the other callback (overflowhandler) for you to store the voxel data.

So yes and no, sidelenght influences when the callbacks are called, and how big a region they are in charge of filling with voxel data.


Think I forgot to answer your actual question in my last post:
It decides the size of a chunk, but not the maximum amount of chunks that are loaded in memory.