Can anyone help me out here?

I'm trying to scale a shape in the z-direction but I want the scaling factor
to be a function of x.
Say for example I have the following cone:

cone {<0,0,0>, 5 <10,0,0>, 20}

And I want to take this shape and scale the such that the left (looking in
from -z) of the cone is scaled by 2*z and the right by 0.5*z so that when
viewed from above (the +y direction) the crosssection is a rectangle with
sides at + and - 10*z.

So far I haven't been able to insert a function into a scale command or a
matrix command.  This may be just a syntax question but I've been unable to
find my answer in the documentation.  I'd like to be able to do something
like:

 scale <1,1, -0.15*x+2>

Thanks if you can point me in the correct direction,
Carl

Post a reply to this message

Only linear transformations are possible with transformation matrices
(scales, rotates and translates are just shortcuts to equivalent
transformation matrices).
  What you are trying to achieve is a non-linear transformation which
is not possible with matrices.

  The way to go is most probably to create the cone as an isosurface
and then modify the input variables of the isosurface function
appropriately.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3fc409da@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Only linear transformations are possible with transformation matrices
> (scales, rotates and translates are just shortcuts to equivalent
> transformation matrices).
>   What you are trying to achieve is a non-linear transformation which
> is not possible with matrices.

A small terminology correction: the transformations POV-Ray can handle 
are affine transforms. Rotate, scale, and shear are linear transforms, 
translation is an affine transform. All linear transforms are affine 
transforms. You're right in that what he's trying to accomplish is a 
non-linear transform.

To go into more detail, linear transforms have the property that 
transforming two points and adding them together gives the same result 
as adding them together and then transforming that point. Affine 
transforms such as those used by POV do not necessarily have this 
property, though they must preserve collinearity (all points on a 
straight line must transform to points on a straight line). In the case 
of POV, they must also be invertible, you will get an error about a 
"singular matrix" otherwise.


>   The way to go is most probably to create the cone as an isosurface
> and then modify the input variables of the isosurface function
> appropriately.

Or just create the transformed version directly. Don't try to transform 
a cylinder into a cone, just create a cone. To bend a tube, use a little 
CSG. Or make a mesh and deform it, which is likely to be faster than an 
isosurface, but will have problems with typical mesh artifacts like 
faceting and polygonal edges.

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

Wasn't it Warp who wrote:
>  Only linear transformations are possible with transformation matrices
>(scales, rotates and translates are just shortcuts to equivalent
>transformation matrices).
>  What you are trying to achieve is a non-linear transformation which
>is not possible with matrices.
>
>  The way to go is most probably to create the cone as an isosurface
>and then modify the input variables of the isosurface function
>appropriately.

There's an example of a non-linearly scaled sphere in my isosurface
tutorial:

<http://www.econym.demon.co.uk/isotut/substitute.htm#nls>



-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Thanks.  I'm glad it wasn't just me fighting a syntax problem though if it
had I guess that would have been the easiest to fix.

I've only been playing with POV-Ray now for about 2 months and as
yet haven't got to the point of playing with isosurfaces.  I guess its time
to learn.

If someone beats me to the bunch... what I'm trying now to find is the
equation I need to use for an isosurface that looks like:

(y/a1)^2+(z/b1)^2=1   in the x=0 plane

and

(y/a2)^2+(z/b2)^2=1   in the x=x0 plane

For my cases b1=b2 but I guess I should write this as general as possible.

I think the "contained_by" should be:

box {<0,+(max(a1,a2)),+(max(b1,b2))>,
        <x0,-(max(a1,a2)),-(max(b1,b2))>}

I'm not so sure about the threshold, accuracy, or max_gradient but I
think I'll get an idea once I start playing.

Thanks...
Carl

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3fc409da@news.povray.org...
>   Only linear transformations are possible with transformation matrices
> (scales, rotates and translates are just shortcuts to equivalent
> transformation matrices).
>   What you are trying to achieve is a non-linear transformation which
> is not possible with matrices.
>
>   The way to go is most probably to create the cone as an isosurface
> and then modify the input variables of the isosurface function
> appropriately.
>
> -- 
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb
M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  -
Warp -

Post a reply to this message

> To go into more detail, linear transforms have the property that
> transforming two points and adding them together gives the same result
> as adding them together and then transforming that point. Affine
> transforms such as those used by POV do not necessarily have this
> property, though they must preserve collinearity (all points on a
> straight line must transform to points on a straight line). In the case
> of POV, they must also be invertible, you will get an error about a
> "singular matrix" otherwise.

I think what I'm trying to do would keep all strait lines as strait lines
after the transformation.  Although lines that were parallel before the
transformation might not be after.  I also think it should be invertible
as long as the point where the z scaling factor becomes zero is
outside the object.

> Or just create the transformed version directly. Don't try to transform
> a cylinder into a cone, just create a cone.

Well what I'm after isn't a cylinder or a cone, though it might be easier
to transform a cylinder into the shape I'm after then a cone come to
think of it.

> To bend a tube, use a little CSG.

I'm not trying to bend a tube either.  You know how a cone can be
used to connect two spheres to make a shape like you'd get with a
linear sphere_sweep.  I'm trying to connect these two spheres with a
similar shape.

sphere {<0,0,0>,a1 scale <1,1,b1/a1>}
sphere {<x0,0,0>a2 scale <1,1,b2/a2>}

Does that make it any clearer what I'm trying to do?

> Or make a mesh and deform it, which is likely to be faster than an
> isosurface, but will have problems with typical mesh artifacts like
> faceting and polygonal edges.

I haven't got around to playing with meshs either and as I don't want
to deal with the artifacts you mention I think I'll continue to work on
the isosurface approach.

Thanks...
Carl

Post a reply to this message

Thanks... I need all the tutorials I can find.  However yours
leaves me a little confused...

In your example you have:

#declare  P = function {x*x + y + z*z - 1}

isosurface {
  function { P(x,y*(1.05-y/5),z) }
  ...

Should P be the formula of a sphere?  In which case shouldn't
the function be x*x+y*y+z*z-1?  If that's not a typo I'm really
confused.  Hmmm... ok after looking closer I see you are substituting
in a y*y term for y when you call the function.  But that leaves me
wondering why you only scaled one of the y's?  I'm now curious how
that differes from:

#declare  P = function {x*x + y*y + z*z - 1}

isosurface {
  function { P(x,(1.05-y/5),z) }
  ...

I'll try it and find out.

Also... a more general question...

Is there a difference between these two as used in an isosurface?

#declare  P = function {x*x + y*y + z*z - 1}
isosurface {
  function { P(x,y,z) }
  threshold 0

and

#declare  P = function {x*x + y*y + z*z}
isosurface {
  function { P(x,y,z) }
  threshold 1

Thanks,
Carl



"Mike Williams" <nos### [at] econymdemoncouk> wrote in message
news:FsgJnBAGpCx$EwP7@econym.demon.co.uk...
> Wasn't it Warp who wrote:
> >  Only linear transformations are possible with transformation matrices
> >(scales, rotates and translates are just shortcuts to equivalent
> >transformation matrices).
> >  What you are trying to achieve is a non-linear transformation which
> >is not possible with matrices.
> >
> >  The way to go is most probably to create the cone as an isosurface
> >and then modify the input variables of the isosurface function
> >appropriately.
>
> There's an example of a non-linearly scaled sphere in my isosurface
> tutorial:
>
> <http://www.econym.demon.co.uk/isotut/substitute.htm#nls>
>
>
>
> -- 
> Mike Williams
> Gentleman of Leisure

Post a reply to this message

Wasn't it Carl Hoff who wrote:
>Thanks... I need all the tutorials I can find.  However yours
>leaves me a little confused...
>
>In your example you have:
>
>#declare  P = function {x*x + y + z*z - 1}
>
>isosurface {
>  function { P(x,y*(1.05-y/5),z) }
>  ...
>
>Should P be the formula of a sphere?  In which case shouldn't
>the function be x*x+y*y+z*z-1?  If that's not a typo I'm really
>confused.

Yes it's a typo. it should be y*y


>Also... a more general question...
>
>Is there a difference between these two as used in an isosurface?
>
>#declare  P = function {x*x + y*y + z*z - 1}
>isosurface {
>  function { P(x,y,z) }
>  threshold 0
>
>and
>
>#declare  P = function {x*x + y*y + z*z}
>isosurface {
>  function { P(x,y,z) }
>  threshold 1

There's no difference. Since I have a mathematical background I'm more
used to dealing with thinking about the first form.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wasn't it Carl Hoff who wrote:
>Thanks.  I'm glad it wasn't just me fighting a syntax problem though if it
>had I guess that would have been the easiest to fix.
>
>I've only been playing with POV-Ray now for about 2 months and as
>yet haven't got to the point of playing with isosurfaces.  I guess its time
>to learn.
>
>If someone beats me to the bunch... what I'm trying now to find is the
>equation I need to use for an isosurface that looks like:
>
>(y/a1)^2+(z/b1)^2=1   in the x=0 plane
>
>and
>
>(y/a2)^2+(z/b2)^2=1   in the x=x0 plane
>


#declare aa=max(a1,a2);
#declare bb=max(b1,b2);
isosurface {
  function {    
      pow((y/(a1+(a2-a1)*x/x0)),2)
     +pow((z/(b1+(b2-b1)*x/x0)),2)
     -1 
  }
  max_gradient 2.8
  contained_by{box{<0,-aa,-bb><x0,aa,bb>}}
}

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Carl Hoff <hof### [at] wtnet> wrote:
> I think what I'm trying to do would keep all strait lines as strait lines
> after the transformation.  Although lines that were parallel before the
> transformation might not be after.

  Nope. If parallel lines do not keep parallel after the transformation,
then there exist lines which do not keep straight after the transformation.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <3fc50a5c@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> Carl Hoff <hof### [at] wtnet> wrote:
> > I think what I'm trying to do would keep all strait lines as strait lines
> > after the transformation.  Although lines that were parallel before the
> > transformation might not be after.
> 
>   Nope. If parallel lines do not keep parallel after the transformation,
> then there exist lines which do not keep straight after the transformation.

Actually, they can remain straight with a transformation that makes 
parallel lines non-parallel...scale two axii by the value of the third, 
flipping everything around at the origin. It wouldn't be an affine 
transform though, it would not be invertible (a singularity at a plane 
going through the origin where all points transform to < 0, 0, 0>), and 
it can not be expressed as a matrix.

-- 
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 <3fc4e32c@news.povray.org>, "Carl Hoff" <hof### [at] wtnet> wrote:

> I think what I'm trying to do would keep all strait lines as strait lines
> after the transformation. 

That isn't the only constraint...


> Although lines that were parallel before the
> transformation might not be after. 

That is another constraint. Parallel lines must transform to parallel 
lines.


> I also think it should be invertible
> as long as the point where the z scaling factor becomes zero is
> outside the object.

It doesn't work that way...the transform has a singularity, which makes 
it non-invertible.


> > To bend a tube, use a little CSG.
> 
> I'm not trying to bend a tube either. 

Well, those were just examples of commonly desired transformations that 
are not possible.


> You know how a cone can be
> used to connect two spheres to make a shape like you'd get with a
> linear sphere_sweep.  I'm trying to connect these two spheres with a
> similar shape.
> 
> sphere {<0,0,0>,a1 scale <1,1,b1/a1>}
> sphere {<x0,0,0>a2 scale <1,1,b2/a2>}
> 
> Does that make it any clearer what I'm trying to do?

It sounds like you are looking for a supercone shape. Look in shapes.inc 
for a macro for creating these..though you may have a hard time fitting 
it to the capping ellipsoids. This transformation can not be done 
directly in POV, you have to use either an isosurface, process a mesh, 
or do it with CSG and existing primitives. The transformations possible 
in POV are scaling (including reflection), rotation, translation, 
shearing, and combinations of these.

http://mathworld.wolfram.com/AffineTransformation.html

-- 
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 <3fc4e81f@news.povray.org>, "Carl Hoff" <hof### [at] wtnet> wrote:

> #declare  P = function {x*x + y + z*z - 1}
> 
> isosurface {
>   function { P(x,y*(1.05-y/5),z) }
>   ...
> 
> Should P be the formula of a sphere?  In which case shouldn't
> the function be x*x+y*y+z*z-1?  If that's not a typo I'm really
> confused.  Hmmm... ok after looking closer I see you are substituting
> in a y*y term for y when you call the function.  But that leaves me
> wondering why you only scaled one of the y's?

That would expand to:
x*x + y*1.05 + y*y/5 + z*z - 1

Change the order to make what happens a little clearer:

x*x + y*y/5 + z*z - 1 + y*1.05

This is scaling the sphere along the y axis, and adjusting the radius 
according to distance along the y axis.


> Is there a difference between these two as used in an isosurface?

No difference. However, I find it easier to adjust things when the 
threshold is 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

Christopher James Huff <cja### [at] earthlinknet> wrote:
> The transformations possible 
> in POV are scaling (including reflection), rotation, translation, 
> shearing, and combinations of these.

  Actually any shearing can be nade as a combination of rotations and
(uneven) scales, so technically it's not an independent transformation
in itself... :)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <3fc5593f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > The transformations possible 
> > in POV are scaling (including reflection), rotation, translation, 
> > shearing, and combinations of these.
> 
>   Actually any shearing can be nade as a combination of rotations and
> (uneven) scales, so technically it's not an independent transformation
> in itself... :)

True, but is is rather different conceptually, which is why I usually 
mention it as a "fourth" transformation. These are just conventions, a 
human categorization. You could say a rotation is just a reorientation, 
or that they are all just matrix multiplications...

BTW, in linear algebra, the transformations are often broken down as: 
contract (scale by a value < 1), dilate or expand (scale by value > 1), 
reflect (scale by -1 on an axis), rotate and translate.

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

> > You know how a cone can be
> > used to connect two spheres to make a shape like you'd get with a
> > linear sphere_sweep.  I'm trying to connect these two spheres with a
> > similar shape.
> >
> > sphere {<0,0,0>,a1 scale <1,1,b1/a1>}
> > sphere {<x0,0,0>a2 scale <1,1,b2/a2>}
> >
> > Does that make it any clearer what I'm trying to do?
>
> It sounds like you are looking for a supercone shape. Look in shapes.inc
> for a macro for creating these..though you may have a hard time fitting
> it to the capping ellipsoids. This transformation can not be done
> directly in POV, you have to use either an isosurface, process a mesh,
> or do it with CSG and existing primitives.

Thanks everyone.  After spending most of a day with this.  Thanks to
the help from Mike, I was able to create the isosurface I asked for,
which as Christopher points out above is (I believe) the same shape
you can get using a supercone.  Where most of the time was spent
however was tring to make the shape join smoothly with the capping
ellipsoids.  In the end I gave up and opted to move away from using
ellipsoids to using a torus filled in with a cylinder.  Two of these shapes
I could easily join smoothly with two cylinders and a prism.

By the way... thanks to pointing me to the shapes.inc file.  I see its
got this:

 Connect_Spheres(PtA, RadiusA, PtB, RadiusB).

It makes the work I spent to write this macro now look a little
silly:

  #macro sphere2fill(V1,R1,V2,R2)
    #local V2a = V2-V1;
    #local angle_z1 = VRotationD(<V2a.x, V2a.y, 0>, x, z);
    #local V2b = vaxis_rotate(V2a, z, angle_z1);
    #local angle_y2 = VRotationD(<V2b.x, 0, V2b.z>, x, y);
    #local V2c = vaxis_rotate(V2b, y, angle_y2);
    #local theta = asin((R1-R2)/V2c.x);

    cone {
      <R1*sin(theta), 0, 0>, R1*cos(theta)
      <V2c.x+R2*sin(theta), 0, 0>, R2*cos(theta)
      rotate -y*angle_y2
      rotate -z*angle_z1
      translate V1
    }
  #end

As a way to say thank you here is another macro that I wrote that
smoothy fills in the space between 3 spheres when used with 3
sphere and 3 sphere2fill calls.  In other words it doesn't draw the
cones or the spheres.

  #macro sphere3fill(V1,R1,V2,R2,V3,R3)
    #local V2a = V2-V1;
    #local V3a = V3-V1;
    #local angle_z1 = VRotationD(<V2a.x, V2a.y, 0>, x, z);
    #local V2b = vaxis_rotate(V2a, z, angle_z1);
    #local V3b = vaxis_rotate(V3a, z, angle_z1);
    #local angle_y2 = VRotationD(<V2b.x, 0, V2b.z>, x, y);
    #local V2c = vaxis_rotate(V2b, y, angle_y2);
    #local V3c = vaxis_rotate(V3b, y, angle_y2);
    #local angle_x3 = VRotationD(<0, V3c.y, V3c.z>, -z, x);
    #local angle_x3p = VRotationD(<0, V3c.y, V3c.z>, z, x);
    #local V2d = vaxis_rotate(V2c, x, angle_x3);
    #local V3d = vaxis_rotate(V3c, x, angle_x3);
    #local V2dp = vaxis_rotate(V2c, x, angle_x3p);
    #local V3dp = vaxis_rotate(V3c, x, angle_x3p);
    #local angle_z5 = degrees(asin((R1-R2)/V2c.x));
    #local angle_x4 = degrees(asin(((((R2-R1)/(V2d.x))*V3d.x+R1)
        -(R3))/(V3d.z*cos(radians(angle_z5)))));
    #local V2e = vaxis_rotate(V2d, x, angle_x4);
    #local V3e = vaxis_rotate(V3d, x, angle_x4);
    #local V2ep = vaxis_rotate(V2dp, -x, angle_x4);
    #local V3ep = vaxis_rotate(V3dp, -x, angle_x4);
    #local V2f = vaxis_rotate(V2e, -z, angle_z5);
    #local V3f = vaxis_rotate(V3e, -z, angle_z5);
    #local V2fp = vaxis_rotate(V2ep, -z, angle_z5);
    #local V3fp = vaxis_rotate(V3ep, -z, angle_z5);
    #local minD = 2*min(R1,R2,R3);

    #local fill1 = prism {
      linear_spline linear_sweep -R1,-R1+minD,4
      <0,0>, <V2f.x,V2f.z>, <V3f.x,V3f.z>, <0,0>
    }

    #local fill2 = prism {
      linear_spline linear_sweep -R1,-R1+minD,4
      <0,0>, <V2fp.x,V2fp.z>, <V3fp.x,V3fp.z>, <0,0>
    }

    merge {
      object {fill1
        rotate z*angle_z5
        rotate -x*angle_x4
        rotate -x*angle_x3
      }
      object {fill2
        rotate z*angle_z5
        rotate x*angle_x4
        rotate -x*angle_x3p
      }
      rotate -y*angle_y2
      rotate -z*angle_z1
      translate V1
    }
  #end

Note the walls are as only as thick as the diameter of the
smallest sphere so this shape might be hollow.  Does anyone
know how to do the above without the hollow space?

And one last question about the ellipsoids problem.  I'm
convinced that the shape that smoothly joins two ellipsoids
is NOT a supercone as the shape doesn't intersect the
ellipsoids in a plane.  And even if I cut the super cone so
that it touches the ellipsoid at <0,0,0> in the x-y plane at
some non-zero x value smoothly and it also touches the
ellipsoid in the x-z plane smoothly at x=0 if both ellipsoids
have the same z extent, then those turned out to be the
only points of contact between the two surfaces.  So...
knowing that I have no idea how to find the isosurface that
would meet my needs.  Does anyone know how the
sphere_sweep call works?  Would it be possible to write
something like an ellipsoid_sweep?  If so I'm sure its way
over my head but maybe its something someone here will
want to play with.

Thanks again everyone,
Carl

Post a reply to this message

Wasn't it Carl Hoff who wrote:
>> > You know how a cone can be
>> > used to connect two spheres to make a shape like you'd get with a
>> > linear sphere_sweep.  I'm trying to connect these two spheres with a
>> > similar shape.
>> >
>> > sphere {<0,0,0>,a1 scale <1,1,b1/a1>}
>> > sphere {<x0,0,0>a2 scale <1,1,b2/a2>}
>> >
>> > Does that make it any clearer what I'm trying to do?
>>
>> It sounds like you are looking for a supercone shape. Look in shapes.inc
>> for a macro for creating these..though you may have a hard time fitting
>> it to the capping ellipsoids. This transformation can not be done
>> directly in POV, you have to use either an isosurface, process a mesh,
>> or do it with CSG and existing primitives.
>
>Thanks everyone.  After spending most of a day with this.  Thanks to
>the help from Mike, I was able to create the isosurface I asked for,
>which as Christopher points out above is (I believe) the same shape
>you can get using a supercone.  Where most of the time was spent
>however was tring to make the shape join smoothly with the capping
>ellipsoids.

That's odd. The isosurface I posted does join smoothly with the two
capping ellipsoids shown above. All you have to do is use the same
values for a1, a2, b1, b2 and x0.


-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Mike Williams" <nos### [at] econymdemoncouk> wrote in message
> That's odd. The isosurface I posted does join smoothly with the two
> capping ellipsoids shown above. All you have to do is use the same
> values for a1, a2, b1, b2 and x0.

Well I said I gave up.  I must not have as I woke up this morning with
another idea stuck in my head.  Seems I do my best problem solving
while I'm not trying to problem solve.  Anyways... I'm now half way
there.  Try out this code.  It joins two ellipsoids with TWO Supercones
and it joins up with the larger ellipsoid perfectly.  However at the
end of the smaller ellipsoid the shape still ends up inside the ellipsoid
at all but 4 points.  I have one other idea that I want to try but without
doing it I'm not sure if its not mathmatically equivalent to what I just did
here.

Enjoy,
Carl

  #include "colors.inc"
  #include "math.inc"
  #include "transforms.inc"
  #include "shapes.inc"

  #macro zellipsoid2fill(V1,R1,V2,R2,R3)

    // V1 = center of sphere1
    // R1 = radius of sphere1
    // V2 = center of sphere2 NOTE: must be in the same z plane as sphere1
    // R2 = radius of sphere2
    // R3 = the new radius of both ellipsoids in the z direction

    #local V2a = V2-V1;
    #local angle_z1 = VRotationD(<V2a.x, V2a.y, 0>, x, z);
    #local V2b = vaxis_rotate(V2a, z, angle_z1);
    #local theta = degrees(asin((R1-R2)/V2b.x));
    #local V2c = vaxis_rotate(V2b, z, theta);
    #local maxyR = max(R1,R2);
    #local maxx = max(V2b.x+R2*sin(radians(theta)),V2b.x);
    #local minx = min(R1*sin(radians(theta)),0);
    #local shearx1 = <V2c.x, V2c.y, 0>/V2b.x;
    #local shearx2 = <V2c.x, -V2c.y, 0>/V2b.x;

    #local shape1 = object{Supercone(<0,0,0>, R3, R1, <V2b.x, 0, 0>, R3,
R2)}

    #local shape2 = intersection {
      object { shape1 Shear_Trans(shearx1,y,z) rotate -z*theta}
      box {<minx, 0, -R3>,<maxx,maxyR,R3>}
    }

    #local shape3 = intersection {
      object { shape1 Shear_Trans(shearx2,y,z) rotate z*theta}
      box {<minx, 0, -R3>,<maxx,-maxyR,R3>}
    }

    merge {
      object {shape2}
      object {shape3}
      rotate -z*angle_z1
      translate V1
    }
  #end

  declare center1 = <0,0,0>;
  declare radius1 = 50;
  declare center2 = <70,30,0>;
  declare radius2 = 20;

  declare maxz = 10;

  sphere{center1,radius1 scale<1,1,maxz/radius1> pigment{Red}}
  sphere{center2,radius2 scale<1,1,maxz/radius2> pigment{Green}}

  declare center = (center1+center2)/2;

  light_source {center-900*x-100*z White}
  light_source {center-900*y-100*z White}
  light_source {center+900*x+900*y-100*z White}
  camera {location center-500*z look_at center angle 27}

  object {zellipsoid2fill(center1,radius1,center2,radius2,maxz)
pigment{Blue}}

Post a reply to this message

> I have one other idea that I want to try but without
> doing it I'm not sure if its not mathmatically equivalent
> to what I just did
> here.

The other idea WAS mathematically equivalent.  :...(

Anyways... I posted a picture over in the images area.  I 'think'
I'm going to try and give up on this idea again but we'll see if
my mind will let it go.  If anyone wants to try and solve this
particular problem please let me know if you have any success.

Thanks again for all the help guys,
Carl

Post a reply to this message

In article <3fc7a2fe$1@news.povray.org>, "Carl Hoff" <hof### [at] wtnet> 
wrote:

> Anyways... I posted a picture over in the images area.  I 'think'
> I'm going to try and give up on this idea again but we'll see if
> my mind will let it go.  If anyone wants to try and solve this
> particular problem please let me know if you have any success.

Well, one easy way to do what you want is to make several hundred 
ellipsoids spread along the axis of your shape, linearly changing from 
one shape to the next. This takes quite a few spheres to make a smooth 
shape, and has some obvious inefficiencies, but is quite feasible...in 
fact, it was a common way of creating swept shapes before the 
sphere_sweep primitive. You can optimize it further by clipping of the 
inner spheres and heiarchial bounding. (Split the object in half, put 
each half in a nested union. Split each half in half, again putting the 
two halves in unions. Repeat...you end up with a heirarchial structure 
which removes most of the shapes from consideration early on in 
intersection testing.)

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

> Well, one easy way to do what you want is to make several hundred
> ellipsoids spread along the axis of your shape, linearly changing from
> one shape to the next. This takes quite a few spheres to make a smooth
> shape, and has some obvious inefficiencies, but is quite feasible...in
> fact, it was a common way of creating swept shapes before the
> sphere_sweep primitive.

I'd thought of that but was afraid it'd be too inefficient.

> You can optimize it further by clipping of the
> inner spheres and heiarchial bounding. (Split the object in half, put
> each half in a nested union. Split each half in half, again putting the
> two halves in unions. Repeat...you end up with a heirarchial structure
> which removes most of the shapes from consideration early on in
> intersection testing.)

Ok... I'm very very new at RAY-Tracing and I'm not sure I
could follow that.  Are you saying built the object up my only
every taking the union of two shapes at a time.  Start by taking
the union of two ellipsoids.  Then taking the union of two of
those shapes and so on?  I don't know enough about how POV-Ray
works to see how that removes any of the shapes as each shape
will still form a part of the surface of the final shape.  Should merge
be used as I know it removes all the interior surfaces?  But I'm
still not sure why a merge of a merge would be faster then a
single merge.  I assume I'm missing something and my guess is
that its experience.  Would it be possible for you to post a
small piece of code that uses this "heiarchial bounding" so I
could study it and maybe get a better understanding of what
you are talking about?

Thanks,
Carl

Post a reply to this message

In article <3fc8bf38@news.povray.org>, "Carl Hoff" <hof### [at] wtnet> wrote:

> Ok... I'm very very new at RAY-Tracing and I'm not sure I
> could follow that.  Are you saying built the object up my only
> every taking the union of two shapes at a time.  Start by taking
> the union of two ellipsoids.  Then taking the union of two of
> those shapes and so on? 

Say you have 16 spheres in a line. o's are spheres, {} braces represent 
unions:
{{{{o o} {o o}} {{o o} {o o}}} {{{o o} {o o}} {{o o} {o o}}}}

Now, say you have a ray that will eventually hit the fifth sphere. The 
first bounding box test sees the bounds for the outermost union:
{                                                           }

Which it hits. The contents of that union are tested, and the next hit 
is this one:
{{                           }                              }

This eliminates half the spheres from consideration with one step. To 
continue:
{{              {           }}                              }
{{              {{   }      }}                              }
{{              {{o  }      }}                              }

Each step halves the number of remaining spheres. Note that you need to 
manually bound the unions used for this, or POV-Ray will just split it 
up and use its own automatic bounding scheme.


> Should merge be used as I know it removes all the interior surfaces? 

If the object is transparent, merge should be used, the overhead of 
removing internal surfaces is compensated for by not having to do 
texturing and lighting for those surfaces. If it is not transparent, the 
merge will be slower.

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