I really appreciate the quick response. Even though I believe this API
has the functionality I need, I'm not really sure I can easily tune the
performance. I need to check out a few other APIs to determine if they
will be a better fit, and if I can't find anything that fits, I'll
probably see what I can do with this geom package. Thanks again for
being so upfront about the state of the project.
Thanks,
Wes G.
On 11/5/2016 11:03 AM, Gilles wrote:
Hello.
On Fri, 4 Nov 2016 23:57:48 -0500, Wes Gilster wrote:
I've been using the commons math geometry libraries for some simple
2d intersection functions, but I'm now interested in expanding it's
use to include some manipulation of 3d models with polygon counts that
will easily reach 200,000 tris. More specifically I would like to
build physical support structures in 3d models. Given that commons
math geo libraries used BSP trees, I had assumed the performance would
be quite adequate. However I'm having second thoughts as to whether
this is the right API for this modeling. I'm building models from STL
files with this constructor:
org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.PolyhedronsSet(List<Vector3D>,
List<int[]>, double)
It seems there are some quite in-efficient loops in here, and with
models with high polygon counts this function really performs poorly:
org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.buildBoundary(List<Vector3D>,
List<int[]>, double)
It also seems as though this API is going to be quite intolerant of
imperfect geometry.
Below is an example that loads an STL from disk and inserts into this
the PolyhedronsSet:
https://github.com/WesGilster/Photonic3D/blob/master/host/src/main/java/org/area515/resinprinter/supports/ImpossiblePerformance.java
I'm hoping someone with a bit of experience in this API could confirm
this assessment.
I have no good news; there is probably no one listening here who
has more experience than you on using this part of the Commons
Math library.
Many of the more advanced codes (in size and/or complexity) have
been orphaned by a fork last May.
A lot of discussion has arisen about the future of CM (have a look
at the ML archive if you are interested).
Some parts have found new maintainers.
We should certainly welcome people who have expertise with using the
"geometry" package, to improve and maintain it, and eventually
release it as a standalone component.
Best regards,
Gilles
Thanks,
Wes G.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
