END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

<a href="http://www.youtube.com/v/yY1-D13KICw&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/yY1-D13KICw&rel=1&fs=1&hd=1</a>

No 3D..no??
They can be 3D but no idea about the formula..

http://www.fractalforums.com/theory/triplex-algebra/

It will be nice to assemble the Mobius formula using Triplex algebra. The formula has already been written (needs only to be transposed in a working code and with all the needed parameters; for 3D transform -> 3 dimensions x 2 kinds x 2 transforms = 12 total. a1,a2,a3, b1,... d2, d3.). The last problem is; what transform we must do? How many (important, because MB can take only 6 transforms in total)? In which order? And after the transforms, we must do some other passages?

(Moreover. Are they all with FIXED parameters (a1,a2... d4) are always the same or change in between? The Aexion code uses some magnifications with non fixed factors).

Another question is; the code would be much (I mean really much) more simple if the transformations are INVERSIONS, SCALINGS, SHIFTS, ROTATIONS and no transform is composite (with both constants non zero, or at least if a and b are nonzero c must be, and if c&d!=0 a must be zero if the transform is of simple type) - the Aexion code uses only simple transformations.

inversion -> I can use Sphere Inversion's code. That covers all kinds of inversion with scaling - but with no rotations.
scaling -> simply multiply everything by a number.
shift -> simply add/sub a set of numbers.
rotate -> more complicated and the slowest transform (if expressed in angular terms), but the code is already written and works good.
Otherwise I can write a rot code using triplex polynomial product formula, faster.

A Mobius transform of composite type can always be simplified as;

(a z + b)/(c z + d) = (z + b1)/(c1 z + d1) where b1=b/a, c1=c/a, d1=d/a

Not true if the transform is "simple". I mean that simple transforms can be coded with much simpler and faster codes.
Any simple transform can be expressed in terms of composition of more "fast" transforms. Those transforms can be done without allocating stack memory if fp stack is free.

I am studying some combination of IFS logic and Mobius. (Just like "IFS Mobius" methos but very simplified). This function is fantastic looking... A sort of Mobius equivalent to Sierpinski.

tester01 {
; ----------------

init:
  z = #pixel
  ;c = @seed
loop:

  ; here is the main fmla
  ; -------------------
  z = (2*@seed1)/(z-flip(@seed2)) + @edge
  z = (2*@seed2)/(z-flip(@seed1)) + @edge
  if real(z)>@edge
  z = flip(@edge-z)
  endif
  if imag(z)>@edge
  z = 1i*@edge-z
  endif
  ;ends here
bailout:
  true
default:
  title = "Test function"
  center = (0,0)
  param seed1
    caption = "Seed 1"
    default = (1,0)
  endparam
  param seed2
    caption = "Seed 2"
    default = (0,1)
  endparam
  float param edge
    caption = "Edge"
    default = 1
  endparam
  int param itercnt
    caption = "Iter count"
    default = 30
  endparam
  float param bailout
    caption = "Bailout"
    hint = "-disabled-"
    default = 1024
  endparam
}

That renders in a fraction of seconds, is autosimilar and fractal. Too bad, in 2D. But it should be easy to convert in 3D.
Look at the picture to be convinced of the power of this method

The only defect of these solutions is the discontinuity.

Definitely my friend
Too bad needs a radical simplification but I'm afraid I'll not be able...
How can I transform the two consecutive inversion in a single one? And the same have to be generalized in 3d. I think that it can be done with 3 flipped sphere inversions, but what is the correct seq and final formula?
The two distinct factors must remain unitary (100 010 001) to vary the effect I will use a single rotation after the fixed inversion sum of flipped inversions...

Definitely simpler than it seems but I don't have a symbolic evaluator!

The problem with the "brute-force' method that Aexion mentions is that in a system using multiple transforms then to get the "complete" attractor using the escape-time method you have to make sure you choose the "correct' transform on each iteration.

In some cases then having a point associated with each transform and choosing the transform to use on a given iteration based on which of these is closest to the current "z" is suffcient.
This is because the correct transform to apply next is based on the current location of the z value - the problem is that these areas/volumes are generally not easy to define, especially when using non-affine transforms, and in some cases the relevant areas/volumes actually overlap and in such cases there are some values of z where more than one possible transform on that iteration must be considered for "correct" "complete" rendering resulting in a more complex and considerably slower branched iteration loop.

If trying to render a Sierpinski Triangle using the escape-time method for example and only applying one transform per iteration and you sometimes choose the wrong transform then parts of the S T will be missing.

In fact the Mandelbox and KIFS are examples of "incorrect" rendering of full IFS systems where the conditional execution of transforms does not necessarily match the areas belonging to those transforms and in fact this failure to render the "true" full IFS is part of what contributes to the final shape.

If the transformations involved are completely affine then there is an alternative method to ray-casting using DE for which my older basic algorithm for escape-time 3D IFS in UF uses (method from Hart et al), this method essentially finds intersection of the viewing ray with the attractor (or not) without any stepping but involves a branching iteration loop - since the Mandelbox and KIFS etc. I've realised that it can be vastly optimised by applying the same location rules regarding transforms to use on each iteration as in the non-branched method in order to reduce the total branching necessary.

In fact a location based method that also allows for branching could be used both for the ray intersection method (if everything is affine) and for the DE method where we have non-affine elements.

Obviously both could also have all the other potential RIFS methods added such as transform x cannot follow (or precede) transform y, transform a cannot be used on the nth iteration or z location based controls (per iteration depth?) to choose the next transform that don't necessarily match the correct location control and these could even vary from one iteration to the next, plus anything else we can dream up

A system such as this would give a lot more control over the results (if wanted) or could just be used to produce competely unpredictable results.

For example, can you guess what you get if you correctly apply the Sierpinski tetrahedron IFS for just one iteration and then continue from then on with a Mandelbrot or Julia (where the constant or zstart are taken from the result of the single IFS iteration) ?
What if you apply the IFS twice first ? Or three times ? etc.

Fractint formulas are supported by UF for backwards compatibility.
I see no trees, but a fascinating spiral!

Yes, but it again looks like a spiral rather than a tree... The irresistible force of the Mobius swirliness

Oh, rotate the fractal counterclockwise 45 degrees (at least on my image), you will see the tree (ok.. add a lot of imagination)..
But not always the Mobius gives swirliness..