It is currently Sun Dec 15, 2019 9:24 pm


All times are UTC




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Recent marching cubes issue
PostPosted: Sat Jun 13, 2015 9:51 pm 

Joined: Sat Jun 13, 2015 5:49 pm
Posts: 5
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:
Image
http://www.hostingpics.net/viewer.php?id=981680beforesobel.png

And here is how it looks like now (only change being the Polyvox version used):
Image
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:
Image
http://www.hostingpics.net/viewer.php?id=486003detail.png

On the wire frame, we see that the tiny triangles seem to break the "smoothing":
Image
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Recent marching cubes issue
PostPosted: Sun Jun 14, 2015 6:34 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Recent marching cubes issue
PostPosted: Sun Jun 14, 2015 8:23 am 

Joined: Sat Jun 13, 2015 5:49 pm
Posts: 5
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Recent marching cubes issue
PostPosted: Sun Jun 14, 2015 9:03 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Recent marching cubes issue
PostPosted: Sun Jun 14, 2015 9:30 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Ok I've reproduced the issue using only Central Difference gradients. It looks pretty bad!

Here's the old (smooth) normals:

Image

And the new (ugly) normals:

Image

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!


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Recent marching cubes issue
PostPosted: Sun Jun 14, 2015 10:44 am 

Joined: Sat Jun 13, 2015 5:49 pm
Posts: 5
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Recent marching cubes issue
PostPosted: Sun Jun 14, 2015 10:56 am 

Joined: Sat Jun 13, 2015 5:49 pm
Posts: 5
Here is a comparison between central difference gradient and sobel gradient:

With central difference:
Image
http://www.hostingpics.net/viewer.php?id=215595beforecentraldiff.png

With Sobel gradient:
Image
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Recent marching cubes issue
PostPosted: Sun Jun 14, 2015 12:12 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Ok, the bug is fixed!


Kishan wrote:
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?.


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?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Recent marching cubes issue
PostPosted: Mon Jun 15, 2015 8:03 pm 

Joined: Sat Jun 13, 2015 5:49 pm
Posts: 5
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Recent marching cubes issue
PostPosted: Tue Jun 16, 2015 9:09 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Kishan wrote:
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.


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


Kishan wrote:
Thanks again for the quick fix!


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!


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net