Welcome to Fractal Forums

Pimp my zoomer (http://wonderfl.net/code/f2bf48cd75852a86fb6b9ebc9001d6631373a7e8)!  O0

Sorry for shitty quality, wonderfl limits images to 500KB, and I could not be bothered programming multipart map :)

Any way, this applet takes it to extreme but, if toned down, this technic could be used to significantly speed up rendering fractal zoom videos. Basically, this is done by transforming r → r^p while making the map, and then applying inverse transform in flash (or, again, you could make many consequtive animation frames).

This is obviously not limited to Mandelbrot and, I guess, can be applied to 3D fractals just as well (going to try at some point) or unrelated imagery (think Blue Marble or Titan landing).

more crazy zooming CSI style (http://wonderfl.net/code/24f2191411145aa05fb863f104f07a0d951f7da8) :D

edit: the image in this one actually shows how inefficient my transform is; this would work so much better in polar coords with log-scaled radius.

A side scroller in polar coordinates ... cool!

yeah, and I'm not the first one to come up with this idea:

http://www.aleph.se/andart/archives/2009/03/mercator_mandelbrot.html

Can't wait to try it out myself.

In the end, it proved to be WAY more efficient (http://wonderfl.net/code/4d3e35c971173b9e8b3d0bb235d7d9658436866f). With large enough map you could even do pixel-perfect frames.

This thing would have been a killer in the demo-scene of the 68k days. :)

I ended up not running my own mandelbrot script but using flickr images for this little toy (http://wonderfl.net/code/b85f0915f58693d646b9f003963cd1cbb4b7f86a) (unfortunately that map points become larger than pixels outside of innermost 58x58 area, so it looks very blurry). I still stand for my statement - calculating video frames from log map would be great time saver.

Btw, demoscene isn't entirely dead, breakpoint'10 ended only few days ago.

64k ;)

I meant to refer to the Motorola MC68000 microprocessor. It used to power the latest home computers; these days it might power a washing machine. The times they are a-changin' ...

ah, good ol' mc68000 that was mine first asm progged processor also :)
but, ehm, people, that log zooming ... does someone has some source code at hand ?!
i am very interested in seeing how it is working

Just posted source for bender kernel (http://makc3d.wordpress.com/2010/04/06/csi-zoom-to-my-house/) that does zoom from log map. Basically, when you do inverse transform you substitude r with r * zoom with zoom running from 1.0 down to the point you still have data for.

btw... by the fluffin w! now when I think about this, I see that it's perfectly possible to zoom into some OTHER point using same log map. but obviously the quality (or zoom limit) will get worse and worse as we move away from map intended center.

could this be somewhat countered if we have another map nearby? well, I think so; even more, if we could set up a database storing large quadtree with "continuous iteration count" for random points of interest, we could build web ui that could zoom anywhere in real time! of course, this quadtree itself would take many months to generate to match details level of available videos. or, if those who made videos could provide the way to restore "continuous iteration count" from the color of particular frame, one could "import" video into database :D sadly, this will never come true without some extensive collaboration.

i like the method because it is easy applicable for realtime fun , because you only have to calculate that map, and have a straight zoom,
 
btw. it should be easy to blend consecutive maps together

I came back to this subject because Anders Sandberg sent me bigger 1600x13000 map he made in ultrafractal, so I actually turned it into video as a proof-of-concept:

http://www.youtube.com/watch?v=Sv2A2r9p6Uk

Anders wrote:
On my side, it takes ~8 minutes to generate 1000 frames and another ~6 minutes to encode the video. I leave it to your judgement how does this compare to calculating each frame independently (note that after 0:20 iteration threshold seems to be too low, so proper calculation would have to take more time).