On 1/20/21 5:12 AM, nj wrote:
> Thanks a lot! That brings me closer to understanding the problem :)
...
> What I still don't quite get is this: Why is the problem occurring where it
> occurs? Or better -- if it's solvable by inserting more points -- how do I know
> where to insert them?

Here, it's related to how particular camera rays approach the lathe 
surface.

You are correct in suspecting there is no generic solution beyond 
inserting many more "segments" for shapes(with segments) which might see 
any sort of possible ray -> surface interaction. This especially true in 
v37 and v38 as they stand today.

More segments might not always completely fix particular artefacts. 
Further, you can go too far and add too many points/control points - 
with some shapes.

Some shapes - the lathe is one - have internal bounding to some degree, 
but generally more segments make the shape slower to render. This means, 
if you can target the insertion of points to the problem region of the 
shape for a particular still image or an animation with a particular 
range of views, it can be a render time win.

My current, occasionally published by tar ball, povr branch has a 
collection of solver improvements which work much more often in practice 
- especially if you turn AA on. It handles your cubic lathe scene fine, 
but yep, you have to build it yourself and povr isn't strictly backward 
compatible with POV-Ray(1). I'll post an image to p.b.i after I post 
this where the top image is with v3.8 master, the two bottom images are 
with the povr branch where only the very bottom has AA on. Basically 
saying there are improvements available which work better, and which 
don't that often require the insertion of additional segments.

Aside: The taper you introduced usually somewhat helps the numerical 
situation. A backward way of saying the lathe cylinder case as you 
posted it was quite difficult numerically. It would have been better to 
use a cylinder{} object. And this touches on shape trade-offs. You might 
find a better v37/v38 general solution coding your shape as an 
isosurface cylinder deformed by the cubic spline. The solver used for 
isosurfaces is different and often more resilient to ray -> surface 
approaches. At least while supposing the gradient is set high enough to 
handle the worst case ray -> surface gradient.

(1) - I have published to github a solver branch which likely can still 
be pulled into the v3.8 master and be built as a v3.8 compatible.

> 
> Also, I would need to know where on the spline the inserted points need to be.
> For the cylinder, this was trivial. Now, I could calculate values on a spline
> (for instance, using scipy.interpolate.spline) and insert those. But I haven't
> really wrapped my mind around this idea, since I'd assume the spline algorithm
> in povray would do exactly the same already!?
> 

Automatic insertion of segments doesn't happen today. As to whether it 
should, or could, perhaps as a parsing option - I don't know. I think 
the better solution would be to avoid it if possible, but this does 
require other improvements. Not all of which that I have in mind are in 
the povr branch either at this point.

The thing you get into - once you get deeply into it - is there are 
always many, many trade-offs. What's best is hard to sort in the context 
of the whole of the trade offs... :-)

Aside 2: For fun, change the pigment in your just posted scene to 'rgb 
1' and render! The povr solver changes fix those artefacts too.

Bill P.

Post a reply to this message