| Volumes Of Fun http://www.volumesoffun.com/phpBB3/ |
|
| Small extra faces between marching cubes faces http://www.volumesoffun.com/phpBB3/viewtopic.php?f=15&t=677 |
Page 1 of 1 |
| Author: | BitteWenden [ Fri Sep 23, 2016 3:34 pm ] |
| Post subject: | Small extra faces between marching cubes faces |
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?  
|
|
| Author: | BitteWenden [ Sat Sep 24, 2016 6:09 pm ] |
| Post subject: | Re: Small extra faces between marching cubes faces |
Mhh, after changing some parts of my code, the extra faces are gone. I'll try to find out what caused them. |
|
| Author: | David Williams [ Sun Sep 25, 2016 8:16 am ] |
| Post subject: | Re: Small extra faces between marching cubes faces |
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? |
|
| Author: | petersvp [ Fri Apr 07, 2017 11:42 am ] |
| Post subject: | Re: Small extra faces between marching cubes faces |
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. |
|
| Author: | David Williams [ Tue Apr 11, 2017 10:49 pm ] |
| Post subject: | Re: Small extra faces between marching cubes faces |
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! |
|
| Page 1 of 1 | All times are UTC |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|