Does this assume that your object is not located somewhere else other
than the origin? (<0,0,0>)  What if I have a gun turret that is located
at <5,0,5> (ie: it rotates around the line defined by <5,y,5>), would
this macro take that in to account? or would another parameter
_location_ be required? 

-paul 

John VanSickle wrote:
> 
> David Fontaine wrote:
> >
> > John's macro should do what you want. The only problem I think would be the axial
> > rotation changing, but if your gun stays pointing on the x-z plane with y up it
> > shouldn't matter I think. I've written one aimilar to keep axial rotation the same
> > (perpendicular vector intersecting y axis still intersects y axis). It's a lot
> > messier than John's though.
> 
> The Reorient vector tilts as if the joint were a ball-and-socket joint.  If you
> want to tilt in the way the POV camera tilts when the look_at parameter is
> specified, here is some tighter, neater, and more flexible code.
> 
> Specifically, it allows you to begin from any direction; this is useful because
> sometimes I model with x=forward, and sometimes with z=forward.  The "up"
> direction of your scene can also be specified, so this can be used by people
> who use up=y or up=z (or up=<3,4,12>/13, if you want to be strange).
> 
> I should probably add this to the Thoroughly Useful Macros file...
> 
> Hope this helps,
> John
> 
> // macro code follows
> 
> #macro PointAlong(OldDirection,NewDirection,Up)
> // OldDirection is the direction in which the object is currently pointed
> // NewDirection is the direction in which you want it to point
> // Up is the vector that is considered to be up
> 
> #if(vlength(OldDirection)=0)
> #error "Zero-length vector supplied as old direction.\n"
> #end
> #if(vlength(NewDirection)=0)
> #error "Zero-length vector supplied as new direction.\n"
> #end
> #if(vlength(Up)=0)
> #error "Zero-length vector supplied as up vector.\n"
> #end
> 
> #local vOD=vnormalize(OldDirection);
> #local vOR=vcross(Up,OldDirection);
> #if(vlength(vOR)=0)
>   #debug "Old direction vector is parallel to up vector.\n"
>   #local vOR=vcross(vOD,<vOD.z,vOD.x,-vOD.y>);
> #end
> #local vOR=vnormalize(vOR);
> #local vOU=vnormalize(vcross(OldDirection,vOR));
> 
> #local vND=vnormalize(NewDirection);
> #local vNR=vcross(Up,NewDirection);
> #if(vlength(vNR)=0)
>   #debug "New direction vector is parallel to up vector.\n"
>   #local vNR=vcross(vND,<vND.z,vND.x,-vND.y>);
> #end
> #local vNR=vnormalize(vNR);
> #local vNU=vnormalize(vcross(NewDirection,vOR));
> 
> matrix <vOR.x,vOU.x,vOD.x, vOR.y,vOU.y,vOD.y, vOR.z,vOU.z,vOD.z, 0,0,0>
> matrix <vOR.x,vOR.y,vOR.z, vOU.x,vOU.y,vOU.z, vOD.x,vOD.y,vOD.z, 0,0,0>
> 
> #end
> // end of macro code

-- 



--------------------------------------------------}
Paul Daniel Jones
The Pennslyvania State University

pdj### [at] psuedu
http://research.chem.psu.edu/glassgrp/paul

       C            The way is near, but men
     // \           seek it afar. It is in the
    N    N          easy things, but men seek it
    |    ||         in the difficult things.
    C    C          -Menicius
     \\  /
       C
--------------------------------------------------}

Post a reply to this message

Margus Ramst wrote:

> ... 8< Snip ...
> #macro v_parallel(V1i,V2i)
>     #local V1=vnormalize(V1i+<0,0,0>);
>     #local V2=vnormalize(V2i+<0,0,0>);
>     #local Vt=(vlength(V1+V2)-1);
>     #if(Vt=1|Vt=-1) Vt
>     #else 0
>     #end
> #end
> ...
> #macro v_reorient(V,RefA,RefB)
>   (#if((v_parallel(RefA,RefB))=0)
>     vaxis_rotate(
>       V,
>       vcross(vnormalize(RefA),vnormalize(RefB)),
>       degrees(atan2(vlength(vcross(vnormalize(RefA),vnormalize(RefB))),
>       vdot(vnormalize(RefA),vnormalize(RefB)))))
>   #else
>     ((v_parallel(RefA,RefB))*V)
>   #end)
> #end
> ...

I like the way you're finding if the two vectors are parallel in the first
macro and how the result is used to make a decision, and later to scale
the "incoming" vector if the other two are parallel.

BUT: From what I can see you're calculating the same things several times.

Wouldn't it be better to store calculated values in variables and use them
up again when needed ?

(Or is there too much overhead for POV to make these new variables ?)

Below are my suggestions of how the same thing could be done with only
one macro. (At least they seem to work the same way :)


Regards,

Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html



// First using your parallel-method:

#macro vReorient(vI,vRefA,vRefB)
  #local vA=vnormalize(vRefA+<0,0,0>);
  #local vB=vnormalize(vRefB+<0,0,0>);
  #local vC=vcross(vA,vB);
  #local vD=vdot(vA,vB);
  #local SS=vlength(vA+vB)-1;
  (SS=-1|SS=1?SS*vI:vaxis_rotate(vI,vC,degrees(atan2(vlength(vC),vD))))
#end


// Then with information about parallelism from vdot:

#macro vReorient2(vI,vRefA,vRefB)
  #local vA=vnormalize(vRefA+<0,0,0>);
  #local vB=vnormalize(vRefB+<0,0,0>);
  #local vC=vcross(vA,vB);
  #local vD=vdot(vA,vB);
  (abs(vD)=1?vD*vI:vaxis_rotate(vI,vC,degrees(atan2(vlength(vC),vD))))
#end

Post a reply to this message

J Charter wrote:

> Yikes! This is great!  So I put together concepts from Margus and David and come up
> with the following.  And it seems to solve a problem I've been chasing for some
> time,...how to orient an arbitrary set of points from a shape ( the processes of a
> vertabrae ) along a spline ( forming the axial structure of an animal's turning neck
)
> and know what the new point locations are ( in order to attach muscles at their
> insertion points ).  Mild testing seems to indicate this works!  Can anyone who
knows
> vet this?  Is this really a solution?  Is there a cleaner way?
>
> #macro repoint(pt,vec1,vec2)
>
>    #if (vlength(vec1)=0)
>       #render "Warning: reposition initial vector length is zero.\n"
>    #end
>    #if (vec1.x=0 & vec1.z=0)
>       #local RotY=0;
>    #else
>       #local RotY=atan2(vec1.x,vec1.z)*180/pi;
>    #end
>    #local RotX=asin((vec1.y)/vlength(vec1))*180/pi;
>
>    #local pt = vrotate ( pt, <0,-RotY,0>    )
>    #local pt = vrotate ( pt, <RotX,0,0>     )
>
> ... 8< Snip ...

May I suggest using degrees() instead of
multiplying with 180/pi ?
E.g.: RotY=degrees(atan2(vec1.x,vec1.z));

You can also write asin(vnormalize(vec1).y)
instead of asin((vec1.y)/vlength(vec1))


Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Tor Olav Kristensen wrote:

> > #macro repoint(pt,vec1,vec2)
> >
> >    #if (vlength(vec1)=0)
> >       #render "Warning: reposition initial vector length is zero.\n"
> >    #end
> >    #if (vec1.x=0 & vec1.z=0)
> >       #local RotY=0;
> >    #else
> >       #local RotY=atan2(vec1.x,vec1.z)*180/pi;
> >    #end
> >    #local RotX=asin((vec1.y)/vlength(vec1))*180/pi;
> >
> >    #local pt = vrotate ( pt, <0,-RotY,0>    )
> >    #local pt = vrotate ( pt, <RotX,0,0>     )
> >
> > ... 8< Snip ...
>
> May I suggest using degrees() instead of
> multiplying with 180/pi ?
> E.g.: RotY=degrees(atan2(vec1.x,vec1.z));
>
> You can also write asin(vnormalize(vec1).y)
> instead of asin((vec1.y)/vlength(vec1))

Ah, will do. New version will go up when I update my site.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

John VanSickle wrote:

> David Fontaine wrote:
> >
> > John's macro should do what you want. The only problem I think would be the axial
> > rotation changing, but if your gun stays pointing on the x-z plane with y up it
> > shouldn't matter I think. I've written one aimilar to keep axial rotation the same
> > (perpendicular vector intersecting y axis still intersects y axis). It's a lot
> > messier than John's though.
>
> The Reorient vector tilts as if the joint were a ball-and-socket joint.  If you
> want to tilt in the way the POV camera tilts when the look_at parameter is
> specified, here is some tighter, neater, and more flexible code.

Ah, now I get it. The 'up' parameter is a good idea too.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

Tor Olav Kristensen wrote:
> 
> BUT: From what I can see you're calculating the same things several times.
> 
> Wouldn't it be better to store calculated values in variables and use them
> up again when needed ?
> 
> (Or is there too much overhead for POV to make these new variables ?)
> 

Oh, certainly the method I suggested isn't optimized. I'm just lazy, and since
the v_parallel macro was so conveniently lying around, I probably saved a whole
10 keystrokes :)

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

Paul Jones wrote:
> 
> Does this assume that your object is not located somewhere else other
> than the origin? (<0,0,0>)

On the contrary, it assumes that the object is at the origin.

>  What if I have a gun turret that is located at <5,0,5> (ie: it
> rotates around the line defined by <5,y,5>), would this macro take
> that in to account? or would another parameter _location_ be required?

Actually, it would be easier to model it at the origin, turn it using
the macro, and then translate it to where you want it.

But if you've already modeled it to turn around some other point, then
use some other transforms before and after:

object { MyGun
  translate -GunLocation
  PointAlong(z,<-1,1,14>,y)
  translate GunLocation
}

This moves the object to the origin, rotates it, and then moves it back.
This code assumes the gun is originally modelled pointing in the +z
direction.

BTW, the macro I gave earlier turns the object, and raises it or lowers
it as well (ie, give both yaw and pitch).  If you want just yaw or just
pitch, let me know and I'll explain how to call the macro for that.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message

John VanSickle wrote:

> BTW, the macro I gave earlier turns the object, and raises it or lowers
> it as well (ie, give both yaw and pitch).  If you want just yaw or just
> pitch, let me know and I'll explain how to call the macro for that.

How is this a special case?

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

David Fontaine wrote:
> 
> John VanSickle wrote:
> 
> > BTW, the macro I gave earlier turns the object, and raises it or lowers
> > it as well (ie, give both yaw and pitch).  If you want just yaw or just
> > pitch, let me know and I'll explain how to call the macro for that.
> 
> How is this a special case?

It's not a special case, but rather a change in what the user wants (since
that's what I was asking for: to know if there was a change in what he
wanted).

Anyway, suppose one has a gun turret (the example under discussion), like
the top of a tank, for instance.  The gun both turns and lifts, while the
turret just turns.  The macro I supplied here will give the transform for
the gun, but not the turret; however, if the NewDirection vector is
modified so that vdot(NewDirection,Up)=0, the macro will give the transform
for the turret.  It would be used this way:

#local TurretDir=NewDirection-Up*vdot(NewDirection,Up);
PointAlong(OldDirection,TurretDir,Up)

The user needs to identify which objects need freedom of movement in
both directions, which need freedom of movement in one direction, and
group and align them as follows:

union { // gun and turret
  union { // just the gun
    object { GunPart1 }
    object { GunPart2 }
    PointAlong(ModelDirection,NewDirection,Up)
  } // end of just the gun
  union { // just the turret
    object { TurretPart1 }
    object { TurretPart2 }
    PointAlong(ModelDirection,TurretDirection,Up)
  } // end of just the turret
  translate GunTurretLocation
} // end of gun and turret

Post a reply to this message

John VanSickle wrote:

> It's not a special case, but rather a change in what the user wants (since
> that's what I was asking for: to know if there was a change in what he
> wanted).
>
> Anyway, suppose one has a gun turret (the example under discussion), like
> the top of a tank, for instance.  The gun both turns and lifts, while the
> turret just turns.  The macro I supplied here will give the transform for
> the gun, but not the turret; however, if the NewDirection vector is
> modified so that vdot(NewDirection,Up)=0, the macro will give the transform
> for the turret.  It would be used this way:
>
> #local TurretDir=NewDirection-Up*vdot(NewDirection,Up);
> PointAlong(OldDirection,TurretDir,Up)
>
> The user needs to identify which objects need freedom of movement in
> both directions, which need freedom of movement in one direction, and
> group and align them as follows:

[snip]
It's still just a simple task for the user to do that with the standard
macro... but I see now that's what you were going to tell him how to do. :)


--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message