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