Order of operations questions

You'd want to put any off/on switches near the result component. If you turn "off" the slow parts of the filter, the program will skip over them entirely.

Quote
Sphinx. wrote: Thus a filter like Crapadilla's Maze 2D would run double as fast if he performed threshold clipping of the wall layers, and he could virtually add as many wall layers as he wanted without much more overhead than calculating whats actually visible Devil Grin

Very, very interesting... your mod runs about 33% faster on my old machine! Gotta look into that!

I'm wondering though, would this technique also be applicable to my Wind Blur filter?

Quote
Sphinx. wrote: The threshold component can be used in a more customizable way to perform smart selection of branches (or "clipping").

It appears you should enlighten us all with an 'Optimizing via Thresholds' wiki article?

Quote
Sphinx. wrote: Several components (NOT the blend) can do internal switch like branch selection.

So a masked blend would still evaluate both foreground and background inputs? In that case it would appear preferable to use threshold instead of blend whenever possible, no?

Quote
Sphinx. wrote: Yeah, in many cases its more optimal to use the threshold instead of the blend, even for "blending" operations.

----Sometimes it (using threshold) seems to be about the only way to get a proper layered look or *blend* of 2 components (depending on what kind of overlay type design you are working on). I didn't know it was more optimal too, guess that's just a bonus eh.

jffe

Quote
Sphinx. wrote: Several components (NOT the blend) can do internal switch like branch selection. Take for example the checker component, the areas of color 1 input only fetches samples from that source branch.

So which components would that be? We've got:

* Threshold
* Checker

I'm guessing:

* Frame
* 3-Color-Gradient
* 5-Color Gradient
* Profile Gradient
* Bricks
* Pavements
* Tiles

Quote
Crapadilla wrote: * Threshold * Checker I'm guessing: * Frame * 3-Color-Gradient * 5-Color Gradient * Profile Gradient * Bricks * Pavements * Tiles

The gradients seem to fetch all color inputs no matter the curve type (i.e. a sharp step curve wont divide the sourcefetching corresponding to the areas).

The thing about the checker is that you can use it to cache constant values like the rotation construction you use in the Maze 2D filter. Using solid fill and as large checkers as possible (Repeat H/V = 1), the sample for a given quadrant will only be fetched once. This method works best if the branch does not undergo drastic distortions, because what we utilize here is the assumption that the rasterization is performed from top left to bottom right in a scanline progressive manner (or roughly close to that).

The optimal component for this kind of use would be one that only fetches one sample for the complete rendering (i.e. the first sample is used during the rest of the rendering), but we don't have that.

All components that have a solid fill option can theoretically be used for caching constant values - the checker component seems to be the fastest though.

Quote
Crapadilla wrote: Croax, you might want to read this thread from start to finish, if you haven't yet. In that thread we discuss - pretty in-depth - how FF samples and caches samples. Vladimir also chimes in and elaborates on our assumptions. Very interesting read that still waits to have a wiki article distilled from it! Wink

Ahh that thread discussion was really good - I just reread the whole thing.. I like how we start from total ignorance regarding the sample cache, and end up finding out all sorts of interesting things about the system

I'll see if I can find some time for updating the wiki.. no promises though!

Quote
Crapadilla wrote: Croax, you might want to read this thread from start to finish, if you haven't yet. In that thread we discuss - pretty in-depth - how FF samples and caches samples. Vladimir also chimes in and elaborates on our assumptions.

Whoa... read it, yes. Understand it: no. Your wiki page makes much more sense to me. LINK

Quote
KGtheway2B wrote: The threshold component can be used in a more customizable way to perform smart selection of branches (or "clipping").

So, buy using threshold to blend, you don't calculate then unseen bits, but using blends it is all calculated? That seems like a pretty major difference...

You know, it would be great to have some kind filter speed score within the Filter Forge filter editor. Just a benchmark standard, to help people learn how things are made more efficient.

Quote
Sphinx. wrote: The sample fetching goes "backward" (reverse direction of the link arrows), so if you have something like A -> B -> C, C fetches from B and B from A. Several components (NOT the blend) can do internal switch like branch selection. Take for example the checker component, the areas of color 1 input only fetches samples from that source branch.

Aha. Good info. This article, which you wrote explaining it, is very helpful btw: LINK

Quote
CorvusCroax wrote: I've been putting all my filter controls way at the beginning

Sometimes that can't be avoided...

Sorry for the naïve interruption here, but would somebody mind explaining exactly what you mean by using threshold for blending?

Quote
rgoer wrote: Sorry for the naïve interruption here, but would somebody mind explaining exactly what you mean by using threshold for blending?

This might help clear some things up. Scroll down to the example with the smilies...

I've started to use threshold for blending purposes now. Good stuff. In many cases it cuts out extra steps I've been putting in.