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:
<1,-100>,<1,-0.5>, <1,0.5>, <1,100>
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
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...
Post a reply to this message