Am 09.05.2017 um 14:14 schrieb William F Pokorny:

> The great news is Christoph fixed ALL the sphere_sweep auto-bounding
> issues I have in hand in beta 6! The auto-bounding issue has dogged
> sphere_sweeps from day one with this object.

In a certain sense I cheated: Rather than trying to come up with a
formula to compute the minimum and maximum coordinates of a sphere sweep
based on a Catmull-Rom spline (the thing POV-Ray calls `cubic_spline`),
I just searched the Internerds for a formula to translate a Catmull-Rom
spline into a (temporary) equivalent Bezier spline, and then exploiting
the neat property that a Bezier spline can never "overshoot" its control
points.

There are cases where this approach gives a non-ideal (i.e. oversized)
bounding box, but that's acceptable, and the upside is that it'll never
give a bad (i.e. undersized) one.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 09.05.2017 um 14:14 schrieb William F Pokorny:
>
> > The great news is Christoph fixed ALL the sphere_sweep auto-bounding
> > issues I have in hand in beta 6! The auto-bounding issue has dogged
> > sphere_sweeps from day one with this object.
>
> In a certain sense I cheated: Rather than trying to come up with a
> formula to compute the minimum and maximum coordinates of a sphere sweep
> based on a Catmull-Rom spline (the thing POV-Ray calls `cubic_spline`),
> I just searched the Internerds for a formula to translate a Catmull-Rom
> spline into a (temporary) equivalent Bezier spline, and then exploiting
> the neat property that a Bezier spline can never "overshoot" its control
> points.

IIIRC that is actually the only solution because afaik one cannot compute the
convex hull of a Catmull-Rom spline.

Post a reply to this message

Am 09.05.2017 um 19:08 schrieb Thorsten Froehlich:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 09.05.2017 um 14:14 schrieb William F Pokorny:
>>
>>> The great news is Christoph fixed ALL the sphere_sweep auto-bounding
>>> issues I have in hand in beta 6! The auto-bounding issue has dogged
>>> sphere_sweeps from day one with this object.
>>
>> In a certain sense I cheated: Rather than trying to come up with a
>> formula to compute the minimum and maximum coordinates of a sphere sweep
>> based on a Catmull-Rom spline (the thing POV-Ray calls `cubic_spline`),
>> I just searched the Internerds for a formula to translate a Catmull-Rom
>> spline into a (temporary) equivalent Bezier spline, and then exploiting
>> the neat property that a Bezier spline can never "overshoot" its control
>> points.
> 
> IIIRC that is actually the only solution because afaik one cannot compute the
> convex hull of a Catmull-Rom spline.

We don't need the convex hull; we just need to identify the minimum and
maximum for any given coordinate.

Like any 3rd order polynomial splines, at their heart Catmull-Rom
splines boil down to piecewise cubic functions with vector coefficients
and a "time-like" parameter. As such, we can consider each dimension
separately, i.e. we can treat the thing as a set of piecewise 3rd order
polynomials, one for each dimension.

For each polynomial we can identify the local minima and maxima by
looking for the roots of the first derivative. We're already computing
the coefficients of the base function anyway, so computing the
coefficients of the first derivative should be a piece of cake. We can
then test those roots for falling inside the relevant interval.

Cobbling together all the local minima and maxima of all the pieces, we
can then determine the smallest local minimum and largest local maximum.

Finally, we can throw the endpoints into the mix, to deal with cases
where the absolute minimum or maximum is not a local one, but rather at
a border of a piece.


That would be the algorithm for an infinitesimally thin spline. A sphere
sweep is a bit more complicated, but if I'm not mistaken we would
actually just have to examine the sum / difference of the location
function and the radius function (instead of the pure location function)
for the local maxima and minima, respectively. And since we're dealing
with polynomials, that's just a matter of adding / subtracting the
coefficients.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 09.05.2017 um 00:29 schrieb omniverse:
>
--->8---
>
> > Curiously the *always there* artifact is diagonal and not at a bend (not exactly
> > anyway) while the new ones seem to be vertical and at either top or bottom of
> > the bends yet not all bends (it is an erratic sine wave), although most are
> > overlapped by a sphere as plotting points.
>
> As far as we are aware so far, the artifacts appear in places where the
> sphere sweep runs nearly perpendicular to the viewing direction. Can you
> confirm this?

Only now getting back to this. I neglected to mention that plotted chart uses
orthographic camera, although it doesn't seem to be anything about that.

As far as camera sphere_sweep alignment goes, I animated the test scene to move
the camera or the sphere_sweep and both cause the same kind of artifacts.

While there appears to be some sort of camera/sphere_sweep orientation reason
for the artifacts it doesn't look like "perpendicular" or another exact
alignment is causing it.

Albeit the sphere_sweep is getting cut across mostly perpendicular, there are
obvious signs of it being curved too. I think it just happens that the most
visible portions align with the camera.

Will let you decide, so I'm putting the stop-frame type animation at
p.b.animations

And I almost thought there could have been something about the sphere_sweep
being on a single plane, but no, also does same with points placed off plane.
Possibly worse effect doing so.

Reasons to me it's a kind of interference with itself. I could only make wild
guesses like this since I don't know how those things work!

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> Thanks for the test scene. I've added it to a small collection of
> problem sphere_sweeps I have going. Also helpful to see you trying such
> a large value for tolerance and getting a better result. I'd always
> followed the documentation with respect to magnitude suggestions and had
> never seen tolerance affect much.
>
> Christoph backed out a fix in beta 6 which caused other problems but
> made sphere_sweep artifacts like yours better. I thrashed around in this
> code yesterday without much luck. Starting to think completely fixing
> things here may require changes in the core solver - that sphere_sweep
> issues might be tangled somewhat in the tiny discontinuities we see in
> other objects at times due scale and ray/surface/coordinate inflections.
>
> The great news is Christoph fixed ALL the sphere_sweep auto-bounding
> issues I have in hand in beta 6! The auto-bounding issue has dogged
> sphere_sweeps from day one with this object.

Good thing to hear that anyway.

I didn't have any luck using small tolerance values but I also didn't know it
defaulted to 0.000001, much less than I thought (by 1000 times!). Trying by tens
down to 0.00000000000001 got me nowhere!

On that subject, I found out the sphere_sweep surface will disappear at the
location of an artifact if the right number is used for tolerance. For example
48 or a little more like 48.1 to see it better, if scene file is unchanged from
that posted.
A scale of 1 instead should make same thing possible at about tolerance 3.905 or
so.

Rendering a good resolution size helps see that, too, such as 800X600. Lacks
shadows as-is so I guess it's like a CSG difference surface.

And I don't think this can work on every artifact location. Maybe only the
nearest to camera...?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 08.05.2017 um 18:55 schrieb Kenneth:

>
> > I saved the DMP file, METADATA file and MINIDUMP file, if they can be useful
> > (although the DMP file is huge, at 100+ MB.)
>
> Let me know how I can get hold of the files.
> See one of my other posts in this thread for details about my e-mail
> address.

I emailed them to you this morning (USA East Coast time), using gmail's 'Google
Drive' thing to bypass the 25MB email limit. Sorry for the delay. If you don't
receive them, then I screwed up somewhere...

Post a reply to this message

Am 08.05.2017 um 02:13 schrieb green:

> pov-ray critical error
> failed to initialize frontend: timed out waiting for worker thread startup
> 
> unfortunately, it appears that the execution of an illegal instruction
> at address 0x000000014001d6d3 has caused this unofficial
> pov-ray build to crash. <write a dump?>


I think I have gotten down to the bottom of this now:

MS Visual Studio has an option called "Whole Program Optimization",
which allows the compiler/linker to optimize stuff looking at the "big
picture" rather than just individual source files. Apparently this can
cause a mess when programs have source files compiled with AVX
instructions enabled and others without, in that the compiler/linker may
accidentally "contaminate" the AVX-free portions with calls to portions
which happen to have been compiled with AVX instructions enabled.

There were also performance regressions on various AVX-capable CPUs,
which might have been due to a reverse proess, in which AVX-enabled code
portions would have been replaced with calls to portions that happened
to have been compiled without AVX instructions.


This has now been addressed in beta 7 by explicitly disallowing
AVX-enabled code portions to participate in whole program optimization
in any manner.

Post a reply to this message

On 05/14/2017 06:08 AM, clipka wrote:
> Am 08.05.2017 um 02:13 schrieb green:
>
> MS Visual Studio has an option called "Whole Program Optimization",
> which allows the compiler/linker to optimize stuff looking at the "big
> picture" rather than just individual source files. Apparently this can
> cause a mess when programs have source files compiled with AVX
> instructions enabled and others without, in that the compiler/linker may
> accidentally "contaminate" the AVX-free portions with calls to portions
> which happen to have been compiled with AVX instructions enabled.
>
>
Have you done any performance comparisons with and without this 
optimization?

The gnu compiler / linker has such an option too - experimental. Trying 
it, I got significantly smaller load modules, but in what I ran not much 
in the way of performance(1). I hacked make files and my development 
environment to get it to compile and link. Perhaps I didn't get the set 
up entirely right.

On a related matter. A while back you started a linux branch to bring 
the intel/amd noise optimizations to that platform too. Did this effort 
stop due some fundamental reason or just lack of time thus far?

Bill P.

(1) - Before I adopted the habit of doing performance comparisons the 
threads <= cores to get somewhat away from cache-induced performance 
variability.

Post a reply to this message

Am 14.05.2017 um 13:17 schrieb William F Pokorny:
> On 05/14/2017 06:08 AM, clipka wrote:
>> Am 08.05.2017 um 02:13 schrieb green:
>>
>> MS Visual Studio has an option called "Whole Program Optimization",
>> which allows the compiler/linker to optimize stuff looking at the "big
>> picture" rather than just individual source files. Apparently this can
>> cause a mess when programs have source files compiled with AVX
>> instructions enabled and others without, in that the compiler/linker may
>> accidentally "contaminate" the AVX-free portions with calls to portions
>> which happen to have been compiled with AVX instructions enabled.
>>
>>
> Have you done any performance comparisons with and without this
> optimization?

Not before; but running a quick test just now, disabling whole program
optimization seems to give me a 6% performance drop on my machine, so
that settles it for me.


> On a related matter. A while back you started a linux branch to bring
> the intel/amd noise optimizations to that platform too. Did this effort
> stop due some fundamental reason or just lack of time thus far?

I still intend to pursue that path, and as a matter of fact a portion of
the necessary changes had already been part of the codebase for beta 6.
They just didn't enter it via a merge (and I also postponed another
portion of the changes), as they conflicted with the additional
optimizations AMD had provided us with prior to beta 6.

So I've been re-tracing the steps I had made in my `feature/unix_cpu`
branch, and manually porting them on top of those AMD optimizations; and
with the crashes of beta 6 hopefully out of the way now, I intend to
continue that work any day now.

Post a reply to this message

On 05/14/2017 08:15 AM, clipka wrote:
> Am 14.05.2017 um 13:17 schrieb William F Pokorny:
>> On 05/14/2017 06:08 AM, clipka wrote:
>>> Am 08.05.2017 um 02:13 schrieb green:
>>>
>>> MS Visual Studio has an option called "Whole Program Optimization",
>>> which allows the compiler/linker to optimize stuff looking at the "big
>>> picture" rather than just individual source files. Apparently this can
>>> cause a mess when programs have source files compiled with AVX
>>> instructions enabled and others without, in that the compiler/linker may
>>> accidentally "contaminate" the AVX-free portions with calls to portions
>>> which happen to have been compiled with AVX instructions enabled.
>>>
>>>
>> Have you done any performance comparisons with and without this
>> optimization?
>
> Not before; but running a quick test just now, disabling whole program
> optimization seems to give me a 6% performance drop on my machine, so
> that settles it for me.
>
>
Wow, six percent! Thanks for doing the test. Significant enough to look 
again at this sort of optimization with the gnu compiler / linker.

Bill P.

Post a reply to this message