Re: [eigen] Bounding Volume Hierarchies
• To: eigen@xxxxxxxxxxxxxxxxxxx
• Subject: Re: [eigen] Bounding Volume Hierarchies
• From: Ricard Marxer Piñón <email@xxxxxxxxxxxxxxxx>
• Date: Wed, 11 Mar 2009 12:07:52 +0100

Maybe I'm wrong, because I don't know much about axis-aligned-box.  This sounds quite a lot as 2D geometry binary operations, and in that field there is also the need for an operator: diff or xor.

Of course diff and xor are not the same, but I think with merge / intersection / (diff OR xor) you can perform all the possible set binary operations. In this case I think diff would be a better option, since it is more clear.

As reference, here is a Wikipedia article which talks about the field I'm thinking this is related to:
http://en.wikipedia.org/wiki/Constructive_solid_geometry

They use the three operators:
union / difference / intersection

Maybe we could use those and their counterparts:
united / differenced / interesected

If I'm completely off topic, then just disregard this email.
ricard

On Wed, Mar 11, 2009 at 11:22 AM, Gael Guennebaud wrote:
that's crazy, I looked at many other axis-aligned-box implementations
via google/codesearch and they all have a crappy API. For instance
none of them have features equivalent to the four operators &, |, &=,
and |= excepted the ones using operators *, +, *=, and +=... Here are
the function names I found:

operator &: intersection, operator*
operator &=: operator*=, clamp
operator |: operator+
operator |=: merge, include, operator+=, add

the pair "merge"/"merged" seems to best the alternative to me.

On Wed, Mar 11, 2009 at 10:35 AM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> hm, there is another problem the choice of "union" as a replacement of
> operator| is of course not possible (union is a keyword). It's getting
> hard to have a consistent naming scheme, at least using operators &,
> |, &=, and |= would solve all these issues, so perhaps it is still
> worth reconsidering them ?
>
> On Wed, Mar 11, 2009 at 10:09 AM, Gael Guennebaud
> <gael.guennebaud@xxxxxxxxxx> wrote:
>> ok, I see two options:
>>
>> options 1:
>>
>> a.makeUnion(b);
>> a.makeIntersection(b);
>> if (a.intersects(b)) blabla;
>>
>> option 2:
>>
>> a.unite(b);
>> a.intersect(b);
>> if (a.isIntersecting(b)) blabla;
>>
>> any preference ? (I vote for opt. 2)
>>
>>
>> gael.
>>
>> On Fri, Mar 6, 2009 at 10:03 PM, Ilya Baran <baran37@xxxxxxxxx> wrote:
>>> I think that "AlignedBox &intersect" vs. "bool intersects" would
>>> usually be OK: it should be clear from the context which is intended
>>> and because AlignedBox is not implicitly convertible to bool,
>>> accidentally overwriting a box is likely to be caught by the compiler.
>>>  That still leaves room for the following bug (for which existing
>>> compilers, I guess, wouldn't issue a warning):
>>>
>>> a.intersects(b); //this has no effect: a.intersect(b) was intended
>>>
>>> If you think this is a problem, perhaps "overlaps" should be the
>>> predicate? (although that's also somehow nonstandard).
>>>
>>>   -Ilya
>>>
>>> On Fri, Mar 6, 2009 at 3:42 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>>> "union" and "intersection" are the obvious choices, "unite" is good
>>>>> too. However, "intersect" is confusing because in my brain it would
>>>>> return true or false whether the two boxes intersect or not. This is
>>>>> why I used "clamp". There is also "crop" , yeah, I know that's not
>>>>> better... (about unite vs extend, that's because I did not thought
>>>>>
>>>>> gael
>>>>
>>>> Ah yes, right. Well, in proper english, that would be "intersects" but
>>>> I agree that this little s is a too small difference...
>>>>
>>>> Benoit
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>

--
ricard
http://www.ricardmarxer.com
http://www.caligraft.com

 Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/