

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 12 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
workaround, 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'

