![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 22 Aug 2000 12:23:01 -0500, Chris Huff wrote:
>In article <slr### [at] fwi com>, ron### [at] povray org
>wrote:
>
>> Even linear spline prisms? Whyever for? There's a simple procedure to
>> determine the distance of a point from an arbitrary polygon[1]. The
>> proximity is then the minimum over all the edges and the two caps of the
>> prism.
>
>Because I didn't know this algorithm. :-)
>Hmm, does this take the caps into account? It looks like an infinitely
>long prism(or proximity to a polygon in a 2D plane).
Yes, it does take the caps into account. You find the distance to each face,
including the two caps, using the method described, then find the minimum.
None of what I described is in 2D.
>BTW, what exactly do you mean by "continuously differentiable"? Do you
>mean that the function may be continuous but the derivative may not be?
>Where would the function "break"?
Exactly. It "breaks" in the "corners." For example, in the interior of a
square, the 2D version of a proximity pattern is undifferentiable along
the diagonals of the square (as you cross the diagonal, the derivative of
the proximity function abrubtly changes sign and possibly magnitude) and
on the edges (the function is undifferentiable wherever it has a value of
zero, since it is the absolute value of a different function.)
What this means to the isosurface solver is that if it happens to look at
the wrong points, it may miss some intersections. What really sucks is
that the function is undifferentiable in exactly the same places that the
object pattern is discontinuous (and thus undifferentiable as well), and
probably in other places as well.
You can remove some of the areas of concern by making a proximity function
that returns negative values for points on the inside of the shape, but
you can't remove them all.
This problem is not unique to prisms and meshes, either. The proximity
function is undifferentiable at the center of a sphere, too.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <slr### [at] fwi com>, ron### [at] povray org
wrote:
> Yes, it does take the caps into account. You find the distance to
> each face, including the two caps, using the method described, then
> find the minimum. None of what I described is in 2D.
Ok, I will have to take a closer look at this algorithm...
> You can remove some of the areas of concern by making a proximity
> function that returns negative values for points on the inside of the
> shape, but you can't remove them all.
One way to flip the inner function's sign would be to use an object
pattern, though I may add this capability to the pattern itself.
And wouldn't this remove *all* the areas which are causing trouble with
the object pattern? There are still other areas, but this would remove
the problem at the surface of the proximity object, which is where the
discontinuity is with the object pattern.
> This problem is not unique to prisms and meshes, either. The proximity
> function is undifferentiable at the center of a sphere, too.
And the axis of a cylinder/cone, and a circle along the major radius of
a torus, I think...actually, I think all objects generated from a
proximity function would have this problem, fortunately, it doesn't
always appear. Isn't the maximum gradient used to help prevent missing
these intersections?
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 22 Aug 2000 17:06:35 -0500, Chris Huff wrote:
>One way to flip the inner function's sign would be to use an object
>pattern, though I may add this capability to the pattern itself.
>And wouldn't this remove *all* the areas which are causing trouble with
>the object pattern?
Yes. That is, it'd remove the surface of the object.
>And the axis of a cylinder/cone
Actually, not the axis. For a cylinder, two cones at the ends, and the line
segment connecting their apexes. For a cone, a different cone at the base
and the line segment connecting its apex with the containing cone.
There are external places where it's undifferentiable as well.
>Isn't the maximum gradient used to help prevent missing
>these intersections?
No. It's used to help the solving algorithm know when there can't possibly
be a solution in the test interval. I've been thinking about the problem,
though, and I think it might be okay after all if there are some isolated
spots where it's not differentiable, so long as it's continuous. After all,
min/max have the same problem. This whole thread may be a false alarm.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |