![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"[GDS|Entropy]" <gds### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"[GDS|Entropy]" <gds### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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'
![Moss.jpg](/povray.general/attachment/%3C49afc9c4%40news.povray.org%3E/Moss.jpg?ttop=443865&toff=1950&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"[GDS|Entropy]" <gds### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Bill Pragnell" <bil### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"[GDS|Entropy]" <gds### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Bill Pragnell" <bil### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"[GDS|Entropy]" <gds### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |