Larger volumes = more smooth meshes?

petersvp · **Joined:** Tue Apr 08, 2014 5:10 pm **Posts:** 124

Quote:

Look at what I wrote above. If this was really the problem, it would affect all volume sizes,

Nope. Oh, okay, you are right, it affects them all, but the larger the volume, less damaging these terraces are. And this is more than just logical. Check the definition of Coherent Noise first. You have a function that alters its value slightly when its input is slightly changed, and random, when it is more hadrly changed. If you have big volume, you end up with sequence like:
0.5, 0.5, 0.51, 0.54, 0.6, 0.63, 0.7, 0.7, 0.71, 0.7, 0.65 ... they change by small intervals thus your density value changes by 1 in worst case. When you downsample it, it looks like: 0.5, 0.53, 0.7, 0.9.... thus terracing is unavoidable.

Better ANL noise resolution = far less terracing.
Smaller the ANL resolution = More nasty the terraces.
And is some of your shots, it looks like you do not use density value at all!
What values do you use?

And this is the problem for you. How to solve it is on your own, because everybody wants something different. You have to base your filtering on my 6 level-deep for loop and filter it as you like. The topic with X/Z voxel heightmaps is not new, but it is definitely one of these topics that require research. The raw low-pass filter will smooth very good, but will eat small features.

Also, you need to run the filter as a post process, and in your case fr each column, only if you hit material in neighbouring columns for given height.

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

TheSHEEEP wrote:

David Williams wrote:

Can you truly verify this? Can you iterate over the voxels in those two columns and print them out?

Ooof, well we actually have 100 large volumes vs. 3600 small ones. That would be a bit... fiddly... to do that for each one of them

That's not quite what I meant. You should print out the list of voxel values for a single column of the large volume, (that is a list of 300 values, because your columns are 300 voxels high in both cases). Then do the same for the column which you believe is the same in the appropriate small volume, and then compare these lists of 300 values.

TheSHEEEP wrote:

We also don't need to get the whole column. Just their height value, as the "downwards filling" is always the same.

Print the column anyway ;-)

I believe your heightmap is consistent, but you need to verify that the actual voxel values are also consistent. The fact that you get different smoothness in the results implies that the voxel data is actually different, so you really should try to verify this by printing a column (or a couple of adjacent columns) from each volume.

On that note, don't print them out as you write them into the column - you should instead do the writing and then have a separate loop which reads them back and prints them out. This is in case you have a problem with the clamping/wrapping/precision of the 8-bit values. Really make sure that PolyVox is seeing the same data in both cases.

When printing, cast the values to int's to avoid just printing the 8-bit values as ASCII characters.

TheSHEEEP · **Posted:** Wed Jan 21, 2015 11:41 am

I did print the values and there really were no differences at all in the values (I printed them to a file and just had Sublime Text check the files for differences).
So the noise values per voxel as well as the filling of the x/z indeed work perfectly, as I suspected.

However, while flying over the terrain a bit, I noticed a curiosity:
The terraces only seem to appear below a certain threshold. Above that, it is smooth. And on coastal lines it is smooth, too. Strange....

I do optimize my smoothing algorithm to not smooth the entire volume, but only from the lowest set Y - 2 to the highest set Y + 2. Tremendous performance boost and super easy to do.

So I just forced the algorithm to always go from y = 1 to the highest Y.
And the result is a smooth terrain, with small terrain cells!
Link to screenshot
(the small seams one can see are the cell borders that are not smoothed yet to keep them aligned perfectly)

So it is not the noise value filling that is off, and not the smoothing.
There is actually something fishy with finding the lowestY. Which is strange as that really is just:

Code:

if (currentXZVoxelHeight < lowestY) lowestY = currentXZVoxelHeight;

Kinda fool proof, one would guess.

I will have a look at it, there must be something I overlooked.

petersvp · **Joined:** Tue Apr 08, 2014 5:10 pm **Posts:** 124

Quote:

However, while flying over the terrain a bit, I noticed a curiosity:
The terraces only seem to appear below a certain threshold.

Exactly what I was trying to explain in my previous TL;DR post.

What smoothing you applied? Did you based it on my code ?

TheSHEEEP · **Posted:** Wed Jan 21, 2015 4:26 pm

Not exactly the same, but very similar.
For example, I don't look at all 27 voxels. Just at 9 (the center and every corner). That is much faster, but slightly less smooth.

I have found the problem and it was that small area of 10 voxels I use to not let the noise values go directly from 0 to 255. That region of course pushes the "actual" height a bit downwards, and I forgot to apply that to my lowest-y calculation.
All fixed now and small cells look as good as big ones.

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

TheSHEEEP wrote:

I did print the values and there really were no differences at all in the values...

Then I'm afraid I really don't know why you would be seeing different mesh shapes if the input data is identical. However, it sounds like you already have a work-around in place.

I can however tell you what I do for my conversion of heightmaps to volumes, as maybe it is useful to you and/or petersvp. Basically I don't perform any filtering but I instead do all the work in floating-point before writing bytes to the volume.

My input is a 2D heightfield with floating point values ranging from 0.0 to 1.0.
I take a voxel and map it's height to the range 0.0-1.0. That is, if my volume is 256 voxels high and my voxel is the 192th voxel in a column then it has height 0.75.
I work out if my voxel is above or below the heightmap by taking the height from the heightmap and subtracting the height of the voxel.
This means than voxels below the surface have increasingly positive values (right?) and those above have increasingly negative values.
I add approx 127.0f, as this will be the threshold once we move to bytes.
I multiply by a largish value to 'compress' or 'squash' the range of values around the surface. I'm not sure what this value should be (still experimenting) but it affects how quickly the voxel values change.
I clamp to the range 0.0f-255.0.0f, and then cast the result to uint8_t and write that into the volume.

That's off the top of my head and I may have made mistakes. The point is that my input has floating point precision and my calculations have floating point precision, but my volume only holds a single byte per voxel. Actually I'm not sure if it is the right approach but it at least works to some degree.

TheSHEEEP · **Posted:** Thu Jan 22, 2015 10:09 am

This doesn't sound too different from what I am doing, really. Actually I think that my version is faster as it only needs to do calculation once per x/z coordinate and not once per voxel.
Your version comes with a certain smoothing on its own, but takes much longer as many more calculations are needed.

I might try it out at some point, maybe its "inherent smoothing" is enough to not require extra filtering/smoothing in our case.

My input also has floating point precision. It is just converted when stored into my C-Array to save memory.

Quote:

Then I'm afraid I really don't know why you would be seeing different mesh shapes if the input data is identical. However, it sounds like you already have a work-around in place.

Well, as I wrote, the smoothing was applied wrong in some cases. And the values I printed were pre-smoothing. Had I output values after smoothing, there would have been a difference.

petersvp · **Joined:** Tue Apr 08, 2014 5:10 pm **Posts:** 124

@David, can you provide code example of your algorithm? Still, I have to selectively apply different approaches to different materials but I may end up displacing Stone mountains into the Vertex shader. I want more jaggy stone and more smooth grass, and while low pass smoothing is easiest, your algorithm seems interesting to try.

I am currently writing OpenCL Marching Cubes implementation and I am really, really trying to make it work. It's hard, hard and hard.

I even plan to refactor ANL to work via OpenCL [as BSD-styled open-source project], But I will not have the time to do so...

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

TheSHEEEP wrote:

Well, as I wrote, the smoothing was applied wrong in some cases. And the values I printed were pre-smoothing. Had I output values after smoothing, there would have been a difference.

Right, sorry, I'm with you now. As long as it wasn't an issue in PolyVox then I'm happy :-)

petersvp wrote:

@David, can you provide code example of your algorithm?

It's using Cubiquity rather than PolyVox but the same idea applies:

Code:

VALIDATE_CALL(cuNewEmptyTerrainVolume(0, 0, 0, volumeWidth - 1, volumeHeight - 1, volumeDepth - 1, pathToVoxelDatabase.c_str(), 32, &volumeHandle))

// Don't yet know the best value for this. Setting it smaller makes the 
// result smoother but sculpting goes a bit crazy (some kind of wraparound)?
float scalarFieldCompressionFactor = 1024.0f;

for (uint32_t imageY = 0; imageY < resampledHeight; imageY++)
{
   for (uint32_t imageX = 0; imageX < resampledWidth; imageX++)
   {
      float fPixelHeight = resampledData[imageY * resampledWidth + imageX];

      for (uint32_t height = 0; height < volumeHeight; height++)
      {
         CuMaterialSet materialSet;
         materialSet.data = 0;

         float fHeight = float(height) / float(volumeHeight - 1);            

         float fDiff = fPixelHeight - fHeight;

         fDiff *= scalarFieldCompressionFactor;

         int diff = int(fDiff);
         diff += 127;

         diff = (std::min)(diff, 255);
         diff = (std::max)(diff, 0);

         materialSet.data = static_cast<uint8_t>(diff);

         // Note: We are flipping Y here to match the Unity3D coordinate system. This no longer matches the
         // OpenGL coordinate system. This flipping shold ideally be controlled by command line switches.
         VALIDATE_CALL(cuSetVoxel(volumeHandle, imageX, height, (resampledHeight-1) - imageY, &materialSet))
      }
   }
}

Note that 'resampledData' is a resized heightmap with floating-point values. In your case you have a noise function which already has floating point values, so no resampling is required.

Larger volumes = more smooth meshes?

Who is online