I don't need a package to build an engine on top of it. If you're
going to write a game with 3d and physic probably you're going to
use ogre, irrlicht, physx or everything else. And they have their
own optimized implementation of these objects.
But a geometry package is not only for game or physics. Just an
example: I wrote (in c++) an app to merge two images. Here a
test: http://www.e-nuts.net/test2.jpg (the right image is an
automatic merge of the other two). In this case a geometry
package would simplify my life a lot :)
Another thing I would like to do is a generator of solids to
print with a 3d printer. Some strange math objects. Or maybe a
slicer for 3d printer's software stack. Or something like
openscad.
Here we need productivity rather than realtime performance.
On Wednesday, 19 March 2014 at 14:05:19 UTC, Marco Leise wrote:
Am Wed, 19 Mar 2014 11:22:55 +0000
schrieb "Andrea Fontana" <[email protected]>:
I miss so much a std.geometry library with operations on 1d 2d
and 3d objects (intersections, unions, difference, and so
on...) in d style...
It would open a whole new world for me :)
I wonder if we could finally have that experimental package,
call it "ext" or "etc" or whatever that has only one barrier
to entry: the intent of the module must pass review. The
API and code can build up over time as people start using
it. At some point it can be called finished and thoroughly
reviewed. I think the barrier of entry is currently very high
since the reviews expect perfect quality from the start, but
good things need time to collect corner cases and use cases
that might cause major refactorings.
It's straight forward to implement for rectangles or circles,
but would any design still be good when someone tries to
implement a 2D physics engine on top of that? Would CSG
operations be part of the module? What about paths, curves and
loading from and saving to vector graphics (SVG)?
(I.e. you could literally draw the collision shape of a tree
bitmap in Inkscape and load it as 2D geometry.)
