?

Log in

No account? Create an account

February's Fractal

« previous entry | next entry »
Mar. 5th, 2008 | 09:17 pm
mood: rushedrushed

February's Fractal is here, only a few days late:

http://pauldoo.com/fractals/JuliaSet.html

The instructions are a bit scant, basically you drag the orange dot around to explore the Julia sets that are associated with each point on the Mandelbrot set. Click the big button to view the high-res version of the Julia set.

The Good:

  • I copied the idea of dragging a control tool (the orange spot) from ChaoticDust.

  • Less late that my January one...


The Bad:

  • I created a real complex number class for hiding away some of the arithmetic, so the rendering is now slower than the January release.

  • Dragging the orange dot can be quite laggy.

  • My interactively updated julia sketch isn't as dense as other ones I've seen: http://en.wikipedia.org/wiki/Image:Reversed_Julia_set_C_%3D_%28_0.4_0.3_%29.gif

  • Still goes a bit nuts if you zoom too far.

  • Caching in your browser may mean you don't see the correct newly updated applet. You will know this if you don't see an orange spot.

Tags:

Link | Leave a comment | Share

Comments {8}

Paul Richards

(no subject)

from: pauldoo
date: Mar. 5th, 2008 09:50 pm (UTC)
Link

PS. If your orange spot is inside the Mandelbrot set then your corresponding Julia set will be connected (one single black object). Conversely, if the orange spot is outside the Mandelbrot set then you'll get a disconnected Julia set (lots of disconnected bits of dust).

Reply | Thread

colours

from: anonymous
date: Mar. 6th, 2008 08:53 am (UTC)
Link

How about some colour fiddlings for the March one?

The colour exploring I currently have is pretty limited (it's just interpolation between two HSVs). I'd be interested if you can do something fancier. Steve mentioned the idea of curves through HSV, and control points on the curve. That might be pretty neat, but I've yet to explore it properly.

And how's Java holding up for this? I had a quick attempt at mono-ing chaoticdust, but mono on mac seems pretty damn clunky still. If your experience is good, maybe a Java port is the best way to get crossplatform (and web embeddable. Yum).

Anyway!

Looks good - I like the obvious connect between the two sets - something I remember doing back in the day with fractint. But in 320x200 chunkovision :) And not as quickly. Or as intuitively.

Dom

Reply | Thread

Paul Richards

Re: colours

from: pauldoo
date: Mar. 6th, 2008 09:42 am (UTC)
Link

For March I'm hoping to do some IFS stuff, so maybe I'll be able to add some colouring there.. :)

Java is holding up great, it's so easy to do simple graphics things with Java and the performance is adequate. If you're willing to launch the applet using 'appletviewer' you can select the non-default 'server' VM and get even better performance.

Reply | Parent | Thread

Re: colours

from: anonymous
date: Mar. 6th, 2008 01:25 pm (UTC)
Link

Heh. I'm working on some IFS right now (well not _right_ now). Specifically a flames implementation. It's pretty sluggish right now, and it's all in primary colors, but it's really pretty!

Dom

Reply | Parent | Thread

Anthony Bailey

(no subject)

from: anthonybailey
date: Mar. 6th, 2008 08:44 pm (UTC)
Link

Love what you're doing with the "publish once a month" thing.

Also having fun playing naively (I do not have a fractal dimension) with what you've done so far.

Of the negatives, I think the slowdown/lag is the one that compromises my enjoyment the most. Any way you can keep sufficient complex number abstraction in the source without paying the performance cost? (I'm guessing C# doesn't do macros per se, but maybe some kind of annotation can fake that kind of approach and/or force the compiler to be more aggressively inlining? Or else perhaps it's metatastic code generation time?)


Edited at 2008-03-06 08:45 pm (UTC)

Reply | Thread

Paul Richards

(no subject)

from: pauldoo
date: Mar. 6th, 2008 11:00 pm (UTC)
Link

Interesting that you should mention the performance thing. There are a number of things that I've noticed...

* Java6 is much better than Java5 at not showing an abstraction penalty. Introducing the complex number class made much less difference with Java6. I see this when I reboot from Mac OS X (Java5) to Windows (Java6).

* With both Java5 and Java6 switching to the "server" VM improves performance dramatically, presumably just a more aggressive optimiser. The browsers don't use this flavour of the VM by default, so it's a command line launch of "appletviewer" if you want to see this.

All in all, I've been aiming for something that's a bit slow but useable on my laptop in Mac OS X. This ends up being pretty smooth on the machines at work (I'd say half my viewers are viewing from Barco machines).

I'll take your comments into account, and aim for something silky smooth for everyone in March.

Reply | Parent | Thread

Anthony Bailey

(no subject)

from: anthonybailey
date: Mar. 7th, 2008 11:28 pm (UTC)
Link

I'm being stupid, Dom is C#, you are Java. That would additionally kind of explain why I could run your applet in the browser on this here Ubuntu machine, wouldn't it? /-: Said machine is also not very cutting edge, 1x2GHz CPU and running Java5. I wouldn't take my comments into too much account when dividing your time - I'm just one unusually low-powered user.

I guess the client/server VM difference is pretty unsurprising for such a CPU-heavy app... Hey, you worked on hotspot compilation during an internship at Sun, didn't you? I'm really dumb about this stuff in that I've never understood why there isn't a server++ mode where Java just compiles *everything* before it starts up, rather than waiting until it's running or about to run particular classes/methods. Given that someone has decided they value speed once running over start-up time, why does even the server VM force you to do the expensive compilation all JIT-style, meaning you run *way* below peak for a little while after you start up? Is Java bytecode compilation just not possible outside of the context of a running app?

Reply | Parent | Thread

Paul Richards

(no subject)

from: pauldoo
date: Mar. 9th, 2008 04:02 pm (UTC)
Link

From what I understand the compiled code is better if you delay the compiler, since you have more profiling information to go on. The VM does lots of clever things with the profiling information, like inlining certain virtual function calls and such like. I don't think this would be possible if the compilation was done upfront.

But hey - I don't know much about this stuff really.. I just know that the server vm generally outperforms the client VM in terms of throughput but maybe not latency (that's what it's designed for).

Reply | Parent | Thread