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'

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'