Tip: linked transforms #2 - introducing pre-transforms

Oh joy! I recall my delight on discovering the power of linked transforms as introduced in the 2.08 release. This was a feature that wasn't trumpeted, just quietly slipped in. Well, those sneaky developers have done it again, given us a little Easter Egg quite undocumented in the spartan changelog. 2.09 has much going for it:

• much more responsive


• unused variations greyed out


• only used variables shown


• transform weight permanently visible in Editor


• transform opacity

The thumbnails are a nice addition, but an option to default to names would be better. And that Easter Egg? Right-clicking in the Xaos tab now gives 2 linked transform options: before and after. The old linked transform is now 'after', but the 'before' option, always available via a little work but again completely missed by yours truly, opens up yet another vast landscape of possibilities. In conformity with my previous notation, I'll refer to these as 'pre-transforms': all of this linked transform's output is fed to the selected transform, and it receives its input from all except itself.

Tip: ad hoc scripting #2 - rapidly change variables for a group of transforms

I have already published a set of utility scripts for working on groups of transforms (link). It's easy enough to write scripts that generalise when it comes to working with variations (one simply needs to maintain a list of currently installed plugins in alphabetical order): the old method of referencing variations by number is most useful in this context. But it doesn't allow for easy manipulation of variables. Rather than write an enormous script that covers all, I've developed a (wait for it) spreadsheet that picks up all the variables via a lookup table. But it's not necessary - just a code snippet repository or, better, a clipboard utlility (e.g. ArsClip, my review) will do the trick. As an example, we'll take the lazysusan variation - all that's required is:

Transform.lazysusan_spin := 3.14159;
Transform.lazysusan_space := 0;
Transform.lazysusan_twist := 0;
Transform.lazysusan_x := 0;
Transform.lazysusan_y := 0;

These are the default values. Also, a loop wrapper:

for i := a to b do
begin
SetActiveTransform(i);
...variables...
end

where a and b are the first and last transforms of the group (zero-based counting, that is the first transform of the flame is in fact transform #0).

Running Apophysis with the script editor window open (Ctrl-D), just click the New tool and paste in the code, amend the values as desired and click the Run tool - one click to perform what would take perhaps 30 seconds to accomplish in the Transform Editor.

Tip: ad hoc scripting #1 - batch rendering multiple .flame files

Following on from the previous tip, this becomes a very simple but powerful tool to enhance lengthy unattended rendering, ideal for setting up before a weekend away. With reference to the previous tip, [script code] represents the chosen block of script for rendering the contents of a single .flame file. The choice of method may be varied for each .flame file. The following code will render the content of three .flame files in a single run:

SetFlameFile('full path\filename1.flame');
[script code]
SetFlameFile('full path\filename2.flame');
[script code]
SetFlameFile('full path\filename3.flame');
[script code]

The snippet may be stored in a text file and then amended and copied to the clipboard (Ctrl-C). In Apophysis, open the script editor (Ctrl-D), click New and paste (Ctrl-V), then click Run. This way, you don't end up with a load of stored scripts that won't be used again.

Tip: batch rendering

Historically, this was always accomplished using a script, whether with the internal renderer or flam3. We now have a bulit-in batch rendering command, plus I have my own custom (script) method. Which method to use depends very much on one's preferred workflow. Essentially, we can divide this into two groups:

1. All renders share the basic rendering parameters.
2. Each render has individual requirements.

Case #1 is simple: its simplest solution is to use the bulit-in method Flame, Render All Flames (Ctrl-Alt-R), offering the usual dialogue for setting parameters. Scripted, the equivalent is:

Renderer.Width := ##;
Renderer.Height := ##;
for i := 0 to FileCount - 1 do
begin
LoadFlame(i);
Flame.SampleDensity := ##;
Flame.Oversample := ##;
Flame.FilterRadius := ##;
Renderer.Filename :='path' + Flame.Name + '.ext';
SetRenderBounds;
Render;
end;
UpdateFlame := False;

where ##, path and ext should be specified as desired.

To render the contents of a .flame file other than the current one, simply precede the code with:

SetFlameFile('full path\filename.flame');

Case #2 requires a little more work, but provides more flexibility. Each parameter set would require saving with the desired dimensions, set on the Image Size tab of the Adjust dialogue (make sure to click Apply). The script code would then read:

for i := 0 to FileCount - 1 do
begin
LoadFlame(i);
Renderer.Width := Flame.Width;
Renderer.Height := Flame.Height;
Flame.SampleDensity := ##;
Flame.Oversample := ##;
Flame.FilterRadius := ##;
Renderer.Filename :='path' + Flame.Name + '.ext';
SetRenderBounds;
Render;
end;
UpdateFlame := False;

But there is no easy way to set individual values for quality, oversample and filter radius, other than editing the .flame file manually, either with a text or XML editor. To this end, I developed a spreadsheet in which values for each parameter set are entered into adjacent cells, then a button pressed that copies the code to form a consecutive set of instructions, like this:

LoadFlame(0);
Renderer.Width := 6000;
Renderer.Height := 6000;
Flame.FilterRadius := 1.2;
Flame.Oversample := 1;
Flame.SampleDensity := 1000;
Renderer.Filename := 'C:\Program Files\Apophysis 2.0\Prints\' + Flame.Name + '.jpg';
SetRenderBounds;
Render;
LoadFlame(1);
Renderer.Width := 6000;
Renderer.Height := 6000;
Flame.FilterRadius := 0.8;
Flame.Oversample := 1;
Flame.SampleDensity := 500;
Renderer.Filename := 'C:\Program Files\Apophysis 2.0\Prints\' + Flame.Name + '.jpg';
SetRenderBounds;
Render;
.
.
.
etc.

This takes very little time and provides complete flexibility for parameter choice for unattended rendering.

Tip: linked transforms - post-transforms on steroids

I've only recently discovered the power of this feature, thanks to this blog post. I'd had as a mental wishlist item for future Apo the ability to apply variations to post-transforms, and here it was under my nose since 2.08!

Application is simple: select the transform to link in the Transform Editor, right-click anywhere in the Xaos tab and select "Add linked xform". All this does is save much clicking as the thing can be set up manually: the transform from which the link is created becomes invisible (check box on the Colors tab), and the new linked transform (default Linear so no noticeable change) takes all its former traffic via xaos coefficients (its sole 'From' is 1 from the invisible xform, its 'To's are inherited from the invisible xform, which retains its 'From's but now has a sole 'To' of 1 running to the linked xform). The Color symmetry value of the linked xform is set to 1, which effectively retains the colour distribution.

The practical upshot of all this is that all the hits to the now invisible xform may be transformed independently of all others. The new scope this offers is quite dizzying: it's like discovering an entire new wing to a familiar house, the stuff of dreams. Of course, it needn't stop there: build as many layers of linked transforms as you like. Some appetite-whetters:

Basic flower



Linked loonie



Basic disc-julian



Linked sinusoidal



Double-linked julian, swirl

Tip: re-aspecting

Leaving aside the verbal coinage of the word (aspect is normally a noun), to what do I refer? Basically, the dimensions, the aspect ratio. This is one of those really simple methods: if your fractal has a final transform, cool. If not, add one and leave it as the default linear since this won't change the fractal at all. Now, say your fractal's square, but you wanted something in a portrait aspect, perhaps 3 x 4. Engage the final transform's post-transform, switch to the Transform tab and amend the relevant X/Y value to give the desired ratio (in this case, setting the Y y-coordinate at 1.3333 provides a 3:4 ratio).

Check out the sequence of screenshots:

Tip: animation scripts

As I've just posted my first animations, I thought I'd share my methodology. But remember, this is my way: there are many others. Some have used this script, but I much prefer the control gained by hand-crafting. Basic format:

Path := 'c:\whatever';
SetRenderBounds;
Flame.SampleDensity := 200;
Flame.Width := 640;
Flame.Height := 480;
Flame.Oversample := 4;
Flame.FilterRadius := 1;
Flame.Name := ('base0000');
SaveFlame(Path + 'myname.flame');

(initialise variables)

(for/while loop, must contain:

SetActiveTransform(i);

(increment variables)

SetActiveTransform(i+n);

(increment variables)

"
"

Flame.Name := 'base' + Format('%.4d', [j]);
SaveFlame(Path + 'myname.flame');
where j increments
end loop)

SetFlameFile(Path + 'myname.flame') ;
for i := 0 to FileCount do
begin
LoadFlame(i);
Renderer.Filename :=Path + Flame.Name + '.jpg';
Flame.SampleDensity := 200;
Renderer.Width := 640;
Renderer.Height := 480;
Flame.Oversample := 4;
Flame.FilterRadius := 1;
SetRenderBounds;
Render;
end;
UpdateFlame := False;

where:

this font denotes example only - substitute with your own text/value
this font denotes general instructions

Tip: Functions.asc

Is there a script or fragment thereof that's re-usable elsewhere? If you have such a thing, then it's possible to call it from other scripts by naming and storing in your Functions.asc script file that comes with the program and resides in you scripts folder. Open Functions.asc: you should see:

{**********************************}
{ Functions and procedures for use }
{ by other scripts. }
{**********************************}
procedure CalculateColors;
{ Spreads the color parameters evenly }
begin
for i := 0 to Transforms - 1 do
begin
SetActiveTransform(i);
Transform.Color := i / (Transforms - 1);
end
end;

As an example, copy the following into the file and save.

procedure FineGradient;
For i := 0 to 255 do
Begin
For j := 0 to 2 do
Begin
Flame.Gradient[i][j] := trunc(31+random*191) ;
End
End;

To prove that it works, open the script editor (Ctrl-D) and click on the 'New' icon (top of right-hand panel). Type, or copy and paste, FineGradient and click on the 'Run' icon (green triangle) - your current gradient will be replaced by a 256-band brightly-coloured one.

Troubleshooting: if it doesn't work, check that Functions.asc is selected in Options, Paths, Function library

Tip: sliding and double-clicking

A good proportion of the fields in Adjust and Editor dialogues support sliding and double-clicking in their title areas to change their values. Double-clicking defaults/toggles*. To use the title field as slider control, click and hold then drag to the right to increase and the left to decrease. Further details:



*if option set in Options, Editor, Double-click on variation (see below)
#sometimes gives Access violation errors - use at own risk!

Tip: colour distribution

Depending on how you build your fractal, or where the parameter came from originally, chances are that your chosen gradient isn't fully distributed. Fine if you like what you see, but not the best situation for actually selecting a gradient. To remedy, from the menu Flame, Calculate Colors Values - this gives full colour distribution i.e. transform #1 has value 0, transform n has value 1, with transform i (0 < i < n) having value (i - 1)/(n - 1). Obviously, you can pull the sliders to what values you like, but this gives a standard starting point. For alternative colour distributions, I have a script available here - only any use for 4 or more transforms.

The situation is somewhat complicated if one transform possesses the lion's share of the total weight - the colour value of this transform will dominate, sometimes to the point of turning the whole thing duotone. To introduce more colour, use symmetry .

Tip: use of colour symmetry

Whilst I must confess to a lack of mathematical rigour in my understanding of this function, what really matters for the artist is the effect. By default, the colour symmetry is 0 for all transforms. It may take any value between -1 and 1. -1 corresonds to "this transform's colour does not contribute". Increasing the value towards 1 has the effect of distributing the entire gradient from around the transform. For high-weight transforms, values closer to 1 give best results:



Here, transform #2 has weight = 30. For this gradient:



For others, experiment! One notable effect is causing colour to begin abruptly at a structural boundary and fade across the structure. Star mandala amulet is a good example of this.

Tip: micro-changes in the Editor

Some fractals are hypersensitive to the smallest changes. This is not the time to manually drag, rotate and resize the transforms, wonderful though these features are. Use the drop-down boxes on the Triangle tab in the Editor. And don't be content with the values given, type in your own: 1, or even less, for the rotation; the 0.01 preset in the move is probably adequate for micro-movements; and 101, or as low as 100.1, in the resize.



Probably the styles to which this applies most strongly are are the julian/juliascope-based types, in combination with any of disc, rings2 and more latterly lazysusan, escher, droste and loonie.