LRIFS Paper

[David Makin]

Yes, but I don't care because I use assembly that ignore such types

I don't see what using assembly or not has to do with using compression or not ?

[DarkBeam]

Yes, but I don't care because I use assembly that ignore such types

I don't see what using assembly or not has to do with using compression or not ?

I can't understand why I need such compression...

[David Makin]

Yes, but I don't care because I use assembly that ignore such types

I don't see what using assembly or not has to do with using compression or not ?

I can't understand why I need such compression...

Well it depends what you want to do exactly, but *someone* will always want to fit more in memory (by it ram, rom, CPU or GPU cache etc) than will fit without using compression *no matter how much memory is available in the future*.

[DarkBeam]

Okay thanks then.

Found this article, did not understood a lot but it can be of interest

http://www.mi.sanu.ac.rs/vismath/kobes/index.html

[knighty]

Hello!

The first formula, translated to fractint 20.0 format is (in 1993 fractint didn't supported conditionals, so I have solved it in my own way):
zpj(YAXIS){
z=pixel:
k=real(z)
IF (k<0)
z=z*p1-1
ELSE
z=z*conj(p1)+1
ENDIF,
|z|<=100
}
solve it for c=0.9-0.87i ...

This is strictly equivalent to:

Code:

zpj(YAXIS){
z=pixel:
z.r=abs(z.r) ; z.r is the real part of z. I'm not familiar with fractint so...
z=z*conj(p1)+1,
|z|<=100
} 

which is a (one fold) kifs  .

[Aexion]

Hello!

The first formula, translated to fractint 20.0 format is (in 1993 fractint didn't supported conditionals, so I have solved it in my own way):
zpj(YAXIS){
z=pixel:
k=real(z)
IF (k<0)
z=z*p1-1
ELSE
z=z*conj(p1)+1
ENDIF,
|z|<=100
}
solve it for c=0.9-0.87i ...

This is strictly equivalent to:

Code:

zpj(YAXIS){
z=pixel:
z.r=abs(z.r) ; z.r is the real part of z. I'm not familiar with fractint so...
z=z*conj(p1)+1,
|z|<=100
} 

which is a (one fold) kifs  .

The history of that formula is this:
Back in 1993, I saw a Glynn set (z=z^1.5-0.2) on a magazine, but without the formula printed, so I tried to make one using IFS, but to my frustration, the set didn't looks like the one made by Earl Glynn, no matter how many variations I have tried.. In those times, Fractint still not supports conditionals, but there was a trick.. so I ported my formula to the program and uploaded it to the old Frac-l list in Bitnet (there's no Internet in those times).. At the end, I got the real Glynn formula and made a 3D render that still lasts on Earl Glynn Gallery.
http://www.efg2.com/Lab/FractalsAndChaos/GlynnFunction.htm
I was thinking that the history was lost forever, but it appears that Google compiled many of the old Frac-L posts, and my old post was among them..
http://groups.google.com/group/bit.listserv.frac-l/browse_thread/thread/c4b8f0dc58a8965d/41c9cae07feec4c2

Oh, anyways, 18 years before that and still the Inverse IFS formulas remains elusive for a general case!!

[David Makin]

In case anyone's not realised, Darkbeam's point earlier in the thread regarding the Menger transforms also shows that if you define 8 transforms as the standard transforms for a 2*2*2 platonic cube you can do exactly what I described later for the 3*3*3 case.
i.e. the 8 transform IFS for a platonic cube with flags for "on"/"off" for all transforms in the tree is *exactly* analogous to a voxel space.

Also one thing about my 3D LRIFS algorithm using Hart's intersection method I forgot to mention is that unless over-ridden by the user the IFS tree is always traversed in the most optimum manner because some pre-render code sorts the transform order such that the transform domains closest to the viewpoint are rendered first - of course this doesn't work perfectly (especially further down the tree) if the transforms include rotations etc.