Simple Question:

Are chunks that are empty in a largevolume counted towards the number of voxels loaded in memory?

In other words are empty voxels treated the same as filled voxels as far as memory usage is concerned?

Hopefully I was clear enough.

Hope to hear from you soon.

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

I'll take a stab at answering this for you. Yes and No.


Yes:
A region is a Vector3DInt32, which is a Vector<3,int32_t>, which is in a sense the same as int[][][].

The memory for a region will be allocated based on the size of the region and the size of the type being stored (in this case it's an Int32 or (int) which is 32bits.)



It does not matter what value is assigned to the int, because it has enough memory allocated to store it's largest value.

No:
That being said... now when you take that region and you start using that data to build your surface mesh you will save on memory for having 0 values.

Since at this point you are only interested in storing values like "vertex positions" of voxels that do exist in your region, you won't be creating any extra memory allocations for empty areas of the region.

In my project I am not so much worried about the size of my regions. It's the stuff you build based off the region data that really starts to take up memory. So just don't keep around data you don't need.

For example when I create my surface mesh based off my region and then use that to build my ManualObject (mesh) in ogre.

I dynamically allocate the surface mesh, extract it, build my ManualObject and then I delete the surface mesh to free up the memory.

When I first started programming I would of probably stored it in a member or forgot to delete it and not even realize I would be leaking a lot of memory if I started updating my region and re extracting a surfacemesh without first deleting the old data

Anyways I hope this helps. I'm still very Jr, but I know these forums aren't the fastest place for help so I thought I would try and get you an answer.

Yes this makes sense. I'm not concerned about the amount of memory it takes when extracting.

I'm concerned as to whether empty chunks in the LargeVolume still count towards the int32 limit of the numbers of voxels it will keep in memory.

I don't want to be creating more meshes than the largeVolume will hold without paging it out.

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

I don't have the code in front of me so I'm a bit hazy here. But I don't think there is any difference between blocks which have all zeros and blocks which have real useful data in. In both cases memory is allocated and the data is stored.

However, many blocks are compressed while in memory, and in this case an empty block will compress much better than one with data in. So if you have a lot of blocks which are all zeros then you will use less memory than if you have real data.

On the other hand, the threshold for paging out blocks is based on a number of blocks used, not the amount of memory used.

Anyway, I guess you havehandlers for the paging in/out so you should probably add some print statements to see what happens when.

Yeah thats what I was afraid of. I didn't want the empty sky to take up my memory, but it looks like it will. For now, I am still working on speed, code cleanup, and shaders so it is not an issue, but eventually I might have to deal with it.

Perhaps if I limit view distance wisely it won't matter, but I was hoping to use quite a few voxels. They add up fast and the Int32 limit becomes surprisingly limiting, something I never thought would happen.

I fear thought that changing to an Int64 would take far too much memory before it started paging blocks out. Are there other options for increasing the amount of blocks that can be loaded in memory?

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

I'm guessing the effort of doing it differently will outweight the benefit. (but have no data to prove this)
Can you explain why you do not want any paging out?



wait... are you talking about the uint32_t that counts the loaded blocks or about the int32_t x,y,z coordinates accessed through SetVoxelAt/GetVoxelAt?

If it's the latter... then I see no possibility how that can be limiting if you don't want any paging out... even with Block Side Length of 1 (one voxel per block), and only using y=0, you will have 2^32*2^32 = 2^64 blocks in memory which will already die b/c of the uint32_t block counter.

and even if you only fill the uint32_t block counter just barely to the limit, you'll be using 2^32*(6+size(empty std::vector)) > 2^32*6 = 24 Gigabyte.

Hmm... I didn't even think about that

I'll cross that bridge when I come to it.



This is what I was talking about. I would like to achieve greater levels of detail by increasing the number of voxels a meter. Unfortunately this greatly increases the number of loaded voxels a scene takes.

Its possible if I keep it to a smaller amount of voxels I can combat this problem by offloading empty chunks and chunks well out of sight (such as those underground). There are some disadvantages to this as well, but it could increase my viewing distance.

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

well... it all depends on your extraction method I think.
if you only extract chunks when they change, only your graphics card's rendering capabilities are your limit. all the other chunks can be unloaded and loaded on demand through the appropriate callback functions of LargeVolume.
I'm not really sure where you'd actually reach any uint32_t limit or a memory limit if you cache stuff to the hdd and use the compression methods of LargeVolume.

Ok. Thats true I can display more meshes and I only really have to have the region the player can edit loaded into memory. Everything else can be reloaded if the player gets closer. I can make it appear like far more is being displayed at one time.

That should address my concerns at the moment. I won't be able to try this for a while anyways. Still have some other basics such as a decent shader to worry about.

Thanks

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--