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

meshio for mesh I/O #51

Open
clbarnes opened this issue Aug 2, 2021 · 3 comments
Open

meshio for mesh I/O #51

clbarnes opened this issue Aug 2, 2021 · 3 comments

Comments

@clbarnes
Copy link
Collaborator

clbarnes commented Aug 2, 2021

Spotted some commits implementing more mesh formats - would it be worth just (optionally?) depending on meshio and calling it a day? Improvements and additional formats could be contributed back upstream. It has neuroglancer's mesh format from a while back - reducing the number of implementations out in the wild is probably for the best.

@schlegelp
Copy link
Collaborator

Ah good point! I didn't bother hunting for existing implementations for neuroglancer's "precomputed" format. I have independent functions in various other packages and this was actually my attempt at consolidating those into navis.

At a glance it looks like meshio currently only deals with the legacy mesh format. The recent commits to navis do a bit more than that:

  • read/write precomputed skeletons (including radii)
  • (optionally) write manifest files for meshes
  • (optionally) read/write info files

I guess the latter two could be contributed back upstream to meshio? As things stand, adding meshio as dependency would shed ~20 lines of code in navis.

@clbarnes
Copy link
Collaborator Author

clbarnes commented Aug 3, 2021

Yes, it was a while ago that I added that so not surprised if the format as come on since then. As it is such a simple format, it also doesn't surprise that the dependency (which is pretty light without extras) wouldn't save much code, but it would add quite a lot of flexibility to navis for reading and writing different mesh formats.

@schlegelp
Copy link
Collaborator

Oh, I see. We might be thinking of slightly different things here. I'm not at all opposed to adding it as a dependency but perhaps you can elaborate a bit on how you would suggest proceeding?

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

No branches or pull requests

2 participants