 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Is there any way to do local transformations based on an object's
current scale, position & rotation? (i.e. a translation on an object's
X axis as apposed to the origin's X axis)
If there isn't currently a way to do this, is there enough interest for
someone to create a patch?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 06 Jan 1999 16:56:08 -0800, Tony Vigil <tvi### [at] emc-inc com>
wrote:
>Is there any way to do local transformations based on an object's
>current scale, position & rotation? (i.e. a translation on an object's
>X axis as apposed to the origin's X axis)
>
>If there isn't currently a way to do this, is there enough interest for
>someone to create a patch?
Maybe I'm an idiot, but if you can't just put the translate along the
X axis in before whatever transformation moved it to the new position,
how is the software going to know what you thought the X axis was?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You're hardly an idiot.
"Ronald L. Parker" wrote:
>
> On Wed, 06 Jan 1999 16:56:08 -0800, Tony Vigil <tvi### [at] emc-inccom>
> wrote:
>
> >Is there any way to do local transformations based on an object's
> >current scale, position & rotation? (i.e. a translation on an object's
> >X axis as apposed to the origin's X axis)
> >
> >If there isn't currently a way to do this, is there enough interest for
> >someone to create a patch?
>
> Maybe I'm an idiot, but if you can't just put the translate along the
> X axis in before whatever transformation moved it to the new position,
> how is the software going to know what you thought the X axis was?
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.htm
=Bob
Post a reply to this message
Attachments:
Download 'us-ascii' (1 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe I am missing something.
If you have an object that is positioned at <0,0,0> and is rotated 45 degrees
on the Y axis, then translate it 1 unit on the X axis, won't it be located at
<1,0,0>???
What I was wanting to do is translate that same object (with it's rotated
axis), 1 unit on it's own X axis.
The approximate coordinates would become < 0.71, 0, 0.71> instead of <1,0,0>
Bob Hughes wrote:
> You're hardly an idiot.
>
> "Ronald L. Parker" wrote:
> >
> > On Wed, 06 Jan 1999 16:56:08 -0800, Tony Vigil <tvi### [at] emc-inccom>
> > wrote:
> >
> > >Is there any way to do local transformations based on an object's
> > >current scale, position & rotation? (i.e. a translation on an object's
> > >X axis as apposed to the origin's X axis)
> > >
> > >If there isn't currently a way to do this, is there enough interest for
> > >someone to create a patch?
> >
> > Maybe I'm an idiot, but if you can't just put the translate along the
> > X axis in before whatever transformation moved it to the new position,
> > how is the software going to know what you thought the X axis was?
>
> --
> omniVERSE: beyond the universe
> http://members.aol.com/inversez/POVring.htm
> =Bob
Post a reply to this message
Attachments:
Download 'us-ascii' (2 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
If VRML can do it, why not POV???
"Ronald L. Parker" wrote:
> On Wed, 06 Jan 1999 16:56:08 -0800, Tony Vigil <tvi### [at] emc-inccom>
> wrote:
>
> >Is there any way to do local transformations based on an object's
> >current scale, position & rotation? (i.e. a translation on an object's
> >X axis as apposed to the origin's X axis)
> >
> >If there isn't currently a way to do this, is there enough interest for
> >someone to create a patch?
>
> Maybe I'm an idiot, but if you can't just put the translate along the
> X axis in before whatever transformation moved it to the new position,
> how is the software going to know what you thought the X axis was?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <369512B3.B9F1079D@emc-inc.com> , Tony Vigil <tvi### [at] emc-inccom> wrote:
>Maybe I am missing something.
No, you aren't missing something, you just did not read the docs! See section
4.3.1.3.
>If you have an object that is positioned at <0,0,0> and is rotated 45 degrees
>on the Y axis, then translate it 1 unit on the X axis, won't it be located at
><1,0,0>???
So your code would look like:
rotate <0,45,0>
translate <1,0,0>
>What I was wanting to do is translate that same object (with it's rotated
>axis), 1 unit on it's own X axis.
>
>The approximate coordinates would become < 0.71, 0, 0.71> instead of <1,0,0>
Did you consider (after reading the docs) to write:
translate <1,0,0>
rotate <0,45,0>
It will do what you want - and reading the docs will surely show you some other
features you don't even know about! :-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 07 Jan 1999 12:01:55 -0800, Tony Vigil <tvi### [at] emc-inccom> wrote:
>Maybe I am missing something.
In that case, please allow me to elucidate.
>If you have an object that is positioned at <0,0,0> and is rotated 45 degrees
>on the Y axis, then translate it 1 unit on the X axis, won't it be located at
><1,0,0>???
Yes it will. That's not what I was trying to say.
>What I was wanting to do is translate that same object (with it's rotated
>axis), 1 unit on it's own X axis.
>
>The approximate coordinates would become < 0.71, 0, 0.71> instead of <1,0,0>
All you have to do is translate first, then rotate:
sphere {
0, 1
/* local transformations */
translate x
/* global transformations */
rotate 45*y
}
makes a sphere with its center at <sqrt(.5),0,sqrt(.5)>, just as requested.
This works for more complex objects and transformations, too, but the proof
is left as an exercise for the reader. (See Exercise 2.)
This assumes you're actually doing the rotation, of course. If you're not,
(for example, you're using a mesh exported from Poser) then there's no way
for you or POV to know what "its own X axis" is. If you're not doing the
rotation, but you know something about the rotation and can supply the
necessary parameters in the form of a rotation vector, then what you need
to do is:
#macro InvRotate( Rot )
transform {
rotate -Rot.z*z
rotate -Rot.y*y
rotate -Rot.x*x
}
#end
object {
MyObject
#declare Rot=<whatever your rotation vector is>;
InvRotate( Rot )
translate x
rotate Rot
}
(Note the three rotates to form the inverse: this is because POV always
rotates along X first, then Y, then Z. The inverse should go in the
opposite direction.)
The same goes for any other transformation: if it's one you did yourself, just
do the "local" transformations first, before you apply the "global" ones. If
it's not, you have to "back out" the pre-applied "global" transformations,
then apply the "local" ones, then apply the "global" ones again. I am
hard-pressed to think of a specification syntax that would make this much
easier than it already is.
EXERCISES:
1. Discover a method to turn off the HTML "feature" in your news posting
software. Use it.
2. Prove that the method given works for more complex objects and transforms.
3. (Extra Credit) Write a short paragraph on the properties of a trivial
bijective mapping between the sets (she's, he's, it's) and (her, his, its)
4. (Extra Credit) The First Law of Usenet claims that every spelling flame
will contain at least one misspelled word or factual error. Find one in
this post.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> No, you aren't missing something, you just did not read the docs! See section
> 4.3.1.3.
I sure did read them. You have misread them. Rotations are relative to the object
axis
& translations/scaling are relative to the origin.
>
> >If you have an object that is positioned at <0,0,0> and is rotated 45 degrees
> >on the Y axis, then translate it 1 unit on the X axis, won't it be located at
> ><1,0,0>???
>
> So your code would look like:
> rotate <0,45,0>
> translate <1,0,0>
>
Your code places the object at <1,0,0>. If POV did have a local coordinate system for
each object, those same transformations would put it at < 0.71, 0, -0.71>.
>
> >What I was wanting to do is translate that same object (with it's rotated
> >axis), 1 unit on it's own X axis.
> >
> >The approximate coordinates would become < 0.71, 0, 0.71> instead of <1,0,0>
>
> Did you consider (after reading the docs) to write:
> translate <1,0,0>
> rotate <0,45,0>
>
I sure did. Now suppose you want to perform another set of transfomations to the same
object:
-45 degrees on the object's Y axis (no translations occuring), then translate 1 unit
along the object's Z axis. Now what??? The object should be at in it's original
rotational state of <0,0,0> located at <0.71 , 0 , 0.29> - but it's not.
> It will do what you want - and reading the docs will surely show you some other
> features you don't even know about! :-)
>
> Thorsten
Thanks for the reading tip though. Perhaps you should do likewise. :-)
Tony
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you mucho for your macro.
Hypothetically, what if you needed to do the following:
Create an object at <0,0,0>
Rotate the object 45 degrees * around the object's Y axis
Translate the object 1 unit along object's X axis (now at a 45 degree angle)
Rotate the object -90 degrees * around the object's Y axis
Translate the object 1 unit along the object's Z axis (now at a -45 degree angle)
Rotate the object 45 degrees * around the object's Y axis
Will your macro place the object at <0,0,0> with 0 rotation on each axis?
Mucho thanks!
Tony
Ron Parker wrote:
> On Thu, 07 Jan 1999 12:01:55 -0800, Tony Vigil <tvi### [at] emc-inccom> wrote:
> >Maybe I am missing something.
>
> In that case, please allow me to elucidate.
>
> >If you have an object that is positioned at <0,0,0> and is rotated 45 degrees
> >on the Y axis, then translate it 1 unit on the X axis, won't it be located at
> ><1,0,0>???
>
> Yes it will. That's not what I was trying to say.
>
> >What I was wanting to do is translate that same object (with it's rotated
> >axis), 1 unit on it's own X axis.
> >
> >The approximate coordinates would become < 0.71, 0, 0.71> instead of <1,0,0>
>
> All you have to do is translate first, then rotate:
>
> sphere {
> 0, 1
>
> /* local transformations */
> translate x
>
> /* global transformations */
> rotate 45*y
> }
>
> makes a sphere with its center at <sqrt(.5),0,sqrt(.5)>, just as requested.
> This works for more complex objects and transformations, too, but the proof
> is left as an exercise for the reader. (See Exercise 2.)
>
> This assumes you're actually doing the rotation, of course. If you're not,
> (for example, you're using a mesh exported from Poser) then there's no way
> for you or POV to know what "its own X axis" is. If you're not doing the
> rotation, but you know something about the rotation and can supply the
> necessary parameters in the form of a rotation vector, then what you need
> to do is:
>
> #macro InvRotate( Rot )
> transform {
> rotate -Rot.z*z
> rotate -Rot.y*y
> rotate -Rot.x*x
> }
> #end
>
> object {
> MyObject
>
> #declare Rot=<whatever your rotation vector is>;
> InvRotate( Rot )
> translate x
> rotate Rot
> }
>
> (Note the three rotates to form the inverse: this is because POV always
> rotates along X first, then Y, then Z. The inverse should go in the
> opposite direction.)
>
> The same goes for any other transformation: if it's one you did yourself, just
> do the "local" transformations first, before you apply the "global" ones. If
> it's not, you have to "back out" the pre-applied "global" transformations,
> then apply the "local" ones, then apply the "global" ones again. I am
> hard-pressed to think of a specification syntax that would make this much
> easier than it already is.
>
> EXERCISES:
>
> 1. Discover a method to turn off the HTML "feature" in your news posting
> software. Use it.
>
> 2. Prove that the method given works for more complex objects and transforms.
>
> 3. (Extra Credit) Write a short paragraph on the properties of a trivial
> bijective mapping between the sets (she's, he's, it's) and (her, his, its)
>
> 4. (Extra Credit) The First Law of Usenet claims that every spelling flame
> will contain at least one misspelled word or factual error. Find one in
> this post.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What you need to do is FIRST translate the object so its position
becomes <1,0,0> and THEN rotate it around the y-axis. (Of course you can
also first rotate and then translate the object using
translate <translation along 'own x-axis'*cos(radians(rotation around
y)),0,translation sin(radians(rotation around y))> (which for 45 deg
would come to <0.71,0,0.71>) but that's a little more complicated.
Julius
http://surf.to/jkhome
United Artists Galleries: http://surf.to/uagalleries
Maybe I am missing something.
If you have an object that is positioned at <0,0,0> and is rotated
45 degrees on the Y axis, then translate it 1 unit on the X axis, won't
it be located at <1,0,0>???
What I was wanting to do is translate that same object (with it's
rotated axis), 1 unit on it's own X axis.
The approximate coordinates would become < 0.71, 0, 0.71> instead
of <1,0,0>
Bob Hughes wrote:
You're hardly an idiot.
"Ronald L. Parker" wrote:
>
> On Wed, 06 Jan 1999 16:56:08 -0800, Tony Vigil
<tvi### [at] emc-inccom>
> wrote:
>
> >Is there any way to do local transformations based on an
object's
> >current scale, position & rotation? (i.e. a translation on
an object's
> >X axis as apposed to the origin's X axis)
> >
> >If there isn't currently a way to do this, is there enough
interest for
> >someone to create a patch?
>
> Maybe I'm an idiot, but if you can't just put the translate
along the
> X axis in before whatever transformation moved it to the new
position,
> how is the software going to know what you thought the X axis
was?
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.htm
=Bob
Post a reply to this message
Attachments:
Download 'iso-8859-1' (3 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 07 Jan 1999 15:42:09 -0800, Tony Vigil <tvi### [at] emc-inccom>
wrote:
>Thank you mucho for your macro.
>
>Hypothetically, what if you needed to do the following:
>
>Create an object at <0,0,0>
>Rotate the object 45 degrees * around the object's Y axis
>Translate the object 1 unit along object's X axis (now at a 45 degree angle)
>Rotate the object -90 degrees * around the object's Y axis
>Translate the object 1 unit along the object's Z axis (now at a -45 degree angle)
>Rotate the object 45 degrees * around the object's Y axis
>
>
>Will your macro place the object at <0,0,0> with 0 rotation on each axis?
Well, the macro only does the inverse of a rotation. It's not a
general solution to anything. But let's try anyway, shall we?
Now, the principle is to do all the local transforms, then all the
global ones. There aren't any global ones, so all we have are the
local ones:
rotate 45*y
// now the object is at 0,0,0 rotated 45 degrees around the Y axis.
translate x
// now at 1,0,0, rotated 45*y
rotate -90*y
// now at 0,0,-1, rotated -45*y
translate z
// now at 0,0,0, rotated -45*y
rotate 45*y
// now at 0,0,0, rotated 0.
Guess it works. But I'm gonna have to modify my earlier statement a
bit: this principle only works if you have a series of global
transformations, followed by a series of local transformations.
Let's prove Exercise 2 from last time for this restricted principle.
First, a note about notation: Transforms whose names start with L are
to be applied locally, and the ones that start with G are to be
applied globally. A symbol of the form LiG will be used to represent
a transform that was originally supposed to have been applied locally,
should now be applied globally, but is in every other respect
identical to the original transform Li. We'll denote the inverse of
G1 as G1', since we don't have any superscripts in plain text.
Suppose you have a sequence of transforms
(G1 G2 ... Gn L1 L2 ... Lm)
It's clear, but again left as an exercise to the reader, that to
perform a single local operation after performing a series of global
operations, you must merely undo all of the global operations, then do
the single local operation, then do the global operations again. Then
we have that Li as a global transform is
(Gn' ... G2' G1') LiG (G1 G2 ... Gn)
So we rewrite with all global transforms:
(G1 G2 ... Gn) (Gn' ... G2' G1') L1G (G1 G2 ... Gn) (Gn' ... G2' G1')
L2G (G1 G2 ... Gn) ... (Gn' ... G2' G1') LmG (G1 G2 ... Gn)
Now you see that the subsequences (G1 G2 ... Gn) (Gn' ... G2' G1')
cancel out, so we are left with L1G L2G ... LmG G1 G2 ... Gn, and all
are global transforms. This is the desired result.
If you have a mixture of global and local transforms in arbitrary
order, you need to be a little more careful. To resolve the sequence
(G1 G2 L1 L2 G3 L3) into all global transforms, we have to do this:
the subsequence (G1 G2 L1 L2) resolves, by the previously stated
principle, to the equivalent sequence of global transforms
(L1G L2G G1 G2). Putting it back into the original sequence, we now
have (L1G L2G G1 G2 G3 L3). Now we have a series of global
transforms, followed by a local transform, so we can reorder and get
(L3G L1G L2G G1 G2 G3). Notice that the formerly local transforms at
the beginning are not in the obvious order. This is important.
EXERCISES
1. Prove that to perform a transform locally, you can undo all of the
global transformations leading up to the current location, then do
the 'local' transform, then redo the global transformations.
2. (Extra Credit) Find out who Thorsten Froelich is. See if you can
determine why everyone's laughing about your telling him to reread
the documentation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 08 Jan 1999 02:02:37 GMT, par### [at] mailfwicom (Ronald L.
Parker) wrote:
>(a bunch of mumbo jumbo that only two people understood)
Whoops, I was wrong on that one. Turns out you have to perform the
local transforms globally IN REVERSE ORDER. So the hypothetical
(G1 G2 ... Gn)(L1 L2 ... Ln) is in fact done properly as
(LnG ... L2G L1G)(G1 G2 ... Gn). I didn't see it because all the
examples have been symmetric. Hope I didn't confuse you with my
mindless prattling. The result is neater, though: you don't have to
worry about which ones are global and which local: just take all the
local ones, in reverse order, then all the global ones, in the
original order, and you're done. Even if you started with
G1 L1 G2 L2.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ronald,
Thank you very much for your in-depth lesson on tranformation sequences! This is
basically what I thought I would have to do, but didn't want to. It would be so much
less convoluted if we could just use local coordinate systems.
Sincerely,
Tony Vigil
P.S. I already know who Thorsten Froelich is since I have read the POV manual - the
entire manual. :-)
Does he know who he is?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ronald L. Parker wrote:
> 2. (Extra Credit) Find out who Thorsten Froelich is. See if you can
> determine why everyone's laughing about your telling him to reread
> the documentation.
Thorsten Froelich - a late 20th century monk creditited with the
abolishment of computer documantion burning. An interesting side
note is that he was an active member of an elite team that developed
advanced visualization software for the masses.
--
Ken Tyler
tyl### [at] pacbellnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 07 Jan 1999 19:16:50 -0800, Tony Vigil <tvi### [at] emc-inccom> wrote:
>Ronald,
>
>Thank you very much for your in-depth lesson on tranformation sequences! This is
>basically what I thought I would have to do, but didn't want to. It would be so much
>less convoluted if we could just use local coordinate systems.
Perhaps. One way to do so, I would think, is to have a set of macros to do
global transformations that has the side-effect of storing the current
transformation matrix into an array. This will require a touch of linear
algebra on the part of the macro writers, though. Then, in addition, have
another set of macros to do local transformations that first transforms by
the inverse of the current matrix, then performs the appropriate local
transformation, then transforms by the current matrix. Finally, these macros
would have to update the current matrix using multiplication from the left.
(i.e. if the matrix is M and the new transform is T, the matrix should be
updated to TM) Note that the way POV's matrices are implemented they are not
square. I think one has to add a fourth column consisting of the transpose
of (0 0 0 1) to make such multiplications work, and ignore that column when
using the matrix to do transformations within POV, but I haven't verified
that.
Of course, as you say, a patch to do this (or at least a patch to retrieve
the current transformation matrix for an object into an array) would be quite
useful. The problem is, not all objects keep the current transformation
matrix as such. If you take an otherwise untransformed sphere, for example,
and scale isotropically, it just adjusts the center and radius appropriately
and leaves the current transformation matrix empty. Rotating or translating
such a sphere only affects the center, again leaving the transformation
matrix empty. So unless you apply a matrix or an anisotropic scale to a
sphere, it has no transformation matrix to retrieve. Changing this might
have a serious impact on rendering time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 07 Jan 1999 19:16:50 -0800, Tony Vigil <tvi### [at] emc-inccom> wrote:
>Ronald,
>
>Thank you very much for your in-depth lesson on tranformation sequences! This is
>basically what I thought I would have to do, but didn't want to. It would be so much
>less convoluted if we could just use local coordinate systems.
One other thing I forgot in my previous followup to this message: make
sure you read my correction. There's an error in my math that affects
most of what I said in that "in-depth lesson."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8 Jan 1999 09:53:08 -0500, Ron Parker <par### [at] my-dejanewscom> wrote:
>On Thu, 07 Jan 1999 19:16:50 -0800, Tony Vigil <tvi### [at] emc-inccom> wrote:
>>Ronald,
>>
>>Thank you very much for your in-depth lesson on tranformation sequences! This is
>>basically what I thought I would have to do, but didn't want to. It would be so
much
>>less convoluted if we could just use local coordinate systems.
>
>Perhaps. One way to do so, I would think, is to have a set of macros to do
>global transformations that has the side-effect of storing the current
>transformation matrix into an array.
...
>Of course, as you say, a patch to do this (or at least a patch to retrieve
>the current transformation matrix for an object into an array) would be quite
>useful.
I just had a great idea that wouldn't require a patch and would be fairly
painless, except that it doesn't work due to what appears to be a bug in
POV-Ray. (It doesn't allow you to put transform identifiers in a transform
declaration unless they're the only thing in the declaration, contrary to
the documentation.)
#macro trans_rotate( trans, rot, islocal )
#declare trans=transform {
#if (islocal) rotate rot #end
transform{trans}
#if (!islocal) rotate rot #end
}
#end
#macro trans_scale( trans, scl, islocal )
#declare trans=transform {
#if (islocal) scale scl #end
transform{trans}
#if (!islocal) scale scl #end
}
#end
#macro trans_translate( trans, tr, islocal )
#declare trans=transform {
#if (islocal) translate tr #end
transform{trans}
#if (!islocal) translate tr #end
}
#end
#declare My_trans=transform{ scale 1 } // identity matrix
trans_rotate( My_trans, 45*y, no ) // global rotate
trans_translate( My_trans, x, yes ) // local translate
...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <369543CF.A44A2BFF@emc-inc.com> , Tony Vigil <tvi### [at] emc-inccom> wrote:
>-45 degrees on the object's Y axis (no translations occuring), then translate 1 unit
>along the object's Z axis. Now what??? The object should be at in it's original
>rotational state of <0,0,0> located at <0.71 , 0 , 0.29> - but it's not.
As this was not in your original post, how could I have known that would want to
several of these in a row.
Well, I don't have complete code for you, but I have something I used/wrote some time
ago that might give you a hint...
Do you know the programming language LOGO or any other language/graphic librbary
implementing a graphic turtle in 2D? Well, here is a simple version as POV-Ray
macros. I wrote it to get a nice handwriting simulation (the drawing turtle is the
ink or the pen) and therefore it is only 2D, but it should be possible to get some
useful macros that do the same in 3D. I added the Turtle_InsertTranslate() macro
which will move any object to the current turtle location.
Oh, and just one question: What exactly do you need the "local transformations" for?
Thorsten
/* ***** Begin Turtle ***** */
#declare gTurtle = array[5]
/* Activate drawing to trace turtle */
#macro Turtle_DrawOn()
#declare gTurtle[4] = 1;
#end
/* Deactivate drawing to trace turtle */
#macro Turtle_DrawOff()
#declare gTurtle[4] = 0;
#end
/* Move to position, set default direction and deactivate drawing */
#macro Turtle_Move(tposx, tposy)
#declare gTurtle[0] = tposx;
#declare gTurtle[1] = tposy;
#declare gTurtle[2] = 1;
#declare gTurtle[3] = 0;
#declare gTurtle[4] = 0;
#end
/* Turn the turtle left */
#macro Turtle_TurnLeft(tdeg)
#local temp = <gTurtle[2], gTurtle[3], 0>;
#local temp = vrotate(temp, <0, 0, -tdeg>);
#declare gTurtle[2] = temp.x;
#declare gTurtle[3] = temp.y;
#if(gTurtle[4])
sphere {
<gTurtle[0], gTurtle[1], 0>, 0.5
pigment { color red 1 }
finish {
ambient 0.2
diffuse 0.7
phong 1
phong_size 80
brilliance 2
}
}
#end
#end
/* Turn the turtle right */
#macro Turtle_TurnRight(tdeg)
#local temp = <gTurtle[2], gTurtle[3], 0>;
#local temp = vrotate(temp, <0, 0, +tdeg>);
#declare gTurtle[2] = temp.x;
#declare gTurtle[3] = temp.y;
#if(gTurtle[4])
sphere {
<gTurtle[0], gTurtle[1], 0>, 0.5
pigment { color red 1 }
finish {
ambient 0.2
diffuse 0.7
phong 1
phong_size 80
brilliance 2
}
}
#end
#end
/* Go forward the specified distance in units */
#macro Turtle_Forward(tlen)
#local temp = <gTurtle[0], gTurtle[1], 0>;
#declare gTurtle[0] = gTurtle[0] + (gTurtle[2] * tlen);
#declare gTurtle[1] = gTurtle[1] + (gTurtle[3] * tlen);
#if(gTurtle[4])
cylinder {
temp, <gTurtle[0], gTurtle[1], 0>, 0.5
pigment { color red 1 }
finish {
ambient 0.2
diffuse 0.7
phong 1
phong_size 80
brilliance 2
}
}
#end
#end
/* Insert a translate <x,y,0> of the current turtle
position to change an objects location */
#macro Turtle_InsertTranslate()
translate <gTurtle[0], gTurtle[1], 0>
#end
/* ***** End Turtle ***** */
camera {
location <0, 0, 20>
right <4/3, 0, 0>
look_at <0, 0, 2>
}
light_source { <0, 0, 50> color rgb 1 }
plane {
z, 0
pigment { color blue 1 }
finish { ambient 0.15 diffuse 0.8 }
}
Turtle_Move(0,0)
Turtle_DrawOn()
Turtle_Forward(2)
Turtle_TurnLeft(60)
Turtle_Forward(2)
Turtle_TurnLeft(60)
Turtle_Forward(2)
Turtle_TurnLeft(60)
Turtle_Forward(1)
sphere {
<0, 0, 0>, 0.7
pigment { color green 1 }
finish {
ambient 0.2
diffuse 0.7
phong 1
phong_size 80
brilliance 2
}
Turtle_InsertTranslate()
}
Turtle_Forward(1)
Turtle_TurnLeft(60)
Turtle_Forward(2)
Turtle_TurnLeft(60)
Turtle_Forward(2)
Turtle_TurnLeft(60)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8 Jan 1999 10:32:17 -0500, I wrote:
> transform{trans}
Whoops, another mistake. Even assuming the documentation were
correct, this is not. The curly braces shouldn't be there.
(It doesn't work right anyway, but I've been told the 3.1b
update will fix it to work as documented. See my bug report
in povray.bugreports if you want to know how to fix it yourself.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
THANK YOU THANK YOU THANK YOU!!!
You are awesome!!!
Thorsten Froehlich wrote:
> In article <369543CF.A44A2BFF@emc-inc.com> , Tony Vigil <tvi### [at] emc-inccom> wrote:
> >-45 degrees on the object's Y axis (no translations occuring), then translate 1
unit
> >along the object's Z axis. Now what??? The object should be at in it's original
> >rotational state of <0,0,0> located at <0.71 , 0 , 0.29> - but it's not.
>
> As this was not in your original post, how could I have known that would want to
> several of these in a row.
> Well, I don't have complete code for you, but I have something I used/wrote some
time
> ago that might give you a hint...
>
> Do you know the programming language LOGO or any other language/graphic librbary
> implementing a graphic turtle in 2D? Well, here is a simple version as POV-Ray
> macros. I wrote it to get a nice handwriting simulation (the drawing turtle is the
> ink or the pen) and therefore it is only 2D, but it should be possible to get some
> useful macros that do the same in 3D. I added the Turtle_InsertTranslate() macro
> which will move any object to the current turtle location.
>
> Oh, and just one question: What exactly do you need the "local transformations" for?
>
> Thorsten
>
> /* ***** Begin Turtle ***** */
>
> #declare gTurtle = array[5]
>
> /* Activate drawing to trace turtle */
> #macro Turtle_DrawOn()
> #declare gTurtle[4] = 1;
> #end
>
> /* Deactivate drawing to trace turtle */
> #macro Turtle_DrawOff()
> #declare gTurtle[4] = 0;
> #end
>
> /* Move to position, set default direction and deactivate drawing */
> #macro Turtle_Move(tposx, tposy)
> #declare gTurtle[0] = tposx;
> #declare gTurtle[1] = tposy;
> #declare gTurtle[2] = 1;
> #declare gTurtle[3] = 0;
> #declare gTurtle[4] = 0;
> #end
>
> /* Turn the turtle left */
> #macro Turtle_TurnLeft(tdeg)
> #local temp = <gTurtle[2], gTurtle[3], 0>;
> #local temp = vrotate(temp, <0, 0, -tdeg>);
> #declare gTurtle[2] = temp.x;
> #declare gTurtle[3] = temp.y;
> #if(gTurtle[4])
> sphere {
> <gTurtle[0], gTurtle[1], 0>, 0.5
> pigment { color red 1 }
> finish {
> ambient 0.2
> diffuse 0.7
> phong 1
> phong_size 80
> brilliance 2
> }
> }
> #end
> #end
>
> /* Turn the turtle right */
> #macro Turtle_TurnRight(tdeg)
> #local temp = <gTurtle[2], gTurtle[3], 0>;
> #local temp = vrotate(temp, <0, 0, +tdeg>);
> #declare gTurtle[2] = temp.x;
> #declare gTurtle[3] = temp.y;
> #if(gTurtle[4])
> sphere {
> <gTurtle[0], gTurtle[1], 0>, 0.5
> pigment { color red 1 }
> finish {
> ambient 0.2
> diffuse 0.7
> phong 1
> phong_size 80
> brilliance 2
> }
> }
> #end
> #end
>
> /* Go forward the specified distance in units */
> #macro Turtle_Forward(tlen)
> #local temp = <gTurtle[0], gTurtle[1], 0>;
> #declare gTurtle[0] = gTurtle[0] + (gTurtle[2] * tlen);
> #declare gTurtle[1] = gTurtle[1] + (gTurtle[3] * tlen);
> #if(gTurtle[4])
> cylinder {
> temp, <gTurtle[0], gTurtle[1], 0>, 0.5
> pigment { color red 1 }
> finish {
> ambient 0.2
> diffuse 0.7
> phong 1
> phong_size 80
> brilliance 2
> }
> }
> #end
> #end
>
> /* Insert a translate <x,y,0> of the current turtle
> position to change an objects location */
> #macro Turtle_InsertTranslate()
> translate <gTurtle[0], gTurtle[1], 0>
> #end
>
> /* ***** End Turtle ***** */
>
> camera {
> location <0, 0, 20>
> right <4/3, 0, 0>
> look_at <0, 0, 2>
> }
>
> light_source { <0, 0, 50> color rgb 1 }
>
> plane {
> z, 0
> pigment { color blue 1 }
> finish { ambient 0.15 diffuse 0.8 }
> }
>
> Turtle_Move(0,0)
>
> Turtle_DrawOn()
>
> Turtle_Forward(2)
> Turtle_TurnLeft(60)
> Turtle_Forward(2)
> Turtle_TurnLeft(60)
> Turtle_Forward(2)
> Turtle_TurnLeft(60)
>
> Turtle_Forward(1)
>
> sphere {
> <0, 0, 0>, 0.7
> pigment { color green 1 }
> finish {
> ambient 0.2
> diffuse 0.7
> phong 1
> phong_size 80
> brilliance 2
> }
> Turtle_InsertTranslate()
> }
>
> Turtle_Forward(1)
>
> Turtle_TurnLeft(60)
> Turtle_Forward(2)
> Turtle_TurnLeft(60)
> Turtle_Forward(2)
> Turtle_TurnLeft(60)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You too are awesome (as is Thorsten)!!!
My apologies to all for my lack of POV understanding & internet
etiquette!
Thanks for all of your help & patience.
Sincerely,
Tony Vigil
Ron Parker wrote:
> On 8 Jan 1999 10:32:17 -0500, I wrote:
>
> > transform{trans}
>
> Whoops, another mistake. Even assuming the documentation were
> correct, this is not. The curly braces shouldn't be there.
> (It doesn't work right anyway, but I've been told the 3.1b
> update will fix it to work as documented. See my bug report
> in povray.bugreports if you want to know how to fix it yourself.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
