It is currently Sat Aug 22, 2020 3:39 am


All times are UTC




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Small extra faces between marching cubes faces
PostPosted: Fri Sep 23, 2016 3:34 pm 

Joined: Fri Sep 23, 2016 3:03 pm
Posts: 5
Hey!

I started with PolyVox not long time ago in the Unreal Engine 4 and it works pretty well so far.

However when using the marching cubes surface extractor (develop branch), I noticed extra faces when using marching cubes which also seem to have weird normals. Is this normal (even though it seems like these extra faces could be avoided?) or is this a bug?

Image
Image


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Small extra faces between marching cubes faces
PostPosted: Sat Sep 24, 2016 6:09 pm 

Joined: Fri Sep 23, 2016 3:03 pm
Posts: 5
Mhh, after changing some parts of my code, the extra faces are gone. I'll try to find out what caused them.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Small extra faces between marching cubes faces
PostPosted: Sun Sep 25, 2016 8:16 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
This is a valid output, it completely depends what the underlying voxel data looks like. Are you using integers or floats? Perhaps your threshold is off by a small amount?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Small extra faces between marching cubes faces
PostPosted: Fri Apr 07, 2017 11:42 am 

Joined: Tue Apr 08, 2014 5:10 pm
Posts: 124
David, The weird faces have indeed wrong normals in current Dev Branch, as they do in 0.3.1 as well.

Long time ago, I had a Checkers Voxel Data which I used to test most available Marching Cubes implementations. ALL of these implementation that used QEFs or Gradient-based normal calculations used to have some form of null normals even through that kind of normals were looking far more good for lighting than average-smooth ones.

In Crafterria I used following approach: After PolyVox Marching Cubes did its output, I reiterate all trianfles and IF a triangle have null normals, I generate them from the averaged normals of all vertices with same position plus the triangle plane normal, so we get it fixed. This was working good, however, within time, I removed Polyvox from the game and wrote marching cubes myself using alternate lookup tables. I used the classic smoothing algorithm that I average vertex normals and it was working quite good.

Marching cubes is indeed easy as cake, If you (OP) manage to understand it you can understand it have flaws as well :) For example, there is ambigous case in its original mesh set definition in by Paul Bourke. There is an implementation of Marching Cubes that resolves these cases, and it's called Extended Marching Cubes. If you can invest a week or two to implement it you will benefit.

If you are making an open-world game, Marching Cubes will not help you that much because of LOD Issues. And any primal method will be a waste, too. Go read about Dual Marching Cubes.

And if you want to have smooth and hard shapes, Dual Contouring is your friend however the algorithm is enormously heavy for big open-world games even today.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Small extra faces between marching cubes faces
PostPosted: Tue Apr 11, 2017 10:49 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
petersvp wrote:
Long time ago, I had a Checkers Voxel Data which I used to test most available Marching Cubes implementations. ALL of these implementation that used QEFs or Gradient-based normal calculations used to have some form of null normals even through that kind of normals were looking far more good for lighting than average-smooth ones.

In Crafterria I used following approach: After PolyVox Marching Cubes did its output, I reiterate all trianfles and IF a triangle have null normals, I generate them from the averaged normals of all vertices with same position plus the triangle plane normal, so we get it fixed.


Indeed, PolyVox uses a simple central-differencing approach to normal calculation which can fail for certain voxel configurations such as a checkerboard. I can't say I've really had a problem with it myself, but computing vertex normals as the average of face normals is a pretty standard approach if you want to replace them.

petersvp wrote:
Marching cubes is indeed easy as cake, If you (OP) manage to understand it you can understand it have flaws as well :) For example, there is ambiguous case in its original mesh set definition in by Paul Bourke.


Actually I thought Paul Bourke's implementation (the original basic for PolyVox) had included the fix for ambiguous cases, though I may have been mistaken. They have never caused me any problems though I agree there are many more advanced algorithms available now - Marching Cubes is now 30 years old!


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

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


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