POV-Ray : Newsgroups : povray.advanced-users : lemon {} revisited Server Time
20 Apr 2024 09:35:46 EDT (-0400)
  lemon {} revisited (Message 3 to 12 of 12)  
<<< Previous 2 Messages Goto Initial 10 Messages
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

From: William F Pokorny
Subject: Re: lemon {} revisited
Date: 12 Mar 2023 16:12:24
Message: <640e3228$1@news.povray.org>
On 3/12/23 13:41, Bald Eagle wrote:
> 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.

My only experience using orthographic & angle was first setting up a 
perspective view of solver test cases - where the camera needs be a 
significant distance away with smaller angles. Then I'd flip perspective 
to orthographic to get the, much harder for ray->surface equations and 
solver, ortho rays as another test case. For me all I did was flip the 
camera types... I've got no experience with more.

Where the documentation says:

"Note: The length of direction is irrelevant unless angle is used." is 
true only in an abstract sense. While not the direction vector length, 
the actual length of the ray in that direction absolutely matters with 
respect to how well many shapes work.

If I take my earlier Camera01z set up and change the location to be:

location <0,0,-2*1e3>

I get the attached image of the same identical scene. The ray length 
went from ~2 to ~2000.

Bill P.

(a) - To some extent it matters to other camera types(b) (or say light 
positions for shooting photons), but in other cases the rays are almost 
all coming in at some angle relative to the scene objects - and this 
alone helps the ray->surface equations set up and the solvers.

(b) - I had too sovler tests for extremely small angle perspective 
cameras 1-2 degrees and these too often turn up equation set up / solver 
issues both because the camera rays are nearing orthogonal, but also due
the length.


Post a reply to this message


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

Preview of image 'behmm.png'
behmm.png


 

From: William F Pokorny
Subject: Re: lemon {} revisited
Date: 12 Mar 2023 23:35:40
Message: <640e9a0c$1@news.povray.org>
On 3/12/23 08:45, Bald Eagle wrote:
> 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.

I'm thinking some about this and unsure how to do it in any general way 
that would not often raise false alarms.

> On to the trivial solution.
> Spindle torus, did you say?


I'll write more about accuracy stuff here so folks are not left too 
'depressed' about higher order inbuilt shapes like the lemon. ;-)

Attached is another image with three shapes left to right where the 
orthographic camera is again pulled back about -2000 from the origin 
where the shapes sit. In fact even -2e6 is no problem.

The middle and right shapes are an isosurface, f_torus 'intersect' 
spindle and on the right is the torus 'intersect' spindle. A good 
question is why do these shapes seem to be immune to the camera set back 
(to the long ray length)?

The answer is both shapes have low order container shapes which are in 
fact the first intersection. The isosurface shape uses either a box or a 
sphere(a) which users specify as the container. The torus internally 
creates a bounding sphere which is the first intersection(a).

On the left is again the lemon, but now it works! It does because I did 
this:

union {
     box { -1,1 pigment {rgbt <0,0,0,1>} } // <--- low order bounding(a)
     lemon {
       <0, -Y, 0>, 0, <0, Y, 0>, 0, r
       texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
     //sturm
     }
     translate <-.7,0,-.1>
}

Bill P.

(a) - This kind of outer bounding certainly helps and is often a decent 
work-around, but it is not a general solution. For example, when the 
shapes themselves are large (big interior) - as the ray->surface 
equation and solvers see the shape. Or where the type of csg forces the 
from camera intersections.

The union, clear, first shape bounding can also introduce issues / 
artefacts with other shapes in the scene because that invisible surface 
exists in the scene.

Aside: An attractive argument for representing all shapes with low 
order, mesh approximations is those low order (simpler) ray->surface 
equations tolerate MUCH longer ray to surface distances on cpu float 
hardware.


Post a reply to this message


Attachments:
Download 'behmmisotorusspindle.png' (77 KB)

Preview of image 'behmmisotorusspindle.png'
behmmisotorusspindle.png


 

<<< Previous 2 Messages Goto Initial 10 Messages

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