Archive for April 2, 2010

e2vector inspired by harmony.

A few weeks ago, Ricardo Cabello (Mr Doob) published an inspirational “procedural drawing tool” called Harmony.  I was impressed by the code simplicity of Ricardo’s brush effects, their natural look, and the responsiveness and speed of an application made with HTML5 and Canvas.  As a Flash/Flex developer on a Mac, I’m not accustomed to speed and responsiveness.

Anyway, Ricardo’s experiment not only caused me to consider HTML5 and Canvas more seriously, but also to try to implement some harmony-like brushes in e2vector.

I had to employ several simplifications.  e2vector imposes smoothing.  So drawn shapes are reduced to well-chosen few points to represent them.

I noticed that Ricardo’s brushes respond to how quickly the user makes a brush stroke.  In harmony, a slower motion with the brush produces more points, and a darker impression.  Unfortunately, these intermediate points would be removed by e2vector’s smoothing – so I couldn’t achieve the same effect.

Also, I tried to do smoothing on-the-fly rather than at the end, but the added computational burden compromised the responsiveness of drawing.  So I had to revert to the old scheme and my brushes appear to change appearance slightly once when the brush stroke is complete.  Not ideal, but computationally simpler and hence more responsive.

But e2vector brushes incorporate some novel features.  Like the ability to edit the path spline of a brush, and the ability to convert any e2vector shape to a brush effect.

(Note: in this latest version, the new brushes feature isn’t entirely recognised by all parts of e2vector – for example, if you export  to .svg or .fxg – you’ll just see the path.  Not the brush effect.  I’ll get round to fixing this when/if I have time in a later version.)

One more thing…

I’ve put some effects like twirl, pinch, and spherize in this latest build of e2vector.

e2vector (AIR application) can be downloaded here.

_______________________________________________________________

To be continued…

Comparing my implementation with Mr Doob’s original implementation – while I’m happy with the kinds of novel heuristics and computational complexity reduction techniques I’ve employed – I’ve compromised the “look” of brushes too much.  I think I lost sight of aesthetic quality, while I got wrapped up in algorithms.

I’ve since improved the look of my brushes – and I’ll report on that soon.

Furthermore, I haven’t really explained the engineering trade-offs.  Software engineers will get it – but graphic designers, unaccustomed to considering how things work beneath the surface, will probably check out this blog and exclaim “That sucks!”.  Why I didn’t I just port Mr Doob’s JavaScript to Flash ActionScript? (see: Mark Knol’s blog)   I’m working with smoothed splines – why is this vital to my application?

All will be explained more carefully in the second instalment.

Advertisements

April 2, 2010 at 5:08 pm Leave a comment


  RSS feed          View Daniel Freeman's LinkedIn profileView my profile

Add to Technorati Favorites

April 2010
M T W T F S S
« Mar   Jul »
 1234
567891011
12131415161718
19202122232425
2627282930