Hello Matt. Thanks for continuing to work on this.
Le jeu. 15 août 2019 à 17:56, Matt Juntunen <matt.juntu...@hotmail.com> a écrit : > > Hi all, > > I've been working on the BSP tree refactor and general API cleanup for a > while now and I finally have the core and Euclidean classes complete. I have > the code in a draft PR on github [1] and I'm hoping to get as much feedback > on it as I can. There is a spurious change of ".travis.yml". Also there are wrong EOL characters in that file: ---CUT--- $ file .travis.yml .travis.yml: ASCII text, with CRLF line terminators ---CUT--- Perhaps you should merge or rebase on "master". > Everything is in its final state from my point of view with the exception of > the spherical module, which still needs to be switched over to the new API. > Here are some highlights of the new code: > > * More user-friendly API > * Does not require users to make unchecked casts to implementation > types. > * BSP tree classes are much more powerful and easy to use. State is > managed internally so that users do not need to be experts in BSP trees to > avoid corrupting the data structures. > * Uses builder pattern instead of large factory methods to build > complicated geometries. That would suit me. ;-) Actually, I'd like to try it with a simple geometry (i.e. build a sphere). Where should I start looking? > * Most classes are immutable. > * A general-purpose AttributeBSPTree class is available so that users can > associate arbitrary data with spatial partitionings. I'm picturing this being > used for spatial data lookups, painter's algorithms, etc. Can it be associated with a surface element? > * All geometric types now support arbitrary transforms (eg, rotate, > scale, translate, etc) via the Transform interface. > * The Transform interface is greatly simplified (GEOMETRY-24). It is now > functional and simply extends java.util.Function. Nice. > * Better performance. My highly unsophisticated stdout benchmarking put > the new code at about 3-4 times faster than the old when performing boolean > operations on 3D regions. Impressive. It would be great to create a maven module for systematizing the benchmarks; see e.g. what is being done in "Commons RNG": https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=tree;f=commons-rng-examples/examples-jmh A "commons-geometry-examples" module would be a place to collect useful code, e.g. simple "howtos" (like the one I mentioned above) and conversion routines from/to popular formats, without the requirement of backwards compatibility (even between minor releases). Best, Gilles > > Regards, > Matt > > [1] https://github.com/apache/commons-geometry/pull/34 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org