I was just playing with media and stuff and figured I'd try the
following scene, but got an error in the warp due to the rotation and
ended up having to move the warp around by hand (sin's and cos's).  Is
there a good reason why warps (particularly black_hole warps) can't work
the way I was trying?

sphere {
  0, 1
  pigment {
    colour rgbf 1
  }
  interior {
    media {
      emission 1
      density {
        agate
        colour_map {
          [0.0 colour 0]
          [0.5 colour 0]
          [1.0 colour 1]
        }
        warp {
          black_hole
          0.5, 0.3
          rotate y*360*clock
        }
      }
    }
  }
  hollow
}

The error I get is "No matching } in warp, rotate found instead."

The idea was to have some sort of hazy cloud with a distortion moving
through it.  I eventually got rid of the rotation and replaced the
position with 0.5*<cos(2*pi*clock), 0, sin(2*pi*clock)> in order to get
the black_hole warp moving around the way I had intended.  I'm still
waiting for the animation to finish tracing, but I didn't get an error
during the parse. 

Anyway, I though that since you're defining the warp pretty much the
same way you would define a sphere, you should be able to transform it
in the same sort of way.  But, apparently not.

This is with 3.1e on windows NT.  I haven't tried it on my regular Linux
computer yet, so maybe it would have worked there.

-- 
  Carl Bartels   |  Spammers make things so much more complicated.
McGill University|  email: There's a see and a bee and I can be found
  Montreal, QC   |  at bravo436 dot chem dot mcgill dot ca.  Or, can
     cAnAdA      |  the a and the five from the reply address.

Post a reply to this message

On Sat, 24 Apr 1999 16:22:54 -0400, Carl Bartels
<cab### [at] bravo436chemmcgillca> wrote:

>I was just playing with media and stuff and figured I'd try the
>following scene, but got an error in the warp due to the rotation and
>ended up having to move the warp around by hand (sin's and cos's).  Is
>there a good reason why warps (particularly black_hole warps) can't work
>the way I was trying?

The main reason is that, in general, a warp IS a transformation of a
very specific sort.  Applying a transformation to a transformation
doesn't always make sense.  However, since it is a transformation, 
you know it will always be applied in order with all the other 
transformations, so you can do something like this:

plane {-z,0 
  pigment {
    checker color rgb 1, color red 1
    rotate -z*360*clock
    warp { black_hole x, 2 strength 2 }
    rotate z*360*clock
  }
}

Post a reply to this message

"Ronald L. Parker" wrote:
> 
> On Sat, 24 Apr 1999 16:22:54 -0400, Carl Bartels
> <cab### [at] bravo436chemmcgillca> wrote:
> 
> >I was just playing with media and stuff and figured I'd try the
> >following scene, but got an error in the warp due to the rotation and
> >ended up having to move the warp around by hand (sin's and cos's).  Is
> >there a good reason why warps (particularly black_hole warps) can't work
> >the way I was trying?
> 
> The main reason is that, in general, a warp IS a transformation of a
> very specific sort.  Applying a transformation to a transformation
> doesn't always make sense.  However, since it is a transformation,
> you know it will always be applied in order with all the other
> transformations, so you can do something like this:
> 
> plane {-z,0
>   pigment {
>     checker color rgb 1, color red 1
>     rotate -z*360*clock
>     warp { black_hole x, 2 strength 2 }
>     rotate z*360*clock
>   }
> }

Alternatively,

plane {-z,0
  pigment {
    checker color rgb 1, color red 1
    warp { black_hole vrotate(x, z*360*clock), 2 strength 2 }
  }
}

Just my musing,
	Mike Andrews.

Post a reply to this message

On Mon, 26 Apr 1999 14:12:41 +0100, Michael Andrews wrote:
>
>
>"Ronald L. Parker" wrote:
>> plane {-z,0
>>   pigment {
>>     checker color rgb 1, color red 1
>>     rotate -z*360*clock
>>     warp { black_hole x, 2 strength 2 }
>>     rotate z*360*clock
>>   }
>> }
>
>Alternatively,
>
>plane {-z,0
>  pigment {
>    checker color rgb 1, color red 1
>    warp { black_hole vrotate(x, z*360*clock), 2 strength 2 }
>  }
>}

The difference is that while black_hole has a location parameter, the same 
cannot be said for every type of warp.  For example, how would you rotate
or translate a turbulence or repeat warp?

Post a reply to this message

Ron Parker wrote:
> The difference is that while black_hole has a location parameter, the same
> cannot be said for every type of warp.  For example, how would you rotate
> or translate a turbulence or repeat warp?

Hmm, absolutely true.
In fact I do usually do it the way you suggested - I was just feeling
contrary :-)
Here's a snippet from some code I'm currently working on to produce
clouds:

density { 
	spherical
	scale scaleVal
	warp { turbulence turbVal octaves 5 lambda 3 omega 1/3 }
	scale cloudHSize
	colour_map { [0 rgb 0][mapVal rgb 1] }
}

It uses scale rather than rotate, but the ideology is the same.

	Bye for now,
		Mike Andrews.

Post a reply to this message

I know this is an old thread, but:

    Mathematically, there are at least two "natural" ways to consider
transforming a warp. One is by composition:

                f(W) = f o W  [do W to whatever you are acting on, then do
f]

this is already available by doing one warp, then another.

    The other is by conjugation - call this f*:

                f*(W) = f o W o f-inverse  [do the inverse of f then do W
then do f]

    This has nice properties, for instance

                f*(W)(fX) = f(WX) = f(W)(X).

However, you can always get

                f(W)(X)

directly. While it might be useful to be able to compute f*(W)(Y) for Y not
equal to fX for any known X, there's a problem: warps may be uninvertible.

    Rotation, translation, and almost all scalings are invertible. For
these, conjugation can be written as a macro if anybody needs to. (But
carefully: rotate -Vector does not in general undo rotate Vector)

    The black hole warp is probably invertable in theory, but perhaps not in
POV - I'm not sure if its inverse is a black hole warp as well or not. The
repeat warp may be invertible or not depending on the relationship between
the two vectors that define it; if it is, another repeat warp can invert it.
The turbulence warp is *not* invertible in general - it can make some of the
original pattern vanish completely. Below a certain strength this won't
happen.
    Even when it's 1-1, POV won't invert it. (Something I've never tried -
if POV takes its usual "an it harm none, do what ye will" philosophy, it
should be possible to give a negative turbulence strength and get an
approximate inverse; as the size goes to 0, the error should go to 0
quadratically.)

    An interesting thought: is there any nice *fast* noise function with an
inverse that is also a nice fast noise function? That would allow a warp to
be conjugated with turbulence.  An obvious point is that if the fractal
nature of the noise were achieved by composing simple warps at different
octaves, the inverse would compose the octaves in the opposite order.

    -Robert Dawson

Post a reply to this message