Given four points that define an arbitraryy rectangle,  but at some unknown
position and rotation,  how can I have a transform that will transform any
given object (say a box which shares the rectangle as one of its sides)  to
that position & rotation?

I've tried for about a full man day of programming and came up to a dead
end....

Restating,  I have a pAf,  pBf,  pAb,  pBb,  which represent the position of
four wheels on a railroad that conforms to a wavy isosurface.     I want to
design a train engine or care that fits within a box of this size but then
is transformed out there.

The problem that I ran into was that I inevitably found unwanted "rolling,"
to use an aeronautical term, in the 30-odd  different algorithms that I
tried.

Post a reply to this message

First, you need to recognize that 3 points determine a plane, but 4 points
may be non-coplanar. So what happens when the 4 points aren't all on the
same plane? Perhaps you should decide which 3 points are the most important
ones to align to?

Once you figure that out, we can probably help you create a transformation
that places the object correctly.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

I've pre-determined them to be coplanar through my "railroad" algorithm.

And say they're out in limbo space but comprise a rectangle of L x W.

If it helps to have a better definition, how about a transform from a
   box{<-L/2,0,-W/2>,<L/2,H,W/2>}

to make its "bottom rectangle" match up with the four points.


I tried my own common sense use of Reorient_Trans(), but the object was
ROLLING as well as getting "re-oriented". Such that the four points did not
line up.

Thanks much.  see also:
http://news.povray.org/povray.binaries.animations/27771/

Post a reply to this message

OK. This should, in theory, do the trick, but it's untested code.

I'm going to take the box
box {<0,0,0>,<L,H,W>}
and make it fit your four points. The point <0,0,0> on the box will
correspond to the point pBb (the back right of the train car).

(pAf,  pBf,  pAb,  pBb must be predefined)

#declare newx = vnormalize(pBf-pBb);
#declare newz = vnormalize(pAb-pBb);
#declare newy = vcross(newz,newx);
matrix <
newx.x,newx.y,newx.z,
newy.x,newy.y,newy.z,
newz.x,newz.y,newz.z,
pBb.x,pBb.y,pBb.z
>

Give that a shot.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Slime wrote:
> OK. This should, in theory, do the trick, but it's untested code.
> 
> I'm going to take the box
> box {<0,0,0>,<L,H,W>}
> and make it fit your four points. The point <0,0,0> on the box will
> correspond to the point pBb (the back right of the train car).
> 
> (pAf,  pBf,  pAb,  pBb must be predefined)
> 
> #declare newx = vnormalize(pBf-pBb);
> #declare newz = vnormalize(pAb-pBb);
> #declare newy = vcross(newz,newx);
> matrix <
> newx.x,newx.y,newx.z,
> newy.x,newy.y,newy.z,
> newz.x,newz.y,newz.z,
> pBb.x,pBb.y,pBb.z
> 

Additionally, it should be added that this is, of course,
highly dependant on how you define your corner points for
the rectangle. The algorithm that generates them must be
consistant in their definition, which I gather it is,
based on the naming convention being used for the
variables.

Since this is a train track segment, I take it that "pAf"
stands for "point A, forward", "pBf" is "point B forward",
etc. I'm guessing the lower case "b" means the "back" edge
of the rectangle relative to the track direction.

Now, it would be helpful for visualization if instead of
"A" and "B" we were saying "L" and "R" so we'd know for
sure what way we're looking at the points, but I'll presume
"A" is left edge and "B" is right as if you were looking down
from above, which seems reasonable to me, since otherwise
you'd need a glass bottom track under your train to look up
at it going over your head <g>. In other words,

    pAf +------------------+ pBf                ^
        |                  |                    |
    pAb +------------------+ pBb   Train moves that way.


So, if you have your points named as per above, then pAb
should be the local origin of the new location for the
local coordinate axis. IF these presumptions are correct,
the macro above would work better, just slightly modified
as...

#macro AlignToRect(pAb, pAf, pBf, pBb)
     #local newx = vnormalize(pAf-pAb);
     #local newz = vnormalize(pBb-pAb);
     #local newy = vcross(newx,newz);

     matrix <
         newx.x,newx.y,newx.z,
         newy.x,newy.y,newy.z,
         newz.x,newz.y,newz.z,
         pAb.x, pAb.y, pAb.z
     >
#end


Note, this uses the left rear of the box as the point
of translation, which makes sense, since if, before you
transformed it, it was running <0,0,0> to <L,H,W> then
the transformed box's local origin will be at the new left
rear lower-most point. Also, accordingly, we've used that
local origin in the vector subtraction that yields the
direction vectors to vcross in order to get the new "up"
orientation, so that the pivot point will also be around
this local origin. Keeping these two points in mind will
help you visualize the position and orientation of your
transformed object when the matrix gets through working
its, er... "wonders" on it. :)

Now of course perfect alignment depends on your source points
being "truly" coplanar, but as you noted that part is already
handled by an algorithm that generates it automatically, so
this shouldn't cause any difficulty as long as you're satisfied
that algorithm is working as it should.


-- 
@C[$F];
The Silver Tome ::  http://www.silvertome.com
"You may sing to my cat if you like..."

Post a reply to this message

Thanks all for the consideration and help. When this project wins a SIGGRAPH
prize, I'll make sure your names are in the commented listing I provide the
press.    ;-)


The newx & newz were switched re: my convention.  It works well.  Will start
a new anim.
 I got compliments on the bounciness of my earlier,  "sloppy" algorithm; I
wonder if this one will be less impressive, although it will allow me to
design fancier engines & cars.

About every three years, I come to the conclusion that the Reorient macros
require rolling in the reorientation, but the only time I see such a
phenomenon is in hopelessly complicated code that I wouldn't have anyone
else wade through....


#macro AlignToRect2(pAb, pAf, pBf, pBb)  // by  Charles Fusner and Slime
     #local newz = vnormalize(pAf-pAb);
     #local newx = vnormalize(pBb-pAb);
     #local newy = vcross(newx,newz);

     matrix <
         newx.x,newx.y,newx.z,
         newy.x,newy.y,newy.z,
         newz.x,newz.y,newz.z,
         pAb.x, pAb.y, pAb.z
     >
#end

Post a reply to this message

> About every three years, I come to the conclusion that the Reorient macros
> require rolling in the reorientation, but the only time I see such a
> phenomenon is in hopelessly complicated code that I wouldn't have anyone
> else wade through....


Well, the reorient macro aligns an axis of the object with a new axis, but
it doesn't specify how much the object should be rotated *around* that axis
in the process. To reorient something and really know what it's going to
look like, you need to align to two axis. That's what I did with the code I
gave you, and since the matrix transformation requires all 3 axis (x,y,z) to
be redefined, I figured out which direction the 3rd axis should point by
doing a vector cross product (which finds a vector perpendicular to the two
vectors crossed).

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

"Slime" <slm### [at] slimelandcom> wrote in message
news:3d974bd2@news.povray.org...
>  To reorient something and really know what it's going to
> look like, you need to align to two axis.

I failed miserably in my attempt at this.  Is there a generic solution
already out there?

Post a reply to this message

Greg M. Johnson wrote:
>>  To reorient something and really know what
>> it's going to look like, you need to align
>> to two axis.
>
> I failed miserably in my attempt at this.
> Is there a generic solution already out there?

Not sure if this is exactly what you're looking for, but:

Suppose that you want the z axis aligned to Z_vector and the y axis
aligned to Normal_vector. If the Z_vector and the Normal_vector are not
perpendicular, you want the Z_vector to be dominant.

Now you can align the object using some code like this (untested code):

#include "math.inc"
#include "transforms.inc"
#declare ObjectZ = vnormalize(Z_vector);
#declare ObjectY = VPerp_Adjust(Normal_vector,Z_vector);
#declare ObjectX = vcross(ObjectY,ObjectZ);
#declare Trans = Matrix_Trans(ObjectX,ObjectY,ObjectZ,<0,0,0>);
object {MyObject transform {Trans}}

Well, that's the method I use all the time anyway.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Sep 8)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message