commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [geometry] GEOMTRY-32 Feedback Requested
Date Fri, 16 Aug 2019 15:37:53 GMT
Hello Matt.

Thanks for continuing to work on this.

Le jeu. 15 août 2019 à 17:56, Matt Juntunen
<> 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
in that file:
$ file .travis.yml
.travis.yml: ASCII text, with CRLF line terminators
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.


>   *   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.


It would be great to create a maven module for systematizing the benchmarks;
see e.g. what is being done in "Commons RNG":;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).


> Regards,
> Matt
> [1]

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message