On 1/19/21 10:50 AM, nj wrote:
> I am having trouble with an artifact on a lathe object that uses hollow and
> interior media emission. I simplified my code as much as I could. Specifically,
> the original lathe uses a more complex spline.
> 
> Any pointers of what I am doing wrong would be appreciated!
> 

Try changing your spline specification to:

lathe {
     linear_spline
     4
     <1,-100>,<1,-0.5>, <1,0.5>, <1,100>
...
}

or similar.

What you are seeing is a numerical issue as the dy of the camera rays 
shrink to almost nothing compared to the active spline segment. (You 
have only one - and the dy for it is large)

Splines and similar objects are handled in segments when the ray surface 
equations are being generated. The bigger the segment the less accurate 
- or more spread out - the ray-surface equation's representation.

The ray distance to the surface(s) has an effect. The loss of dx,dy,dz 
in the camera ray direction has an effect. The range of the shape 
described has an effect. The order of the equation necessary for the 
local surface has an effect. To the extent you can control it, you want 
everything to be a similar order of magnitude.

Moving your camera to say y+10 would be another way to make better the 
numerical ray-surface representation.

Solver improvements can make your sample scene render better. Those in 
my povr branch produce speckles for your scene - not cuts. I also 
enabled sturm for second order equations where POV-Ray proper prevents 
sturm use on most shapes - even when sturm is specified. But what's done 
solver wise in povr is more or less near the best that can be done I 
think - and sometimes there is still noise. See the long discussion 
thread in https://github.com/POV-Ray/povray/pull/358, if interested in 
more detail.

At some point the issue in many of these speckling situations is the 
equation generated is trying to represent too much space - and so 
locally, even with perfect evaluations, you cannot represent the numeric 
space with enough "steps" (accuracy) to avoid numerical problems. 
Floating point is ultimately another kind of grid representation...

Aside: A couple years back I worked up an idea making the shape and 
solver code one and the same thing (published in povray.programming I 
think - search for a subject containing "epiphany") which I think would 
greatly improve accuracy. Unfortunately, it requires significant changes 
to how the current code base works and is implemented - just not gotten 
there. I think of the approach as "ray surface intersections by point 
blank polynomials." Someday, maybe...

Bill P.

Post a reply to this message