FF4.0 Beta 2: Loops and Recursions!

Quote
In a surprising turn of events, Filter Forge 4.0, initially planned as a boring release with some usability improvements, unexpectedly introduces a new component – ...

Code
function Awesome(msg)   print msg     Awesome(msg + msg)   Awesome(msg + msg) end

Awesome()

Wow! Can't wait to get home and play with this!

Im glad this is seeing the light of day I hope more codeing procedures can be made into premade functions to simplyfy it for artists

Im not nocking the ability to code I have to write code all the time for work. The codeing option is a godsend but for people that dont speak techineese having prebuilt functions is great.

Nope you are doing nothing wrong Davide...I have the same issue with firefox...Even tried to do a right click and save as.....

I think it's really nice, I'm novice when it comes to make filters but I have much fun with this.

I'm glad I saw an iterative tree. XD

"The number of iterations, 5 for this example, is set in the properties of the Loop component."

Can this be controlled with a slider or other input component?

YES!!! Awesome feature for the new FF 4.0!!!!!

Thanks very much for changing of idea and finally including this feature in FF 4.0 as I think it will be very good and useful to have and open a really wide door for new filters that was a pain to do before without this, and this can be a revolution on the possibilities for new filters and ways to do things.

Also would be good to know how to use it in the best possibel way and to learn to how to get the most out of it.

Hints and Tips on how to get the most out of the Loop component

Half the stuff's definitely possible. Might be slow. That's good homework material for you.

With three recursive branches such a loop will top out at 7 iterations, (3^7=2187 loops) but will probably be excruciatingly slow at that point.

Quote
This is seriously the most meaty FF release ever

Is there anything now that can't be done without the Loop component? If every loop can be 'unrolled', I assume there isn't. So do you mean "meaty" in the cosmetic sense? Scripting was pretty big.

Quote
Is there anything now that can't be done without the Loop component? If every loop can be 'unrolled', I assume there isn't. So do you mean "meaty" in the cosmetic sense? Scripting was pretty big.

That argument applies to the rest of the component palette as well, go back to visual studio! No wait.. assembler.. no wait: stones and fire!

(by "meaty" I refer to the fact that FF4 will contain both grouping and recursion .. one might think they'll even add multichannel support! )

xirja, yes, switches et cetera, but there's this thing I'd call prohibitive complexity. Look at the example I posted below. Let's assume that it uses 100 iterations of the subtree. Each iteration has some parameters modified, and some per-iteration increments may be non-linear.

If you wanted to create a filter like that using unrolled loops and switches, I suspect you'd probably end up writing a .ffxml generator that chains the iterations and inserts the increments into proper places programmatically.

There's no question that this cannot be done manually. It's just incredibly inconvenient and hard to debug and refine.

Quote
What do you mean by "multichannel support"?

I mean two additional channel components: Set Auxiliary Channel, Get Auxiliary Channel, which let you slip / extract in some extra non visible channels in the processing chain (to be processed in the same manner as R,G and B). You once mentioned that the internals support this. Why not introduce *external* support also

Actually if we are to use this looping stuff (after the sample cache has been oiled) for stuff like raytracers and bigger renders, we need more channels (i.e. variables) in the loop.

Path pattern -ish.

Quote
As far as I can tell, adding branches to Randomizer, Iteration and Position subcomponents does not seem to incur the exponential recursions problem that happens with Accumulated.

That's because they don't spawn recursive samples as Accumulated does. Also, their get_sample(), in most cases, is very fast (except when you map their inputs with other components).

Also, exponential recursion (with samples at different coordinates) is not a problem, it's a logical consequence of the filter design.

Oh nice, Sphinx!

Threedee, how did you get the Stars to follow the Path?

Very Nice ThreeDee..I was gonna try for following gradients but paths are even better..
Awesome Sphinx.....Guess I got some homework as well Skybase..

Quote
"Native" (no scripting) Julia / Mandelbrot experiment

Wow. A great answer to Loop skeptics.

Sphinx, could you post the filter (or email it to me privately)? I'd like to post a screenshot to CGTalk.

wow.... the magic of fractals.