Re: [Algorithms] Clipping against OBBs

[<ro...@do...>]

Nicolas Serres  wrote:

>I personally store OBBs as :
>- center
>- normalized axis
>- half width
>
>.....
>If you are interested in plane equation, you almost have it in that format;
>axis being plane normals; you have (a,b,c) of ax+by+cz+d=0. I prefer to
>store them with normalized axis because I consider it is the best compromise
>for my different applciations of OBBs. But if you almost always work with
>the planes of the obb, you might want to replace box center+half width with
>"d" values.

Actually the "d" values of the equations of the planes of the box
faces are the negatives of the six values 
	(center dot normalized axis) [+-] half width
where there are three axes and three corresponding half widths,
assuming that you use "normalized axis" as the unit normal to each of
the two box faces perpendicular to it. 

> It might be less easier to use if your OBB is frequently
>transformed.
>
>But anyway, if you already have a functional software clipping pipeline, the
>easiest way is to express your world coordinates in bbox coordinates (the
>transformation is straightforward if you have obb axes). Using half
>width/normalized axis makes you clip against (-half_width,+half_width).
>Using "tweaked" (1 / half_width) non normalized axis makes you clip against
>(-1,+1). The latests seems easier, especially if you already have a working
>homogenous clipping pipeline. You just have to set w to 1, and care about
>the (z<-w) issue (and not z<0 as usal)... It even allows you to use
>extremely efficiently some buggy SIMD instructions that are not well suited
>for classical frustrum clipping, but are perfectly suited for that.
>
>If you do that, you will need to store extra information (which is basically
>the inverse of the world->box space transformation previously stored) to be
>able to transform your clipped results into viewport space (which is, I
>suppose your final goal). As my code that did the clip was
>ultra-experiental-debug-stuff, I did a brute force matrix inversion, and I
>definitely don't recommend it!
>

"Brute force"?? For inverting a matrix consisting of a rotation and
translation?  All you have to do is transpose a 3x3 and multiply a 3x3
by a 1x3.  Nothing to solve, and nothing I would call "brutish". 

Actually, when I do stuff like that in my code, I don't use matrices
at all, (and so have none to invert)  but just the functions of my
fast elementary vector algebra library.

For example, given a world coordinate vector V of a vertex, its 1-
component in box coordinates is just
	(V - box center) dot nomalized axis1
and similarly for the other two box coordinates of V.

Going the other way, given a point in box coordinates (B1, B2, B3),
its world x, y, z coordinates are the x, y, z coordinates of 

B1*normalized axis1 + B2*normalized axis2 + B3*normalized axis3 +
    box center.

where I am making the natural assumption that you have the normalized
axis vectors and box center in world coordinates.

Matrices are handy in some circumstances, especially when you have to
concatenate transformations,  and you do have to use them as arguments
to many 3D API calls, but don't get stuck in the rut of thinking you
HAVE to construct them and invert them and whatnot to effect EVERY
mapping that comes up in the computational geometry of your
application.  For lots of short, simple stuff, thinking in terms of
your elementary vector algebra library, which is much closer to the
geometric fundamentals,  is much better than thinking in matrices. You
end up doing exactly the same operations, but it is much easier to
figure out what those operations need to be when you keep the vector
geometric fundamentals in your mind, and just write them down in the
form of calls to your vector algebra library.

>----- Original Message -----
>From: "Doug Chism" <dc...@d-...>
>To: <gda...@li...>
>Sent: Monday, August 14, 2000 10:20 PM
>Subject: [Algorithms] Clipping against OBBs
>
>
>> Does anyone know of any good code sources for fast clipping of
>> lines/triangles against OBBs? I guess the idea would be to pull the planes
>> out of the OBB and clip against them - something along that line of
>thought?
>> If you are keeping track of the Center, Corner, Axes, Normalized Axes, and
>> Half Size, whats the fastest way to get the 6 plane equations of the OBB
>> from that ( or if cheaper/faster clipping approach available is there info
>> on that? )
>>
>> Doug Chism
>>
>>
>> _______________________________________________
>> GDAlgorithms-list mailing list
>> GDA...@li...
>> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list