





 
 


From: Alain Martel
Subject: Re: Artefact in lathe object using hollow and interior media emission
Date: 19 Jan 2021 11:21:58
Message: <60070726@news.povray.org>



 
 


Le 20210119 à 10:50, nj a écrit :
> 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.
>
>
> Example code:
> 
>
> #version 3.7;
>
> camera {
> location <0,0,10>
> look_at 0
> }
>
> lathe {
> linear_spline
> 2,
> <1,100>, <1,100>
>
> hollow on
> pigment {rgbf 1}
> interior { media { emission <1,1,1> } }
> }
>
>
When using media containers, you need closed objects. Your object is
open at both ends, meaning that the media is not constrained by that object.
Change your lathe as follow :
lathe {
linear_spline
4, // instead of 2
<0, 100>, // added bottom end cap
<1,100>, <1,100>,
<0, 100> // added top end cap
hollow //on Default to on when hollow is present
pigment {rgbf 1}
interior { media { emission <1,1,1> } }
}
In your original lathe, make sure that the first and last points have a
zero U coordinate. If not, increase the point count and add the missing
point.
Alain
Post a reply to this message


 
 




 
 


Thanks for the reply. It sadly didn't fix the problem, though. I am getting the
exact same result. In fact, I had end caps like this in my original code and
removed them for the minimal example to make it as minimal as possible.
Admittedly, I wasn't aware that they are actually needed.
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: Artefact in lathe object using hollow and interior media emission
Date: 19 Jan 2021 19:04:38
Message: <60077396$1@news.povray.org>



 
 


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 raysurface 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 raysurface 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 POVRay 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/POVRay/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


 
 




 
 


Thanks a lot! That brings me closer to understanding the problem :)
I still have trouble converting it into a working solution for the spline that I
actually want. So, if you don't mind, here's another  less minimal  example:
#version 3.7;
camera {
location <1, 2, 4>
look_at <0, 0, 0>
}
lathe {
cubic_spline
7,
<0, 20>, <1, 20>,
<0.5, 10>, <0.1, 0>, <0.5, 10>,
<1, 20>, <0, 20>
hollow
pigment { rgbf 1 }
interior { media { emission <1, 1, 1> } }
rotate <0, 0, 90>
}
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?
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!?
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: Artefact in lathe object using hollow and interior media emission
Date: 20 Jan 2021 11:51:58
Message: <60085fae$1@news.povray.org>



 
 


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 POVRay(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 tradeoffs. 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 tradeoffs. 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


 
 




 
 


"nj" <nomail@nomail> wrote:
> 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?
>
> Also, I would need to know where on the spline the inserted points need to be.
Yeah  that's a tricky thing to ponder at first, but perhaps you can use a
bezier_spline in your lathe, and use "degree elevation" to figure out exactly
where your additional points need to be.
https://ufile.io/820aj7gm
The concept is outlined / illustrated on page 16
Post a reply to this message


 
 




 
 


William F Pokorny <ano### [at] anonymousorg> wrote:
> 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 POVRay(1).
It seems I should look into this. I hadn't planned to actually dive that deep
...... ;)
> It would have been better to
> use a cylinder{} object. And this touches on shape tradeoffs. You might
> find a better v37/v38 general solution coding your shape as an
> isosurface cylinder deformed by the cubic spline.
OK. That sounds promising. I will look into this first. Thanks for the tip!
> 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.
Ah, nice :D
Looks like the opposite of what I had so far :\
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Yeah  that's a tricky thing to ponder at first, but perhaps you can use a
> bezier_spline in your lathe, and use "degree elevation" to figure out exactly
> where your additional points need to be.
Ah, thanks! That a nice one :)
I had a look into it and wrote some python code that adds points to a bezier
spline this way (I can share the code if it helps someone else). The results are
......let's say... interesting. I have to go to over thousand points for the
artifact to vanish. Here is a gif of the results:
https://imgbox.com/GKS9Afwb
From plotting the curves, my degree elevation looks correct. I am, however, a
bit surprised that the thickness of the lathe is not always the same.
Specifically, it changes strongly for small numbers. I would have expected that
povray draws the exact same spline for all numbers of points.
Post a reply to this message


 
 




 
 


> From plotting the curves, my degree elevation looks correct. I am, however, a
> bit surprised that the thickness of the lathe is not always the same.
> Specifically, it changes strongly for small numbers. I would have expected that
> povray draws the exact same spline for all numbers of points.
Sorry. Scratch that part. I accidentally used cubic splines with the bezier
points... Obviously, they need more points to get close to the bezier curve.
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: Artefact in lathe object using hollow and interior media emission
Date: 28 Jan 2021 07:35:39
Message: <6012af9b@news.povray.org>



 
 


On 1/21/21 9:16 AM, nj wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
>> 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 POVRay(1).
>
>
> It seems I should look into this. I hadn't planned to actually dive that deep
> ...... ;)
>
Another option if you are only after an emissive media lathe shape is to
put the media inside a cylinder (or other container object)  or in free
space at scene top. You'd then define the media density inside apart
from the container (or in free space) with the shape and density you
want. This has the advantage too that your media need no be of constant
density(1).
(1)  Non constant media render more slowly because they need more
sampling.
On adding points to a cubic spline. I've just started my first cup of
coffee for the day, but if you create a spline {} (or function based on
a spline) it should be you can use SDL (POVRay's own language) to walk
the spline in whatever number of steps you want; creating a new, more
finely defined spline which you'd use as the cubic spline definition for
the lathe. (Never done it myself though. YMMV)
Bill P.
Post a reply to this message


 
 


From: Alain Martel
Subject: Re: Artefact in lathe object using hollow and interior media emission
Date: 28 Jan 2021 12:15:35
Message: <6012f137$1@news.povray.org>



 
 


Le 20210120 à 05:12, nj a écrit :
> Thanks a lot! That brings me closer to understanding the problem :)
>
> I still have trouble converting it into a working solution for the spline that I
> actually want. So, if you don't mind, here's another  less minimal  example:
>
>
> #version 3.7;
>
> camera {
> location <1, 2, 4>
> look_at <0, 0, 0>
> }
>
> lathe {
> cubic_spline
> 7,
> <0, 20>, <1, 20>,
> <0.5, 10>, <0.1, 0>, <0.5, 10>,
> <1, 20>, <0, 20>
>
> hollow
> pigment { rgbf 1 }
> interior { media { emission <1, 1, 1> } }
>
> rotate <0, 0, 90>
> }
>
>
> 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?
>
> 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!?
>
>
You may want to use sturm here.
Your lathe will use a different, more accurate root solver. It's
somewhat slower, but, in some cases, it can get rid of artifacts like yours.
It becomes something like this :
lathe {
cubic_spline
7,
<0, 20>, <1, 20>,
<0.5, 10>, <0.1, 0>, <0.5, 10>,
<1, 20>, <0, 20>
sturm // Use the Sturmian root solver.
// Slower but more accurate.
hollow
pigment { rgbf 1 }
interior { media { emission <1, 1, 1> } }
rotate <0, 0, 90>
}
Post a reply to this message


 
 




 

