Here's point symmetry, which I've been using a lot lately. It's great on a camera transform, especially blended with other variations, but works well in structures too:
Code:
<transform_def name="point_symmetry">
<node name="input_params">
<real name="point_symmetry">1</real>
<real name="point_symmetry_centre_x">0.25</real>
<real name="point_symmetry_centre_y">0.5</real>
<real name="point_symmetry_order">3</real>
<real name="point_symmetry_colorshift">3</real>
</node>
<node name="internal_params">
<real name="weight" />
<real name="centre_x" />
<real name="centre_y" />
<real name="order" />
<real name="colorshift" />
</node>
<int name="num_unit_randoms">1</int>
<string name="winter_init_function">
<![CDATA[
point_symmetry_init_result(point_symmetry, point_symmetry_centre_x, point_symmetry_centre_y, point_symmetry_order, point_symmetry_colorshift)
]]>
</string>
<string name="winter_eval_function">
<![CDATA[
let
idx = truncateToInt(unit_rnd_0 * order)
dx = (p_in.x - centre_x) * weight
dy = (p_in.y - centre_y) * weight
da = twopi() / order
angle = toReal(idx) * da
cosa = cos(angle)
sina = sin(angle)
in
vec2(centre_x + dx * cosa + dy * sina, centre_y + dy * cosa - dx * sina)
]]>
</string>
</transform_def>
<node name="input_params">
<real name="point_symmetry">1</real>
<real name="point_symmetry_centre_x">0.25</real>
<real name="point_symmetry_centre_y">0.5</real>
<real name="point_symmetry_order">3</real>
<real name="point_symmetry_colorshift">3</real>
</node>
<node name="internal_params">
<real name="weight" />
<real name="centre_x" />
<real name="centre_y" />
<real name="order" />
<real name="colorshift" />
</node>
<int name="num_unit_randoms">1</int>
<string name="winter_init_function">
<![CDATA[
point_symmetry_init_result(point_symmetry, point_symmetry_centre_x, point_symmetry_centre_y, point_symmetry_order, point_symmetry_colorshift)
]]>
</string>
<string name="winter_eval_function">
<![CDATA[
let
idx = truncateToInt(unit_rnd_0 * order)
dx = (p_in.x - centre_x) * weight
dy = (p_in.y - centre_y) * weight
da = twopi() / order
angle = toReal(idx) * da
cosa = cos(angle)
sina = sin(angle)
in
vec2(centre_x + dx * cosa + dy * sina, centre_y + dy * cosa - dx * sina)
]]>
</string>
</transform_def>
This is point symmetry on camera blended against linear and glynnSim2:
The British variable naming (and unused colorshift variable) comes from JWildfire. This general use case is where my variable matching request comes from. The reason I have automated variable parity in my JW plugin set is so I can paste .flame XLM direct into Chaotica straight from the clipboard. Plugins that didn't translate/compile, I replace with shim plugins that do nothing (but keep variables).
I haven't stress tested C2 much, but Chaotica 1.x straight crashes if you paste in Apo-style flame XML with messing or badly named variables.
So with porting plugins I regularly use, but ones I'm pretty sure only exist in Apo/Chaotica form from my plugin translation, it's kind of a question: Do I sanitize names (i.e. point_symmetry and not post_point_symmetry_wf)? Drop unused variables (3D stuff, direct color stuff)? Or be more selfish and keep my workflow as intact as possible? It's kind of a pain to do both.
I have been meaning to do a .chaos -> .flame conversion tool in the other direction, which I guess I could just extend to Chaotica 1.x <--> Chaotica 2.x name changes too.
P.S. Speaking of tools, I snuck out the Chaotica render automation GUI over the weekend: https://www.youtube.com/watch?v=GniEpxHCxmY
.gif "Wink")