Vague Art Discussion #1: Rhythm

Now that I will be able to focus on arts (drawing and 3D modeling), I decided to start a series of blog posts in which I write my thoughts about what I learn in drawing and modeling. I'll call this series "Vague Art Discussion" because art discussions feel vague to me most of the time.

Rhythm
Last year, while my sketch group was working on our doujin artbook, I tried reading the book Force: Dynamic Life Drawing for Animators by Michael D. Mattesi, but I could not understand it at all. Recently, the book was recommended for reading by Dom, one of our life drawing instructors. So I am trying to read the book again now, with an additional motivation to make sense of what it says. I still don't understand most of what the book says; it uses many terms that I just cannot understand: "directional force", "applied force", and "rhythm".
(This only reinforces my opinion that art discussions are vague most of the time.)

I didn't pay much attention to the word "rhythm" when reading. It started to seem important in the next life drawing class, when Dom (casually) mentioned the word while demonstrating drawing a series of sketches to depict an action. It made me want to understand this concept.

Before proceeding, let me make it clear that what I write below are my attempt to understand what rhythm means in drawing. I could very well be completely wrong.

I personally interpret rhythm as the regular beat in music. It suggests the need for time. The best way I can define rhythm is "something similar that happens more-or-less regularly".

• "Something similar" because sometimes beat sound changes, yet I can still understand that rhythm continues.
• "Happens more-or-less regularly" because, again, sometimes the duration between 2 beats changes, yet I can still understand that the rhythm continues.

As I re-read the paragraphs about rhythm for the third time or so, suddenly it hit me that there is a time dimension in drawing.

• When drawing, I start from a position, go to another position, etc, with a pencil/charcoal. I know that I have a certain kind of speed when drawing a line; so I need a certain amount of time to draw a length of a line. Thus, drawing similar length of line takes me similar duration. This may explain the "more-or-less regular" part of rhythm description.
• Now I only need to draw something similar "more-or-less regularly" and perhaps I will have my rhythm!

The example given in the book is about drawing zigzag lines, with skiing downhill as analogy (on hindsight, perhaps my finding above should be straightforward after all), so it seems like I'm getting closer to understanding rhythm.

However, this is life; obviously the next wall comes hitting me in the face very soon after that: the moment I hold a pencil and tried to apply my understanding of rhythm when drawing. The examples given in the book were drawn by people who understand rhythm, so it is easy to see rhythm in these drawings. In life drawing class, however, I see a real life model. Suddenly I realize that I need to find rhythm as an imaginary overlay from a real model. Some poses make it easier to see rhythm than others; most of the time, though, I just cannot see a rhythm on a pose. So that's something I need to be working on, I guess.

NB: Anyone reading who understand rhythm, please feel free to leave a comment. Thanks!

Hierarchy

Recently, I see the concept hierarchy everywhere. I am attending a 3D modeling class, which includes a life drawing class; and at work I am coding an editor for a web application.

In life drawing, Andrew, one of my instructors, says "Go for the large shape first". I think it's easy to imagine that the same advice applies in 3D modeling. After all, both drawing and modeling are about defining shapes.

In programming, it is more difficult to see how Andrew's advice applies. Perhaps it helps to put programming activity in the context of a development project. A project has goals and time limit. Thus, it is sensible to go for the large items first. "Large" in this case I interpret as "essential" or "must have". Then, I progressively go for smaller and smaller items to refine the system's behavior as close to the ideal behavior as possible. I interpret "smaller items" as "non-essential goals" or "nice-to-have items" and "non-essential bug fixing".

I was uncomfortable with "non-essential bug fixing" at first because, as item#5 in the Joel Test suggests, fixing bugs should have higher priority than writing new code. However, in the tight deadlines I was in, it simply felt right that non-essential bugs should wait. Re-reading what Joel wrote, I think what's important is not a rigid "fix bugs first then write new codes" rule; but finding a compromise between implementing new items and fixing bugs in items already implemented.

Anyway, I thought it's interesting to see a parallel between drawing and programming process. Perhaps I see it only now because the life drawing classes forces me to draw in a very limited time (3-minute poses, 1-minute hands, 10-minute faces, etc).