The Pursuit for Paths

Oh dear, molasses. I was hoping you were on some old machine. As soon as 'BitMap Buffer' and 'Table Memory Limit' are feasible, then matrix math can be used and then no more 'while' function to step through right?

Some Great work ThreeDee..

Quote
Sphinx wrote: I have a 570% faster version of your sine-o-graph running now I will publish when ready

WOW! this is really a good optimization and good news.
Thanks very much.

Yes its all in the script. I use several optimization tricks. I will publish later on

Quote
Morgantao wrote: Actually, if it's all in the script, I won't see the difference... It's like you'd tell me that now the script is in Cantonese instead of Mandarin

Exactly the same for me

BUT I do not care, at least I can use this without knowing how it works.

Actually I posted that link before looking into the actionscript implementation. Just a brief look reveals a very expensive implementation - not suitable to run W*H*Points time..

About the optimizations: I still use the map input, but I use the initialization trick to fetch the points needed for the overall rendering. When you have the points, you can do various precalculations also. The initialization trick used to be even more efficient, but changes in the scripting engine made it slower (now it initializes for each block in each thread, not just once). It is still better than fetching all the points for each sample.

I then made sure that the use of all these expensive math functions were limited to an absolute minimum. Stuff like math.sqrt inside a loop is something you want to avoid. And the algorithm were simplified a bit.. I applied several other optimization tricks - most described in this article:
http://filterforge.com/wiki/index.php...and_Tricks

The attached version renders in 32 sec (vs 7 mins 33 sec original)

Note that it is WIP - I'm currently working on some sort of z input (or scale input) so the gradient might not be 100% identical to your original

Sine-O-Graph One - Sphinxmorphed.ffxml

Ok, now that I've read the code line by line, I have to admit, I'm not sure I follow it everywhere. As far as I can tell, you are calculating the squared distance first and using it to determine which segment is closest. I'm not sure what you are using the variable "r" for, or the reciprocal of the squared distance for that matter. Is it needed because were in the range of 0 to 1 or more directly in the distance calculation?

At least I can't picture it all in my head. Perhaps I should graph it out.

I get that the az is not really used as yet. I imagine you could use it for either z depth of for variable line weight.

TD

That flash implementation of distance to a quadratic bezier curve is, by the way, wrong -- it doesn't find the closest point, just the closest point that is at 90 degree angle fr om the curve segment, which becomes rapidly apparent when you test it with the included flash app.

For instance, it gives the below solution, wh ere the yellow dot on the curve is supposedly the point on the curve that is closest to the red circled dot.

Heh, yeah the downside of the optimization is that the script is a lot harder to read.
Variable r is simply used to determine the segment length: if inside 0..1 range we're between a and b (I think you used a similar approach?). Actually the ramp btwn a and b (the value of r) could be useful as an additional output.

About the table: no that one is not big - its only a 1D table with up to 1000 entries. The table size debate is about w*h sized tables :-S I can't say what is the recommended size limit. I'd keep an eye on the memory usage and performance and then as a general rule of thumb: as long as you're dealing with 1D arrays with a few variables per entry, don't worry about the size.

The reciprocal variable is simply to avoid expensive divisions inside main inner loops, i.e. use a*(1/x) instead of a/x, where 1/x is precalculated.

Btw. check out this script http://forums.codeguru.com/showthread.php?t=194400 I used it as reference implementation, and it is not "ruined" by too many optimizations.

About the bezier stuff.. yeah its no good. I'm afraid there is no continuous solution and we need to generate the whole point series and check one by one. Bye bye performance...

Here's another thought I woke up with this morning. What if we approximated the bezier curve with arc segments instead of straight lines? It is not much more calculation, but we would get very smooth curves at low quality settings. Even 8 segments would give a very nice result if they were done as arcs instead of lines.

Interesting idea - That could greatly limit the number of points needed to inspect.

As you say we would get an infinite number of possible center points on the perpendicular bisector, but with three points from the bezier segment it might be possible. I.e. instead of finding circle center C from A,B, we find circle center D from A,B,C (circumcircle of a triangle, http://local.wasp.uwa.edu.au/~pbourke...clefrom3/).

Since the bezier path generation itself can take place in an initialization section, we don't have to worry too much about generating some extra points..

Right now I'm a bit worried about what comes after... i.e. how to get a continuous line rendering from the circle distances

Real bezier in polynomial time

Render time under one minute. It's a beautiful day!

Next two challenges:

1) Filled shape

2) Helper application for Bezier curve input so that it is possible for humans to input the anchor and control points

Oh boy, this might become exciting! How about making a vector drawing with variable line weight? Or animating the bezier anchor and control points randomly over time?

Here's the filled-shape version you can play with.

Bezier Draw Scrippet 6.ffxml

Quote
ThreeDee Here's the filled-shape version you can play with.

Amazing work, and what I like much more is the showing of the bezier control points!

And as they show in a light and soft way, I have made rendered it in FF and then after went to Photoshop and used the "Shadows & Highlights" tools increasing the highlights about 90% and then all the control points appear sharp and defined

SpaceRay, here's a new version where you can change the colors.

Bezier Draw Scrippet 6A.ffxml

I submitted that version to the library as well under the name Random Bezier Curve, will be easier to find there. Besides, the library is a pretty good place to back up filters -- would have lost many of them over the years had I not had them there.

Quote
Render time under one minute. It's a beautiful day!

Truly! ...and with that filling method, ya man!

Quote
the library is a pretty good place to back up filters -- would have lost many of them over the years had I not had them there.

Aha, so that's what the lightning in your Avatar is all about. Damn EMP zappers!

An unsurprising development

It is insanely difficult to draw anything with it, but here I have used color inputs for position control. There are 30 color inputs (for 10 bezier anchors and 20 controls points) to get something like this. In other words, this shape was actually "drawn" with FF. (Which took about 15 minutes this way as opposed to about 15 seconds with Illustrator.)

Oh yes, and one more idea to be investigated: An unsafe LUA script that saves the selected point information in an external file array of points. This way you would only need 3 color inputs (1 anchor, 2 control points), all points would be read from the external file into the filter each time the controls were moved and the current point would be changed and written to the external file (on checkbox selection, or some such action).

(That is, if LUA can read and write to the local file system.)

Woah!!! Mind blown