|Re: [eigen] Bounding Volume Hierarchies|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Bounding Volume Hierarchies
- From: Ilya Baran <baran37@xxxxxxxxx>
- Date: Fri, 6 Mar 2009 14:25:17 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Lt0+6HP06wK+OpbmUhq1UJ7HDr/HJ0Q+npKBq5BDqfQ=; b=V3WME8iPBqw81EtWmC+2nEo6FJeo6rmS7Lb7cKkBWIqFvq3a5NEF538IrF8ueCadaB 5V6cO6LzmtbODQRsUlng90YWs+yIY8ExV5FzrylYP0rQCoD9A9ZD8B/zrJ0D8lGyLRbH hJ+mF/PW3VSr1YXlFVogaIYJXvlHEaO/Gr8ik=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mL/ZtKfGMla4tfc5TJJ5WMVG9J/sr3TIShyDT3vq6do8noflc1KziV4BfQ7d13DLnq yDomoicp8jLcCI6Gqk+uVZx2yRhJt2JT5v/l45YvQ7pyutSqZ95DbtUBsSwHSqzhscg0 67sSkOUZIY5dAPu/RCCB4Ml8zV3mUuuuoF95g=
> Actually, I think a BVH is a bit too far to Eigen's objectives, and at
> a first glance I don't think it should be included in Eigen.
> Otherwise, by extension, we'll soon add a physics engine, a raytracer,
> etc. I think we have to find a limit.
> On the other hand, I have the project to write a spatial data
> structure library based on Eigen, and so your contribution would
> perfectly fit :) Since it is not started and yet and I don't have much
> time for that, I'm currently ok to commit your patch in Eigen's tree
> 1 - the module is in unsupported so no big deal, we can still see
> later whether it is worth creating a separate project or not,
> 2 - the contribution looks good, and so it's worth it making it
> available to most people right away,
> 3 - I know one KDE application which needs a BVH: Step.
Yes, this basically mirrors my thinking that I didn't articulate in
the previous email: I agree that BVH doesn't properly fit into Eigen's
scope as a linear algebra library (but does the geometry module,
really? would other numerical methods, like solvers, integration,
ODE's etc?). However, at this stage, the BVH is not sufficiently
fancy to warrant the overhead of a separate library, so I think
Eigen/unsupported is a good home for now, especially since with
Eigen's architecture you don't pay for what you don't use.
> Regarding the changes in AxisAlignedBox, I'm not very fan of using
> operator & and | for the intersection and union, and I would suggest
> explicit names.
I prefer reading "(a | b) & (c | d)" to
"(a.union(b)).intersection(c.union(d))", but it's not a strong
preference (and, of course, your call at that). For explicit names,
I'd suggest "union" and "intersection" for operator| and operator& and
"unite" and "intersect" for operator|= and operator&= (rather than the
current "extend" and "clamp").