Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: make mesh more amenable to other Julia datatypes? #7

Closed
Ickaser opened this issue Apr 1, 2022 · 3 comments · Fixed by #8
Closed

Feature request: make mesh more amenable to other Julia datatypes? #7

Ickaser opened this issue Apr 1, 2022 · 3 comments · Fixed by #8

Comments

@Ickaser
Copy link
Contributor

Ickaser commented Apr 1, 2022

One of the reasons I want to use this module is to be able to put together a pure-Julia data pipeline for micro-CT data. To that end, it would be helpful if I could take the mesh generated by this project, and pull it over to Makie.jl or some other Julia plotting software.

It seems to me like it shouldn't be too difficult to modify the code base to use Triangles from GeometryBasics.jl , then make the mesh compatible with Meshes.jl and therefore MeshViz .

I can help with this, I think (although maybe not very fast).

@t-bltg
Copy link
Member

t-bltg commented Apr 1, 2022

Hi,

I'm a bit puzzled on this one. The goal of this package was to be as light weight and universal as possible. This is why e.g. PlyIO is an optional [extras] dependency used only for the example scenario.

The representation using vertices, triangles and normals is quite universal, uses standard Julia types and pretty common StaticArrays, whereas GeometryBasics is already a level upwards in the abstraction, and oriented towards Makie.jl.

This package was written for https://github.com/JuliaPlots/UnicodePlots.jl, specifically for isosurface, and since we're not using GeometryBasics there, I don't see a reason to add extra dependencies (they will just pile up with more and more maintenance needed, e.g. when GeometryTypes was superseded by GeometryBasics).

Why not write a conversion method which maps vertices and triangles to GeometryBasics types (should be relatively straightforward) instead of modifying the internal algorithm types ? We can add it to README.md as an example application if you wish ...

@Ickaser
Copy link
Contributor Author

Ickaser commented Apr 1, 2022

That seems like a good way forward to me. I can start digging through to try and put something together.

@t-bltg
Copy link
Member

t-bltg commented Apr 1, 2022

We can eventually support GeometryBasics in the (optional) way I dealt with PlyIO(even if this is non standard), by passing the module to the function, as in example.jl:

output(PlyIO::Module, m::MC, fn::AbstractString = "test.ply") = begin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants