Hmm... I've actually done that before getting a physics engine to line up... I feel kind of silly right now.

So I align my volume center to my graphical center and choose the number of pixels/voxel I want. Then all I have to do is scale by that ratio.

Thanks

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

My graphical center is lined up with volume center. The reason I do that is because I work with Ogre's paging system which works with pages. Where my page is defined as a 32x32 sized region.

World coordinate is your camera position in world space. So to pigeon hole into a region of 32x32x32 volume that's what you do. This is a ratio. You don't have to divide. You also don't have to use floor, you can use truncate instead.

But you are right, in your paging system you don't have to work in Page units like Ogre's paging system. You could just work all in world space and define Regions relative to the camera. So a region is just camera center position plus region extents. But wouldn't you have to update your positions constantly and page in constantly? I don't think doing this is a good idea. So you have to keep track of the camera as it changes regions...which basically you are going to work in page units anyway.

My volume is defined with world coordinates, in world space. There is no reason to convert between different coordinate system. THe only reason for converting to page units is for the paging system because it's easier to work with pages when you are...paging.

Hmm, I'm confused. I thought you wanted to do paging and convert into page units, ie sets of 32x32 regions. SO region 0 would be the 0th 32x32 region and so on.

Beside conversion for paging to work with page units, there is no need to do any conversion like that. The actual voxels in the volume can all be aligned with graphical units or whatever--world space.

Sorry I might have explained myself poorly. I also have an admittedly poor understanding of how this library works. I am still experimenting to figure it out.

I simply meant that my graphical center and volume center needed to be the same, and then I choose how these different spaces relate to each other. In my limited experience it comes down to a ratio that you use to convert one coordinate system into another. For example I am planning on 4 voxels a meter and 100 pixels a meter. 4 v/m 100 p/m. Using these ratios I can convert between OGRE, PolyVox, and eventually a physics engine.

However I don't understand what you are talking about when you mention paging units.

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

I've made a little progress, but I keep banging my head against things I don't understand yet. I believe I understand how to manage paging, and how to manage how much data is extracted at a given time. But how do I handle the meshes?

If I use 32^3 chunks and a mere maximum viewing distance of 40 meters... at my desired ratio of 4 voxels a meter that is 5 meshes in one direction. That makes ten meshes across, 100 meshes^2, and 1000 meshes^3. Is this the amount of meshes I should be expecting?

I think I am missing something obvious about management



THis was mentioned earlier, but I am a little confused. Doesn't extracting a mesh take some time? So how does frustrum culling help when someone is looking around the landscape? Wouldn't the delay in extracting meshes be too much?

Anyway any more advice on managing meshes would be appreciated.

Thank you!

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

Correct me if I'm wrong but I think that's right. You want 40m loading radius, which come out to 5 *regions*, thus 10* region across. So 10^3 will give you a volumetric cube that will contain all the *regions* with a loading radius of 40m. This is actually what I was talking about earlier when I went on about pages. Pages-->Regions.

Yes that would be right. But isn't that too demanding for the system?

And that viewing range is too small. It would almost certainly have to be larger which greatly increases the number of meshes. I believe I know how to handle the polyvox volume, but how do I handle the incredible number of meshes?

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

You can load as many meshes as you want onto the GPU. 1000 or 10,000, it doesn't really matter (except to the point that you run out of GPU memory). The important point is that you can't render them all at once (you can probably render just a few hundred per frame), but then you can't see them all anyway as most of them are behind you or off to the side.

So you can place the camera somewhere in space, generate all surfaces within 1000 voxels, and load all the meshes onto the GPU. Then out of all those meshes you only render the ones which are actually in the view frustum. As the camera rotates you change which meshes get rendered, but you don't need to extract anything because it is already on the GPU.

Of course, if you then start to move the camera you need to do some extraction and load more meshes onto the GPu (and delete the old ones). But movement speed is usually limited so you have time to do this, whereas rotation is usually instant.

Memory is potentially a problem, and to be honest I haven't done the maths here. But you already seen the demo with a 1024x1024x256 terrain and that seems to load onto the GPU ok.

If I attach a manual object to the scene manager is that the same as loading the mesh to the GPU?

If the number of meshes is not a problem then how do you manage such a large number of meshes? Such as Keeping track of which ones that are loaded so you don't regenerate meshes that have already been created?

Thanks for the help.

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

Ogre's manual object manages hardware buffers for you, so yes, one you create them they are uploaded to the GPU. Once you copy the data in PolyVox::Mesh objects to Ogre's manual objects, you no long need PolyVox::Mesh objects. All you have to do now is manage the pointers to these manual objects.

So we have the PolyVox::Volume which stores the volumetric data for us. You want to divide the world into 32^3 regions, fine. We already have the volumetric data in the volume associated to each of these region, but we also have some extra data beside the volume data that is also associated with the region, things like Ogre's manual object, for example. We need a logical representation of the region and store this. The point is we need a data structure to represent the region and storage for these, beyond just PolyVox::Volume. In my app, I have a small structure called PageRegion, which does exactly this. Actually you don't have to do this if you don't plan on doing any paging. Although, beside paging there are other uses for having a data structure representing regions.

This brings us to paging. Suppose you start the world with a camera position, we have already figure out that if you want a 40m view radius, plus also number of *regions* that represent this 40m view radius, 10 across. So, we just loop through each region and load it. If you don't need paging then we're done. If you need paging, then you need to figure out new regions to load as you move the camera. How to do this?

You can use Ogre' paging system. Ogre' paging system works with Pages. In our case, each page corresponds with our definition of a region, given above. Each Ogre page has an ID, which is computed from it's page x, y. Ogre's pages has a ratio of One page per Page Dimension. Specifically for our case, it's just One page per 32 voxels. Thus we can directly correspond Ogre's page to our region.

In Ogre's paging system, the system will call load / unload methods as provided by you. With these functions, it will pass in the page x, y, with this you can then take the appropriate action such as loading, unloading a page. Oh yeah, you can use the Ogre's page ID as the key in to your page storage.

In my own clone of PolyVOx I've implemented an example paging system. You can reference it. It basically does what I described above.

https://gitorious.org/~beyzend/polyvox/ ... eManager.h

BTW my paging system only does 2D paging but it's easily converted to 3D. In the end I suggest looking over at my paging example then use Ogre's paging system, since it does 3D paging and 2D paging.

....

Oh course you don't have to do this at all. There may be other ways of doing this.