Show HN: A Polygon Mesh Processing Library

#1

Post by dsieger » Sun, Jun 02, 2019, 12:35 PM UTC

Show HN: A Polygon Mesh Processing Library
pmp-library.org

Re: Show HN: A Polygon Mesh Processing Library

#2

Post by fulafel » Sun, Jun 02, 2019, 2:55 PM UTC

Sounds promising. If authors are reading this: web demo ui is too small on mobile.

Re: Show HN: A Polygon Mesh Processing Library

#3

Post by electricslpnsld » Sun, Jun 02, 2019, 5:29 PM UTC

What is the use case of PMP over something like IGL [1]? IGL has a ridiculous number of implemented algorithms -- at this point the second a new paper comes out in the geometry processing community it gets implemented in IGL!

[1] https://libigl.github.io

Re: Show HN: A Polygon Mesh Processing Library

#4

Post by dsieger » Sun, Jun 02, 2019, 6:27 PM UTC

electricslpnsld wrote: post #3

What is the use case of PMP over something like IGL [1]? IGL has a ridiculous number of implemented algorithms -- at this point the second a new paper comes out in the geometry processing community it gets implemented in IGL! [1] https://libigl.github.io

There are a couple of things, actually:

- A proper mesh data structure providing meaningful abstractions

- Support for general polygon meshes

- Support for dynamic connectivity updates

- Cross-compilation to JavaScript, allowing for web-based demos[1] and interactive HTML slides[2]

- Implementations of canonical algorithms as described in the standard textbook of the field (Polygon Mesh Processing[3])

[1] http://www.pmp-library.org/mpview.html

[2] https://pmp-library.github.io/pmp-slides/slides.html

[3] http://www.pmp-book.org

Re: Show HN: A Polygon Mesh Processing Library

#5

Post by dsieger » Sun, Jun 02, 2019, 6:34 PM UTC

fulafel wrote: post #2

Sounds promising. If authors are reading this: web demo ui is too small on mobile.

Co-author here. Good point. So far we did not yet really optimize for mobile. Thanks for the feedback.

Re: Show HN: A Polygon Mesh Processing Library

#6

Post by huxingyi » Sun, Jun 02, 2019, 9:52 PM UTC

dsieger wrote: post #4

electricslpnsld wrote: post #3

What is the use case of PMP over something like IGL [1]? IGL has a ridiculous number of implemented algorithms -- at this point the second a new paper comes out in the geometry processing community it gets implemented in IGL! [1] https://libigl.github.io

There are a couple of things, actually: - A proper mesh data structure providing meaningful abstractions - Support for general polygon meshes - Support for dynamic connectivity updates - Cross-compilation to JavaScript, allowing for web-based demos[1] and interactive HTML slides[2] - Implementations of canonical algorithms as described in the standard textbook of the field (Polygon Mesh Processing[3]) [1] http://www.…

Looks like a really good start. One suggestion: add mesh boolean algorithm, currently, only CGAL do this well, if your library could supports this on the MIT license, I would definitely try it. Currently, I am using libigl to do parameterization and CGAL to do mesh boolean in my 3D modeling software[1]

[1] https://github.com/huxingyi/dust3d

Re: Show HN: A Polygon Mesh Processing Library

#7

Post by dsieger » Mon, Jun 03, 2019, 1:00 PM UTC

huxingyi wrote: post #6

dsieger wrote: post #4

Earlier quoted context omitted.

There are a couple of things, actually: - A proper mesh data structure providing meaningful abstractions - Support for general polygon meshes - Support for dynamic connectivity updates - Cross-compilation to JavaScript, allowing for web-based demos[1] and interactive HTML slides[2] - Implementations of canonical algorithms as described in the standard textbook of the field (Polygon Mesh Processing[3]) [1] http://www.…

Looks like a really good start. One suggestion: add mesh boolean algorithm, currently, only CGAL do this well, if your library could supports this on the MIT license, I would definitely try it. Currently, I am using libigl to do parameterization and CGAL to do mesh boolean in my 3D modeling software[1] [1] https://github.com/huxingyi/dust3d

Thanks for the suggestion, definitely something to think about. However, this is also non-trivial to implement in a robust and efficient manner, so not sure we'll look at this soon.