Hi,
I'm trying to do a prism with a dodecagon (? -- anyway, polygon with 12
equal sides ) face and instead of trying to figure out the exact vectors
of the points, I wanted to do something like specifying every 4th
vector, then rotating the in-betweens around the y-axis, like this:

#declare v_01 =  <0.5, 0> ;  
#declare v_02 =  <0.5, 0> rotate y*30 ;
#declare v_03 =  <0.5, 0> rotate y*60 ;
#declare v_04 =  <0, -0.5> ;
#declare v_05 =  <0, -0.5> rotate y*30 ;
#declare v_06 =  <0, -0.5> rotate y*60 ;
#declare v_07 =  <-0.5, 0> ;
#declare v_08 =  <-0.5, 0> rotate y*30 ;
#declare v_09 =  <-0.5, 0> rotate y*60 ;
#declare v_10 =  <0, 0.5> ;
#declare v_11 =  <0, 0.5> rotate y*30 ;
#declare v_12 =  <0, 0.5> rotate y*60 ;


prism {
linear_sweep
linear_spline
0, // sweep the following shape from here ...
1, // ... up through here
13, // the number of points making up the shape ...
v_01, , v_03, v_04, v_05, v_06, v_07, v_08, v_09, v_10, v_11, v_12, v_1
pigment { Green }
}


Of course I'm getting errors, else I wouldn't be posting, but I'm sure
the basic concept I'm thinking of is 'do-able' but what am I missing?

Thanks!
"LibraryMan"

Post a reply to this message

"LibraryMan" <mrm### [at] attnet> wrote in message
news:3DCFC48B.4893CC95@att.net...
> I'm trying to do a prism with a dodecagon (? -- anyway, polygon with 12
> equal sides ) face and instead of trying to figure out the exact vectors
> of the points, I wanted to do something like specifying every 4th
> vector, then rotating the in-betweens around the y-axis, like this:
>
> #declare v_01 =  <0.5, 0> ;
> #declare v_02 =  <0.5, 0> rotate y*30 ;

A prism for a dodecahedron? Not sure you could ever get that shape from a
single prism object.  Anyway, your syntax trouble is with the rotates. Can't
declare those in along with a vector.

There's a predefined Dodecahedron in Shapes2.inc which is made of rotated
intersecting planes.

P.S.

This brings up something I almost forgot about, Dave Dunn had noticed the
Shapes2.inc doesn't call for Shapes_old.inc so that a Cone_Y can be used in
the HalfCone_Y object. And the Shapes2.inc file is not included into
Shapes.inc although Shapes_old.inc is. To correct matters you need to add it
to Shapes.inc like this:

#include "shapes_old.inc"  // this is already there
#include "shapes2.inc"  // this line needed after the old shapes file

Post a reply to this message

LibraryMan wrote:
> 
> Hi,
> I'm trying to do a prism with a dodecagon (? -- anyway, polygon with 12
> equal sides ) face and instead of trying to figure out the exact vectors
> of the points, I wanted to do something like specifying every 4th
> vector, then rotating the in-betweens around the y-axis, like this:
> 
> #declare v_01 =  <0.5, 0> ;
> #declare v_02 =  <0.5, 0> rotate y*30 ;
> [...]

Bob's suggestion is surely the best for your purpose but
rotating/transforming vectors can be done with
'vrotate()'/'vtransform()'.    See the documentation for details.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 02 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

hughes, b. wrote:

> A prism for a dodecahedron? 

I think he meant a (extruded) regular 12-sided polygon. Don't know if it 
has an "official" name, but his guess, "dodecagon", sounds logical to me...

Post a reply to this message

Correct, that is what I meant. :-)  "Dodeca-" I took to mean the prefix
for twelve, and "gon" I thought would be the suffix for a multi-sided
geometric shape.
-MW

Johannes Dahlstrom wrote:
> 
> hughes, b. wrote:
> 
> > A prism for a dodecahedron?
> 
> I think he meant a (extruded) regular 12-sided polygon. Don't know if it
> has an "official" name, but his guess, "dodecagon", sounds logical to me...

Post a reply to this message

The number of sides to the extruded shape is not as much the matter as
is the question of how to rotate vectors of a given distance from the
origin (in XZ plane) around the y-axis.  Looks like this 'vrotate' is
worth a look.  Let me go study some...  Unless of course one of you
decides to GIVE me the answer... ;-)

--LibraryMan

Christoph Hormann wrote:
> 
> LibraryMan wrote:
> >
> > Hi,
> > I'm trying to do a prism with a dodecagon (? -- anyway, polygon with 12
> > equal sides ) face and instead of trying to figure out the exact vectors
> > of the points, I wanted to do something like specifying every 4th
> > vector, then rotating the in-betweens around the y-axis, like this:
> >
> > #declare v_01 =  <0.5, 0> ;
> > #declare v_02 =  <0.5, 0> rotate y*30 ;
> > [...]
> 
> Bob's suggestion is surely the best for your purpose but
> rotating/transforming vectors can be done with
> 'vrotate()'/'vtransform()'.    See the documentation for details.
> 
> Christoph
> 
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 02 Nov. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

"LibraryMan" <mrm### [at] attnet> wrote in message
news:3DCFEC0E.9C09C925@att.net...
> The number of sides to the extruded shape is not as much the matter as
> is the question of how to rotate vectors of a given distance from the
> origin (in XZ plane) around the y-axis.  Looks like this 'vrotate' is
> worth a look.  Let me go study some...  Unless of course one of you
> decides to GIVE me the answer... ;-)

I don't think anything written up for POV so far does something with the uv
kind of vectors such as prism uses. Checking out vrotate for that here got
me nowhere even though I tried to use the dot operator in an attempt to
limit the usual 3 float vectors to two floats but POV will not allow it into
the prism.

I had a feeling you knew a prism wasn't going to do a dodecahedron but I
didn't catch on about the dodecagon name and jumped ahead that you were
confused about the prism. My fault, sorry.

If anyone tells of a way to work with the uv vector, as described above, I'm
all ears too.

Post a reply to this message

BTW, what are uv vectors (RANK newbie here!)

Wow, it's hard to believe something simple enough for _ME_ to come up
with it isn't actually possible 
to do!!  I mean, in principle it ought to work, right?  POV's SDL can do
so many other things (that I sure DON'T understand! ;-)  )

I was allowed to declare the following vectors, no problem, :
#declare v_01 =  <0.5, 0, 0>;
#declare v_02 =  vrotate(<0.5, 0, 0>,y*30);
#declare v_03 =  vrotate(<0.5, 0, 0>,y*60);
#declare v_04 =  <0, 0, -0.5>;
#declare v_05 =  vrotate(<0, 0, -0.5>,y*30);
#declare v_06 =  vrotate (<0, 0, -0.5>,y*60);
#declare v_07 =  <-0.5, 0, 0>;
#declare v_08 =  vrotate(<-0.5, 0, 0>,y*30);
#declare v_09 =  vrotate(<-0.5, 0, 0>,y*60);
#declare v_10 =  <0, 0, 0.5>;
#declare v_11 =  vrotate(<0, 0, 0.5>,y*30);
#declare v_12 =  vrotate(<0, 0, 0.5>,y*60);

But when it came to actually using them in the prism, like so:

prism {
linear_sweep
linear_spline
0,
1,
13,
v_01, v_02, v_03, v_04, v_05, v_06, v_07, v_08, v_09, v_10, v_11, v_12,
v_01
pigment { Green }
}

POV choked on it!  AARRGGGH!  It's SO simple!  Why isn't it possible?!
--Mark


"hughes, b." wrote:
>
> I don't think anything written up for POV so far does something with the uv
> kind of vectors such as prism uses. Checking out vrotate for that here got
> me nowhere even though I tried to use the dot operator in an attempt to
> limit the usual 3 float vectors to two floats but POV will not allow it into
> the prism.
> 
> I had a feeling you knew a prism wasn't going to do a dodecahedron but I
> didn't catch on about the dodecagon name and jumped ahead that you were
> confused about the prism. My fault, sorry.
> 
> If anyone tells of a way to work with the uv vector, as described above, I'm
> all ears too.

Post a reply to this message

I quote from section 4.1.4 of the manual for POV v3.1g:  
"A vector is a set of related float values. Vectors may be specified
using literals, identifiers or functions which return vector values. You
may also create very complex vector
expressions from combinations of any of these using various familiar
operators."

I _SHOULD_ be able to use the identifiers as vectors in the prism
statement, shouldn't I?  If not, the above is a LIE!

Anyone?  (Bueller?...)
--Mark

"hughes, b." wrote:
> 
> "LibraryMan" <mrm### [at] attnet> wrote in message
> news:3DCFEC0E.9C09C925@att.net...
> > The number of sides to the extruded shape is not as much the matter as
> > is the question of how to rotate vectors of a given distance from the
> > origin (in XZ plane) around the y-axis.  Looks like this 'vrotate' is
> > worth a look.  Let me go study some...  Unless of course one of you
> > decides to GIVE me the answer... ;-)
> 
> I don't think anything written up for POV so far does something with the uv
> kind of vectors such as prism uses. Checking out vrotate for that here got
> me nowhere even though I tried to use the dot operator in an attempt to
> limit the usual 3 float vectors to two floats but POV will not allow it into
> the prism.
> 
> I had a feeling you knew a prism wasn't going to do a dodecahedron but I
> didn't catch on about the dodecagon name and jumped ahead that you were
> confused about the prism. My fault, sorry.
> 
> If anyone tells of a way to work with the uv vector, as described above, I'm
> all ears too.

Post a reply to this message

LibraryMan wrote:
> 
> I quote from section 4.1.4 of the manual for POV v3.1g:

This corresponds to section 6.1.4 of the POV 3.5 help (for Win).

Post a reply to this message

In article <3DD0220B.1B5F76C3@att.net>, LibraryMan <mrm### [at] attnet> 
wrote:

> POV choked on it!  AARRGGGH!  It's SO simple!  Why isn't it possible?!

It is possible, POV just choked because you gave it bad information. It 
is expecting a 2D vector in this case, you gave it a 3D vector. I'm not 
really sure what it would do in this case, either chop off the third 
component or give an error. Either way, it would not work...the third 
component is one you need. If you replace each "v_XX" with "< v_XX.x, 
v_XX.z>" it should work fine. If POV truncates 3D vectors to 2D ones, 
you just need to use coordinates in the xy plane and rotate around the z 
axis. I know that seems counterintuitive when the prism is in the xz 
plane.

Here are a couple macros that might be useful:

This macro truncates a vector to 2D, only useful if POV doesn't do it 
automatically:
#macro V2D(V) (<V.x, V.y>) #end
You would need to rearrange your vectors to be in the xy plane to use 
this macro. Or use this version:
#macro V_XZ(V) (<V.x, V.z>) #end

Another one, takes a 2D vector and angle to rotate it around the z axis:
#macro VRotate2D(V, A)
    #local Tmp = vrotate(V, z*A);
    (< Tmp.x, Tmp.y>)
#end

And if you are trying to get a perfect dodecagon, you are doing it the 
hard way...you could just use a loop:

#macro RegularPrism(Sides
    prism {linear_sweep linear_spline
        #local J = 0;
        #while(J < Sides)
            VRotate2D(<1, 0>, 360*J/12)
            #declare J = J + 1;
        #end
    }
#end

object {RegularPrism(12)
    pigment {color Green}
}

-- 
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

I did get it accepting the 2D vectors, as Chris had shown by forcing them
within the prism. I kept getting a 3D (or 4D or 5D?) when predeclaring even
with dot operators.

No dodecahedron (yet), so I leave that up to you to try and figure out.
Especially since I'm not sure what I'm doing with it. Chris's loop idea
sounds simpler but I couldn't get it to make one by rotating just the x
value, not with the loop he suggested though.

#declare v_01 =  <0.5, 0>;
#declare v_02 =  vrotate(<0.5, 0>,30*y);
#declare v_03 =  vrotate(<0.5, 0>,60*y);
#declare v_04 =  <0, -0.5>;
#declare v_05 =  vrotate(<0, -0.5>,30*y);
#declare v_06 =  vrotate(<0, -0.5>,60*y);
#declare v_07 =  <-0.5, 0>;
#declare v_08 =  vrotate(<-0.5, 0>,30*y);
#declare v_09 =  vrotate(<-0.5, 0>,60*y);
#declare v_10 =  <0, 0.5>;
#declare v_11 =  vrotate(<0, 0.5>,30*y);
#declare v_12 =  vrotate(<0, 0.5>,60*y);

prism {
linear_sweep
linear_spline
0, // sweep the following shape from here ...
1, // ... up through here
13, // the number of points making up the shape ...
<v_01.x,v_01.y>, <v_02.x,v_02.y>, <v_03.x,v_03.y>, <v_04.x,v_04.y>,
<v_05.x,v_05.y>, <v_06.x,v_06.y>, <v_07.x,v_07.y>,
 <v_08.x,v_08.y>, <v_09.x,v_09.y>, <v_10.x,v_10.y>, <v_11.x,v_11.y>,
<v_12.x,v_12.y>, <v_01.x,v_01.y>
pigment { color rgb <0,1,0> }
 rotate -90*x // face camera
}

camera {
 location -4*z
 look_at 0
}

light_source {
 <10,10,-10>,<1,0.5,1>
}
light_source {
 <-10,-10,-10>,<0.5,1,0.5>
}

Post a reply to this message

In article <3dd05985@news.povray.org>,
 "hughes, b." <omn### [at] charternet> wrote:

> No dodecahedron (yet), so I leave that up to you to try and figure out.

There's one in the include files.


> Especially since I'm not sure what I'm doing with it. Chris's loop idea
> sounds simpler but I couldn't get it to make one by rotating just the x
> value, not with the loop he suggested though.

The main problem was not with the loop, but with the prism statement, I 
didn't give a complete one. My excuse? I've never used the object 
before... ;-)
There was also a typo that would have made it work only with 12 sides, 
but that doesn't seem to be what you ran into.
I'm not sure what you mean by "rotating just the x value", unless you 
mean x as in < 1, 0, 0>.
This seems to work fine, with shorter code, and supporting any number of 
sides.

global_settings {assumed_gamma 1}

#declare CamPos = <-3, 2.5,-8>;
camera {
    location CamPos
    look_at < 0, 0, 0>
    angle 45
}

light_source {<-50,-50,-50>, color rgb 1}
light_source {CamPos, color rgb 0.05}

#macro VRotate2D(V, A)
    #local Tmp = vrotate(V, z*A);
    (< Tmp.x, Tmp.y>)
#end

#macro RegularPrism(Height1, Height2, Sides)
    prism {linear_sweep linear_spline
        Height1, Height2, Sides
        #local J = 0;
        #while(J < Sides)
            VRotate2D(x, 360*J/Sides)
            #local J = J + 1;
        #end
    }
#end

object {RegularPrism(0, 1, 12)
    pigment {color rgb 1}
    finish {ambient 0}
    rotate -x*45
}

-- 
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

On Mon, 11 Nov 2002 11:52:28 -0500, Johannes Dahlstrom quoth:

> hughes, b. wrote:
> 
>> A prism for a dodecahedron?
> 
> I think he meant a (extruded) regular 12-sided polygon. Don't know if it
> has an "official" name, but his guess, "dodecagon", sounds logical to
> me...
 
Yes, the name is "dodecagon".  Specifically, he wants a "right
dodecagonal prism".

-- 
Mark

Post a reply to this message

"LibraryMan" <mrm### [at] attnet> wrote in message news:3DC### [at] attnet...
> Correct, that is what I meant. :-)  "Dodeca-" I took to mean the prefix
> for twelve, and "gon" I thought would be the suffix for a multi-sided
> geometric shape.
> -MW
>
> Johannes Dahlstrom wrote:
> >
> > hughes, b. wrote:
> >
> > > A prism for a dodecahedron?
> >

www.tomandlu.co.uk/webres/misc/dodecahedron.wav

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3dd05985@news.povray.org>,
>  "hughes, b." <omn### [at] charternet> wrote:
>
> > No dodecahedron (yet), so I leave that up to you to try and figure out.
>
> There's one in the include files.

Yes, I pointed that out before myself.  :-)

> > Especially since I'm not sure what I'm doing with it. Chris's loop idea
> > sounds simpler but I couldn't get it to make one by rotating just the x
> > value, not with the loop he suggested though.
>
> The main problem was not with the loop, but with the prism statement, I
> didn't give a complete one. My excuse? I've never used the object
> before... ;-)
> There was also a typo that would have made it work only with 12 sides,
> but that doesn't seem to be what you ran into.
> I'm not sure what you mean by "rotating just the x value", unless you
> mean x as in < 1, 0, 0>.
> This seems to work fine, with shorter code, and supporting any number of
> sides.

Yeah, that is great. Glad to see it can work that way, so thanks for
expanding on that scene script for it.

You misunderstood what I was saying, typing as I would speak there. I just
meant I hadn't even tried the loop and only did the prism like:

#declare v_01 =  <1, 0>;
#declare v_02 =  vrotate(<1, 0>,30*y);
#declare v_03 =  vrotate(<1, 0>,60*y);
...
#declare v_12 =  vrotate(<1, 0>,330*y);

which is the loop without the loop, I guess you could say, and got nothing
right from that. My mistake is apparently that I kept it using y instead of
z. I was *that* close! Oh well. Not my dodecagon anyway.  ;-)

Bob H.

Post a reply to this message

Christopher James Huff wrote:
> 

> And if you are trying to get a perfect dodecagon, you are doing it the
> hard way...

Well, I haven't gotten around to learning to use/write macros yet;  I
suspect much of the scene I'm working on could be done in more efficient
ways, coding-wise, but I'm just not up to reinventing that wheel yet...
;-)

--Library Man

Post a reply to this message

Christopher James Huff wrote:
> If you replace each "v_XX" with "< v_XX.x,
> v_XX.z>" it should work fine. 

It does, indeed!! Many thanks to all, even the ones who thought I was
trying to do a dodecaHEDRON! ;-)

--Mark ("LibraryMan")

Post a reply to this message

Christopher James Huff wrote:
> 

> 
> It is possible, POV just choked because you gave it bad information. It
> is expecting a 2D vector in this case, you gave it a 3D vector. I'm not
> really sure what it would do in this case, either chop off the third
> component or give an error. Either way, it would not work...the third
> component is one you need. If you replace each "v_XX" with "< v_XX.x,
> v_XX.z>" it should work fine. If POV truncates 3D vectors to 2D ones,
> you just need to use coordinates in the xy plane and rotate around the z
> axis. I know that seems counterintuitive when the prism is in the xz
> plane.


Just a point of info I'd like to clarify (or maybe I shouldn't open this
can of worms):

If I had declared only 2D vectors like so:
#declare v_01 = <0.5, 0>;  ... (rather than the 3D I used)

then would these be uv vectors, and would I be able to specify them in
the prism (or polygon, or conic sweep, or whatever) by using  [...]
<v_01.u, v_02.v>, <v_02.u, v_02.v>, etc. ?

I shouldn't get nit-picky, after all, what you specified using .x and .z
worked just fine.  I merely wanted to
see if I was understanding the manual correctly about uv vectors...

Thanks!
--Mark

Post a reply to this message

In article <3DD13CF9.CA8287AE@att.net>, LibraryMan <mrm### [at] attnet> 
wrote:

> Just a point of info I'd like to clarify (or maybe I shouldn't open this
> can of worms):
> 
> If I had declared only 2D vectors like so:
> #declare v_01 = <0.5, 0>;  ... (rather than the 3D I used)

I think this is the main problem...POV doesn't seem to support declared 
2D vectors, it seems to promote them to 3D. A language oddity that 
probably isn't worth fixing in 3.5, something to watch out for in 4.0.

-- 
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

In article <3DD1354B.28FB473B@att.net>, LibraryMan <mrm### [at] attnet> 
wrote:

> Well, I haven't gotten around to learning to use/write macros yet;  I
> suspect much of the scene I'm working on could be done in more efficient
> ways, coding-wise, but I'm just not up to reinventing that wheel yet...
> ;-)

No need to reinvent any wheels, I posted a working version in another 
message.

-- 
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 wrote:
> 
> In article <3DD13CF9.CA8287AE@att.net>, LibraryMan <mrm### [at] attnet>
> wrote:
> 
> > Just a point of info I'd like to clarify (or maybe I shouldn't open this
> > can of worms):
> >
> > If I had declared only 2D vectors like so:
> > #declare v_01 = <0.5, 0>;  ... (rather than the 3D I used)
> 
> I think this is the main problem...POV doesn't seem to support declared
> 2D vectors, it seems to promote them to 3D. A language oddity that
> probably isn't worth fixing in 3.5, something to watch out for in 4.0.

Actually it was an intentional design decision. By design the program
presumes the user was brain damaged at the time he wrote the 2D vector
and corrects if for him rather than stopping and issuing an error message.
Microsoft calls such behavior "user friendly" :)

Should it be fixed, and if so in what way? There are only a couple of
places where a 2D vector statement is useful while there are dozens of
places where a 3D vector is mandatory. I think the current behavior
is useful and would support its continued use if asked to vote on it.

-- 
Ken Tyler

Post a reply to this message

In article <3DD1B253.575E6908@pacbell.net>, Ken <tyl### [at] pacbellnet> 
wrote:

> Should it be fixed, and if so in what way? There are only a couple of
> places where a 2D vector statement is useful while there are dozens of
> places where a 3D vector is mandatory.

Simple:
Assigning to a vector results in a vector of the same size as the 
original. If the "source" is too small, it is extended with 0's. (except 
for scalars, where every component of the resulting vector gets set to 
the scalar's value) If it is too big, it is truncated.
If something needs a 3D vector, it gets one, whether you give it a 
scalar, a 2D vector, or a 10D vector. If something needs a 2D vector, it 
gets one. The same for scalars, 4D vectors, 5D vectors...maybe POV could 
be changed to handle any size vectors, though some functions would still 
require specific sizes.

#declare scalar = 1; //scalar is a scalar value, one float
#declare vect2d = < 0, 0>; //vect2d is a 2D vector
#declare vect3d = < 0, 0, 0>; //vect3d is a 3D vector

scalar = < 1, 2> results in 1.
scalar = < 1, 2, 3> results in 1.

vect2d = < 1, 2, 3> results in < 1, 2>, maybe giving a warning.
vect3d = < 1, 2> results in < 1, 2, 0>.

vect2d = 3.14 results in < 3.14, 3.14>.
vect3d = 3.14 results in < 3.14, 3.14, 3.14>.

This is what I think anyone would expect from reading the existing 
documentation, and what seems most useful.


> I think the current behavior is useful and would support its 
> continued use if asked to vote on it.

What would you use the current behavior for? It seems unexpected that 
declaring a 2D vector results in a 3D vector, it requires workarounds to 
get the desired result, and I can't think of any time you would actually 
want it.

-- 
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