Metallica again (nothing else matters)

[RobbeK]

Hi all,

4 Mike

A more sophisticated design,
Trackbars to change the colours, glow and iterations level -- info to display these.
(in this case it is not changing colours on a bmp, it are calculations and the gradient may not collapse and has to be reasonable uniform, explains the use of a compensation value.
Zoom and navigation is poor for the moment. The intention picking the colour values (6).

best Rob

cursor keys and PgUp/DN to navigate (very poor, it are complete and unnecessary recalculations of the whole thing)

[mike lobanovsky]

Hehe, your controls are very good for what they actually do and I'm also very fond of your metallica effect, especially of its sharp reincarnation. It gives a perfect silky look to the surface. :)

But!

Is it possible to find some algorithm how to assign different colors to the opposing or distantly neighboring apexes of the interior areas where glow appears? So that the interior isn't so uniform color-wise all across the surface but rather sectioned into different ordered colorful areas and gradients iin between them? The gradients should not be too smooth or spatious so that the surface will look like a grid of animated patterns rather than a pool of uniformly colored or gradient latex.

And Rob, I would be more interested in finding a way to paint that white blotch which appears at I(c) < 0.66 (see attached snapshot). It does have a structure of its own, it isn't as uniform as it seems when painted all white. That was exactly my problem that I was trying to resolve. If your metallica, especially the one segmented into glowing colored patterns following the blotch's inner structure with narrow color gradients in between, could be applied to this blotch in all its animated transformations into an ordinarily structured Julia that we see in your submissions, the problem would be resolved.

[RobbeK]

Hi Mike,

I see the problem :
When the F is "compact" the algorithm fails, you can drop the number of iterations then (try 10 and the metal look will be back (but then the circle when C= (0,0) will always escape - completely clean and compact ).
However, I think I can solve it by a simple trick :
Let 's cut open "the thing" diagonally between something as -2 and 2 and then we count the islands (unconnected zones) and the variation in the orbits -- I'm almost sure there will be a correlation between this number and a value to be used in the algorithm (let's call it the entropy of the Fractal - that's a good definition ).
This is one single run (400 points to make it easy) - that's less than a single scan-line of the image -- yes, perfect, this will work - I'll make a prototype -- wait and c

most interesting !! ;-)

Rob
(I'll start with this and the colour variations later, this may contain info for the second)
btw : forgot to reset the colour trackers upon a "warm" start.

[RobbeK]

.. addendum ...

I think I can (more or less) restore the patterns when the F gets less choatic --
(done by cross-wise sampling the F, 600 points -- attached : the closer the "delta" value comes to 0 the less entropy in the system, using this together with the value of the number of hits it may be possible to restore the metallic pattern in the dull zones).

Several coloring patterns can be used, can you describe exactly what you need ?

best Rob,

[mike lobanovsky]

Hello Rob,

I'm most excited about all this plotting, and interference patterns like in your other submissions have always been making my jaw drop wide open. Lissajous figures on a large oscilloscope screen may freeze me to total stupor. :o

Yet if you would pardon my inbred moronity, I can't for the life of me relate your findings to the actual problem of plotting colored patterns in the dull areas of the blotch. Can you please provide me with a simple applied example of possible coloring methods to set off my otherwise dormant imagination?

:bom:

[RobbeK]

;-) niiiice

Ah -- ok ... in the mean time I could eleminate most of those dull images during the animation (based on those Monte Carlo parameters).
Not all gave up, but it's a step in right direction. It's done by tuning the iteration level during the animation. (the #it is set, so that activity will show up - if you run the attached program , you can notice at some moments it shows serious lightnings ;-)

It this is ok , I'll step onto the colours. (the iteration constant is reset at its initial value after the animation, and is calculated frame by frame -on a double cross line sampling of 600 points - not much time is lost ). If we need colour tables, a pre-jit can be done to store them away - it will work smooth.


greetz Rob

[mike lobanovsky]

Rob,

I sincerely admire your work but I think we've taken the wrong turn here. The only visible contribution of entropy() seems to be extra pattern jerkiness that kills smooth transition effects.

There's a nice pair of functions, exp() and log(), that produce distinct interference patterns which can serve as the basis for further colorization, attenuation and all other sorts of bells and whistles. This was my absolute best I was ever able to produce:

http://www.fbsl.net/phpbb2/download/file.php?id=1838

It however looks somewhat crude even when animated.

Your template seems to be far more attractive and promising but needs your further enlightened improvement:

http://i1240.photobucket.com/albums/gg490/FbslGeek/Interference.png

The green streaks here were emulated with saturating the red color over 255 by multiplication yet the streaks preserve their glowing crest. What I'd like to do is turn every other (or every 3rd or 4th etc. - whichever looks best) interference ring into a similar streak with an individual color rotating through red-green-blue-yellow-cyan-magenta. If the existing golden gradient can be preserved, that would be a definitive plus.

Attached below is your script I took the liberty to vivisect. Entropy() is commented out, Red, Green, Blue and Iterations trackbars are disabled and the values are hardcoded to 20 in all cases. Glow is working as usual but is most spectacular in its leftmost and rightmost positions only. The leftmost position produces the green streaks while the rightmost one enlarges minute interference patterns to a more pleasant size.

Further, log() and exp() are applied to Red and Blue, respectively, and 10*log() over-saturates Red to become selectively unrenderable to yield the green streaks. Animation is prolongated to see the transformations symmetrically.

Can you take over from this, do you think?

[RobbeK]

Hi Mike,

I quickly (don't look at the code - recycled, uncleaned, messed-up thing from previous ) tried next idea to generate colours.
We need 3 : (still based on the fractal itself - no alien bitmaps, gradients , cyclic functions mapped on these)

1) the increase of the last ORBn/ORB(n-1)
2) the increase of the real part /x
3) the increase of the imaginary part /y

However, when the entropy is low (low chaos) these 3 values become equal and the image gets dull. (but can be revived after sampling as in previous code).

If the distribution of colours is OK , it can be tuned in something workable.

best Rob

[mike lobanovsky]

Thank you Rob,

This one looks very promising for starters. Most importantly, it doesn't use any logarythmic functions (yet). log() is indeed very slow in animations so it should be held back as heavy artillery till nothing else helps. :)

Regards,

[RobbeK]

Hi Mike,

Yes, this is imho what we were looking for :

- No need for the sampling routine any more , the variables Dx,Dy,Dorb can measure directly when things become less flamboyant and can be tuned on the spot. (either in the color mixer / or by iteration)
- Colours can be mixed as one likes
- As you mentioned no log etc ... even in case , because these numbers or so close to zero :

p.e. by Taylor McLaurin = exp(x)=1 + x + x²/2! + x³/3! + ...............
it is easy to notice x³ for close to zero values and further terms are almost "nothing" compared with the first ones and don't have to be calculated , idem dito for sin and cos ... log is something else of course , you can expand it around (x-1) but then previous trick only works around values of 1 and more terms may be needed.

Well, it took some time to find this ;-)

best Rob

[mike lobanovsky]

Rob,

Can we confine ourselves to iter=20 only for experimentation purposes? That's a restriction imposed by the original script, otherwise animation goes too slow in a large window when the rings merge into this blotch we're working with. You can then add variable iteration # later on for a more generic sample, if you like.

And colors in a color mixer please. This will be much faster than any iteration which is important for fast (=smooth) animation too.

Thanks,
:)

P.S. And of course special thanks for devoting so much of your time to this problem!

[RobbeK]

Hi Mike,

FWIIW, i tried to keep to colour patterns by changing the iteration levels / frame , resulting in a kind of disco bar ;-)
It can be done by adjusting the colours - I tried manual, but a formula is very difficult to find (tried linear , parabolic , logarithmic - but non of these fits well ).
I need to sample a few 100's runs to find a better fitting one.
I'll write something doing this for me ...

no problem, it's very interesting and challenging ;-)

best Rob

[mike lobanovsky]

Hi Rob,

Sorry to have been away for some time - FBSL v3.5 Release Candidate 2 is pending and will be available for download in a couple of days. Too much work.

Can you kindly tell me exactly what is entropy() used for in your code from aesthetical point of view?

[RobbeK]

Hi Mike,

The entropy is an attempt to measure the degree of chaos inside the fractal.
On the "silence of the fractal" (which unfortunately doesn't work on your XP) you can see it is not constant either , and that the increase in R(x) and I(x) is indepent from the fractal and therefore not usuable.
There are many problems :

- entropy() can be used , the value should be used to get R , G , B between 0 and 255 , however some values show boring flatness.
- finding a correlation is extremely difficult.
- The sampling needs fine tuning , it may hit the edge of the fractal giving a number 10000x higher than the inside, those values have to be filtered.
- the way the Gods made things : iterations are defined on countable numbers, we can not do p.e. 12.3333 iterations , using this never can produce contineous animations - there will be jumps.
- and some other problems ....

sigh Rob ,

[mike lobanovsky]

Oh. I see.

Which unfortunately makes me think we won't be able to avoid using logarithmic functions to generate controllable, not chaotic, interference for further coloration. As I say, negative is also a valid answer.

XP is not the only OS in my possession. There are at least five OS's installed natively on my workstation (x86 XP, x86 Vista, x64 7, x64 8, and x64 Ubuntu 13.10) not counting emulators for older and totally alien platforms, and my two laptops boot natively into yet two more OS's each (x86 Slitaz+x86 KolibriOS and x86 ReactOS+x86 7). I'm a language developer and rigorous performance testing of all my products on all supported platforms is in my veins. XP will continue to be my primary development platform till April 2014 as the lowest one that x86 FBSL is guaranteed to support.

So I admired your "silence" under my x64 Windows 7 which is yet my second most-used development platform. But I admit the failure report that I felt was my obligation to submit to my TB colleagues did spoil my pleasure a little. Just as simple as that.

Anyway, I sincerely appreciate the effort you've put into this seemingly unresolvable problem and I assure you your results are very spectacular and certainly have aesthetic and practical value even if they don't meet the requirements of the challenge. Thank you.

Regards,