POV-Ray : Newsgroups : povray.advanced-users : lemon {} revisited Server Time
1 Oct 2023 17:25:35 EDT (-0400)
  lemon {} revisited (Message 1 to 10 of 12)  
Goto Latest 10 Messages Next 2 Messages >>>
From: Bald Eagle
Subject: lemon {} revisited
Date: 11 Mar 2023 16:05:00
Message: <web.640cec30f93802011f9dae3025979125@news.povray.org>
I was interested in using a lemon, or the inner surface of a spindle torus, or
the surface of revolution of a vesica piscis - whichever terminology you prefer
- to compare to a surface.

There is precious little information that I can find describing the lemon, and I
wanted a parameterized object.

The documentation doesn't have a diagram of how the lemon {} available in
version 3.8 is constructed (like it does for the ovus {} ), and the explanation
took me longer than it should have to clearly understand.

https://wiki.povray.org/content/Reference:Lemon
https://wiki.povray.org/content/Reference:Ovus

Presently, I have two problems. And one other issue.

First, when I try to render the lemon {} object with the current parameters, I
only get a very faint speckling rather than a well-formed surface. (I have
rendered several successful test lemons in 3.8)

You can just see it in the render.  This makes me sad, as I know Jerome Grimbert
did a lot of work on this shape.

Second, after I finally worked out how to isolate the inner surface of a
standard torus using an isosurface, I found that I needed to add a Fudgefactor
to the minor radius in order to remove a lot of artefactual noise.  I found the
0.2 magnitude of the FudgeFactor to be disturbingly large.

(Maybe I would have better luck with a polynomial object.)

The other issue is that the isosurface seems to have the interior_texture on the
outside, and the texture on the inside.

Anyone have any ideas?

// -------------------------------------------------------------------------

#version 3.8;
global_settings {assumed_gamma 1}
#declare E = 0.00001;


#declare Zoom = 160;
camera {
 orthographic
 //angle
 location <0, 0,  -image_width*2>
 right x*image_width/Zoom
 up y*image_height/Zoom
 //sky y
 look_at <0, 0, 0>
 rotate y*0
}

light_source {<image_width/2, image_height/2, -image_width*4> rgb 1 shadowless}
sky_sphere {pigment {rgb 1}}


#declare R = 3;
#declare r = 0.25;

#declare Line = 0.01;


#macro LemonLayout (Radius, Distance, Points)
 #local Circle =
 union {
  sphere {0, Line*2}
  torus {Radius, Line rotate x*90}
  pigment {rgb x}
 }
 object {Circle translate  x*Distance}
 object {Circle translate -x*Distance}

 #if (Points)
 union {
  #for (Phi, 0, tau, 0.1)
   #for (Theta, 0, tau, 0.1)
    #local X = Radius * cos (Theta) * sin (Phi) - Distance;
    #if (X >= 0)
     #local Y = Radius * sin (Theta);
     #local Z = X * sin (Phi);
     sphere {<X, Y, Z>, Line*2}
    #end

   #end
  #end
  pigment {rgb z}
 }
 #end

#end


#declare MF = 0.6;
#declare Min_factor= min (MF, 1);
#declare Max_gradient = 250;
#declare P0 = Max_gradient * Min_factor;
#declare P1 = sqrt (Max_gradient/(Max_gradient * Min_factor));
#declare _P2 = 0.7;
#declare P2 = min (_P2, 1);

#declare r = 1;
#declare R = 0.6;

// intersection points of 2 circles
// (x+R)(x+R) + y*y = r*r
// (x-R)(x-R) + y*y = r*r

// x*x + 2*R*x + R*R + y*y = r*r
// x*x - 2*R*x + R*R + y*y = r*r

//       4*R*x = 0
//           x = 0

//  y = sqrt ( r*r - R*R )

#declare Y = sqrt ( r*r - R*R );

#declare FudgeFactor = 0.2;


#declare Torus = function {pow (x*x + y*y + z*z + R*R - r*r, 2) -
4*R*R*(x*x+z*z)}
#declare Spindle = function {select ((r-R)*(r-R) - (x*x+z*z) + FudgeFactor, 0,
pow (x*x + y*y + z*z + R*R - r*r, 2) - 4*R*R*(x*x+z*z))}

#declare Iso =
isosurface {
 function {Spindle (x, y, z)}

 contained_by { box {<-(R-r), -Y, -(R-r)>, <R-r, Y, R-r>} }  // container shape
 accuracy 0.001
 max_gradient 250
 //evaluate P0, P1, P2
 open
 texture {
  pigment {rgb z}
  finish {specular 0.4}
 } // end texture

  interior_texture
  {
  pigment {rgb x+y}
  finish {specular 0.4}
 } // end texture

} // end isosurface



union {
 LemonLayout (1, 0.6, no)
 object {Iso }
 translate -x*r
}

union {
 LemonLayout (1, 0.6, no)
 object {Iso}
 rotate y*90 translate x*r
}


lemon {
 <0, -Y, 0>, 0, <0, Y, 0>, 0, r
 texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
 sturm
}


Post a reply to this message


Attachments:
Download 'lemon.png' (57 KB)

Preview of image 'lemon.png'
lemon.png


 

From: Bald Eagle
Subject: Re: lemon {} revisited
Date: 11 Mar 2023 16:20:00
Message: <web.640cef821e421ea21f9dae3025979125@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

> First, when I try to render the lemon {} object with the current parameters, I
> only get a very faint speckling rather than a well-formed surface. (I have
> rendered several successful test lemons in 3.8)
>
> You can just see it in the render.  This makes me sad, as I know Jerome Grimbert
> did a lot of work on this shape.

And wouldn't you know it, subtracting that exact same FudgeFactor from the
radius in the lemon {} makes it show up, but as a sphere, not the shape that I'm
shooting for.

Puzzling.


Post a reply to this message

From: William F Pokorny
Subject: Re: lemon {} revisited
Date: 11 Mar 2023 23:47:49
Message: <640d5975$1@news.povray.org>
On 3/11/23 16:01, Bald Eagle wrote:
> Anyone have any ideas?

I'm in the middle of another code tangle, but...

After the lemon was added and we started to bang on it, a few numerical 
issues turned up. I think most of this was discussed for a time on the 
developer mailing list. No idea what is fixed. What might github have...
Looks like https://github.com/POV-Ray/povray/pull/358 has a little on 
the lemon if you scroll down through the comments. Well, I suppose not 
would help you near term of that work in any case.

A reminder the f_torus inbuilt function implements a couple of the 
spindle modes though it is not directly documented anywhere that I know 
about. See post to povray.binaries.images

Subject: Some v38 torus vs f_torus() information.
Date: 30 Apr 2020 08:32:29

https://news.povray.org/povray.binaries.images/thread/%3C5eaac55d%241%40news.povray.org%3E/

Message: <5eaac55d$1@news.povray.org>

Running your scene with my current development povr code, and without 
sturm(a), I get the attached a result.

Bill P.

(a) - With sturm on I get a tiny nub on the ends bringing the height to
to about where the left and right shapes are. Without it it 'looks' like
the shape is a little more rounded at the ends than your equivalents. 
Might be there is still some other numerical stuff going on... It's not 
the easiest shape for the solvers.


Post a reply to this message


Attachments:
Download 'be.png' (53 KB)

Preview of image 'be.png'
be.png


 

From: William F Pokorny
Subject: Re: lemon {} revisited
Date: 12 Mar 2023 00:17:55
Message: <640d6083$1@news.povray.org>
On 3/11/23 23:47, William F Pokorny wrote:
> It's not the easiest shape for the solvers.

Ah, and you are using an orthographic camera. This often the worst case 
ray set up for the solvers. Other shapes like the sphere_sweep have 
similar issues with the orthographic camera. Your' also positioning well 
away it looks too.

If I step an ortho camera back just -2 in z and code as the lemon:

#declare r = 1;
#declare R = 0.6;
#declare Y = sqrt ( r*r - R*R );
lemon {
   <0, -Y, 0>, 0, <0, Y, 0>, 0, r
   texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
   sturm
   translate <-.1,0,-.1>
}

I get the attached image.

The ray length matters in that the longer it travels the more the 
accuracy of the ray->surface equation degrades in accuracy. The equation 
has to represent all those useless potential landing steps on the way to 
the shapes surface and this burns up the floating point accuracy.

That bit was my painful discovery discussed in the previously referenced 
github issue. I have a solution for best possible floating point 
hardware accuracy, but the implementation is not trivial...

Bill P.


Post a reply to this message


Attachments:
Download 'behmm.png' (29 KB)

Preview of image 'behmm.png'
behmm.png


 

From: Bald Eagle
Subject: Re: lemon {} revisited
Date: 12 Mar 2023 08:50:00
Message: <web.640dc9811e421ea21f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

Haha!  Your previous post jogged something in my memory that provides a truly
trivial solution.


> Ah, and you are using an orthographic camera.

Yes.  Any time you see me doing graphs and drafting layout lines, there's a 99%
chance it's an orthographic camera.

> This often the worst case
> ray set up for the solvers. Other shapes like the sphere_sweep have
> similar issues with the orthographic camera.

> Right.  I hammer through so many exploratory idea and experiments that my default is
a copy-paste from one of the 20 
last-working-scene tabs that  I have open in the editor.

> Your' also positioning well away it looks too.

IIRC, it was the single-image photogrammetry where I had an issue with all my
stuff disappearing because it hadn't damned on me how LARGE the objects were,
and therefore how far back they extended (past the camera plane).   So yeah,
it's WAAAAAY back.   I'll try to keep those under-the-hood issues about the
solver and the camera distance in mind.

> The ray length matters in that the longer it travels the more the
> accuracy of the ray->surface equation degrades in accuracy. The equation
> has to represent all those useless potential landing steps on the way to
> the shapes surface and this burns up the floating point accuracy.

Perhaps an interesting thing to have available in povr would be a "global
bounding box" for the scene in the render statistics.  It could help clue scene
authors in to overlooked distance issues and maybe help track down spuriously
placed objects, as well as resolve other weird issues.

Still not sure what the crud on my isosurface is that gets removed with the
FudgeFactor.   I'll make a quick switch to the perspective camera and see if it
goes away.


On to the trivial solution.
Spindle torus, did you say?
"The merge and intersection spindle modes have long existed with the f_torus,
but via value arguments."
Well, they've long existed for the regular torus primitive too.
Which I had discovered, and therefore "knew", but forgot.

http://news.povray.org/povray.binaries.misc/message/%3C604613ed%241%40news.povray.org%3E/#%3C604613ed%241%40news.povray
.org%3E

https://wiki.povray.org/content/Reference:Torus

and so, adding
torus {R, r intersection texture {pigment {rgb z} finish {specular 0.4}}
translate x*2*r}

gives me just what I was looking for.

"Oh, POV-Ray developers, you understand everything!"  :)


Post a reply to this message


Attachments:
Download 'lemon.png' (65 KB)

Preview of image 'lemon.png'
lemon.png


 

From: Kenneth
Subject: Re: lemon {} revisited
Date: 12 Mar 2023 09:30:00
Message: <web.640dd2cd1e421ea29b4924336e066e29@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> First, when I try to render the lemon {} object with the current parameters, I
> only get a very faint speckling rather than a well-formed surface.

The speckling was even worse for me.

By changing the camera to 'perspective' and with location <0,0,-.7>, I see the
nice lemon shape. Also, I don't see any difference re: sturm vs. no sturm.
>
> The other issue is that the isosurface seems to have the interior_texture
> on the outside, and the texture on the inside.
>

As an experiment, I negated your spindle function...
      #declare Iso =
      isosurface {
       function {-Spindle (x, y, z)}...

and the interior/exterior textures look correct now. A clue to something?


Post a reply to this message

From: Bald Eagle
Subject: Re: lemon {} revisited
Date: 12 Mar 2023 10:35:00
Message: <web.640de2011e421ea21f9dae3025979125@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> By changing the camera to 'perspective' and with location <0,0,-.7>, I see the
> nice lemon shape. Also, I don't see any difference re: sturm vs. no sturm.

I did the same but needed to remove the fudge factor to transition from the
sphere to the lemon.

My isosurface still need the fudge factor, else I still have the cylinder of
crud.

> and the interior/exterior textures look correct now. A clue to something?

It's just the sign.  I was just wondering if the native implementation of the
torus was "wrong", since I recall the uv-mapping being off compared to most
other shapes.


Post a reply to this message

From: William F Pokorny
Subject: Re: lemon {} revisited
Date: 12 Mar 2023 11:41:52
Message: <640df2c0$1@news.povray.org>
On 3/12/23 08:45, Bald Eagle wrote:
> IIRC, it was the single-image photogrammetry where I had an issue with all my
> stuff disappearing because it hadn't damned on me how LARGE the objects were,
> and therefore how far back they extended (past the camera plane).   So yeah,
> it's WAAAAAY back.   I'll try to keep those under-the-hood issues about the
> solver and the camera distance in mind.

With the orthographic camera, the distance doesn't matter with respect 
to the size of scene things. The size of the orthographic camera plane / 
rectangle does matter - and that the plane be back a small distance from 
all the objects and bounding in the scene.

The location of the camera's ray shooting plane can be very close to 
objects. The orthographic camera rays are more difficult for the 
solvers, as a rule we should position the orthographic cameras close to 
the objects in the scene.

My (-z / looking toward +z) orthographic camera code is:

//---
#declare VarOrthoMult =
5.0/max(image_width/image_height,image_height/image_width);
#declare Camera01z = camera {
     orthographic
     location <0,0,-2>
     direction z
     right VarOrthoMult*x*max(1,image_width/image_height)
     up VarOrthoMult*y*max(1,image_height/image_width)
}
//---

To see a larger part of the x/y plane in the scene, I change that 5.0 
multiplier to something larger.

---

The spindle modes of the regular torus were added to v3.8 and have now 
existed some years (4-5 give or take?), the f_torus modes came with the
addition of functions, the isosurface object and the function vm - which 
I think goes back to v3.5. Those working in v3.7 would have only the 
f_torus spindle options available. The lemon too isn't there in v3.7 
being new in v3.8.

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: lemon {} revisited
Date: 12 Mar 2023 11:54:57
Message: <640df5d1$1@news.povray.org>
On 3/12/23 10:30, Bald Eagle wrote:
> It's just the sign.  I was just wondering if the native implementation of the
> torus was "wrong", since I recall the uv-mapping being off compared to most
> other shapes.

You remember correctly. :-)

IIRC think we found the torus 'uv_mapping' reversed (handedness) 
compared to all other uv mapping in POV-Ray. It was for a short time 
corrected, but then restored to what it had been since v3.7 to maintain 
compatibility with old scenes. IIRC povr stuck with the corrected uv 
mapping - but that memory of mine might be wrong...

Aside: It's also true the new 'uv_mapping' added to additional shapes 
for v3.8/v4.0 was turned back off for other general 'uv_mapping' 
concerns. This is one place where our current v3.8 documentation does 
not align with the real state of v3.8 - the last I checked. In pulling 
back the newer 'uv_mapping' I 'think' povr  did too in the moment, 
thinking a fix would soon be adopted - but that never happened and I 
believe povr aligns with v3.8/v4.0.

Bill P.


Post a reply to this message

From: Bald Eagle
Subject: Re: lemon {} revisited
Date: 12 Mar 2023 13:45:00
Message: <web.640e0ed11e421ea21f9dae3025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> My (-z / looking toward +z) orthographic camera code is:

I also have a usage question with regard to orthographic:
I did not seem to be able to get this particular inclusion of the "angle"
keyword to work as described, but maybe I didn't try hard enough, or my camera
{} block was malformed.  It would make my life easier instead of having to
switch between 2 different cameras and define (guess at) a Zoom value, like I do
now.


https://wiki.povray.org/content/Reference:Camera#Orthographic_projection


If, in a perspective camera, you replace the perspective keyword by orthographic
and leave all other parameters the same, you will get an orthographic view with
the same image area, i.e. the size of the image is the same. The same can be
achieved by adding the angle keyword to an orthographic camera. A value for the
angle is optional. So this second mode is active if no up and right are within
the camera statement, or when the angle keyword is within the camera statement.

....

Note: The length of direction is irrelevant unless angle is used. The lengths of
up and right define the dimensions of the view. The angle keyword can be used,
as long as less than 180. It will override the length of the right and up
vectors (the aspect ratio between up and right will be kept nevertheless) with a
scope of a perspective camera having the same direction and angle.


Post a reply to this message

Goto Latest 10 Messages Next 2 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.