|
|
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
|
|