wrote me saying that he's doing a real external for this, so that would
be a better solution.
Why is an external a better solution ?
isn't a hard coded external always more efficient than an abstraction,
specially if tcl/tk and gop are involved? I thought so.
Anyway. I was inspired to make a bézier patch. It's an integer solution,
so, for 17 points I run t from 0 to 16 instead of to 1, then I divide by
pow(16,3) at the end to compensate. I could redo it in floats with almost
the same number of boxes though.
Here's the screenshot of the whole patch :
http://gridflow.ca/gallery/bezier.png
It takes only 9 (nine) objects to compute it. For large numbers of
points,
I can add a cache using two more boxes. Float requires two extra boxes
(and editing some more). Using a different order doesn't require any
repatching, just edit three or four boxes to change some numbers (I'm not
counting the fact that you have to recreate the multi-numberbox at the
right to have more rows). When I count the objects I'm not counting the
multi-numberbox nor any of the objects on the left. The wire that goes up
is carrying the polygons ready to be rendered.
I have my patch in the other computer, can't send it now. my patch shows
only a gop with the line (array) and 4 control points, which can be moved
around with the mouse. it's also possible to dump the present coordinates
of the points, and to feed others into the array. so it can be used
graphically or with parameters.
there are also a couple other details, and other things I want to do, but
won't have the time for now.
if I remember, I can send the current version tomorrow.
João
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
