Filter Forge Changelog

What's new in Filter Forge 7.0

Nov 17, 2017

The key feature of Filter Forge 7.0 is simultaneous render and export of render channels that generate special texture maps used in 3D packages and game engines. It will save much time and effort for all 3D artists using Filter Forge.
The rewritten rendering engine can speed up lots of filters. Most filters can benefit from the new sample cache architecture, and in quite a few lucky cases the improvement is in double digits.
The new Copy and Paste commands enable interoperability with any graphic editor regardless of its plug-in support. They preserve the image precision and HDR colors and thus allow for filter stacking: users can now copy the rendered image and paste it back into Filter Forge to apply another filter.
For filter creators, Filter Forge 7.0 introduces mappable list and slider inputs that were added to 47 existing components. The new input types give filter authors more expressive power by allowing parameter mapping, the foundational principle of Filter Forge, to be applied to component parameters defined by lists and sliders.

New in Filter Forge 6.006 (Jan 5, 2017)

New in Filter Forge 6.005 (Nov 21, 2016)

New in Filter Forge 5.009 (Mar 9, 2016)

New in Filter Forge 5.0 Beta 2 (Jul 16, 2015)

New in Filter Forge 4.014 (Jun 18, 2015)

New in Filter Forge 4.013 (Dec 24, 2014)

New in Filter Forge 5.0 Beta 1 (Dec 9, 2014)

New in Filter Forge 4.012 (Nov 26, 2014)

New in Filter Forge 4.011 (Sep 25, 2014)

New in Filter Forge 4.010 (May 1, 2014)

New in Filter Forge 4.009 (Jan 25, 2014)

New in Filter Forge 4.008 (Jan 17, 2014)

New in Filter Forge 3.0.15 (Dec 14, 2013)

New in Filter Forge 4.0 Beta 5 (Nov 9, 2013)

New in Filter Forge 4.0 Beta 4 (Jun 5, 2013)

New in Filter Forge 3.0.14 (May 7, 2013)

New in Filter Forge 4.0 Beta 2 (Mar 19, 2013)

Loops and Recursions:
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 – and a paradigm – that adds a whole new dimension to filter creation.
Loop is immensely powerful: it brings two key concepts of programming – nested loops and recursions – into a visual environment of Filter Forge, in a way that doesn't require you to write any code. Arguably, this is the biggest addition to Filter Forge since version 1.0 in terms of image generation abilities.
However, proceed with caution. At the core of the Loop component lies recursion, a concept adapted from programming languages with all its benefits and hazards (such as potential exponential growth in rendering time). Unlike many other Filter Forge components that produce visible results no matter how you connect them, Loops require a more deliberate approach. That's why we put them into the new Advanced component category, together with Scripts.
How Loop Works:
In programming, a loop is a construct that repeats a certain sequence of commands multiple times, with possible variation from iteration to iteration. Similarly, the new Loop component in Filter Forge lets you render a subtree of components multiple times and combine results of all these iterations into a single output image.
Slave Components:
The Loop component cannot work without its slave components. Slave components are permanently linked to their master Loop and cannot be detached. Their outputs should be connected to the subtree of their master component, otherwise they will have no effect on the output of the Loop component.
The key thing to understand about slave components is that their output changes depending on the current Loop iteration. This means that you can use them to vary any number of parameters in the iterated subtree from iteration to iteration.
The Loop component has four slave components: Accumulated, Position, Iteration and Randomizer:
The Accumulated slave component outputs the combined result of all previous Loop iterations, which is then combined with the result of the current iteration and fed into Loop’s Accumulator input. This slave component is necessary for any Loop to work and cannot have multiple copies.
The optional Position slave component outputs the ‘completion percentage’ of the Loop as normalized iteration number converted to color.
The optional Iteration slave component outputs raw iteration number as an HDR color with RGB values corresponding to the number of current iteration (1, 2, 3...).
The optional Randomizer slave component produces a normalized random value (converted to color) that is unique for each loop iteration. Multiple Randomizers can have different Variation settings (i.e. random seeds).
You can have multiple slave components linked to a single Loop (except Accumulated, which cannot have multiple copies). This example uses multiple Randomizers, each with their own color range and Variation (i.e. random seed) for randomizing multiple inputs of the Loop subtree:
Nested Loops:
Loops can be nested. In the example below, an inner loop creates a row of 5 circles, which is then duplicated 5 times by the outer loop. Note that slave components of the outer loop can affect components in the subtree of the inner loop:
Loops Are Recursions:
Technically, all loops in Filter Forge are recursions. In programming, recursion occurs when a function calls itself once or multiple times. In Filter Forge, recursion means a subtree of components plugged into itself, i.e. one that takes its own output as an input.
That's exactly what the Loop component does: essentially, it provides user interface and internal logic (most importantly, the termination condition) for circular connections. Otherwise, such connections are not allowed by Filter Forge.
Caution: Recursions Are Explosive!:
When we say "recursion" we mean it: internally, Filter Forge's loops are implemented via recursive calls to the sampling function of the subtree connected to the Accumulator input of the Loop component. So if you're not careful with the number of recursive calls (i.e. sampling calls to Accumulated), you get a recursion growing exponentially.
Consider, for example, this innocent-looking loop evaluating 3 components over 7 iterations:
If you unroll this loop by creating the corresponding component tree manually, here's what you get:
That's 3 * (1 + 2 + 4 + 8 + 16 + 32 + 64) = 381 components that must be evaluated in order to render the result. Increase the iteration count from 7 to 8 and boom, you get 3 * (1 + 2 + 4 + 8 + 16 + 32 + 64 + 128) = 765 components: the number of components basically doubles with every additional iteration! Wait, it gets worse: if you change the loop subtree so that it sends three samples to Accumulated instead of two as shown above, you'll get 3 * (1 + 3 + 9 + 27 + 81 + 243 + 729 + 2187) = 9840 components!
The technical term for this is exponential recursion. In programming, it occurs when a function calls itself more than once, and in Filter Forge it occurs when the Loop subtree requests more than one sample from the Accumulated slave component.
When you have an exponential recursion with a relatively high number of iterations in your filter (which can be as low as 7 or 8), the rendering times may grow so big that you may never see any rendered result. Thankfully, Filter Forge's user interface remains (somewhat) responsive during such explosions, so you can dial the number of loop iterations down.
Here are three rules of thumb for keeping exponential recursions in check:
Keep the number of Loop iterations as low as possible.
Minimize the number of sampling calls to Accumulated. That is, all components in the Loop subtree between the Accumulated slave component and the Accumulator input of the Loop should all have as few outgoing connections as possible:
To be more precise, this rule talks about samples requested from Accumulated at different coordinates, for example by components such as Noise Distortion, Rotation or Offset. If multiple samples hit Accumulated at the same coordinates, Filter Forge's sample cache may be able to prevent additional sample calls. However, sample cache implementation is different from component to component, so this solution may not work for some components.
To avoid exponential recursions altogether, limit the number of samples to Accumulated to one per loop, as shown below. Such recursions unroll into neat linear chains of components, as opposed to ever-branching trees of exponential recursions:
Also note that limiting the number of samples to Accumulated won't help you deal with components that sample their inputs multiple times at different coordinates, such as Edge Detector and Derivative. Having a single such component in a loop between Accumulated and Accumulator guarantees an exponential recursion.
Limitations of Loops:
The maximum number of nested loops is 16.
The maximum number of iterations in a single loop is 1000.
The maximum total number of iterations of all loops combined is 3000 when there are no Script components inside the loop, and 1000 when a Script component is present in the loop. If the limit is exceeded in the latter case, a Lua script error “C stack overflow” will occur.
Bitmap-based components such as Blur, Sharpen or High Pass cannot be used inside the loop. That would require rebuilding the entire input and output bitmap caches for each such component for each loop iteration, which would lead to insane memory requirements.
Numeric (gray) inputs of the subtree cannot receive values that differ from iteration to iteration. This is because all slave components of the Loop are of the Map type (green), and thus cannot be connected to numeric inputs.

New in Filter Forge 4.0 Beta 1 (Mar 19, 2013)

Groups and Instancing:
Until version 4.0, Filter Forge had no way of organizing filter complexity or abstracting it away. To simplify the creation of complex filters, Filter Forge 4.0 introduces groups that let you “package” reusable parts of the filter tree into custom-made components with user-definable inputs and parameter.
Creating Groups:
Creating groups is very easy. Just select components you want to group and click the Group button that has been added to the top toolbar of the Filter Editor.
When you click the button, Filter Forge creates a group with all the selected components inside, adds an input for every inbound connection, and uses the outgoing connection as the output. One caveat though: when selecting components to be grouped, make sure that they don't have more than one outgoing connection – the resulting group must have a single output.
Editing Groups:
To edit a group, you just double-click it, and edit its contents just like you would edit a filter. You can add, change or remove control components to modify the group inputs, or you can edit the component tree to alter the resulting image (or the curve – yes, curve components can be grouped too!) When you're done editing, just click the Back link in the group navigation bar.
Adding Inputs:
A group can have an arbitrary number of custom inputs, such as colors, sliders or checkboxes. To define group inputs, Filter Forge uses Control Components, which now serve a dual purpose: in addition to their usual role of defining filter controls, they can now define group inputs when placed within a group.
Ungrouping:
To ungroup, simply select the group and hit the Ungroup button on the toolbar. However, be aware that this may not bring the filter tree into exactly same state as it was before grouping. For example, grouping may automatically create control components inside the group to serve as inputs, and when you ungroup the group, these components will appear despite the fact you haven't created them manually before grouping. Groups are not meant as a GUI tool for quickly hiding and unhiding unwanted parts of the component tree – instead, it is a way of creating custom components, so use them wisely and strategically.
Navigating Nested Groups:
Filter Forge supports group nesting: a group can contain any number of other groups. Navigating such group hierarchy sounds complicated, but actually it's easy: the new Group Navigation Bar lets you view the “breadcrumb trail” of the groups you went through. Clicking the group names lets you jump one level back or directly to a specified level of the group hierarchy.
Instancing:
Instancing lets you create multiple groups that are linked together, so that when you modify the contents (but not the input values) of an instanced group, all other instances are automatically updated. This is useful when you want to use the same group in multiple places in the filter tree. Instancing eliminates the hassle of manually updating each copy of the group every time you make a change to the “master group”.
All instances of the same group are equal: there’s no dedicated “master” among them – you can edit any of the instances to update the others.
After taking the above screenshot, we edited the contents of one of the groups to replace the checkerboard texture with a particle pattern, and the other two instances updated automatically. Note that all the instances retained their Color settings and other input values.
To create an instanced group, just copy and paste a group: by default, groups are pasted as instances. To detach a group from instancing (so that editing its internals does not affect its other copies), select the box titled “Instance” underneath the group, and click the Detach button in its properties.
A Fly in the Ointment:
Implementing groups and instancing came at a cost: for the first time in history, we decided to retract a feature from Filter Forge. That feature is the ability to use external images as overrides, an obscure option in the Color and Grayscale Control components. To be more specific, we removed this option from Filter Forge 4.0 and, retroactively, from 3.0, and updated the two (yes, only two) filters in the Filter Library that used it.
Decided to remove this feature because it interfered with our decision to adapt Control Components for their second role, group inputs. Keeping both image overrides and dual-role Control Components was too complex for us to implement and maintain.

New in Filter Forge 3.003 Beta (Aug 10, 2011)

New in Filter Forge 3.0 Beta (Apr 29, 2011)

New in Filter Forge 2.0 (Jul 8, 2010)

New in Filter Forge 2.0 Beta 3 (Feb 26, 2010)