On 04/29/2017 08:05 PM, Jörg "Yadgar" Bleimann wrote:
> Hi(gh)!
>
> I started to model the building blocks of a Swiss-made marble lane
> system... when I came to an elongated block with a serpentine-shaped
> marble track on top, I chose to use a cubic sphere to create the
> hollow... but it resulted in heavy artifacts (object on the extreme
> right of the scene attached). I tried various tolerance values - but
> nothing removed those artifacts! Here is the code:
>
Thanks for posting code. I've opened a github issue for this:

https://github.com/POV-Ray/povray/issues/287

given it seems to render correctly in 3.6.1.

Bill P.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> I tried all sorts of tricks to try and eliminate the problem, but no luck...
>

I ran the scene in the latest(?) 3.7.1 beta 5, as well as in my original 3.70
install; same problems in both.

IIRC, sphere_sweeps using a cubic spline have been problematic for a *long*
time. If it were possible to do, I would suggest adding the 'natural_spline'
type to the sphere_sweep code. I don't know the math differences between natural
and cubic splines (or if one is mathematically 'simpler' than the other) but it
might give us at least one way to make curvy sphere_sweeps that can be
CSG-differenced from another object.

Post a reply to this message

Hi(gh)!

Am 30.04.2017 um 13:23 schrieb Jörg "Yadgar" Bleimann:
> Hi(gh)!
>
> Am 30.04.2017 um 06:06 schrieb Cousin Ricky:
>
>> It is for just such a reason that I created the SphereSweep module in
>> the Object Collection:
>>
>>
http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky
>>
>
> Very good, I will try this out!

Now it looks correct: see attachment!

See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download '2017-04-30 cugolino, take 2.jpg' (31 KB)

Preview of image '2017-04-30 cugolino, take 2.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:

> IIRC, sphere_sweeps using a cubic spline have been problematic for a *long*
> time.

I was unaware of this.

>If it were possible to do, I would suggest adding the 'natural_spline'
> type to the sphere_sweep code. I don't know the math differences between natural
> and cubic splines (or if one is mathematically 'simpler' than the other) but it
> might give us at least one way to make curvy sphere_sweeps that can be
> CSG-differenced from another object.

Maybe for the time being you could use:

http://www.econym.demon.co.uk/isotut/splines.htm

it may be slower, but would give good end results straightaway.

Post a reply to this message

Le 30/04/2017 à 17:06, William F Pokorny a écrit :
> On 04/29/2017 08:05 PM, Jörg "Yadgar" Bleimann wrote:
>> Hi(gh)!
>>
>> I started to model the building blocks of a Swiss-made marble lane
>> system... when I came to an elongated block with a serpentine-shaped
>> marble track on top, I chose to use a cubic sphere to create the
>> hollow... but it resulted in heavy artifacts (object on the extreme
>> right of the scene attached). I tried various tolerance values - but
>> nothing removed those artifacts! Here is the code:
>>
> Thanks for posting code. I've opened a github issue for this:
> 
> https://github.com/POV-Ray/povray/issues/287
> 
> given it seems to render correctly in 3.6.1.
> 
> Bill P.
> 
Thanks for logging.

I tested with hg-povray and it is fine there (at least the tmp372.pov file)

Actually, it is also ok on my master head, but both stable and official
master have problem.

Which leads me to conclude: read the note about the patch of my master,
for sphere_sweep:
* sphere sweep: less noise under some angles
* sphere sweep: UV mapping
* sphere sweep: removed the preliminary workaround for FS#81 (not
effective, was adding noise)
* sphere sweep: added the suggested fix for FS#243 (negative uniform
scaling of untransformed object should have effect on radius as absolute
factor)


From what I would keep in the sphsweep.cpp, previously in
source/backend/shape (now spheresweep.cpp in source/core/shape ):
const DBL ZERO_TOLERANCE        = 1.0e-1;// less noise when near 1 than
near 0 [JG]

instead of

const DBL ZERO_TOLERANCE        = 1.0e-4;

Good luck.

Post a reply to this message

Attachments:
Download 'offmaster.png' (51 KB) Download 'hg.png' (52 KB) Download 'master.png' (52 KB) Download 'stable.png' (51 KB)

Preview of image 'offmaster.png'

Preview of image 'hg.png'

Preview of image 'master.png'

Preview of image 'stable.png'

Le 01/05/2017 à 18:19, Le_Forgeron a écrit :

> * sphere sweep: removed the preliminary workaround for FS#81 (not
> effective, was adding noise)

And also, REMOVE THAT FS#81 PATCH which do no good.

Post a reply to this message

Am 30.04.2017 um 17:42 schrieb Kenneth:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> I tried all sorts of tricks to try and eliminate the problem, but no luck...
>>
> 
> I ran the scene in the latest(?) 3.7.1 beta 5, as well as in my original 3.70
> install; same problems in both.
> 
> IIRC, sphere_sweeps using a cubic spline have been problematic for a *long*
> time. If it were possible to do, I would suggest adding the 'natural_spline'
> type to the sphere_sweep code. I don't know the math differences between natural
> and cubic splines (or if one is mathematically 'simpler' than the other) but it
> might give us at least one way to make curvy sphere_sweeps that can be
> CSG-differenced from another object.

Mathematically, "natural splines" are only marginally different from
what POV-Ray calls "cubic splines": Both are 3rd order polynomial
splines, i.e. piecewise defined functions mapping a single scalar
parameter to a point in N-dimensional space, with each piece having the form

    F(t) = A[3] * t^3 + A[2] * t^2 + A[1] * t + A[0]

with A[i] being N-dimensional constants (N=3 in the case of POV-Ray's
splines).

I would therefore not expect "natural splines" to have any advantage
over the so-called "cubic splines" (except possibly being more intuitive
to control, depending on user and use case). To the contrary, "natural
splines" have fewer degrees of freedom, allowing less control over the
direction and curvature at the start and end of the spline.

Technically speaking, all 3rd order polynomial splines are cubic
splines. This also includes POV-Ray's "bezier splines", which behind the
scenes differ from the other types only in that they provide even more
degrees of freedom, allowing for sudden changes in both direction and
curvature between the pieces of the spline.

Post a reply to this message

Am 01.05.2017 um 18:35 schrieb Le_Forgeron:
> Le 01/05/2017 à 18:19, Le_Forgeron a écrit :
> 
>> * sphere sweep: removed the preliminary workaround for FS#81 (not
>> effective, was adding noise)
> 
> And also, REMOVE THAT FS#81 PATCH which do no good.

I was about to press "send" on a passionate defense of that patch just
now, when something crossed my mind.

Can you confirm my hunch that all use cases where the patch negatively
impacts quality are cases where we see the sphere sweep's inside?

Other than that, I'm at a loss how the patch could possibly have any
negative impact.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> Mathematically, "natural splines" are only marginally different from
> what POV-Ray calls "cubic splines": Both are 3rd order polynomial
> splines... [snip]

Thinking back to the v3.62 days, I'm ashamed to admit that you probably
explained this long ago-- and probably in response to a similar post by me! Mea
culpa.

I've been looking at Wikipedia's entries on 'spline interpolation' and 'cubic
Hermite splines', in a (poor) attempt to understand them. But I'm trying! ;-)

My mention of using a 'natural spline' is simply based on its well-behaved use
in other parts of POV-Ray (without knowing its mathematical differences vs.
POV-ray's 'cubic splines'.) I had assumed that a 'natural spline' was somehow
better behaved mathematically than a cubic one... or maybe that it wasn't 3-rd
order...

Since both 'natural splines' and 'cubic splines' ARE both 3-rd order, I'm
willing to guess(!) that the problem is not in POV-ray's mathematical
implementation of the cubic spline, but rather in some kind of co-dependent
problem with the 'difference-ing' operation. Based on nothing but my nutty
intuition ;-)

Post a reply to this message

Am 02.05.2017 um 22:58 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
> 
>>
>> Mathematically, "natural splines" are only marginally different from
>> what POV-Ray calls "cubic splines": Both are 3rd order polynomial
>> splines... [snip]
> 
> Thinking back to the v3.62 days, I'm ashamed to admit that you probably
> explained this long ago-- and probably in response to a similar post by me! Mea
> culpa.

I'm an explainer by nature. It's difficult to tire me out on
re-iterating stuff I've explained over and over again. Ask me again
tomorrow, and I'll explain once more.

> Since both 'natural splines' and 'cubic splines' ARE both 3-rd order, I'm
> willing to guess(!) that the problem is not in POV-ray's mathematical
> implementation of the cubic spline, but rather in some kind of co-dependent
> problem with the 'difference-ing' operation. Based on nothing but my nutty
> intuition ;-)

There _is_ (or so I think by now) a fundamental flaw of that infamous
"FS#81 Patch" that specifically screws up difference ops (and other
cases where the interior of the sphere sweep is exposed). However, the
issue the patch was originally intended to fix does hit 3rd order
splines even without a difference op. (In a nutshell, any 3rd order
sphere sweep will be screwed up anywhere the spline runs approximately
perpendicular to the viewing direction.)

Post a reply to this message