POV-Ray : Newsgroups : povray.unofficial.patches : Font Patch/Feature Request : Re: Font Patch/Feature Request Server Time
2 Sep 2024 14:17:02 EDT (-0400)
  Re: Font Patch/Feature Request  
From: Ron Parker
Date: 17 Dec 1999 09:27:03
Message: <385a4837@news.povray.org>
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

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