Le 2021-01-19 à 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

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

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

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

"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 POV-Ray(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 trade-offs. 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

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 POV-Ray(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 (POV-Ray'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

Le 2021-01-20 à 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