Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

PolyVox and Ogre3D
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=2&t=77		 Page 5 of 6
Author:  AndiNo [ Sun Oct 17, 2010 8:34 pm ]
Post subject:  Re: PolyVox and Ogre3D
David Williams wrote:
you should store the world accross many volumes.
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.

David Williams wrote:
How big do you actually want your volumes to be?
From my experiences 32^3 will do fine perfomance wise so I will probably stick with this.
Author:  David Williams [ Sun Oct 17, 2010 10:02 pm ]
Post subject:  Re: PolyVox and Ogre3D
AndiNo wrote:
David Williams wrote:
you should store the world accross many volumes.
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.

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

AndiNo wrote:
David Williams wrote:
How big do you actually want your volumes to be?
From my experiences 32^3 will do fine perfomance wise so I will probably stick with this.

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.
Author:  beyzend [ Mon Oct 18, 2010 6:24 am ]
Post subject:  Re: PolyVox and Ogre3D
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.
Author:  AndiNo [ Mon Oct 18, 2010 10:02 am ]
Post subject:  Re: PolyVox and Ogre3D
David Williams wrote:
Yes, it's odd that beyzend hasn't mentioned this. Maybe he found a way around it?
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.

AndiNo wrote:
Actually, I meant what is the size of your whole world in voxels?
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.

beyzend wrote:
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.
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?
Author:  David Williams [ Mon Oct 18, 2010 5:18 pm ]
Post subject:  Re: PolyVox and Ogre3D
@beyzend - Yes, I do now remember you talking about this in one of your blog posts.

AndiNo wrote:
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.

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.
AndiNo wrote:
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.

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.
Author:  AndiNo [ Mon Oct 18, 2010 8:03 pm ]
Post subject:  Re: PolyVox and Ogre3D
David Williams wrote:
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.
Author:  David Williams [ Mon Oct 18, 2010 8:49 pm ]
Post subject:  Re: PolyVox and Ogre3D
AndiNo wrote:
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.
Author:  AndiNo [ Tue Oct 19, 2010 12:17 pm ]
Post subject:  Re: PolyVox and Ogre3D
I will probably think more about this during the next days.
On a positive note: Texture atlas is working! :)
Image

But I've got another problem: I'm using
Code:
typedef PolyVox::MaterialDensityPair<uint8_t, 7, 1> MaterialDensityPair80;
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.
Author:  David Williams [ Tue Oct 19, 2010 5:31 pm ]
Post subject:  Re: PolyVox and Ogre3D
AndiNo wrote:
On a positive note: Texture atlas is working! :)
Image


Great work!

AndiNo wrote:
But I've got another problem: I'm using
Code:
typedef PolyVox::MaterialDensityPair<uint8_t, 7, 1> MaterialDensityPair80;
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.


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;'.
Author:  AndiNo [ Tue Oct 19, 2010 9:30 pm ]
Post subject:  Re: PolyVox and Ogre3D
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 ;)
Page 5 of 6 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/