I guess I'm just having difficulty understanding how to achieve predictable
results with a conically swept prism object in my scene.  I specifically
want the object to have the "ziggurat" type flattened top.  Given such a
prism declaration, (lifted almost wholecloth out of the docs)
  prism {
    conic_sweep
    linear_spline
    0.85, // height 1
    1, // height 2
    5, // the number of points making up the shape...
    <4,4>,<-4,4>,<-4,-4>,<4,-4>,<4,4>,
    rotate <180, 0, 0>  //(yes, I get this part)
    translate <0, X?, 0>
    scale <1, 4, 1>
    pigment { gradient y scale .2 }
  }

How much should the object get translated downward for its base to be at
y=0? And would scaling the object along y affect where its base lay?

Post a reply to this message

Wasn't it LibraryMan who wrote:
>I guess I'm just having difficulty understanding how to achieve predictable
>results with a conically swept prism object in my scene.  I specifically
>want the object to have the "ziggurat" type flattened top.  Given such a
>prism declaration, (lifted almost wholecloth out of the docs)
>  prism {
>    conic_sweep
>    linear_spline
>    0.85, // height 1
>    1, // height 2
>    5, // the number of points making up the shape...
>    <4,4>,<-4,4>,<-4,-4>,<4,-4>,<4,4>,
>    rotate <180, 0, 0>  //(yes, I get this part)
>    translate <0, X?, 0>
>    scale <1, 4, 1>
>    pigment { gradient y scale .2 }
>  }
>
>How much should the object get translated downward for its base to be at
>y=0? And would scaling the object along y affect where its base lay?

If you can't work it out, yo could try using trace() to find the
position of the base and then translating it by that amount in the
opposite direction.

#declare Thing =
  prism {
    conic_sweep
    linear_spline
    0.85, // height 1
    1, // height 2
    5, // the number of points making up the shape...
    <4,4>,<-4,4>,<-4,-4>,<4,-4>,<4,4>
    rotate <180, 0, 0>  //(yes, I get this part)
    scale <1, 4, 1>
    pigment { gradient y scale .2 }
  }
  
object {Thing translate -trace (Thing, <0,-100,0>, <0,1,0>)}


In this case, the distance to translate downwards is equal to the Y
coefficient of the scale. So for a scaling of <1,4,1> you translate by
<0,-4,0>.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Mike Williams" <mik### [at] econymdemoncouk> wrote in message
news:XZ6Z4EABqP1+Ewa### [at] econymdemoncouk...
> Wasn't it LibraryMan who wrote:
> >
> >How much should the object get translated downward for its base to be at
> >y=0? And would scaling the object along y affect where its base lay?
>
> If you can't work it out, you could try using trace()

Good idea. However, this is a problem about transformation order.

By putting translate before scale is making -0.85*y move by four times, so
what's needed is the common scale, rotate, translate ordering to keep that
from happening. Doing so makes it like this: "height 2" is at 1*y (the
ever-widening conic sweep shape's top, starting from a point at 0 regardless
of "height 1"), becoming 4*y next, then turned upside down to become -4*y,
and finally moved upward by 4*y.

  prism {
    conic_sweep
    linear_spline
    .85, // height 1
    1, // height 2 [is +y*1 here]
    5, // the number of points making up the shape...
    <4,4>,<-4,4>,<-4,-4>,<4,-4>,<4,4>
    scale <1, 4, 1> // will move height 2 by this multiple
    rotate <180, 0, 0> // upside-down
    translate <0, 4, 0> // final move to 0*y
    pigment { gradient y scale .201 }
  }

Please notice that the pigment scaling here is to circumvent pattern/surface
alignments, since it would have created unwanted artifacts where the object
and pattern are equally positioned. Reason in this case: 4 times 0.15 equals
0.6, making exactly 3 repeats of the gradient.

Curious thing about this though is that I had thought all such patterns were
changed to shift them slightly to stop this from happening. I know the
'checker ' pattern was, anyway. Oh well, something to think about again.

Bob H.

Post a reply to this message

Mike Williams wrote:
>If you can't work it out, yo could try using trace() ...

Sounds interesting;  when I tried to search the index of the Windows Help on
it, I found references to Max_Trace_Level, and general ray tracing stuff,
but not where this particular command/function/macro/whatever is documented
in more depth.  A pointer, please?  Thanks

Post a reply to this message

LibraryMan wrote:
>Mike Williams wrote:
>>If you can't work it out, yo could try using trace() ...
>
>Sounds interesting;  when I tried to search the index of the Windows Help on
>it, I found references to Max_Trace_Level, and general ray tracing stuff,
>but not where this particular command/function/macro/whatever is documented
>in more depth.  A pointer, please?  Thanks
>

Never mind, found it! Thanks.

Post a reply to this message