I'm looking through the docs and see that vrotate *seems* to do what I'm 
looking for; that is to have a vector A which is rotated by a vector B.

So this would mean that if I have two vectors, say the top and bottom of a 
cyl, that I could, using vrotate, arbitrarily rotate the top of the cyl 
while leaving the bottom in place?

If so, sweet, and can vrotation be used to determine the effect of vrotate?
Would vcross give the perpendicular axis needed in vrotation, if its inputs 
were vector A and vector B from above?

I really should have started digging around in this program more fully many 
years ago. :-|

ian

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote in message 
news:49af84d0$1@news.povray.org...
> I'm looking through the docs and see that vrotate *seems* to do what I'm 
> looking for; that is to have a vector A which is rotated by a vector B.
>

It rotates vector A around the origin by the number of degrees specified by 
vector B, returning a vector. It rotates by B.x followed by B.y then B.z.
Is that what you want to do?


> So this would mean that if I have two vectors, say the top and bottom of a 
> cyl, that I could, using vrotate, arbitrarily rotate the top of the cyl 
> while leaving the bottom in place?
>

You can use it to help you do that. You need to be a little careful because 
you are talking about rotating one location vector around another location 
vector and vrotate rotates around the origin, so you need to compensate for 
that. You can use NewTop = vrotate(CylTop-CylBot,<30,0,0>)+CylBot; Then you 
can use NewTop and CylBot to define a cylinder object.


> If so, sweet, and can vrotation be used to determine the effect of 
> vrotate?

VRotation can indeed give you the angle between two direction vectors in 
Radians. To use it with CylTop and CylBot you still need to work on the 
difference between these positions to get a direction vector. Use VRotationD 
if you want to work in degrees. These can't reveal the original 3 angles 
used to rotate the vector in the first place.


> Would vcross give the perpendicular axis needed in vrotation, if its 
> inputs were vector A and vector B from above?

You can use vcross or VPerp_To_Plane to give you an axis that's 
perpendicular to two direction vectors (which you need for vrotation). You 
wouldn't want to use A and B from above as input because A is a direction 
vector, B is a vector containing 3 angles in degrees. You could use 
(CylTop-CylBot) and (NewTop-CylBot) which provides two direction vectors.


Regards,
Chris B.

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> I'm looking through the docs and see that vrotate *seems* to do what I'm
> looking for; that is to have a vector A which is rotated by a vector B.
>
> So this would mean that if I have two vectors, say the top and bottom of a
> cyl, that I could, using vrotate, arbitrarily rotate the top of the cyl
> while leaving the bottom in place?
>
> If so, sweet, and can vrotation be used to determine the effect of vrotate?
> Would vcross give the perpendicular axis needed in vrotation, if its inputs
> were vector A and vector B from above?

Um... unfortunately, rotation stuff is quite complex, and I know neither whether
you got the docs right nor whether I get you right :}

First off, vrotate(A,B) does the same thing to vector A that an "object { O
rotate B }" does to the whole object O; i.e., B does not specify the axis to
rotate about, but rather a set of three consecutive rotations about the X, Y
and Z axes respectively.

For that reason, computing the dot product of A and B makes absolutely no sense.


Speaking of the VRotation macro and the perpendicular axis, the thing you should
input to - say - VRotation(A,B,C) - as C is c*VCross(A,B), where c is an
arbitrary float constant, of which only the size matters.

Actually, to my knowledge the only added value of VRotation over VAngle is that
while VAngle just gives you the angle between two vectors, VRotation will add
some direction information to this angle.


Maybe the best thing is you tell us what you actually want to do; vector stuff
involving rotations is quite a complex topic (as you can probably see from the
number of macros related to it).

Post a reply to this message

"clipka" <nomail@nomail> wrote in message 
news:web.49afac96ed80e874f567c3de0@news.povray.org...
> Um... unfortunately, rotation stuff is quite complex, and I know neither 
> whether
> you got the docs right

No, no...you are correct, I actually *do* have no idea what I'm talking 
about. :-p
I tend to learn best by undertaking difficult tasks with basically no idea 
what I am doing.
I know, I'm weird.. :-D

>nor whether I get you right :}

This is likely, as I am worse than horrible at explaining things that I 
happen to be attempting, as I am sure you have realized by now.  :-)

>
> First off, vrotate(A,B) does the same thing to vector A that an "object 
> { O
> rotate B }" does to the whole object O; i.e., B does not specify the axis 
> to
> rotate about, but rather a set of three consecutive rotations about the X, 
> Y
> and Z axes respectively.

I found this out by dicking around these last few hours.

> For that reason, computing the dot product of A and B makes absolutely no 
> sense.
>
> Speaking of the VRotation macro and the perpendicular axis, the thing you 
> should
> input to - say - VRotation(A,B,C) - as C is c*VCross(A,B), where c is an
> arbitrary float constant, of which only the size matters.

Ok, so I wasn't too awfully far from target there at least.

> Actually, to my knowledge the only added value of VRotation over VAngle is 
> that
> while VAngle just gives you the angle between two vectors, VRotation will 
> add
> some direction information to this angle.

This is potentially useful.

> Maybe the best thing is you tell us what you actually want to do; vector 
> stuff
> involving rotations is quite a complex topic (as you can probably see from 
> the
> number of macros related to it).

Ok.
I'm using the following macro (ye olde snowmacro core) to output relevant 
vectors along with the surface normal:

#macro 
GDSX_VectTestN(Array,normArray,ctr,vectorArray,testVector,testObject,Normal)
 #local vectorA = min_extent(testObject);
 #local vectorB = max_extent(testObject);
 #local i=0;
 #while (i<ctr)
  #if (((vectorArray[i].x <= vectorB.x) & (vectorArray[i].x >= vectorA.x)) & 
((vectorArray[i].y <= vectorB.y) & (vectorArray[i].y >= vectorA.y)) & 
((vectorArray[i].z <= vectorB.z) & (vectorArray[i].z >= vectorA.z)))
   #if (inside(testObject,vectorArray[i]))
    #declare Array[i] = trace(testObject,vectorArray[i],testVector,Normal);
    #declare normArray[i] = Normal;
   #end
  #end
 #set i=i+1;
 #end
#end

This works well, and I've tested the output with cyls, which give the effect 
that I want, with the obvious exception that cyls make *terrible* moss. 
Since I'm dealing with a moss object generated from a macro that 
approximates Campylopus sp., which is obviously more complicated than a cyl, 
I need to find a meaningful way to rotate the individual models according to 
the surface normal to acheive any kind of meaningful effect.

Right now I am stuck with the attached image, and I know you guys are just 
about sick of that damned torus, but it renders fast and has a hole, so is 
useful for testing trace based effects.
I also would like to use some kind of rotation within the actual moss object 
macro every so often, as real moss isn't y+ straight (but the base of one 
object must remain stationary while the top moves, I think NewTop = 
vrotate(CylTop-CylBot,<30,0,0>)+CylBot; as proposed by Chris B might get 
that at least in part, but requires the solution to the other problem to 
use).

Thanks!
ian

Post a reply to this message

Attachments:
Download 'Moss.jpg' (46 KB)

Preview of image 'Moss.jpg'

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> This works well, and I've tested the output with cyls, which give the effect
> that I want, with the obvious exception that cyls make *terrible* moss.
> Since I'm dealing with a moss object generated from a macro that
> approximates Campylopus sp., which is obviously more complicated than a cyl,
> I need to find a meaningful way to rotate the individual models according to
> the surface normal to acheive any kind of meaningful effect.

Sounds like you want Reorient_Trans() in transforms.inc. Just put your small
moss component at the origin, aligned on the axis of your choice, then apply
this transform before translation.

http://www.povray.org/documentation/view/3.6.1/488/

Bill

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote in message 
news:web.49afd147ed80e8746dd25f0b0@news.povray.org...
> Sounds like you want Reorient_Trans() in transforms.inc. Just put your 
> small
> moss component at the origin, aligned on the axis of your choice, then 
> apply
> this transform before translation.

Ok, so since my translation is the trace output and the vector I wish to 
reorient towards is the normal, would I do this:

   object {
    mossFrond(5,6,<0,0,0>,0.125*0.5,frond)
    Reorient_Trans(mossVectArray[i],normVectArray[i])
    translate mossVectArray[i]
   }

That seems to get me close, but still some point straight up which should 
not, and those which are pointing in a direction are aimed toward the 
opposite of where they should be.

I'll post an image in p.b.i. (accidently posted one here earlier as I forgot 
I was in p.g...need sleep...)

ian

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Ok, so since my translation is the trace output and the vector I wish to
> reorient towards is the normal, would I do this:
>
>    object {
>     mossFrond(5,6,<0,0,0>,0.125*0.5,frond)
>     Reorient_Trans(mossVectArray[i],normVectArray[i])
>     translate mossVectArray[i]
>    }

Almost. The first parameter should be the axis vector to be transformed, i.e.
your component object's up-direction. So, if mossFrond() is grown up the
y-axis, you need:

Reorient_Trans(y,normVectArray[i])

Bill

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote in message 
news:web.49afdafded80e8746dd25f0b0@news.povray.org...
> Almost. The first parameter should be the axis vector to be transformed, 
> i.e.
> your component object's up-direction. So, if mossFrond() is grown up the
> y-axis, you need:
>
> Reorient_Trans(y,normVectArray[i])

Oh jeebus... *smacks head*. That would explain a few things lol!
That works perfectly by the way. :)

So could this also work for orientation around a point, in a way that could 
be used within the moss frond, versus just for its placement?

Thanks,
ian

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> This works well, and I've tested the output with cyls, which give the effect
> that I want, with the obvious exception that cyls make *terrible* moss.
> Since I'm dealing with a moss object generated from a macro that
> approximates Campylopus sp., which is obviously more complicated than a cyl,
> I need to find a meaningful way to rotate the individual models according to
> the surface normal to acheive any kind of meaningful effect.

Ah, I see.

So what you're looking for is the B in object{O rotate B} so that whatever was
vertically in O is now parallel to a vector N (your normal).

Or, the transformation matrix M in object{O transform M} to get the same effect.

Try this:

  #include "transforms.inc"
  ...
  #declare M = Reorient_Trans(y, MyNormal)
  object{MyCampylopusSp transform { M } }

For better effect, you may want to use:

  object{
    MyCampylopusSp
    rotate y*rand(MyRand)*360
    transform { M }
  }

AFAIK this should do exactly the thing you want. I guess there's a clever
combination of V* macros that will give you the proper B for a "rotate B", but
nothing as easy and elegant as the Reorient_Trans macro.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
>   #declare M = Reorient_Trans(y, MyNormal)

Just found an even simpler one:

    #declare M = Point_At_Trans(MyNormal)

Post a reply to this message