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