Uploaded image for project: 'OpenVDB'
  1. OpenVDB
  2. OVDB-117

MeshToVolume non-deterministic bug

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: High High
    • None
    • None
    • Core
    • None
    • Platform: 3.10.0-693.2.2.el7.x86_64
      Operating System: CentOS Linux release 7.4.1708 (Core)
      Verified at: 17058c2b7ca1f265bdc13b5c1cdc88b926dbfd4c
      VDB Version: 6.2.0

      I've run into what I believe is a problem with the threaded reduction of values during the voxelization of triangles in the meshToVolume code. Specifically, I think the problem is coming from non-deterministic threading behaviour of the VoxelizePolygons op. The issue first appeared in our solver regression tests (a while back), one of which is a particle to level set operation followed by a level set rebuild. I originally believed it was something purely on our end, but I've spent the last few days trying to track this down and have a reproducible case. It's not as granular a case as I would like, however the issue is occurs so little that it's hard to catch with smaller cases.

      I've been pulling apart the VoxelizePolygons op to try and diagnose this but have hit a bit of a wall. I believe I've verified that the problem is to do with the general structure of the threaded implementation, not the sub tasks - I removed the subsequent threading of the internal sub tasks and the issue persisted however I was unable to re-produce it with everything unthreaded. I'm comparing the sdf and idx values and it's the sdf values that are different - the idx values have always been the same. I'm also fairly confident that the accumulation of the TLS trees post VoxelizePolygons op is correct. If I had to guess at this stage, I believe it may be to do with the primitive id tree that's being populated and cleared within the VoxelizePolygons op that's causing some distance values to not be set or visited.

      I've attached a main, two data files and a vdb file. The VDB file has a SDF which was produce from one of our surfacing operations (simple sphere stamping) which we want to rebuild. The mesh_points and mesh_prim txt files hold serialised vec3s and vec4i info. The main is capable of reading either the mesh files and uses those directly, or the vdb file and running a volume->mesh->volume test. You can also replicate this problem in Houdini with a for-each loop which rebuilds the level set and compares it (subtract+deactivate) to a cached version of the rebuilt ls.

      I've been testing explicitly against deps by Houdini 17.5.259

        1. main.cpp
          12 kB
        2. mesh_point_data.txt
          38 kB
        3. mesh_prim_data.txt
          50 kB
        4. tbb_example.cpp
          2 kB
        5. test.vdb
          125 kB

            nna nna
            nna nna
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: