That's probably what I will be doing. Just the thing/bug which doesn't calculate mesh data for the outmost blocks of a Volume is a bit hindering when using this.

From my experiences 32^3 will do fine perfomance wise so I will probably stick with this.

Yes, it's odd that beyzend hasn't mentioned this. Maybe he found a way around it?


Actually, I meant what is the size of your whole world in voxels? If it will be infinite then you will need streaming, but if it is just large (say 1024^3) then you might get by without.

I think I did say something about it but you know my posts can long and hard to understand .

I'm currently not using the regions function within Volumes (although I would prefer to use regions), what I do instead is store 16x16x256 (height) "chunks" per volume. Problem with doing this is you get missing blocks on borders between volume regions. What I did as a quick fix is modify the surface extractor from x,y,z < regionSideLen to x,y,z <= regionSideLen. Problem with this as you know is for each region a {n * n - (n-2) * (n-2)} border surface is created, no matter what the actual value along the border because we assume the border to be air.

My current plan for a quick fix is to store the data in 256x256x256 Volumes instead of keeping them in a bunch of different Volumes. For streaming I would translate my page ID (page size is still 16x16) into regions within this single volume. For transitions between volumes I would translate the page id, then allocate new Volume if found that we are transitioning, and create the terrain procedurally as before. Wait you say, why are you doing this stupid translation? Well, it's because I'm using one of Ogre's default paging strategies and I'm not going to bother with implementing my own, for now.

Eventually, maybe I could modify Volume to support paging within Volume. I'm not sure.

For the time being I will wait and hope you come up with a fix to this. I have an idea which could work in case you don't fix it, but it would only complicate things.

Oops I think I will try something like 256^3 consisting of 512 32^3 volumes. That's my plan for now.
edit: Yes, I want to use streaming to have an infinite world. So multiple volumes will probably be the easiest way.

Well, to me this seems like a solution. If I understand you correctly the problem is the outmost faces of a volume are always rendered, even if the neighbouring voxels are solid - because one volume has no information about the volume next to it. From my point of view this seems to be acceptable, so I probably will use your change. Would you be so kind to post what code you changed exactly?

@beyzend - Yes, I do now remember you talking about this in one of your blog posts.


I will probably fix it so that the voxels do go right to the edge of the volume (because this would be correct behaviour), but not so that one volume is aware of what is in its neighbouring volume. So you'll still get the extra polygons on the border. The correct solution would be to add streaming support inside the Volume class but this isn't something I'm currently planning to implemnt.

I must say, I never imagined using such small volumes. Thermite uses a single volume and easily handles scenes of 512^3, and I expect it will go further. I don't know if small volumes will casuse any real problems, but it may not be very memory efficient as the compression is designed for larger volumes.

Then I got something really wrong I was making that decision on how long it takes to completely recreate the volume + ManualObject after a change. With 32^3 there is only a short stutter so I thought this would be the best size. From what I read I got the impression that Thermite uses regions to get a small subset of voxels out of the volume and update it, right? I always wondered why Thermite was so fast^^ But I think the price for this is more complexity in the code. But I will take a look at that sooner or later.

Yes, this is correct. Thermite creates a single volume and then extracts (for example) 8x8x8=512 meshes. Each mesh corresponds to a seperate region of the volume. When part of the volume changes, only the meshes for the corresponding regions need to be regenerated.

But PolyVox just provides the Volume and a way to get the surface for any part of it. You need to implement the logic to decide which regions to extract when.

I will probably think more about this during the next days.
On a positive note: Texture atlas is working!


But I've got another problem: I'm using
but I want to use the full 8 bits for material and 0 for density. Is there a way to do this without changing PolyVox or completely creating my own class? (tried that once and my game crashed^^) And of course without resorting to 16 bit integers.

Great work!



I'm going to need something like this myself fairly soon, and I'll probably use template specialization to handle the cases where one of the parameters is zero. So unless you need it soon the easiest thing is to wait for me to implement it. Otherwise you could just create a new class by copyin and modifying the existing one. Just store a simgle char for the material, return it with the 'getMaterial()' function, and implement getDensity() as something like 'if(material > 0) return 255; else return 0;'.

It's not that urgent for now. I'll wait some time, gotta do a lot of stuff for gameplay now. I have faith in you