POV-Ray : Newsgroups : povray.beta-test : Sphere sweep: Experimental version Server Time
29 Mar 2024 03:29:26 EDT (-0400)
  Sphere sweep: Experimental version (Message 1 to 8 of 8)  
From: clipka
Subject: Sphere sweep: Experimental version
Date: 15 May 2017 12:46:17
Message: <5919db59$1@news.povray.org>
Folks,

I'm trying out a new approach at fixing the sphere sweep issues; please
give this version a thorough test:

https://github.com/POV-Ray/povray/tree/experimental/sphere_sweep

I'll build Windows binaries as soon as I find the time.


Post a reply to this message

From: William F Pokorny
Subject: Re: Sphere sweep: Experimental version
Date: 16 May 2017 06:35:59
Message: <591ad60f$1@news.povray.org>
On 05/15/2017 12:46 PM, clipka wrote:
> Folks,
>
> I'm trying out a new approach at fixing the sphere sweep issues; please
> give this version a thorough test:
>
> https://github.com/POV-Ray/povray/tree/experimental/sphere_sweep
>
> I'll build Windows binaries as soon as I find the time.
>
Christoph,

Isn't your use of 'i' in the for loop at line 627 of spheresweep.cpp 
muddling with the 'i' (DBL) used later at line 648 ?

I'm going to change the loop var name for now in any case given I'm not 
sure what the compiler will do.

Bill P.


Post a reply to this message

From: clipka
Subject: Re: Sphere sweep: Experimental version
Date: 16 May 2017 07:25:01
Message: <web.591ae15988adb668350257320@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 05/15/2017 12:46 PM, clipka wrote:
> > Folks,
> >
> > I'm trying out a new approach at fixing the sphere sweep issues; please
> > give this version a thorough test:
> >
> > https://github.com/POV-Ray/povray/tree/experimental/sphere_sweep
> >
> > I'll build Windows binaries as soon as I find the time.
> >
> Christoph,
>
> Isn't your use of 'i' in the for loop at line 627 of spheresweep.cpp
> muddling with the 'i' (DBL) used later at line 648 ?

I confess I didn't pay attention to that, but it shouldn't be a problem, as the
C++ standard is pretty clear about what should happen in this situation: The
scope of any variable declared in a `for` statement is limited to that `for`
statement.

If I remember correctly, in old versions of MSVC the scope of such variables
would continue after the loop, but modern versions are standard-compliant by
default.


But yes, it might be prettier to rename that variable to `n` instead.


Post a reply to this message

From: William F Pokorny
Subject: Re: Sphere sweep: Experimental version
Date: 16 May 2017 07:43:39
Message: <591ae5eb$1@news.povray.org>
On 05/15/2017 12:46 PM, clipka wrote:
> Folks,
>
> I'm trying out a new approach at fixing the sphere sweep issues; please
> give this version a thorough test:
>
> https://github.com/POV-Ray/povray/tree/experimental/sphere_sweep
>
> I'll build Windows binaries as soon as I find the time.
>
Absolutely a big improvement across my problem sphere_sweep problem 
collection - and more or less at speed.

1) We still sometimes get noise in the end result which I think AA will 
mostly clean up. The nosiest example is yours from Github #147:

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

see the attached: LipkaFS81_Apr2010_Example.png image.

2) There is still too the ill formed polynomial into the solver planar 
when the segment coordinates are planar and the ray is perpendicular to 
the plane. See: Qfyd_Pete00_Jan19_2005.png where the scene is set up 
with an orthographic camera and the b_spline is in a plane perpendicular 
to all camera rays.

For such situations I was playing with the idea of checking for this 
special ill formed polynomial case; finding the ray intersection with th 
plane; testing if the point was this->Inside the sphere_sweep (the 
inside root solver test appears to be pretty stable result wise); then 
doing some magic with perturbed inside points I'd not sorted out... Code 
I have isn't too long so I'll include it too as an attachment with the 
thought you can probably get to a solution this faster than I can.

3) We are still exposed some to badly formed input splines. The original 
FS81/GH147 is somewhat this case. Thought about adding some sanity 
testing in the parser. Doing this generally is probably not possible, 
but perhaps something like control point spacing > some multiple of the 
max of the two radius values would make some sense. Is it worth it?

Bill P.


Post a reply to this message


Attachments:
Download 'lipkafs81_apr2010_example.png' (32 KB) Download 'qfyd_pete00_jan19_2005.png' (12 KB) Download 'workingcodefor2.txt' (3 KB)

Preview of image 'lipkafs81_apr2010_example.png'
lipkafs81_apr2010_example.png

Preview of image 'qfyd_pete00_jan19_2005.png'
qfyd_pete00_jan19_2005.png

From: clipka
Subject: Re: Sphere sweep: Experimental version
Date: 16 May 2017 08:52:47
Message: <591af61f$1@news.povray.org>
Am 16.05.2017 um 13:43 schrieb William F Pokorny:
> On 05/15/2017 12:46 PM, clipka wrote:
>> Folks,
>>
>> I'm trying out a new approach at fixing the sphere sweep issues; please
>> give this version a thorough test:
>>
>> https://github.com/POV-Ray/povray/tree/experimental/sphere_sweep
>>
>> I'll build Windows binaries as soon as I find the time.
>>
> Absolutely a big improvement across my problem sphere_sweep problem
> collection - and more or less at speed.

I love to hear this.

Did you notice any new artifacts whatsoever?


> 1) We still sometimes get noise in the end result which I think AA will
> mostly clean up. The nosiest example is yours from Github #147:
> 
> https://github.com/POV-Ray/povray/issues/147
> 
> see the attached: LipkaFS81_Apr2010_Example.png image.

Note that this example, too, is a "planar" sphere_sweep, with all center
points on a plane perpendicular to the camera direction. I'd suspect a
connection there.


> 2) There is still too the ill formed polynomial into the solver planar
> when the segment coordinates are planar and the ray is perpendicular to
> the plane. See: Qfyd_Pete00_Jan19_2005.png where the scene is set up
> with an orthographic camera and the b_spline is in a plane perpendicular
> to all camera rays.
> 
> For such situations I was playing with the idea of checking for this
> special ill formed polynomial case; finding the ray intersection with th
> plane; testing if the point was this->Inside the sphere_sweep (the
> inside root solver test appears to be pretty stable result wise); then
> doing some magic with perturbed inside points I'd not sorted out... Code
> I have isn't too long so I'll include it too as an attachment with the
> thought you can probably get to a solution this faster than I can.

I must confess I can't yet claim to understand what you (or Massimo
Valentini) are trying to say.


> 3) We are still exposed some to badly formed input splines. The original
> FS81/GH147 is somewhat this case. Thought about adding some sanity
> testing in the parser. Doing this generally is probably not possible,
> but perhaps something like control point spacing > some multiple of the
> max of the two radius values would make some sense. Is it worth it?

Don't. Splines with very close control points can still be perfectly
well-behaved, and people might even deliberately generate them to get a
very close smooth approximation of some other curve.


Post a reply to this message

From: William F Pokorny
Subject: Re: Sphere sweep: Experimental version
Date: 16 May 2017 10:51:00
Message: <591b11d4$1@news.povray.org>
On 05/16/2017 08:52 AM, clipka wrote:
> Am 16.05.2017 um 13:43 schrieb William F Pokorny:
>
> Did you notice any new artifacts whatsoever?
>

No. Unless somebody turns up some issue I think we should go with your 
update.

>
>> 1) We still sometimes get noise in the end result which I think AA will
>> mostly clean up. The nosiest example is yours from Github #147:
>>
>> https://github.com/POV-Ray/povray/issues/147
>>
>> see the attached: LipkaFS81_Apr2010_Example.png image.
>
> Note that this example, too, is a "planar" sphere_sweep, with all center
> points on a plane perpendicular to the camera direction. I'd suspect a
> connection there.
>

I'm certainly not claiming to be an expert, but the way I currently see 
it is that our solver is capable of handling everything up to the 
ray/plane (I think also ray axis alignments in play(1)) alignments - if 
we adjust current hard coded internal controls to allow it. See the 
attached image LipkaFS81_SolverTune.png where I have done this.

(1) The axis alignment issues are why I think we sometimes see seams in 
polynomial based shapes. Changing camera position, scale etc can all 
"solve" these seam artifacts, but the fundamental issue is the solver 
cannot reliably handle particular "alignments."

LipkaFS81_NearPerpAsPlane.png is an image, using a hack based on the 
code I posted earlier, showing rays near-ish perpendicular as a, clipped 
by sphere sweep, plane. So yes, we do have rays getting near 
perpendicular, but I think there is no fundamental issue with finding 
the roots until we are ray / plane / axis aligned within numerical 
accuracy. At that point the polynomial is "ill-formed" and we HAVE to do 
something different if we want reliable roots.

Use of the orthogonal camera will tend to bring out the ill-formed 
polynomial issues.

I've been looking some at our solver code and reading up, but theory, 
algorithms and code all new & a big stretch for me. I've no idea at the 
moment how to fix the fundamental ray / axis alignment issue in our 
solver. Perhaps it must be handled by analyzing and pre-conditioning the 
polynomials used in some fashion. Basically I don't know what I'm doing. 
:-)

As an aside AA itself sometimes fixes things given it changes ray / 
"object" relationships.

Apologies to all for the gibberish I sometimes write.

Bill P.


Post a reply to this message


Attachments:
Download 'lipkafs81_nearperpasplane.png' (13 KB) Download 'lipkafs81_solvertune.png' (31 KB)

Preview of image 'lipkafs81_nearperpasplane.png'
lipkafs81_nearperpasplane.png

Preview of image 'lipkafs81_solvertune.png'
lipkafs81_solvertune.png


 

From: William F Pokorny
Subject: Re: Sphere sweep: Experimental version
Date: 16 May 2017 11:03:15
Message: <591b14b3$1@news.povray.org>
On 05/16/2017 07:24 AM, clipka wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> But yes, it might be prettier to rename that variable to `n` instead.
>
>

Perhaps remove the extra scope braces in SphereSweep::Compute_BBox when 
you do this?

At or about line 1336:

     else
     {
         for (i = 0; i < Num_Modeling_Spheres; i++)
         {
             { // Extra
                 mins = min(mins, Modeling_Sphere[i].Center - 
Vector3d(fabs(Modeling_Sphere[i].Radius)));
                 maxs = max(maxs, Modeling_Sphere[i].Center + 
Vector3d(fabs(Modeling_Sphere[i].Radius)));
             } // Extra
         }
     }

Bill P.


Post a reply to this message

From: clipka
Subject: Re: Sphere sweep: Experimental version
Date: 16 May 2017 12:36:04
Message: <591b2a74$1@news.povray.org>
FYI,

the latest sphere sweep changes have now been carried over into the
official 3.7.1 branch:

    https://github.com/POV-Ray/povray/tree/release/v3.7.1

Which means that they'll also be included in the next beta.

(The `experimental/sphere_sweep` branch has been ditched, so don't be
surprised if the link posted earlier leads nowhere now.)


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.