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