JuliaGeometry
Better IO support
Might not be what you hoped people would use this for, but I want to 3-print something (I think) I can build with your package. But to do so I'll need to save it to disk first. The file formats most commonly used are stl, obj, and 3mf.
Feel free to close this is you feel this is off topic.
Definitely on topic 💯 I think we should document here in the issue the steps to achieve these goals.
Currently I've been using PlyIO.jl, which is an excellent package to read PLY meshes from disk. We need similar packages for STL, OBJ and 3mf. After that we can try to update MeshIO.jl to load these modules in a single clean API.
Another format that is quite popular in the scientific domain is VTK. The WriteVTK.jl package works amazingly well and is quite stable at this point. There is a recent ReadVTK.jl but it is still maturing.
For those who need to get the work done quickly, a good workaround while these formats aren't implemented in pure Julia consists of opening the file in MeshLab, which is free and open source, and reexporting it in PLY to read with PlyIO.jl
@yakir12 do you think you can help writing some of these IO packages for STL, OBJ, 3mf, maybe adapt some of the code in MeshIO.jl to make it more general, robust and compatible with Meshes.jl?
ooo, I would probably not have time. I'll soon post something on Discourse for how I got it done, with the results and all though.
@yakir12 @juliohm If you are urgent to do this, look at MeshBridge.jl. Although it is uglier and does not leave behind the burden of history, it is at least usable. What I means is convert it to GeometryBasics.jl mesh and then load or save via MeshIO.jl.
That is a great resource, thank you for sharing it. It will help other users while things get organized.
On Wed, Dec 15, 2021, 05:22 Haoxuan Guo @.***> wrote:
@yakir12 https://github.com/yakir12 @juliohm https://github.com/juliohm If you are urgent to do this, look at MeshBridge.jl https://github.com/HaoxuanGuo/MeshBridge.jl. Although it is uglier and does not leave behind the burden of history, it is at least usable.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JuliaGeometry/Meshes.jl/issues/227#issuecomment-994483764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZQW3PUKOZUIIHTO6QMZU3URBF25ANCNFSM5JV66FRA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I'll soon post something on Discourse for how I got it done
and here it is: https://discourse.julialang.org/t/3d-printing-apriltags
Hi,
hope I'm not beating on a dead horse by posting here.
I'm currently working on solving PDEs in Julia (mainly flexible FE methods) and came across the same problems that you already addressed with your package. So first of all kudos for the nice work! 🚀
Another format that is quite popular in the scientific domain is VTK. The WriteVTK.jl package works amazingly well and is quite stable at this point. There is a recent ReadVTK.jl but it is still maturing.
I agree 100%. I think writing outputs to an independent format is the way to go in terms of reproducibility. So naturally I'm interested in seeing that case of IO combined with computational meshes.
In combination with FE related code I've been setting up quite a similar structure to handle meshes and was planning on implementing VTK IO. But since you already did a lot of work on the geometry side, I'd personally much rather combine the efforts instead of having duplicate functionality across packages.
@juliohm If it's okay with you and you still plan to have this functionality within scope, I would offer my help on handling this. I can't promise a strict timeline but would certainly be wiling to contribute.
Contributions are very welcome Patrick, it would be awesome to have cohesive IO experience on top of the mesh types here. Are you planning to start the contributions with any specific file format? Let me know if something needs to be adapted to handle more IO flexibility. Looking forward to working together on this.
Em qui., 18 de ago. de 2022 06:32, Patrick Zimbrod @.***> escreveu:
Hi,
hope I'm not beating on a dead horse by posting here.
I'm currently working on solving PDEs in Julia (mainly flexible FE methods) and came across the same problems that you already addressed with your package. So first of all kudos for the nice work! 🚀
Another format that is quite popular in the scientific domain is VTK. The WriteVTK.jl package works amazingly well and is quite stable at this point. There is a recent ReadVTK.jl but it is still maturing.
I agree 100%. I think writing outputs to an independent format is the way to go in terms of reproducibility. So naturally I'm interested in seeing that case of IO combined with computational meshes.
In combination with FE related code I've been setting up quite a similar structure to handle meshes and was planning on implementing VTK IO. But since you already did a lot of work on the geometry side, I'd personally much rather combine the efforts instead of having duplicate functionality across packages.
@juliohm https://github.com/juliohm If it's okay with you and you still plan to have this functionality within scope, I would offer my help on handling this. I can't promise a strict timeline but would certainly be wiling to contribute.
— Reply to this email directly, view it on GitHub https://github.com/JuliaGeometry/Meshes.jl/issues/227#issuecomment-1219254181, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZQW3LU762GVHTFXNN6EV3VZX7LLANCNFSM5JV66FRA . You are receiving this because you were mentioned.Message ID: @.***>
Great! I would prefer starting off with structured and unstructured grids, as they tend to be the most useful in this field. I'll let you know if something comes up.
I mean specific file formats like VTK and PLY. We currently have PlyIO.jl which is great for PLY files and could write other IO packages that read the meshes as simple Julia arrays or dictionaries. Then, combine these packages into a high level package MeshIO.jl or similar name that convert these arrays to the final Meshes.jl types.
Em qui., 18 de ago. de 2022 06:49, Patrick Zimbrod @.***> escreveu:
Great! I would prefer starting off with structured and unstructured grids, as they tend to be the most useful in this field. I'll let you know if something comes up.
— Reply to this email directly, view it on GitHub https://github.com/JuliaGeometry/Meshes.jl/issues/227#issuecomment-1219283747, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZQW3NIZNWVWNHWGHFPSJDVZYBI7ANCNFSM5JV66FRA . You are receiving this because you were mentioned.Message ID: @.***>
Oh yeah sorry, I wasn't aware of the fact that you outsourced the IO to other packages.
I was originally referring to structured and unstructured grid formats that VTK specifies, WriteVTK.jl implements them for output already. Depending on the data type, the files have different formats (vtu, vtp, etc.).
We currently have PlyIO.jl which is great for PLY files and could write other IO packages that read the meshes as simple Julia arrays or dictionaries.
I guess to comply with the naming scheme, we would have a VTKIO.jl package and MeshIO.jl to have a unified interface to Meshes.jl, right?
Let me know if you'd like to go forward this way and if I should set up those repos here. We could then move the discussion over to the respective repositories. I can imagine there's some work to be done regarding the type hierarchy in order to make PlyIO work under MeshIO as well.
So the idea is that all these backend packages only rely on native Julia arrays and dictionaries. The wrapper package MeshIO.jl will then depend on these backend packages to post-process these arrays into Meshes.jl types.
So VTKIO.jl sounds like a good plan. It could combine ReadVTK.jl and WriteVTK.jl under a common interface with arrays.
Em qui., 18 de ago. de 2022 08:44, Patrick Zimbrod @.***> escreveu:
Oh yeah sorry, I wasn't aware of the fact that you outsourced the IO to other packages.
I was originally referring to structured and unstructured grid formats that VTK specifies, WriteVTK.jl https://jipolanco.github.io/WriteVTK.jl/stable/grids/unstructured/ implements them for output already. Depending on the data type, the files have different formats (vtu, vtp, etc.).
We currently have PlyIO.jl which is great for PLY files and could write other IO packages that read the meshes as simple Julia arrays or dictionaries.
I guess to comply with the naming scheme, we would have a VTKIO.jl package and MeshIO.jl to have a unified interface to Meshes.jl, right?
Let me know if you'd like to go forward this way and if I should set up those repos here. We could then move the discussion over to the respective repositories. I can imagine there's some work to be done regarding the type hierarchy in order to make PlyIO work under MeshIO as well.
— Reply to this email directly, view it on GitHub https://github.com/JuliaGeometry/Meshes.jl/issues/227#issuecomment-1219392390, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZQW3PD2N3Z3IMIGBGRR2LVZYOZJANCNFSM5JV66FRA . You are receiving this because you were mentioned.Message ID: @.***>
All IO backends are being wrapped in the GeoIO.jl module: https://github.com/JuliaEarth/GeoIO.jl