Issue #36 new

Zero-length normals occuring during MarchingCubesSurfaceExtraction.

David Williams
created an issue

It seems that the MC surface extractor sometimes generates zero-length (or at least very short) normals. This causes an assert during normalisation. This has been observed when editing the terrain in Cubiquity and also by users. See here: http://www.volumesoffun.com/phpBB3/viewtopic.php?f=15&t=504

Comments (6)

  1. Jan Drabner

    What I did as a workaround was to insert those lines after the length is received in the normalise function:

    if (fLength == 0.0f)
    {
         fLength = 1.0f;
    }
    

    Not exactly perfect, but at least it doesn't crash any more and I did not see many more artifacts as usually.

  2. David Williams reporter

    I've spent some time looking at this in the context of Cubiquity. I believe there are scenarios when the surface extractor can fail to generate normals. From the comments:

    // The gradient for a voxel can be zero (e.g. solid voxel surrounded by empty ones) and so
    // the interpolated normal can also be zero (e.g. a grid of alternating solid and empty voxels).
    

    However, I believe this should be extremely rare and yet it was happening frequently in Cubiquity. It turned out to be threading related as I was both reading and writing from the volume at the same time and thus corrupting the data.

    I will put in a warning when a zero length normal is found, and also some asserts to detect corrupted data. If you are encountering this issue then think whether it could be a threading problem.

  3. David Williams reporter

    Ok, I'd also be curious whether you were using the LargeVolume or the Raw/SimpleVolume. The last release of PolyVox did have some LargeVolume bugs so maybe that is the cause? Let me know if you get a chance to test it again.

  4. Log in to comment