I have a situation where I am defining a set of points relative to <0,0,0>
then rotating them into the final position. In a later step, I need to know
where one of these points has ended up (so I can use it with the "Connect"
macro).

So I think I want something like

    #declare newPlace = DoSomething( <Ax,Ay,Az>, <Dx,Dy,Dz>);

where the 'D' values are in degrees.

Can I somehow do this with vaxis_rotate? If so, how do I convert the
<Dx,Dy,Dz> to a rotation vector (vaxis_rotate's "B" parameter) and the
degrees of rotation (the "F" parameter)?  Since I'm always working from the
origin and can use an arbitrary orientation with the initial construction, I
should, I think, be able to set things up for a simple special case usage--
but I don't really know any trig any more, and I can't visualize the
problem.

Is there another approach that would be easier? Do I just need vrotate(A,B)?

I am so confused. Somebody please pat me on the head and point me in the
right direction.


[BTW, knowing that I needed a vector answer did make it a lot easier to
search the help files for possibly useful functions. To my mind, this has
justified the current organization of that material]


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

"Will W" <wil### [at] NOSPAMwizzardsnet> wrote in message
news:3e5e7330@news.povray.org...
> I have a situation where I am defining a set of points relative to <0,0,0>
> then rotating them into the final position. In a later step, I need to know
> where one of these points has ended up (so I can use it with the "Connect"
> macro).
>

<snip>

As far as I understand it, I think you need the 'vtransform' function from
'transforms.inc'.

Here is a sample scene that returns the new position to the #debug stream:

#declare S1= sphere{0,0.1 pigment{rgb 1}}
#declare T1= <2,0,0>;
#declare R1= <0,-45,0>;

object{S1 translate T1 rotate R1}

#include "transforms.inc"
#declare NewPos = vtransform(T1, transform{rotate R1});

#debug concat("New Pos: ", vstr(3, NewPos, ",", 0, 5), "\n")

Post a reply to this message

Thanks for this pointer! I haven't looked at any of the transforms.inc
material yet.

 I had thought that in scanning the manual's section on functions that
return point vectors, I had done a comprehensive search of everything that
might be of use in this situation. I hadn't realized that I was skipping
right by all the wealth that is kept in macros-- silly me.

So documentation on functions is organized by return type, which is nice.
But documentation on macros included in the v3.5 package are organized by...
the arbitrary name of the include file? I hope that doesn't sound snide. I
really appreciate all the effort that has gone into making POVRay and
documenting it. But I think I'm detecting an opportunity for improvement.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net


"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3e5f32c8@news.povray.org...
>
> "Will W" <wil### [at] NOSPAMwizzardsnet> wrote in message
> news:3e5e7330@news.povray.org...
> > I have a situation where I am defining a set of points relative to
<0,0,0>
> > then rotating them into the final position. In a later step, I need to
know
> > where one of these points has ended up (so I can use it with the
"Connect"
> > macro).
> >
>
> <snip>
>
> As far as I understand it, I think you need the 'vtransform' function from
> 'transforms.inc'.
>
> Here is a sample scene that returns the new position to the #debug stream:
>
> #declare S1= sphere{0,0.1 pigment{rgb 1}}
> #declare T1= <2,0,0>;
> #declare R1= <0,-45,0>;
>
> object{S1 translate T1 rotate R1}
>
> #include "transforms.inc"
> #declare NewPos = vtransform(T1, transform{rotate R1});
>
> #debug concat("New Pos: ", vstr(3, NewPos, ",", 0, 5), "\n")
>
>

Post a reply to this message

"Will W" <wil### [at] NOSPAMwizzardsnet> wrote in message
news:3e5fae9a@news.povray.org...

> So documentation on functions is organized by return type, which is nice.
> But documentation on macros included in the v3.5 package are organized
by...
> the arbitrary name of the include file? I hope that doesn't sound snide. I

No, you don't sound snide - all I can say is that you get used to the docs,
and while not perfect and sometimes unintuitive, they are logical (and
probably better than the online docs. available with many commercial
products).

And until you get used to them, there are these groups. ;)

Post a reply to this message

In article <3e5fae9a@news.povray.org>,
 "Will W" <wil### [at] NOSPAMwizzardsnet> wrote:

> So documentation on functions is organized by return type, which is nice.
> But documentation on macros included in the v3.5 package are organized by...
> the arbitrary name of the include file? I hope that doesn't sound snide. I
> really appreciate all the effort that has gone into making POVRay and
> documenting it. But I think I'm detecting an opportunity for improvement.

The names of the include files are not arbitrary. shapes.inc contains 
macros for dealing with shapes, rand.inc for random numbers, math.inc 
for math stuff, and so on.
Organizing by file wouldn't be very logical if things were just evenly 
spread around, but the files themselves are organized by purpose. If you 
want transformation macros, transforms.inc is the obvious place to look.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...

<snip>

The thing with the docs is that they logical, but the logic still has to be
learnt. In the end, it's neither a criticism of new users or of the docs,
just a comment on the process.

For example, the solution I gave involves vtransform from transforms.inc,
but Will was trying to work something out with  vaxis_rotate - it would be
hard for Will to intuit that vaxis_rotate was a built in function, and that
vaxis_rotate was an include. I wouldn't know off-hand, and would have to
check both sections, but the difference would be that I would know to check
both.

Post a reply to this message

In article <3e5fd86e@news.povray.org>,
 "Tom & Lu Melly" <all### [at] tomandlucouk> wrote:

> For example, the solution I gave involves vtransform from transforms.inc,
> but Will was trying to work something out with  vaxis_rotate - it would be
> hard for Will to intuit that vaxis_rotate was a built in function, and that
> vaxis_rotate was an include. I wouldn't know off-hand, and would have to
> check both sections, but the difference would be that I would know to check
> both.

Well, if he found vaxis_rotate() by looking through the documentation, 
vrotate() would be near by. There's no hint that vtransform() exists 
though, it might be a good idea to merge the documentation of built-in 
functions and the include files. A big reason for the layout of the 
include file documentation is that it was written separately from the 
manual, much later and by different people than those who did the 
function documentation, going file by file, and then grafted into the 
main documentation by yet another group of people. It's useful for 
finding out how to use something you know is in the include files, but 
you still have to read it or the include files to find out it exists.

The search feature helps, but only if you know what you're looking for. 
My best suggestion is to read through the entire manual. Not necessarily 
study it in depth, but page through it and get an idea for what is 
there. Some things can be hard to find even if you know exactly what to 
look for, but this helps a lot for most things.

The documentation does need a lot of reworking and reorganization, I was 
just pointing out that the include file names are not arbitrary. The 
additions in 3.5 were carefully thought out, and went through several 
possible organizations before reaching the one that was released. The 
others...well, there's a lot of crud that was only useful in earlier 
versions of POV, left over for backwards compatiblity, but it's pretty 
well arranged for the most part.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Thanks, again, everybody. Both for the specific help, and for the discussion
about how to use the docs and why they are the way they are. That, too, is
very helpful.

Slowly the world of POV is beginning to make more sense. In the mean time,
I'm very appreciative of the newbie support.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

"Tom & Lu Melly" <all### [at] tomandlucouk> wrote in message
news:3e5fd86e@news.povray.org...

> hard for Will to intuit that vaxis_rotate was a built in function, and
that
> vaxis_rotate was an include.

Uh... well, you knew what I meant.

Post a reply to this message