Hi,

I'm trying to create a shape called a "lemon"
(http://mathworld.wolfram.com/Lemon.html) using POV-Ray, but am
encountering problems.
I need it to have a well-defined inside, so simply clipping a spindle torus
won't work.
Also, I'm unsure about the exactness when using a lathe or SOR object.

Does anyone have any suggestions?

Post a reply to this message

"Shark" <nomail@nomail> wrote in message 
news:web.441a893b5fb92620b6fe43de0@news.povray.org...
> Hi,
>
> I'm trying to create a shape called a "lemon"
> (http://mathworld.wolfram.com/Lemon.html) using POV-Ray, but am
> encountering problems.
> I need it to have a well-defined inside, so simply clipping a spindle 
> torus
> won't work.
> Also, I'm unsure about the exactness when using a lathe or SOR object.
>
> Does anyone have any suggestions?
>
>

How about one of these:

camera {location <0,0,-2.5> look_at 0}
light_source {<10,20,-100>,1}

difference {
  sphere {0,1.0}
  torus {1,1.414}
  pigment {color rgb <0,1,1>}
  translate -x/2
}

intersection {
  torus {1,1.414 inverse}
  sphere {0,1.0}
  pigment {color rgb <1,1,0>}
  translate x/2
}

Regards,
Chris.

Post a reply to this message

Wasn't it Shark who wrote:
>Hi,
>
>I'm trying to create a shape called a "lemon"
>(http://mathworld.wolfram.com/Lemon.html) using POV-Ray, but am
>encountering problems.
>I need it to have a well-defined inside, so simply clipping a spindle torus
>won't work.
>Also, I'm unsure about the exactness when using a lathe or SOR object.
>
>Does anyone have any suggestions?

Try this:

#declare r1 = 0.6;
#declare r2 = 1.0;                        
#declare  F = function {x*x + y*y - r2*r2}

isosurface {
  function { F(sqrt(x*x+z*z)+r1, y, z) }
  max_gradient 3.1
  contained_by{sphere{0,r2}}
  pigment {rgb <1,1,0>}
}

max_gradient will need tweaking for different values of r1 and r2.
-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

news:web.441a893b5fb92620b6fe43de0@news.povray.org...
> Hi,
>
> I'm trying to create a shape called a "lemon"
> (http://mathworld.wolfram.com/Lemon.html) using POV-Ray, but am
> encountering problems.
> I need it to have a well-defined inside, so simply clipping a spindle
torus
> won't work.
Even if you put it inside-out with "inverse"?


Marc

Post a reply to this message

"Mike Williams" <nos### [at] econymdemoncouk> wrote in message 
news:hdq74DAPgqGEFw+p### [at] econymdemoncouk...
> Wasn't it Shark who wrote:
>>Hi,
>>
>>I'm trying to create a shape called a "lemon"
>>(http://mathworld.wolfram.com/Lemon.html) using POV-Ray, but am
>>encountering problems.
>>I need it to have a well-defined inside, so simply clipping a spindle 
>>torus
>>won't work.
>>Also, I'm unsure about the exactness when using a lathe or SOR object.
>>
>>Does anyone have any suggestions?
>
> Try this:
>
> #declare r1 = 0.6;
> #declare r2 = 1.0;
> #declare  F = function {x*x + y*y - r2*r2}
>
> isosurface {
>  function { F(sqrt(x*x+z*z)+r1, y, z) }
>  max_gradient 3.1
>  contained_by{sphere{0,r2}}
>  pigment {rgb <1,1,0>}
> }
>
> max_gradient will need tweaking for different values of r1 and r2.
> -- 
> Mike Williams
> Gentleman of Leisure

Interestingly on rendering the three solutions side-by-side I see that 
Mike's solution is the only one that gets lit correctly.
I'm not sure why this should be. I've adjusted the light in the SDL below to 
emphasize the effect, in case anyone can shed light on this.

Regards,
Chris B.

camera {location <0,0,-2.5> look_at 0}
light_source {<0,20,-20>,1}

#local MajorRadius = 0.6;
#local MinorRadius = 1;
#local SphereRadius = pow(pow(MinorRadius,2)-pow(MajorRadius,2),0.5);

difference {
  sphere {0,SphereRadius}
  torus {MajorRadius,MinorRadius}
  pigment {color rgb <1,0,1>}
  translate -x
}

torus {MajorRadius,MinorRadius inverse
  pigment {color rgb <0,1,1>}
  clipped_by {sphere {0,SphereRadius}}
  translate x
}

#declare r1 = 0.6;
#declare r2 = 1;
#declare  F = function {x*x + y*y - r2*r2}

isosurface {
  function { F(sqrt(x*x+z*z)+r1, y, z) }
  max_gradient 3.1
  contained_by{sphere{0,r2}}
  pigment {rgb <1,1,0>}
}

Post a reply to this message

"Chris B" <c_b### [at] btconnectcomnospam> wrote in message 
news:441ac7de$1@news.povray.org...

> Interestingly on rendering the three solutions side-by-side I see that 
> Mike's solution is the only one that gets lit correctly.
> I'm not sure why this should be. I've adjusted the light in the SDL below 
> to emphasize the effect, in case anyone can shed light on this.

I assume it's associated with the torus - any known bugs with torii?

Post a reply to this message

Wasn't it Chris B who wrote:
>
>Interestingly on rendering the three solutions side-by-side I see that 
>Mike's solution is the only one that gets lit correctly.
>I'm not sure why this should be. I've adjusted the light in the SDL below to 
>emphasize the effect, in case anyone can shed light on this.

I think the CSG torus solver doesn't do quite the right thing with the
bit in the middle when the minor radius is greater than the major radius
and the major radius is positive. 

Once the surface normals are pointing the wrong way, "inverse" doesn't
fix them, it only fixes the situation where the inside is on the outside
and swaps the interior_texture for the texture.

Oddly, these work.

torus {-MajorRadius,MinorRadius 
  pigment {color rgb <0,1,1>}
  clipped_by {sphere {0,SphereRadius}}
}

difference {
  sphere {0,SphereRadius}
  torus {-MajorRadius,MinorRadius inverse}
  pigment {color rgb <1,0,1>}
}

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Mike Williams" <nos### [at] econymdemoncouk> wrote in message 
news:NKv### [at] econymdemoncouk...
> Wasn't it Chris B who wrote:
>>
>>Interestingly on rendering the three solutions side-by-side I see that
>>Mike's solution is the only one that gets lit correctly.
>>I'm not sure why this should be. I've adjusted the light in the SDL below 
>>to
>>emphasize the effect, in case anyone can shed light on this.
>
> I think the CSG torus solver doesn't do quite the right thing with the
> bit in the middle when the minor radius is greater than the major radius
> and the major radius is positive.
>
> Once the surface normals are pointing the wrong way, "inverse" doesn't
> fix them, it only fixes the situation where the inside is on the outside
> and swaps the interior_texture for the texture.
>
> Oddly, these work.
>
> torus {-MajorRadius,MinorRadius
>  pigment {color rgb <0,1,1>}
>  clipped_by {sphere {0,SphereRadius}}
> }
>
> difference {
>  sphere {0,SphereRadius}
>  torus {-MajorRadius,MinorRadius inverse}
>  pigment {color rgb <1,0,1>}
> }
>
> -- 
> Mike Williams
> Gentleman of Leisure

Wow !#!*  That's something I didn't even think of trying :-)

I find the 'difference' version the most bewildering, as I would have 
thought that slicing the 'inverse' of the torus out of the sphere would have 
left the sphere with a bit cut out of the inside, whereas the reverse 
happens. I guess it's safest to recommend not using this torus workaround 
lest the behaviour gets fixed in a future release (given that your 
isosurface provides a perfectly good solution).

Regards,
Chris B.

Post a reply to this message

Mike Williams wrote:
> 
> I think the CSG torus solver doesn't do quite the right thing with the
> bit in the middle when the minor radius is greater than the major radius
> and the major radius is positive. 
> 

LOL - I hadn't even noticed that this was the case.

Post a reply to this message