This includes a color picker to select from 15 color palettes; also textures are dithered to reduce the 16bpp banding.
-
Recent Posts
Archives
Categories
Meta
This includes a color picker to select from 15 color palettes; also textures are dithered to reduce the 16bpp banding.
Played with this over the weekend on my iPad. Love the results, but I think with some simple interface tweaks I’d enjoy “surfing” the fractal space a lot more.
For me –
1) I would love all navigation controls to have drift on them, so that navigation is always smooth (e.g. how contacts scroll on the iPhone, but probably damped faster than this)
2) I want to be able to massively slow down the speed at which the zoom does it’s zooming. Ideally, I’d be able to set two things – the period over which the zoom happens (let’s say, 0.5s -> 5 minutes!), and the magnification factor of the zoom. I love travelling into the set but at the moment it happens too fast and requires too many interactions. I’d be happy to say “take me THERE, 100x BIGGER, and take 2 minutes to get there”… and then sit back and enjoy the show!
Thanks for the feedback –
1) I agree, the scrolling should have inertia like other widgets in the iOS. I had a hacky version of this implemented already, but took it out again because it made the graphics shimmer. I’ll hopefully get it right next time round.
2) I don’t think I’ll be able to do exactly what you described there, just because it’ll be tricky to expose a good user interface for that.. there’s only so many gestures you can fit into the app without them starting to conflict. I do agree that some sort of hands-off mode where stuff moves slowly without you having to press on the screen the whole time would be good. Some desktop apps had these autopilot modes which tried to zoom into interesting bits automatically; otherwise, I could wrap this into a bookmark / favorites system if I ever get around to making one. Lots of possibilities!
Cool Georg,
I totally take your point about 2… haven’t really thought about it myself.
One thing’s for sure in my mind though, a slower movement option could be great to show off the fractals (and the app!).
Perhaps the best way to do this would be to have switchable control modes through the cog icon…
If you did bookmarks, then perhaps a string of bookmarks could be used to construct a path, along with a speed control maybe.
Now I’m imagining a hardcore twin stick type control with LRUD panning anywhere on the left hand side of the screen and IN/OUT radial control on the right hand side would be great, then I could literally fly through and keep the centre of the screen free!
Yes, I’m thinking the same about stringing favorites together into tours. I’ll be a while before this is done though, what with needing servers, authentication, ratings systems etc etc. This sort of thing then also enables an `export to video’ function.
Hadn’t thought of a d-pad mode – excellent idea. Could also do some sort of tilt-to-steer. I’ll look into it, thanks!
why cannot i zoom more than x14.4E12?
That’s the precision limit of the arithmetic used (approx 64 bit fixed-point). Going to more precision, e.g. 96 bit or 128 bit or even arbitrary precision, is possible but would be much slower – slow enough to be useless IMO.
I really like this app. I only miss a small progress bar or counter for the iterations. And a simple zoom out-function. Doesn’t need to be fancy, just a simple button that zooms you to the starting point. I’ts amazing how far deep you actually are and this gets really clear when you zoom out.
Hi Mike – you can zoom all the way out by pressing and holding with one finger. Progress indicator is interesting, but so far feedback has been that people want as little on the screen as possible.. not sure.
Thanks for the feedback!
I’ve been fond of fractals since the early 90s after reading turbulent mirror. I think you are right to have as little gui as possible. I wanted to keep on zooming but yes Response time is more important. Will this change as the iPad versions get more powerful? Is it the CPU clock speed? What is the hardware that is the bottleneck for the display of deeper computation at the same speed?
Hi – the current limit to zoom level is that the arithmetic used runs out of precision. The further you zoom the more accurate the number representation has to be, i.e. the more bits you need to represent a number. If you ignored this and zoomed in further, the image would start becoming blocky, as if you’re just zooming a static JPEG or something.
Fractile currently uses two different number representations: For the first few zoom level Fractile uses 32-bit floats. Thanks to the ARM cpu’s NEON unit, this is very fast, and navigation is very snappy.
After a while, it switches to 64-bit fixed-point (this turns out to be faster than float-64). This is maybe 5-6 times slower. You can maybe tell the difference as you’re zooming in that all of a sudden things get a lot less quick to render.
Eventually, 64-bit runs out of steam too – at this stage we could get a few extra zoom levels by going to 96-bit, but this would probably be another order of magnitude slower, and wouldn’t buy you that much extra zoom, so I just don’t think it’s worth it. All the math has to be written in NEON to get good performance so it’s a big implementation effort for not very much gain. And then repeat the same effort for 128-bit, 160-bit, etc.
On the PC, it’s probably reasonable to use some arbitrary-precision software library to do the maths, but this can be phenomenally slow – think back to the times when you’d wait for hours for a frame to render. Besides the time taken, there’s also battery life to consider on these mobile devices. So yes, it’s mostly a performance consideration. Other than this there’s no real obstacle to going to deeper zoom levels.