Read and write surface mesh microstructure using .txt files, inconsistencies

[stopk...@gmail.com]

Hello Mike,

I have a question regarding .json pipelines to read and write surface meshes using text files. I have attached two .json files here. The pipeline entitled “Filter_5_FaceLabels_different_lengths.json” reads in a synthetic microstructure .dream3d image file (also attached), creates a surface mesh using the “Quick Surface Mesh” filter, and then writes .stl and .txt files that should fully describe the microstructure. It seems to correctly make .stl files but the text files it creates are inconsistent between multiple runs of the pipeline, i.e., each time I run that .json file, the text files differ in number of nodes and triangles.

Assuming that the text files are correct, the second pipeline attached here is entitled “Read_surface_mesh_from_text_files.json”. This pipeline reads in the text files generated by the other pipeline and export .stl files of the microstructure, which should be identical to the .stl files generated by the other .json pipeline. However, they are not, and I am unsure where the problem is. I believe I have all the right filters in the second .json pipeline. One issue is perhaps that the “create attribute matrix” filter requires an input for “Tuple dimensions” which will change because of the inconsistency of the first pipeline. Please let me know at your convenience what the issue may be (perhaps whether I am missing filters in the second pipeline) and thank you in advance!

I want to make sure I can get these .json files to work as I am experimenting with Siddharth Maddali’s “HierarchicalSmooth” algorithm (https://github.com/siddharth-maddali/HierarchicalSmooth). This algorithm produces a list of shifted nodes that should be easily read by DREAM.3D to further manipulate the microstructure, be easily visualized in ParaView and using .stl files, etc.

 

Best regards,

Kris

 

Krzysztof Stopka, Ph.D.
Postdoctoral Researcher
School of Aeronautics and Astronautics
Purdue University

[stopk...@gmail.com]

Attaching files here... thanks!

[stopk...@gmail.com]

Apologies for the multiple posts... having trouble attaching multiples files.

On Saturday, August 14, 2021 at 8:43:32 AM UTC-5 stopk...@gmail.com wrote:

Attaching files here... thanks!

[Michael Jackson]

Kris,

   Thanks for reporting. I took a look at the code and there is actually a stochastic element to the codes as we try to “fix” some problematic voxels that result from the mesh.

 

https://github.com/BlueQuartzSoftware/DREAM3D/blob/823db0bd875168f608ec9bfa6479da14f8490f76/Source/Plugins/SurfaceMeshing/SurfaceMeshingFilters/QuickSurfaceMesh.cpp#L1548

 

That line kicks off the process. If you follow through the codes then you will see that in our algorithm there is an actual random number generated and used for selections. This was based off of a paper that discuss the algorithm. I will see if I can dig it up and forward it along (Looked around, can't even remember the name of the paper that describes the algorithm).

 

The changes were committed on 12 DEC 2018 and is commit 1ed41586a0bf7e9c528a11dd65c2530aa1d7682d in the DREAM3D Repo.

 

We could potentially put in a checkbox to enable/disable the feature. Not fixing these voxels will lead to loops in triple lines, non-manifold meshes and other surface meshing anomalies. These become quite apparent when you apply the Laplacian smoothing.

 

As a workaround you could try 6.5.38 which was released well before those codes were committed. Not sure of what other bugs would be lurking in that version.

 

 

--

Mike Jackson

--
You received this message because you are subscribed to the Google Groups "dream3d-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dream3d-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dream3d-users/6e31943a-bdee-44b2-ad1a-058dba48485dn%40googlegroups.com.

[stopk...@gmail.com]

Thanks for the swift reply, Mike!

I have some follow up questions: would/should this affect the other .json pipeline that reads in the .txt files to reproduce the original surface mesh? Also, can you please check to make sure I have the correct filters/information in that second pipeline?

Best regards,

Kris

[Michael Jackson]

Yes, it will affect the “Read_surface_mesh_from_text_files.json” pipeline as you need to know exactly how many vertices/triangles you are reading from the input files. That will change on each run through of the first pipeline.

 

If I can get to it I will try to put in the checkbox to enable/disable the functionality over the weekend. You would have to start using a nightly build to get the feature though.

 

Also, as a side note we spent some time trying to integrate the hierarchical smoothing codes into DREAM.3D. We were waiting on a newer version of Eigen to include some needed functionality as the original c++ codes that Sidharth wrote depended on CGAL library which is a huge dependency. Over all the codes worked well with the example presented but had issues with some of our newer meshes. We just never got the time to collaborate properly to debug what was going wrong.

 

If you happen to be on a Windows machine there are some experimental Python bindings and an Anaconda-dream3d distribution that you could try which would allow you to use Python to drive DREAM.3D (from a programmatic point of view, not drive the UI) and then use other python libraries to process your data. I’m not sure of your current working environment.

 

--

Mike Jackson

To view this discussion on the web visit https://groups.google.com/d/msgid/dream3d-users/99fb71c8-14a2-4148-9aa0-a31e06773933n%40googlegroups.com.

[stopk...@gmail.com]

Thanks again, Mike. As a reference for other users, I have attached a pipeline here that works to read in microstructures as defined by a shared vertex list, shared triangle/face list,  Face Labels,  Feature IDs, and node type. These five files can be exported using the other .json pipeline mentioned above. If the tuple dimensions are correctly specified and correspond to the text files properly, the microstructure can be read in correctly. This pipeline was made using version 6.5.138.

As a note, the "Create Geometry" filter is used in this .json pipeline but some additional checks should perhaps be added to this filter when "triangle" is selected as the geometry type (and this may be true for others). For instance, I was previously getting erroneous .stl files from this pipeline because I was erroneously specifying the same tuple dimensions for both vertex and face/triangle data, whereas these should be stored in separate attribute matrices. The "Create geometry" filter should check that the vertex and face data do not exist in the same attribute matrix because they should necessarily be of different size (I think the only scenario in which this is untrue is for a series of free-floating triangle that are not connected... and thus vertex and edge data of equal dimensions).

Best regards,

Kris

[Michael Jackson]

What really needs to be written would just be a “Triangle” Read filter that just reads the verts and triangles from files. I just don’t have the time at the present to write those filters. IF there are any energetic software engineers out there who would like to write some of these filters BlueQuartz might be able to fund those filters.

 

--

Mike Jackson

To view this discussion on the web visit https://groups.google.com/d/msgid/dream3d-users/b01ba490-a90a-4636-8387-9ce3cbc4627an%40googlegroups.com.