Loop component

Ive looked through the guts of tons of filters that pipe the output into identical components multiple times
While it would not save on render time couldnt you all create a loop component with inputs

for instance zoom blur by uber instead of a ton of repipes you could simply plug a loop component with an integer slider and the user then could select how many times to pipe the effect

again --no this would not reduce render times but it would clean up the code and probably make the code aspect of it more efficient

I'm kinda shocked that this topic really hasn't earned any kind of reply or real attention

Is this just to inconceivable a concept?

+1

+1 Bump! Don't forget this feature request!

voldemort said

Quote
I'm kinda shocked that this topic really hasn't earned any kind of reply or real attention

Skybase said

Quote
+1 Bump! Don't forget this feature request!

And I say that this loop component must be in the list of priorities. So + 1 000 000 000

Orteil +∞

Morgantao +(∞)^2

Ghislaine +∞ x 1000.000.000

Me +∞ x ∞ that would be the same

Is there a bigger number than infinity? What is infinity times infinity?

One important thing to keep in mind about infinity is that it's not really
a number, it's something else. It's a concept that means "something bigger
than all numbers." So there are no numbers bigger than infinity, but that
DOESN'T mean that infinity is the biggest number, because it's not a number
at all. In fact, there is no biggest number, because if you think you've
got it, you can always add one, and you've got something bigger.

Since infinity isn't really a number, it doesn't always make much sense to
multiply it by things, but we can think about doing it anyway. We can say
that infinity x infinity = infinity, and keep in mind that we're being a
little bit sneaky to even talk about multiplication like that.

Will we have to request this feature in a continous loop to FF Inc. until it is finally implemented as it has happened already for many request since FF 1.0 and that are not available yet?

Or will FF Inc. be so kind and good to make this available in FF 4.0 ?

I think this is something very important.

Please, so FF Inc. knows better and can make it as wanted, I think that would be good to explain HOW this component should be done and what options should include

Quote
the limit should be set to some reasonable number.

Define reasonable...
Some would say that 20 is a reasonable maximum ammount of presets per filter

derp.

FEAR NOT IT'S NOT THE SAME AS SCRIPTING!! The idea of macros is like scrippets. You know how you typically copy-and-paste huge loads of nodes? Well imagine bundling the set of operations into 1 component and using that as a component. That's a macro. The ability to bundle a bunch of operations is very very useful because you can nest specific operations instead of having components everywhere.

It makes sense to use the macro as a FOR LOOP since it's a bundled package of a couple nodes. So that basically allows us to expand into different levels of visual complexity without having to find work arounds or copy-and-paste huge loads of the same thing.

I've been thinking about loops / iterators / integrators for quite a while. I have a good idea on how to do that, but we haven't prototyped it yet.

In a nutshell, it will include a new type of connector which I tentatively call "loopback". One end of this connection is forever glued to the Iterator node, and on the other end of it is a thingy resembling a control component. The thingy has an output which can be plugged into any compatible inputs. Technically, the thingy may be similar to IntSlider, Slider or Color, but it is controlled by the Iterator, not by the user.

The trick is, the "loopback thingies" emitted by the Iterator (yes, there can be more than one) cannot be connected to inputs of components outside the subtree of this particular Iterator, and to subtree that have connections that go outside this subtree. Tehcnically, it has output of the same type as the Iterator, and this output must be used within the iterated subtree, otherwise no accumulation / merging is possible.

The loopback thingies, or perhaps the Iterator itself, allows you to specify the value range for the thingy.

Also, the iterator will have another special thingy called Accumulated Result, which lets you specify a component subtree which will combine the accumulated result with the current iteration, be it sum, average, some kind of blend mode or whatever else you can construct from FF components.

The loopback connectors can potentially be used for creating variability per cell in Checker components, per Brick / Tile in the Bricks / Pavement / Tile components, or per particle in the Bomber component. For example, Checker could emit loopbacks like "Cell X Coord", "Cell Y Coord", "Cell Row", "Cell Column" and the like. Since we now have Math components, handling real-world numeric data emitted by loopback connectors shouldn't be a problem for the subtree.

Another interesting use: a Noise component can expose the octaves via loopbacks, so that they can be processed by subtrees before being scaled and summed up into the final noise (could be problematic due to internal octave edge-blending).

Added: in other words, loopback connectors let your subtree "know" what particle, cell, brick, octave or iteration is being sampled at the moment, so the subtree can form the result accordingly.

(I'll draw a picture when I get the chance. Update: see below!)

(Note to myself and programmers: Given the current infrastructure, loopback dongles must be map/green or curvy/blue. They can't be gray because changes of gray inputs require Prepare(). We can't call Prepare() per every sample, that would be slow as hell, especially given the fact that Scripts can have a custom prepare step. If we keep the loopback dongles green/blue, we can do everything during the sampling phase without much problems. Now we only have to find a way to somehow pass the dongle data (or "data for dongle") with the get_sample() call.)

(Related: Houdini seemingly can "cook"/update/data-propagate the network without needing a dedicated prepare() step executed before all sampling. Obviously, that would be a big infrastructural challenge for us. Keeping the dongles green/blue sounds orders of magnitude easier.)

(Another reason why we should avoid making dongles gray: bitmap components. We can't just change blur radius per sample, that would invalidate all rendered cache blocks. Yes, Captain Obvious thinking aloud, but still.)

(Also: the loopback dongles should allow users to manually change their value for preview / tuning purposes, so that the user can tune the subtree. The subtree displayed just for the default values of all dongles would be impossible to tune, users will try to work around this by disconnecting dongles from inputs, entering test values into these inputs, tuning the subtree on them then connecting dongles back.)

(Also: bitmap component would kill dongle metadata. How to deal with this?)

(GUI: Loopback connections, that is the wires that go from Iterator to dongles, aren't free-form. These wires follow rectangular path, have rounded corners and are somehow arranged automatically. This will distinguish them from the regular input-output connections.)

(Lorentz, don't be so scared , this may be years off.)

Which would be an equivalent of this subtree (Rotation is marked with yellow to note that it must be manually changed from component to component in fixed increments, 5 degrees for this example):

Here are a couple I recall bumping into. Typically the conversation never carried that far....

http://www.filterforge.com/forum/read...essage1995
http://www.filterforge.com/forum/read...essage6400
http://www.filterforge.com/forum/read...essage6905
http://www.filterforge.com/forum/read...ssage73017

Back in May this year Uberzev came up with this to do recursions:
http://www.filterforge.com/forum/read...#nav_start

But mentions of "looping" are kinda scattered in the forums.

(Added the links to the wiki "feature wishlist". Thanks, Skybase)

Couldn't find any information on the Memory Blend node. What does it do?

If so, if I understand their looping paradigm correctly, their accumulation methods are limited to blending modes implemented by Memory Blend, because otherwise they would need Memory Distortion, Memory Perlin Noise, Memory Math, Memory HueSaturation, Memory Custom Subtree etc.

Quote
Absolutely. Actually come to think of it, it's pretty much the same thing you've described in the previous posts. It's just that the "blend mode" comes attached to it.

It's similar but it's not the same. In Artmatic, the operation that combines accumulated results with the result of the latest iteration is embedded / hardcoded into Mem* nodes, while in the loopback approach I outlined above this operation is customizable: it is possible to use any subtree of components to implement it.

Quote
there are other types of iterators

Very interesting. I'll take a closer look.

Thanks Vlad for the loop component to come. I'm so glad for this.

(I deleted three posts about my email exchange with Skybase so they don't clutter the thread.)

So I tried Artmatic demo, hoping to play with their Iterator and Looper nodes, but I hit a roadblock I didn't anticipate: I couldn't, for the life of me, figure out how to edit their tree: I mean I couldn't even connect a component's output to an input!

It looks like that I need a full day or two to get familiar with Artmatic tree editing interface, hence this question to Skybase:

Could you explain, in plain words, the conceptual difference between Loopers and Iteration?

I think the following phrase from the user guide contains the key information:

Quote
"After the first iteration, each successive iteration uses the space as transformed in the previous iteration. So, in our example, each new iteration is rotated a bit more. (By contrast, the 1 -> 1 Iterations component uses the same space for each iteration)"

Also, this one:

Quote
The Looper components have three outputs. The first two outputs are the transformed space.

And this one:

Quote

If the iteration is performed by a Looper component, there is an additional step. The output of any component that directly feeds the Looper is fed back into itself in the next iteration. I.e. if Rotate A feeds the looper, the first iteration will rotate unrotated space. The second iteration will feed the result of the first rotation back into the Rotate A component so that the result is a rotation of the rotated space. By feeding the Looper with a compiled tree, very complex transformations can be created.

Do they need this "feed-into-itself" thing because they don't have a generic "Mem-Anything" mechanism that allows for custom-designed accumulation operations, not just blend, max, min etc?

Look at the mockup I posted above. There's nothing that prevents you from plugging the Accumulated Result into the Source input of a Noise Distortion, Rotate, Offset or any other distorter. This way, each iteration will operate on the combined results of all previous iterations, and the accumulation operation will be the distortion itself ("Mem Noise Distortion" in Artmatic terms).

Is this what they mean by Loopers?

Skybase, thank you! And speaking of Quartz Composer, could you give a brief overview of its looping capabilities other than the Iterator node? QC looks much more promising than Artmatic in this regard.

Quote
WOW, you have been using it for 10 YEARS and only recently began to undertand how it works?

Some of us have been using FF since the beta in 2006 and still haven't got it figured out. Like me, for example. It just keeps growing and growing...

I already watched that video (though I didn't yet play with QC, will do that soon).

My question was, are there ways to loop stuff in QC other than the Iterator node?

As I understand, QC term "patch" refers to a native QC node, but what's a "macro"? Is it something similar to FF groups? A patch with sub-patches?

Also: as I see from googling, the Iterator does not allow to feed its output back into its input (which is, I think, something that the Feedback patch should be able to do). If so, the scheme I outlined above will have the capabilities of both Iterator and Feedback.

(Excuse me. I should stop asking stupid questions and go play with the thing myself).