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