search

JuliaGeometry / OldMeshes.jl

A collection of tools for working with Meshes
Other
20 stars 12 forks source link

Merge new Mesh architecture #55

Closed SimonDanisch closed 8 years ago

SimonDanisch commented 9 years ago

This is not ready for a merge yet, but I want to start the discussion. The mesh and vertex/point/vec types reside in GeometryTypes now. The meshtype is probably quite unpleasant, considering how much more verbose it is. My peace offer would be to continue using the current meshtype and also put it inside of HomogenousMesh, since I build uppon the assumption that faces and vertices always exist anyways. I'm not sure how much this would help though, considering that the constructors are fairly convinient. We can also re-introduce the notion of topology. I for myself try to always have topology == true, but I can be convinced that you might not always want this. If a file loader uses topology or not would not work over a keyword arguments anymore, but rather via the meshtype passed by the loader function. That's the general scheme I want to enforce, to make it possible to make the load process type stable by overloading call (e.g. GLNormalMesh("test.obj")), even though that different file formats encode different mesh types. So the loader always returns the best mesh type for the underlying file format, but you can force it to return a specific mesh type. The IO is implemented via FileIO and the loader/saver code mostly resides in MeshIO. This means you can just say load("test.stl") anywhere and it will just work (by loading MeshIO and GeometryTypes at runtime, or just using them when they're already present). I'm not completely done there and still need to clean up a few things and write more tests.

What belongs into Meshes.jl might not be that clear anymore. Images.jl has a similar problem and @timholy suggested, that the package with the simplest name should become more of a toolbox package, meaning that it loads all other meshing packages, reexports the functions and makes it easy to have a quick start. It can also have tests spanning all the other packages, to better guarantee that everything works well together. The full discussion is in JuliaImages/meta#1

This would mean that we might want to split up Meshes further into packages like IsoSurfaces, MeshSimplifications, MeshSlicer, etc...

I hope this is not contrary to what other people would like to have for Meshes.jl.

Some Milestones:

sjkelly commented 9 years ago

Yes, I totally agree with this. I think the "topological" distinction is similar to Ints vs. Floats. We should implement other abstracts to make this distinction because for many operations topology is not strictly necessary and only expedites the operation. As to the balkanization of Meshes, I strongly agree. Meshes currently supports: Marching Tetrahedra, functional solid construction, IO, and basic algorithms. I started a block diagram a couple nights ago that I'll finish and share when I'm at a computer. On Aug 29, 2015 8:32 AM, "Simon" notifications@github.com wrote:

This is not ready for a merge yet, but I want to start the discussion. The mesh and vertex/point/vec types reside in GeometryTypes now. The meshtype is probably quite unpleasant, considering how much more verbose it is. My peace offer would be to continue using the current meshtype and also put it inside of HomogenousMesh, since I build uppon the assumption that faces and vertices always exist anyways. I'm not sure how much this would help though, considering that the constructors are fairly convinient. We can also re-introduce the notion of topology. I for myself try to always have topology == true, but I can be convinced that you might not always want this. If a file loader uses topology or not would not work over a keyword arguments anymore, but rather via the meshtype passed by the loader function. That's the general scheme I want to enforce, to make it possible to make the load process type stable by overloading call (e.g. GLNormalMesh("test.obj")), even though that different file formats encode different mesh types. So the loader always returns the best mesh type for the underlying file format, but you can force it to return a specific mesh type. The IO is implemented via FileIO and the loader/saver code mostly resides in MeshIO. This means you can just say load("test.stl") anywhere and it will just work (by loading MeshIO and GeometryTypes at runtime, or just using them when they're already present). I'm not completely done there and still need to clean up a few things and write more tests.

What belongs into Meshes.jl might not be that clear anymore. Images.jl has a similar problem and @timholy https://github.com/timholy suggested, that the package with the simplest name should become more of a toolbox package, meaning that it loads all other meshing packages, reexports the functions and makes it easy to have a quick start. It can also have tests spanning all the other packages, to better guarantee that everything works well together. The full discussion is in JuliaImages/meta#1 https://github.com/JuliaImages/meta/issues/1

This would mean that we might want to split up Meshes further into packages like IsoSurfaces, MeshSimplifications, MeshSlicer, etc...

I hope this is not contrary to what other people would like to have for Meshes.jl.

Some Milestones:

  • use call(::Type{Vector{Point}}, mesh) instead of getindex(mesh, ::Type{Point})
  • assure that slicer and simplification work
  • port and write new tests
  • improve documentation
  • make threejs, amf and off work under MeshIO && FileIO

You can view, comment on, or merge this pull request online at:

https://github.com/JuliaGeometry/Meshes.jl/pull/55 Commit Summary

  • rewrote types -> now clean things up!
  • still needs more cleaning, but things start to work
  • fixed mesh merging
  • deleted IO from Meshes
  • removed debug output
  • fixed cube creation
  • fixed 0.4 deprecation
  • added pyramid mesh convert
  • added direct mesh translation
  • getting ready for ntuples
  • removed mesh types

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/JuliaGeometry/Meshes.jl/pull/55.

sjkelly commented 9 years ago

@SimonDanisch https://github.com/JuliaGeometry/meta/pull/9

I used https://wiki.gnome.org/action/show/Apps/Dia?action=show&redirect=Dia to create this.

sjkelly commented 9 years ago

FYI: The contents of isosurface is now in Meshing.jl. If you want, I think we can do this gradually on master, "build the plane as its flying". For the time being, I think breaking out slicing and simplification is less of a priority. Slicing could live in the GeometryIntersections package as a mesh-plane intersection.

Have you gotten the simplification algorithm working? AFAIK it has never worked 100% and has some antiquated code now.

The meshtype is probably quite unpleasant, considering how much more verbose it is. My peace offer would be to continue using the current meshtype and also put it inside of HomogenousMesh, since I build uppon the assumption that faces and vertices always exist anyways. I'm not sure how much this would help though, considering that the constructors are fairly convinient.

Meshing.jl is using the HomogenousMesh type in GeometryTypes. It is just as easy to use IMO, and if people want the Mesh type back it could be reincarnated as SimpleMesh or something.

SimonDanisch commented 9 years ago

Nope, haven't invested a single second into Simplifactions :D Good to hear that HomogenousMesh works for you. From where did you branch off the code in Meshing!? It seems it incorperates new things but not some old improvements, like using NTuples instead of Vec and some other fixes I incorperated over time.

sjkelly commented 9 years ago

The code that was "merged" in isosurface.jl was done manually. Somethings might be off since I did that about 2-3 months ago. There are a bunch of incorrect diffs here: https://github.com/JuliaGeometry/Meshes.jl/blob/ntuples/src/isosurface.jl presumably because this has not been rebased. I will look at the diffs and report here: https://github.com/JuliaGeometry/Meshing.jl/issues/1

sjkelly commented 9 years ago

Re: uniqueness (topology) https://github.com/JuliaGeometry/GeometryTypes.jl/commit/852da9e2179cbba52fb91af912d78219c16bdea5