 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Thu, 17 Dec 1998 10:14:49 -0800, Jerome M. BERGER wrote:
> > Wouldn't the object pattern used as an isosurface do that?
>
> The proximity pattern would handle rounded edges. The object pattern
> wouldn't work very well as an isosurface, as it's discontinuous and
> piecewise constant.
>
Oups sorry, yes I meant the proximity pattern...
Jerome
--
*******************************
* they'll tell you what can't * mailto:ber### [at] iname com
* be done and why... * http://www.enst.fr/~jberger
* Then do it. *
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> Anyway, the result is that if you want to do bevels or rounds you need
> an algorithm for finding the parallels to quadratic curves (not
> cubics... guess that article won't help much.) Ideally, the algorithm
> would be fast and cheap, because it's likely to get called a lot for
> testing insideness in the beveled region, and probably for doing
> intersection testing as well. I suspect rounded edges would have to
> be approximated by multiple bevels with some normal modification to
> conceal the facets, but if you manage to handle that you could
> produce just about any sort of bevel you might desire (though the code
> would be simplified if you limited the bevel profile to bijective
> mappings from R to R.)
I asked about this on comp.graphics.algorithms and the only reply I recieved
did not sound to encouraging -
Ken <tyl### [at] pacbellnet> wrote:
> If someone knows of some existing code that
> I could look at or a research paper or two on finding parallels to
> quadratic curves I would appreciate the help.
I've posted details of my methods for approximating parallel Bezier curves
in earlier threads this past year. Summary: since you know the locations of
the parallel endpoints and midpoint, as well as the slope at start and finish,
you can compute the locations of the control point(s). This is a closed form
solution that works well in "easy cases".
The general problem is much more difficult: (1) If the parallel distance
exceeds the radius of curvature of the parent curve, the parallel curve will
kink. This is going to happen *often* in parallels to glyph shapes.
(2) Parallels to glyphs shapes will often self-cross, elevating the problem
into constructive planar geometry of curved regions. (3) Etc. I have
extended solutions for these cases but they're too involved to describe here.
You may want to consider polygon approximations rather than the native curves.
The computation is slower but it is already solved.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 04 Jan 2000 14:01:29 -0800, Ken wrote:
>Ken <tyl### [at] pacbellnet> wrote:
>
>> If someone knows of some existing code that
>> I could look at or a research paper or two on finding parallels to
>> quadratic curves I would appreciate the help.
>
>I've posted details of my methods for approximating parallel Bezier curves
>in earlier threads this past year. Summary: since you know the locations of
>the parallel endpoints and midpoint, as well as the slope at start and finish,
>you can compute the locations of the control point(s). This is a closed form
>solution that works well in "easy cases".
That isn't even close to truly parallel, even for "easy cases." There are much
better approximations that can be made; I have an article around here somewhere
that talks about it. Besides, we're not talking about Bezier curves here.
>The general problem is much more difficult: (1) If the parallel distance
>exceeds the radius of curvature of the parent curve, the parallel curve will
>kink. This is going to happen *often* in parallels to glyph shapes.
>(2) Parallels to glyphs shapes will often self-cross, elevating the problem
>into constructive planar geometry of curved regions. (3) Etc. I have
>extended solutions for these cases but they're too involved to describe here.
This, at least, is correct.
>You may want to consider polygon approximations rather than the native curves.
>The computation is slower but it is already solved.
This is what I expected to hear anyway. All is not lost, though - it's not
that hard to approximate the bevels with a bunch of smooth_triangles. It's
just a question of whether it's worth it to put something like that in POV
when there are already external programs that do it so well.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> >You may want to consider polygon approximations rather than the native curves.
> >The computation is slower but it is already solved.
>
> This is what I expected to hear anyway. All is not lost, though - it's not
> that hard to approximate the bevels with a bunch of smooth_triangles. It's
> just a question of whether it's worth it to put something like that in POV
> when there are already external programs that do it so well.
Due to the popularity of the text object in POV-Ray I have little doubt
that there would be a large and appreciative following for this feature.
The limitation with outside text utilities is for the most part the fact
they are usualy triangle meshes which add greatly to scene file size and
do not work or work well in CSG operations. Elefont is a great tool for
what it does but the meshes it produces are seldom well behaved and would
never be reliable in CSG operations if Nathans triangle patch does make
it into the official version. Too many holes in the objects and flipped
normals. If the smooth triangle were generated in POV-Ray at least the
mesh portion of the font would act in a well behaved manner and POV
could keep track of the inside and outside of the object in CSG operations.
--
Ken Tyler - 1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Jan 2000 06:47:50 -0800, Ken wrote:
>The limitation with outside text utilities is for the most part the fact
>they are usualy triangle meshes which add greatly to scene file size and
>do not work or work well in CSG operations. Elefont is a great tool for
>what it does but the meshes it produces are seldom well behaved and would
>never be reliable in CSG operations if Nathans triangle patch does make
>it into the official version. Too many holes in the objects and flipped
>normals. If the smooth triangle were generated in POV-Ray at least the
>mesh portion of the font would act in a well behaved manner and POV
>could keep track of the inside and outside of the object in CSG operations.
Good points. Besides, as I realized soon after I posted this, it wouldn't
be the first time a "primitive" object got turned into a triangle mesh
before rendering.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
