 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
Preview of image 'qfyd_pete00_jan19_2005.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
Preview of image 'lipkafs81_solvertune.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
