Hi,

I recently posted the thing about text paths.  I've been able to extract
the path data from TrueType fonts.  As far as I've read, this is
quadratic b-spline data.  And I've been able to represent these paths
in a tcl/tk app, which natively uses quadratic b-splines, and everything
looks beautiful.

But when I try to represent these paths in povray using the sphere_sweep
b-spline, things aren't working out so well.  Of course at first I just
thought this was because povray uses cubic b-splines.  And it should be
straightforward to convert a quadratic b-spline into a cubic b-spline.  

But I'm not having any success yet.

I can convert the quadratic b-spline into a set of bezier curves.  And
I can overlay the bezier curves in tcl/tk on top of the quadratic
b-spline curve and they match perfectly.

I thought (and maybe this is where I'm wrong) that a cubic b-spline curve
was nothing more than a bunch of bezier curves strung together with
endpoints joined (and actually removed, being represented by the midpoints
of adjacent control points).  But this does not yield a curve that matches
the original letter shape.  It's close, but the curves are too sharp near
the control points and too flat near the mid-points.

Is my assumption about the relationship between cubic b-splines and
beziers wrong?  Or is povray's sphere_sweep b_spline just some other kind
of curve?  Or am I on the right track, but just making some mistake in
representing the data in the appropriate order?

Thanks,

     tom

Post a reply to this message

Thomas A. Fine wrote:

> Is my assumption about the relationship between cubic b-splines and
> beziers wrong?  

I think in order to combine cubic beziers into cubic b-splines
you will actually, in general, need to repeat the start, end, and
shared intermediate knots 4 times. There may be better solutions
if your curves are not arbitrary and satisfy some smoothness
requirement where you connect them, but it may not be trivial.

Of course, you also need to do degree elevation on the
quadratic bezier curves first:

http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/spline/Bezier/bezier-elev.html

Post a reply to this message

Le 23/11/2010 16:35, Thomas A. Fine nous fit lire :
> Is my assumption about the relationship between cubic b-splines and
> beziers wrong?  Or is povray's sphere_sweep b_spline just some other kind
> of curve?  Or am I on the right track, but just making some mistake in
> representing the data in the appropriate order?
> 

The sphere_sweep object is complex in regard to the type of splines.
(in particular, they are different from the lathe & prism).

For sphere_sweep:
 * linear_spline : reuse the points from one segment to another, need 2
points per segment (the curve (aka line!) go through each point)
 * cubic_spline : reuse the points from one segment to another, need 4
points per segment (preceding, 2 points to go through, next)
cubic_spline is also catmull_rom spline.
 * b_spline : reuse the points from one segment to another, need 4
points per segment (this is not cubic_spline),

For lathe & prism:
 * bezier_spline: group of 4 points not reused per segment: first point
(a), 2 control (b,c) , second point (d). (a,b,c,d)
Recommended that next segment start with (d,...) if continuity is wanted
(you better want that most of the time, but prism can have holes)
 * quadratic_spline: reuse the points from one segment to another, need
3 points per segment : preceding, 2 points to go through.
 * linear_spline, same as sphere_sweep
 * cubic_spline, same as sphere_sweep

And to make matter worse, the spline in SDL is also different (sometime
it maps fine, sometime it's totally different: natural_spline is
unmatched as a shape (lathe/prism/spheresweep), and b_spline is not
available (nor bezier_spline)

(oh, the spline of sor is yet another kind)

Post a reply to this message

On 11/23/2010 03:35 PM, Thomas A. Fine wrote:
> Hi,
>
> I recently posted the thing about text paths.  I've been able to extract
> the path data from TrueType fonts.  As far as I've read, this is
> quadratic b-spline data.  And I've been able to represent these paths
> in a tcl/tk app, which natively uses quadratic b-splines, and everything
> looks beautiful.
>
> But when I try to represent these paths in povray using the sphere_sweep
> b-spline, things aren't working out so well.  Of course at first I just
> thought this was because povray uses cubic b-splines.  And it should be
> straightforward to convert a quadratic b-spline into a cubic b-spline.
>
Have you tried to use spheres+cylinders
instead of sphere_sweep to represent original quadratic paths?
In fact, it might be even faster.

Post a reply to this message

On 11/23/2010 3:47 PM, Le_Forgeron wrote:
> Le 23/11/2010 16:35, Thomas A. Fine nous fit lire :
>> Is my assumption about the relationship between cubic b-splines and
>> beziers wrong?  Or is povray's sphere_sweep b_spline just some other kind
>> of curve?  Or am I on the right track, but just making some mistake in
>> representing the data in the appropriate order?
>>
>
> The sphere_sweep object is complex in regard to the type of splines.
> (in particular, they are different from the lathe&  prism).
>
> For sphere_sweep:
>   * linear_spline : reuse the points from one segment to another, need 2
> points per segment (the curve (aka line!) go through each point)
>   * cubic_spline : reuse the points from one segment to another, need 4
> points per segment (preceding, 2 points to go through, next)
> cubic_spline is also catmull_rom spline.
>   * b_spline : reuse the points from one segment to another, need 4
> points per segment (this is not cubic_spline),
>
> For lathe&  prism:
>   * bezier_spline: group of 4 points not reused per segment: first point
> (a), 2 control (b,c) , second point (d). (a,b,c,d)
> Recommended that next segment start with (d,...) if continuity is wanted
> (you better want that most of the time, but prism can have holes)
>   * quadratic_spline: reuse the points from one segment to another, need
> 3 points per segment : preceding, 2 points to go through.
>   * linear_spline, same as sphere_sweep
>   * cubic_spline, same as sphere_sweep
>
> And to make matter worse, the spline in SDL is also different (sometime
> it maps fine, sometime it's totally different: natural_spline is
> unmatched as a shape (lathe/prism/spheresweep), and b_spline is not
> available (nor bezier_spline)
>
> (oh, the spline of sor is yet another kind)
>
Yeah, biggest hang up is likely that "most" applications use control 
points where the line is not drawn "through" the control points. Likely 
a font works with this, due to the fact that you would need two extra 
control points, which are not part of the line at all, which alter, to 
some extent, where all the rest in the first and last segments end up. 
Other curve types, including, as I understand it, many in POVRay, use a 
version that is less flexible, but which "does" pass directly through 
the controls. With that sort, which is useful for camera movements and 
the like, you can't adjust the curve of each part at all, making them 
sharper or looser, which is, I suspect, how fonts are likely handled.

I think you can convert from "through each point" types, to the more 
adjustable one, using something like the tangents to the control points, 
or some such (I gave up trying to work it out when I realized only one 
type would work for what I wanted anyway, which was a camera/flight 
path... lol), but, without adding more control points, to "flesh out" 
the original curve path (i.e., if its sharper, you need to create a 
curve that matches that path, not just use the control points you 
already have), since the way they are computed is completely different. 
Probably more feasible to convert to a mesh, and manipulate that, using 
the points defining the edge of the mesh which *would* follow the 
correct path (has to, to look right). Using the control points directly 
just won't work, unless you are using a curve type that is computed 
fairly close to the same way (some can likely come close to matching, 
with the right parameters).

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

I take that back, actually. Probably no even possible to "flesh out" a 
path. The reason being that high-adjust-ability paths use both a vector, 
which defines location of the control, and angle *and* a value between 0 
and 1, which determines how "tight" or "loose" the curve gets, from 
nearly formless, to a sharp corner. Needless to say, Catt-mull Rom 
curves have no way to handle either of the later parameters.

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <4cebdf3f$1@news.povray.org>,
Thomas A. Fine <fin### [at] head-cfaharvardedu> wrote:
>I thought (and maybe this is where I'm wrong) that a cubic b-spline curve
>was nothing more than a bunch of bezier curves strung together with
>endpoints joined (and actually removed, being represented by the midpoints
>of adjacent control points).  But this does not yield a curve that matches
>the original letter shape.  It's close, but the curves are too sharp near
>the control points and too flat near the mid-points.
>
>Is my assumption about the relationship between cubic b-splines and
>beziers wrong?  Or is povray's sphere_sweep b_spline just some other kind
>of curve?  Or am I on the right track, but just making some mistake in
>representing the data in the appropriate order?

As it turns out, I was wrong about what "cubic b-spline" means.  I'm
still not entirely clear, and it seems like it may mean different things
to different people, but I think what I had in mind was actually a
cubic bezier spline, which is not the same thing.

And furthermore, I don't even think it's possible.  Or if it is, I haven't
been able to wrap my head around it.  I think the problem is that cubic
b-splines are always C2 continuous, but quadratic b-splines are usually
only C1 continuous.  But I haven't seeen this explicitly confirmed anywhere.

So what I'm doing now is converting the TrueType quadratic b-spline into
a collection of cubic beziers, and converting each bezier into a separate
sphere_sweep.

This works!  Except that I'm finding sphere_sweep to be extremely unstable.
The curve segments randomly blow up in spectacular ways, spewing extra
pixels far and wide.  I'm not talking about the documented black specks on
the curve.  I'm talking about plotting the curve far far away from where the
curve should be plotted.  Is there a known bug here that I could fix by
upgrading my 3.6.1 macports install?

I'm thinking I might need to go with the excellent suggestion from bart of
just decomposing the thing into spheres and cylinders.  This works great
for 2-D drawing. Unfortunately, shading makes seams really obvious so I'll
need to use vastly more increments than I would need in 2-D drawing.  But
it's better than abstract pixel explosions.

	tom

Post a reply to this message

> In article<4cebdf3f$1@news.povray.org>,
> Thomas A. Fine<fin### [at] head-cfaharvardedu>  wrote:
>> I thought (and maybe this is where I'm wrong) that a cubic b-spline curve
>> was nothing more than a bunch of bezier curves strung together with
>> endpoints joined (and actually removed, being represented by the midpoints
>> of adjacent control points).  But this does not yield a curve that matches
>> the original letter shape.  It's close, but the curves are too sharp near
>> the control points and too flat near the mid-points.
>>
>> Is my assumption about the relationship between cubic b-splines and
>> beziers wrong?  Or is povray's sphere_sweep b_spline just some other kind
>> of curve?  Or am I on the right track, but just making some mistake in
>> representing the data in the appropriate order?
>
> As it turns out, I was wrong about what "cubic b-spline" means.  I'm
> still not entirely clear, and it seems like it may mean different things
> to different people, but I think what I had in mind was actually a
> cubic bezier spline, which is not the same thing.
>
> And furthermore, I don't even think it's possible.  Or if it is, I haven't
> been able to wrap my head around it.  I think the problem is that cubic
> b-splines are always C2 continuous, but quadratic b-splines are usually
> only C1 continuous.  But I haven't seeen this explicitly confirmed anywhere.
>
> So what I'm doing now is converting the TrueType quadratic b-spline into
> a collection of cubic beziers, and converting each bezier into a separate
> sphere_sweep.
>
> This works!  Except that I'm finding sphere_sweep to be extremely unstable.
> The curve segments randomly blow up in spectacular ways, spewing extra
> pixels far and wide.  I'm not talking about the documented black specks on
> the curve.  I'm talking about plotting the curve far far away from where the
> curve should be plotted.  Is there a known bug here that I could fix by
> upgrading my 3.6.1 macports install?
>
> I'm thinking I might need to go with the excellent suggestion from bart of
> just decomposing the thing into spheres and cylinders.  This works great
> for 2-D drawing. Unfortunately, shading makes seams really obvious so I'll
> need to use vastly more increments than I would need in 2-D drawing.  But
> it's better than abstract pixel explosions.
>
> 	tom

Long known problem when usint version 3.6.1.

Thing is that sphere_sweep is buggy in 3.6.
They behave beter in version 3.7.
Although version 3.7 is still in beta stage, it's prety robust, you only 
have to update it when a new subversion comes up.



Alain

Post a reply to this message