osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Geometry][Numbers] Blocker issues (Was: [geometry] 1.0 Roadmap)


Hi Matt.

Could you please make a list of tasks to be done in [Numbers]
on which [Geometry] relies.  All those should be reported in
JIRA, with their status elevated to "blocker".  We need to have
them implemented, and make an official release of [Numbers]
before [Geometry] can be released (since a release cannot
depend on a SNAPSHOT version).
Perhaps Steve will be able to help here.  Others welcome too...

Best regards,
Gilles

On Fri, 7 Sep 2018 02:29:21 +0000, Matt Juntunen wrote:
Hi all,

I've been working on the new commons-geometry component for a while
now and I wanted to share with everyone the current state of the
project and what I'm picturing for the future, up to a 1.0 release.

Here is where we are now:

  1.  All of the original geometry code from commons-math has been
moved to commons-geometry.
  2.  Code has been split into a number of distinct modules, per Java
9+ conventions.
  3.  The old Vector classes have been completely redesigned and
refactored into separate Point and Vector classes to better reflect
the underlying math.
  4.  All Point and Vector classes are now VALJOs.
  5.  Support for spherical and polar coordinates has been added.

Here is what I'd like to still accomplish before a 1.0 release (in
order of priority):

  1.  Add additional Vector methods (GEOMETRY-9) -- This includes
methods like lerp, project, and reject among others. A pull request
has been submitted for this and is in discussion.
  2.  Vector normalization optimizations (GEOMETRY-10) -- We can
avoid a lot of computation by making some tweaks here. I've started on
this but do not yet have a pull request.
  3.  Add matrix-based AffineTransform?D classes (GEOMETRY-14) -- We
are sorely lacking an API to translate, rotate, and scale.
  4.  Encapsulate concept of tolerance (GEOMETRY-11) -- We currently
use raw double tolerance values to help determine equality between
floating point numbers. I think we should encapsulate this into a
GeometryContext class to ensure that this is done consistently and to
allow us to easily tweak the algorithm if needed. If anyone has any
ideas for how to best maintain floating point accuracy here, that
would be great.
  5.  API cleanup for Region, Hyperplane, and BSPTree (no JIRA issue
yet) -- This is a big one and kind of ill-defined. One of the main
gripes I and other people at my work have had with the old
commons-math geometry code was that it was awkward to use. You had to
jump through a bunch of hoops to do things like get the vertices of
the union of two 2D shapes. I'd like to try to clean this up and
streamline some of the common use cases. Comments and feedback on this
would be great.
  6.  BSPTree optimizations (no JIRA issue yet) -- I have some ideas
I'd like to try out to speed up the BSP tree code. My unofficial
benchmark is to convert a model of the Utah teapot I have with ~1000
facets into a PolygonsSet and back. The current code cannot do this.
It takes forever and then fails, I believe due to accumulated floating
point errors. If we can get the code to be able to do this correctly
and in a reasonable amount of time, then I'd feel good about making a
release.

Thoughts? Comments? I have a project at work coming up near the end
of the year that I'd really love to use commons-geometry on, so that's
what I'm aiming for in terms of a timeline.

Thanks,
Matt Juntunen


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx