POV-Ray : Newsgroups : povray.bugreports : sphere slicing problem : Re: sphere slicing problem Server Time
3 May 2024 00:57:44 EDT (-0400)
  Re: sphere slicing problem  
From: William F Pokorny
Date: 1 Nov 2019 13:39:14
Message: <5dbc6dc2$1@news.povray.org>
On 11/1/19 10:16 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ... This means for
>> you, you'll have both coincident (sometimes wrongly ordered)
>> intersections and ones less and less likely to align with the
>> orthographic camera rays as the sampled surface becomes parallel to the
>> ray. Such rays, if they hit, would be near tangents to the surface - the
>> shortest of these tends to get filtered in many objects too for a few
>> reasons.
> 
> the image posted in p.b.misc shows a lo-res Y-axis scan, orthographic camera on
> the left, perspective on the right.  and the 'surface becomes parallel' thing is
> clearly where expected on the left.  I cannot fathom though why for the
> perspective camera the problem manifests above "the bulge" instead of the
> centre; cameras in both stationed directly above the sphere.

It's the same, sampled-surface being mostly parallel to the rays, issue. 
The results are about what I'd expect. With the perspective camera the 
rays are not parallel to the y axis, but some rays are still essentially 
running parallel/tangent to the parts of the sphere causing that upper 
bulge.

> 
> I now think that if, perhaps, there is a relatively simple and accurate way of
> calculating camera parameters for both camera types such that the object is seen
> in exactly the same size/position, perhaps one could merge the results.  any
> thought(s) welcome.
> 

Maybe... I had the thought while traveling it might be possible to get 
further for your simple sphere with my hard_object patch by creating a 
thin skin to the sphere - an aim for that pattern was to create the 
peeling paint isosurface skins more or less automatically(1).

(1) - The issue immediately hit was performance. The inside test is 
really slow for some objects and for all shapes it slows dramatically as 
the complexity of the input objects gets complex. With large CSGs for 
example, it looks to be just trundling through all the shapes. 
Performance aside, while the hard_object pattern handles convex shapes 
really well, it struggles with a shape's concave parts. It can get noisy 
/ fill in crevices.

> I also find the patterns appearing in many of the sliced rings interesting, the
> regularity of the spacing etc holds information -- I just can't .. parse it. :-(
>   if anyone's interested I can post the frame/slice images.
...

Perhaps reasons, but doubt the usefulness for anything found.

Bill P.


Post a reply to this message

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