Drawing in CSS – Parrot

August 29, 2008
A parrot made of right-triangles in pure CSS

A parrot made of right-triangles in pure CSS

So as I said in the previous post, I’ve started taking interest in making real drawings using just CSS.

This had led me to create a parrot, which is made purely in CSS. It consists only of axis-aligned right-triangles, and so can be articulated using only DIVs and borders.

Go see the parrot!

And be sure to have a glimpse at the source.

Note it won’t work in IE6.0, but should work on any real web browser (IE7, FF2+, Opera, etc.).

Special thanks goes to ragestorm.net for hosting my page (WordPress.com won’t allow it). It’s also an interesting website for programmers, so check it out.

On Drawing the Parrot

I produced the parrot from this picture.

Drawing the parrot was in many ways a puzzle. Since I could only use axis-aligned right-triangles, I had to figure out how to produce many basic shapes. I tried to keep the count of the triangles low — I could just as well get a program to produce a pixel-by-pixel copy of the parrot — but what I wanted was a rough sketch that browsers can download and draw quickly.

The beak was paricularly challenging. I wanted to make a convincing curve, without using too many angles. The lighting on the beak helped me get a good effect with very few triangles (considering).

I had a constant battle between detailing and using few triangles. I used creative superimposing to create several details with the same triangle.

In a “blurry” picture, detail represents focus. I left the origin of the wing undetailed on purpose. I didn’t want it to draw attention from what I think are the main features of the image: the face and the tip of the wing (I now regret detailing the stand so much).

What I found curious in the process of drawing it, is that there seemed to be a certain order of drawing which was right to follow. Because it’s made of layers on top of layers, the drawing order is affected by the z-placement. In what way – depends on your method. I found it easier — in the parrot’s case — to draw the top-level triangles first, and background triangles last.

Deciding which details fit in and which don’t, was a completely artistic choice. You’ll notice the legs are rather blurry in that aspect. In the original image you could see the leg in much more detail, and also a hint of another leg. I thought it’s not really relevant to the Big Picture. However, the little yellowish strip on the wing I not only drew, but even emphasized it. I thought it adds realism to an otherwise rather abstract body.

Comments and ideas are welcome.

I’m also planning on making another drawing, so if you have a picture which you think I should reproduce, I’d be happy to consider it.


Look what I found

August 28, 2008

Using the same technique I described in a previous post:


Pretty cute.

You can probably do some really amazing drawings with it. I’m thinking of taking such a project, it would be interesting.

Zen, Art and Programming

July 7, 2008

The main advantage of having no readership is that I have very few restrictions on what to write about.
(the main disadvantage is obvious)

So in this post, I would like to tell a short zen story –

Notice the excessive and redundant outlining (very blunt around the eyes), and that nothing is just quite right. I would be embarassed to display this in public, but everyones first steps were (or still are) awkward.

Notice the excessive and redundant outlining (very blunt around the eyes), and that nothing is just quite right. I would be embarassed to display this in public, but everyones first steps were (or still are) awkward.

On my first drawing lesson (sketching, to be precise) my teacher gave me the task of copying a grayscaled painting with coal (coal is easy to erase and is good for beginners). The painting featured the face of a girl. As most people would, I started by outlining her face and hair, positioning her nose, shaping her eyes, and went on to coloring the paper to match the tones on the painting. I already spent a hour and a half working on the drawing yet naturally it was disfigured. The teacher did not seem to care much about this. Instead he remarked that in the painting the eyes are not outlined, nor is the face. He also remarked about the incorrect differences in tones. Then he said “this drawing is stuck”, took a small cloth and smeared the drawing, erasing most details and leaving only the general shape and tone. An hour and a half of work was ruined, and I was in shock. But I kept an open-mind and listened to his instructions. Here they are, partly in my own words and commentary, but in the same spirit:
1. Avoid detail. Anything you can’t see when reducing your eyes is not important
2. Your sight is biased. To be correct you have to compare elements to other elements (elements being location, size, color, etc.).
3. Observe. Spending time on understanding the drawing (the relationships of elements) will save you time when drawing.
He said this before but it only made sense at that point. And so I resumed drawing, trying to keep these rules. I was amazed by two things: How quickly I managed to reconstruct the painting, and how convincing it looked without any real detail. And so, I learned several things:
1. Your internal model is harder to construct than the drawing. Spend more time on observing, and you will spend less time on the drawing.
2. Detail distracts you from the more important problems.
3. Keep detail to the end. If you start from it, you will never get it right.

If you remember the title, you must ask yourself what all this has to do with programming. Well, as I returned home from the lesson I had some time to contemplate and I remembered a time when a friend and I had to teach someone how to program. This was at work, so that someone was committed. Among the teachings we conjured up an exercise which was supposed to bring the “student” to the right spirit. The right spirit, or as we called it, the “programming zen”, was very important to us. The exercise was this: The student was given a programming problem which he had to solve. After making sure that he completes the program correctly and that the code is of high quality, we order him to erase the program (and any copy) from his computer.
This seemingly cruel exercise was meant to give the following lesson: Code is not important. What’s important is your knowledge and your understanding of it. Once you solve a problem once, you can solve it again without an effort.

This was what I remembered, and I then realized that I have been taught what I tried to teach someone else some time ago, and it applies to both drawing and programming:

Your internal model is harder to construct than the output, and is also more important. Spend more time understanding the problem, and you will spend less time on implementing it.

I believe the other tips and learnings mentioned here also apply to programming, but these are stories for another time.