Volumes Of Fun

[0.2.1/0.3.1] Strange normals generating NaNs
Page 1 of 1

Author:  petersvp [ Thu Oct 15, 2015 10:01 pm ]
Post subject:  [0.2.1/0.3.1] Strange normals generating NaNs

I am having a problem with provided normals from PolyVox 0.2.1 in some strange cases.

The normals generate NaN or Inf and end up as "Chuck Norris" triangles, with bugged values and rendered on top of almost everything

Also, David you may remembed that I used binary source volumes that I smoothed afterwards, this is no longer the case, I no longer smooth volumes, I generate them column-by-colum with floating point based smoothing which in this case produces such meshes.

I have no idea how to work-around this problem... :)


Author:  David Williams [ Fri Oct 16, 2015 10:19 pm ]
Post subject:  Re: [0.2.1/0.3.1] Strange normals generating NaNs

In your post title you mention 0.2.1/0.3.1 but in the text you only mention 0.2.1. Do you know if this problems still exists on develop? I know it might not be possible to test.

There was a bug fix a few months ago which might also be applicable to PolyVox 0.2.1: https://bitbucket.org/volumesoffun/poly ... eff742bd12

Also, it is in theory possible for zero-length normals to be generated. Imagine a 3D checker board for example. In this case the normal at each voxel will be zero, and so the interpolated normal at vertices will also be zero. It's hard to imagine how this would be happening in your case though.

Can you see NaN/Inf normals in the debugger? Can you trace it back at all and see what voxel values generate them?

As for working around it, you also have the option of ignoring the PolyVox normals and computing some yourself via face averaging. Actually, does ignoring the normals fix the black face problem? Cam you turn off lighting completely and/or see anything happening in wireframe mode?

Author:  petersvp [ Fri Oct 16, 2015 11:34 pm ]
Post subject:  Re: [0.2.1/0.3.1] Strange normals generating NaNs

The problem is indeed the normals. When I added a call Mesh.recalculateNormals() in Unity side, the problem is gone away, but chunks don't line up perfectly now :D

The map in bugged case is something like:


Black = this layeer, rose = layers below under interest, blue - ping 1 - previous layer

But checkerboard pattern did indeed ended up very corrupted :D
Where is the dev branch? I will test with it when I have time.

Author:  David Williams [ Sun Oct 18, 2015 11:27 am ]
Post subject:  Re: [0.2.1/0.3.1] Strange normals generating NaNs

When you say the chunks don't line up I assume you mean it is a lighting discontinuity? It seems unlikely Unity would move the vertices. But yes, this is a drawback of computing the normals separately, as by that point you have lost information about neighbouring voxels.

You could manually recalculate the normals yourself but only do it for those vertices which you can see contain NaN/Inf values? Or interpolate a dodgy normal from it's neighbours? These are all hacks though.

The develop branch is in BitBucket but you'll find you need to update your code. You were using 0.2.1 because you still wanted the mesh decimator as I recall.

The Marching Cubes algorithm only operates on densities (not materials, etc) so you have a function to convert to densities via a MarchingCubesController. Can you see which set of density values are causing the problem? Perhaps the issue can be recreated in the BasicExample but with a small 4x4x4 volume of just floats/ints?

Author:  petersvp [ Sun Oct 18, 2015 10:51 pm ]
Post subject:  Re: [0.2.1/0.3.1] Strange normals generating NaNs

I merged the code you linked back, and most of black triangles dissappeared... I decided that I can sacrifice the quality a little and used the Unity calculated normals. Yes, light discontinues a bit in some places of the terrain, but I'm OK with that.

7 Days To Die have a lot more problems with chunks that don't line up, and adding some foliage hiddes these as well. Here is the visual fallback when using unity provided normals. I posted some screenshoits to Showcase thread to not hijack this one

Page 1 of 1 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group