Hello, again

we are progressing nicely with our project and I am implementing our terrain generation at the moment, which is:
create a number of terrain cells via noise, get a mesh of that with PolyVox, then store to file. At runtime, snap these cells together.

A screenshot of one such terrain cell (3x3km big) can be seen here:
screenshot
The vorher/nachher (before/after) showcases smoothing, you can ignore it.

As you can see, when extracting a surface mesh, the border of that mesh gets a straight vertical "wall" (where the text is on).
Now, this wall only appears on two sides of the mesh for some reason.

We want this wall gone for two reasons:

• It influences normals on the border regions, which makes plugging the cells together a bit ugly.
• It creates a large amount of unrequired vertices.

So, yes, this is a request from Berlin to tear down the wall

Is it somehow possible to extract surface meshes without these walls?
Or, even better, is it possible to extract a mesh that ignores border regions completely?
Because even on the sides without such a wall, it seems that the border vertices have normals that seem to bend "unnaturally" due to being at the border.


Bonus question
As you can see, the number of vertices is rather significant.
Would the old MeshDecimator still work with surface meshes? (never quite got why you removed it - it worked well) If not, is there a replacement?
Right now, the amount of vertices PolyVox produces is really too large.

We could reduce it on Ogre side, but that would be much slower due to having to create a "wasteful" Ogre mesh first, just to be able to reduce it.

_________________
My site! - Have a look
Also on Twitter - with more ketchup

This is not a bug, but feature that often confuses newbies.

Define your regions you pass to the surface extractor so they ignore the offending wall, that is, try extracting inner region, not the whole region (e.g. if the source region is 0,0,0 ... 32,32,32, you have to extract 1,1,1....32,32,32, or 0,0,0...31,31,31, depending from where you have the walls)

I cannot assist any further, just play with the region boundaries by yourself until you manage to understand how Regions exactly work

About the normals problem, for neighbourhood borders, you need to overlap the data in them by two voxels.

e.g. if you need 10x10x10 chunk, the volume must be 14x14x14, and you extract 2,2,2...12,12,12.

Even better, Store your data in plain C 3D (even better, 1D) arrays per chunk, and when you need to extract a chunk, copy overlapped data from needed chunks to RawVolume and extract this.

Check how my chunks line up perfectly: The side walls are kept intentionally in the smooth terrain shot.
https://fbcdn-sphotos-b-a.akamaihd.net/hphotos-ak-xpa1/t31.0-8/1149471_715708458488322_2356268206906638875_o.png
https://fbcdn-sphotos-d-a.akamaihd.net/hphotos-ak-xfp1/t31.0-8/10582923_773194666073034_3383763318931333794_o.jpg

Thanks, I will try that!


I'm not quite sure I understand what you mean.

Let me try to rephrase:
So, basically, the border of volume when extracted as a mesh (where the outmost voxels are) always has that normal problem.
If I want to avoid this problem, I need to add two more voxels in each dimension.
Those two border voxels must contain the values that are also at the respective positions in neighbouring cells/chunks.
In the end, I must have redundant data in each volume I create, though only a bit.

Is that correct?
If it is, and I want a 300x300x300 chunk, I create a 304x304x304 Volume, of which I only extract 2x2x2...302x302x302, right?

Would this also remove the border walls? It sounds like it at least, as I do never extract the outmost voxels as a mesh.

_________________
My site! - Have a look
Also on Twitter - with more ketchup

300x300x300 is fairly huge dataset to work with. In Crafterria, we use 16x16x16 chunks (I call them Chunk Sections, like Minecraft's terms) I can considering trying out 32x32x32 chunks, but I know, 64x64x64 is not suitable for real-time chunk deformations.

While implementing my chunk manager, I was set the chunk size to 4x4x4 so I can debug it far easy.

However, in orer to avoid maintaining overlapping data sets (volumes), I highly advise you to store them in C arrays and when a chunk is requested, you just build Polyvox volume from requested chunk data and its neighbouring chunks. The border have to be 2 voxels because the way Polyvox 0.2.1 handles normals. If you only care about correct geometry, you can overlap by only one voxel, and then calculate your normals somehow.

You can check the repo at https://sourceforge.net/p/kitten-platform/code/HEAD/tree/ - the Polyvox version there is slightly modified - the MeshDecimator is patched to always line up with neighbour chunks. Also, please note that the code there have no l1c3nse and is purely for backup purposes, I even fear a bit about it and someday I will copy the repo to private server because the project starts to evolve. But you are free to examine the buggy code of PGF and inspire / steal ideas from it, especially steal the shaders and the code for the splatting even if it's not optimized for memory

petersvp is basically correct, but I'll provide some context for why it is like this. The marching cubes algorithm generates a surface whenever it finds an occupied voxel next to an empty voxel. If you region you are extracting extends outside the volume then the external voxels are considered empty (as I recall... slightly hazy here) which means you have the occupied voxels in your volume adjacent to the 'empty' voxels outside your volume. This is what creates the wall.

If you make the volume bigger than necessary and just work on a sub-region of it then you can avoid these edge cases.

As for the decimation, it was removed because I wasn't using it myself and it was some extra effort to maintain (e.g. would it work with the new compressed vertex format?). In Cubiquity we are doing LOD by building a downsampled copy of the volume data and running Marching Cubes on that. Some effort is required to line up the resulting meshes but it works fairly well. In the future we may well perform mesh decimation as well but I intend to test out the OpenMesh library rather than implementing it ourselves.

Thanks for the help and clarification, guys!
I will go with a slightly extended region then and see how that goes


In our case, we do not keep any voxel data as we don't want terrain deformation. We use PolyVox "only" for mesh creation. As soon as the world terrain is created (at game start), we do not use voxels any more.


Will do! Mostly for the MeshDecimator.

_________________
My site! - Have a look
Also on Twitter - with more ketchup

Let me add something David completely forgot to mention.

Cubic Surface Extratror is straight forward. You have cube for each voxel.
Marching cubes, however, is another beer:
We have a vertex placed in BETWEEN the voxels.
How much, much, MUCH special cases exists because of that, one of them is why have walls only on TWO sides The algorithm itself is somehow ambigous! If you have 4x4x4 density volume (3d array of floats), you end up with... well... 5x5x5 mesh. Not 4x4x4. Polyvox's implementation takes strange decisions that I have no idea WHY, but I just ended up tweaking my regions with +1/-1 to be happy with it. Then another questions start to arise: WHAT is the ambigous material ID of the vertex? What is... well, WHAT IS? This is the next question that we all asks us when we decide to use Marching Cubes and look at all possible borderline cases. But well, the overlapping of voxel data solved so much of these problems, including the ambiguity with material ids and rendering - I used 3D Volume texture and Texture volume mapping in the pixel shader. And STILL, I have a lot more ambiguities to solve. Texture interpolation on the GPU, for example, s..k at borders. Overlapping ot the volume data solves this - I just don't care about texture borders. And we have a lot of "unused" texel data in the GPU. Well, Marching cubes.... Why not something different that is by definition aligned to its voxel data? Because Life is complicated

More tips for you. Note: Mesh Decimator is only available with Polyvox 0.2.1 and older, David removed it for some reason even if it was perfect piece of code.

The original mesh decimator had nasty bug: Optimized chunks did not lined up perfectly and a lot of gaps were present. Neither you, nor me wanted this, so I had to look thru its code and just add return false; in . This made chunks lining up perfectly without requiring TransVoxel and lower-scaled volumes.

You can patch the Mesh Decimator from here: https://sourceforge.net/p/kitten-platfo ... imator.inl - if you are with 0.2.1 (or similar old version that have this code)

In my particular case, David's approach (downscaling volumes) is not just unacceptable (to be honest, it's impossible), because of following downsides:

1. The game's voxel data is always there as is. Downsampling it is not efficient and slow procedure because you have to calculate a lot of interpolations while the process. I have to use the data as is.
2. Downsampling approach cannot make chunks line up perfectly when placed next to each other. We will need to overlap meshes, which is 1. overdraw (not so serious problem with today's GPU and hardware) and 2, the real bottleneck, some physics engines are not appy with such penetrationns. In Bullet physics, all my objects become CRAZY when they hit overlapping parts.

In your case, Mesh decimation is the fastest solution to the problem as it is there and only one "return false" is needed to fix it to work for us.

Hope David bring it back again, and even if OpenMesh is used, MeshDecimator must have built-in setting to never collapse border edges, so our chunks always line up correctly. The rest ambigousities like interpolation of material IDs is for ourselves to research.

Alright, your hints worked very well.
The border walls are removed (decreasing the vertex count by up to 40% in some cases) and it seems that the normals at the borders are also unaffected of any "border-induced" strangeness.

Of course, if the cells fit together perfectly still has to be tested, that is my next task to implement.
The MeshDecimator is also not tested yet, which is the task after.

_________________
My site! - Have a look
Also on Twitter - with more ketchup

Okay, I placed the cells next to each other and noticed that 3 border seemingly perfect. At least I could not find visible artifacts.

One border (the left one, -x direction) however still has the last row of vertices dragged downwards for some reason.

I can remove that by extracting (3, 2, 2) -> (302, 302, 302), but that of course leaves the left and right border not fitting that well any more. So, (2, 2, 2) -> (302, 302, 302) for some reason drags the left border of each cell downwards.

Here is an image that shows the problem when using (2, 2, 2) -> (302, 302, 302):

As you can see, the leftmost vertices of the right cell are all dragged down.

I guess that extracted surface meshes align perfectly only if they are all extracted from the same volume. Could that be correct?
It is really annoying that 3/4 borders work just fine, but one screws it up

_________________
My site! - Have a look
Also on Twitter - with more ketchup

"I guess that extracted surface meshes align perfectly only if they are all extracted from the same volume"

You are wrong as I am working with the way I told you. Do you fill your volumes completely? Try filling outside them with 1 until you hit the bounds checking assert. I already do that and with 2x2x2 overlap, just the time I solved my seamlessly-fitting-glitches was way too much time ago. I solve all my seams and all my chunks tile seamlessly including their normals.

Try correcting your algorithm, for that, try with way smaller vlume until you get it properly, then just alter it, e.g. try to play with 16x16x64 chunks until you manage to get them lining up properly. It is possible because I managed to achieve it after a day playing with indexes and numbers without knowing why.