 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greetings,
There seems to be some talented patch warriors in the groups these
days and perhaps one of you would like to tackle a new challenge.
How about a method of auto beveling and or rounding the face of
text objects ?
Certainly there are methods to do this outside the text object by
using lots of CSG or it can be done by way of third party programs
but I have little doubt that it would make a lot of people happy to
have this ability as an internal function of the text object in
POV-Ray itself.
Any takers ?
--
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !
Ken Tyler - 1200+ 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbell net> wrote:
: How about a method of auto beveling and or rounding the face of
: text objects ?
It would be really cool if it was possible to specify the smoothness
of the surfaces of the text objects. This would be achieved by modifying
the normal of the (front and back) surface (now the surface is just flat).
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 16 Dec 1999 23:05:15 -0800, Ken wrote:
> There seems to be some talented patch warriors in the groups these
>days and perhaps one of you would like to tackle a new challenge.
>
> How about a method of auto beveling and or rounding the face of
>text objects ?
For my contribution, I can dig up a paper I was reading the other
day on piecewise cubic approximation of parallels to cubic bezier
curves.
--
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:
>
> On Thu, 16 Dec 1999 23:05:15 -0800, Ken wrote:
>
> > There seems to be some talented patch warriors in the groups these
> >days and perhaps one of you would like to tackle a new challenge.
> >
> > How about a method of auto beveling and or rounding the face of
> >text objects ?
>
> For my contribution, I can dig up a paper I was reading the other
> day on piecewise cubic approximation of parallels to cubic bezier
> curves.
As you are one of those who would probably know how is the text object
represented internaly ?
--
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 Dec 1999 05:46:22 -0800, Ken wrote:
>
>
>Ron Parker wrote:
>>
>> On Thu, 16 Dec 1999 23:05:15 -0800, Ken wrote:
>>
>> > There seems to be some talented patch warriors in the groups these
>> >days and perhaps one of you would like to tackle a new challenge.
>> >
>> > How about a method of auto beveling and or rounding the face of
>> >text objects ?
>>
>> For my contribution, I can dig up a paper I was reading the other
>> day on piecewise cubic approximation of parallels to cubic bezier
>> curves.
>
>As you are one of those who would probably know how is the text object
>represented internaly ?
There's a good chance of it.
It's represented as a CSG union, with each glyph being a separate object.
A glyph is represented internally as a series of quadratic curves.
To test for insideness, POV first makes sure the point is between the front
and back planes of the glyph, then makes sure the projection of the point
into X,Y space falls inside the glyph representation by counting crossings.
To intersect a ray, POV first finds the intersection points of the ray
with the front and back planes. Those points are projected onto the plane
and tested to make sure they're inside the glyph representation before
being pushed onto the intersection stack. Finally, it projects the ray
itself into the plane (skipping the case where the ray is parallel to the
extrusion direction) and tests the projection of the ray against each curve
in the glyph representation.
Clear as mud, right?
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.)
--
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:
> It's represented as a CSG union, with each glyph being a separate object.
> A glyph is represented internally as a series of quadratic curves.
> Clear as mud, right?
Absotutely !
Thank you for your explaination. I think I got about 50% of it and that is
more than I expected after the first glance I took at your reply.
--
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>For my contribution, I can dig up a paper I was reading the other
>day on piecewise cubic approximation of parallels to cubic bezier
>curves.
I have no idea what you just said, but it sounds intelligent, so good luck
with this new project. =)
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.)
http://www.math.niu.edu/~rusin/papers/known-math/95/equiv.cls ???
--
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !
Ken Tyler - 1200+ 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Greetings,
>
> There seems to be some talented patch warriors in the groups these
> days and perhaps one of you would like to tackle a new challenge.
>
> How about a method of auto beveling and or rounding the face of
> text objects ?
>
> Certainly there are methods to do this outside the text object by
> using lots of CSG or it can be done by way of third party programs
> but I have little doubt that it would make a lot of people happy to
> have this ability as an internal function of the text object in
> POV-Ray itself.
>
> Any takers ?
>
Wouldn't the object pattern used as an isosurface do that?
Jerome
--
*******************************
* Always listen to experts, * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why... * http://www.enst.fr/~jberger
* Then do it. *
*******************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
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:
>
> 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
--
*******************************
* Always listen to experts, * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* 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
|
|
| |
| |
|
|
|
|
| |
