POV-Ray : Newsgroups : povray.advanced-users : lemon {} revisited : Re: lemon {} revisited Server Time
17 Apr 2024 18:59:18 EDT (-0400)
  Re: lemon {} revisited  
From: Bald Eagle
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.



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

Download 'lemon.png' (65 KB)

Preview of image 'lemon.png'


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