Hi there,

I'm using Polyvox since a few month on my project and I've been following this forum since then, seeking for all the good information it contains.
First, a quick word to say how glad I am to have found this great voxel library, considering all the time I saved on my project thank to it. So many thanks for all the good work!

Now, about my issue. I recently updated the version of Polyvox I use to the latest commit on the develop branch. I was using the sobel gradient for normals extraction in the marching cubes, so I had to retrieve it back from a previous version of MarchingCubesSurfaceExtractor.h to paste it into MarchingCubesSurfaceExtractor.inl, along side with the central difference gradient function.

But unfortunately, the resulting normals aren't the same as before and look terrible now.
Basically, the grass texture is on the Z (up) plane, and the soil texture on the others planes for my triplanar texturing.

This is how it used to look with my older version of polyvox:

http://www.hostingpics.net/viewer.php?id=981680beforesobel.png

And here is how it looks like now (only change being the Polyvox version used):

http://www.hostingpics.net/viewer.php?id=726236aftersobel.png

I looked at a detail where the normal seem to break, and it looks like some triangles don't use the right normal:

http://www.hostingpics.net/viewer.php?id=486003detail.png

On the wire frame, we see that the tiny triangles seem to break the "smoothing":

http://www.hostingpics.net/viewer.php?id=655794detailwireframe.png

I looked at possible mistakes I could have made when doing my changes to use the sobel gradient, but found nothing at first glance.

Would you have an idea of what produced this change? I saw the marching cubes extractor has been refactored a lot so I suppose this is related.

Thanks in advance for the help!

Cheers,

Kishan.

Hi, welcome to the forums and I'm sorry to hear about this problem. I can actually think of two potential causes, so it would be useful if you could specify exactly which versions of PolyVox you were using before and after?

The first potential cause is indeed the way the normals are calculated - as noted I removed the sobel gradient as I didn't think it was going to be significantly smoother (particularly considering the second potential cause). I may have been wrong about this in which case the sobel approach can be brought back.

The second potential cause is that we have changed the way in which positions and normals are encoded. This happened longer ago and I think it is the more likely cause. Basically, we encode the normals into a single 16-bit integer and also encode the vertex positions. This reduces the size of the data to about 1/3 but with some loss of precision.

Let me know your version number and I'll take a look.

Hi David,

Before I was at this commit: https://bitbucket.org/volumesoffun/polyvox/commits/c98ad8c948e79d9dd6480a244f8b4dd6f812b904?at=develop

This was when you removed the wrap modes. The positions and normals were already encoded at that time. I mean, I already use the decodeMesh() function, if this is what it is about.

My recent update is to this commit: https://bitbucket.org/volumesoffun/polyvox/commits/14cac713bd724b6a74f1aff2c1aa07e11fc31a3a?at=develop, just after the merge of the branch extractor-optimizations.

And maybe this wasn't clear in my initial post, but both before and after, I was using the Sobel gradient.

I also compared with the central difference gradient before and after and, even if less noticeable, the same kind of artefacts appear. I'll post screenshots about this later today.

Thanks!

Kishan.

Ok, I'll take a look and see if I can reproduce it. Can I also ask what data you are storing per-voxel? Are you storing a density or computing it on-demand? And is it a float, int8_t, etc?

Ok I've reproduced the issue using only Central Difference gradients. It looks pretty bad!

Here's the old (smooth) normals:



And the new (ugly) normals:



In both cases this is with central difference normals and with the compressed vertex format. So something else is broken :-S

Actually I remember having normal problems in Cubiquity but I put it down to the encoding... maybe that wan't true. Anyway, I'll do some investigation and get this fixed. Thanks for the heads up!

I'm glad you managed to reproduce it!

And just for completeness, even if it doesn't really matter anymore, my voxel data is a class from which I return a zero density if it's empty, or an uint8 density otherwise, cast into a float in my implementation of MarchingCubesController::convertToDensity().

I look forward for your fix. Thanks a lot!

Kishan.

Here is a comparison between central difference gradient and sobel gradient:

With central difference:

http://www.hostingpics.net/viewer.php?id=215595beforecentraldiff.png

With Sobel gradient:

http://www.hostingpics.net/viewer.php?id=981680beforesobel.png

As you can see, Sobel looks better. I didn't tried, but do you think applying a low pass filter to my data could improve significantly the normals generated with the central difference gradient?

Cheers,

Kishan.

Ok, the bug is fixed!

• https://bitbucket.org/volumesoffun/polyvox/commits/f8e1bb8452885325495b8c3831e478eff742bd12

Yes, I can see that Sobel looks better. It might be that you can improve the central difference version but improving the smoothness of the voxel data (i.e. by generating smoother voxel data in the first place) but I understand this can be difficult to do (especially with only 8-bit precision). It was also a challenge in Cubiquity.

I don't think you should use the low-pass filter - there will be extra complications if you do this. Probably it's best if you generate the voxel data to be as smooth as you can, and then if you find Sobel helps the appearance then you should continue to use that.

I can put the Sobel code back into PolyVox. However, how were you calling it before? My memory is hazy, but as far I can see it was not possible to choose which method to use? Did you just modify the source before?

Hi,

That's great news! I'll test the fix as soon as I have some time.

Regarding the use of Sobel gradient, I think I'll stick with it as I don't want all my generated data to be smooth anyway. And yes, I modified the marching cubes surface extractor directly to use the sobel gradient function.

I'll share in another post some other changes I made (not much).

Thanks again for the quick fix!

Kishan.

Great, the sobel code is back in there now so you can do the same again:

• https://bitbucket.org/volumesoffun/polyvox/commits/920c78f4d11d78dcb8f078051b2d6ef4665cd988

Thanks for finding it! I had actually done an image comparison to make sure I didn't break the extractor during the refactoring, but my test volume only had densities of the minimum and maximum values (i.e. it wasn't smooth) and the bug doesn't show up in this case. I would probably have just blamed any future artifacts on the normal compression so it's good that you spotted it!