One of the most important (but also most complex) factors in graphic design is composition: is the image as a whole dynamic or static? Does it express tension or tranquility? Is it trendy or old-fashioned?
We don't have a clear solution on composition at this moment, there are a few things getting jumbled up that cannot seem to be separated from each other. There is composition by itself, but also the elements in a composition and the relation between those elements - which apparently is something quite different than composition.
We have three research threads going:
<p><span class="pink_box">Grids</span> <br />A mediator imposes a <a href="quicksplit">grid</a> on the canvas. This is the most straightforward solution. All elements in the composition get stuffed in the grid. The grid allocates more space for important or big elements (we know if elements are big or small by mapping language to formal parameters in the same fashion as <a href="Colors_Algorithm">Prism</a>) and as such is <i>growing</i> or <i>dynamic</i>. However, this makes self-reflection almost impossible since the elements have no way of discerning for themselves if they are happy.</p><p><span class="pink_box">Vectors </span><br />Each composition has a <i>direction</i>, and a <i>tension</i> and <i>gravity</i>. These are all three aspects of one supervector that describes the composition. Once the supervector is determined, all elements can be placed according to its path (this would be somewhat similar to superstring theory).</p><p><span class="pink_text"><span class="pink_box">Cells</span> </span><br />Each element in the composition is an intelligent ant that communicates with the other elements: do we overlap? Are you happy or should I move a bit more to the left? Possible solutions for this approach is a <i>backtracking</i> algorithm (which would actually make the computer-generated design self conscious!) and a <i>relational</i> approach, in which composition is described purely in terms of relations between elements; the rest they figure out by themselves.</p> <p> </p> <p><img src="/static/media/cpathf.gif" class="border" /></p> <p> </p> <hr /> <h1>Boids</h1> <p>Our current experiments are dealing with <i>Boids</i>, <a href="http://www.red3d.com/cwr/boids/">Craig Reynolds' algorithm</a> for coordinated, leaderless animal movement, e.g. flocking. Right now, Boids seem to be the panacea since it apparently addresses all of the problems we are dealing with: </p> <ul> <li>elements keep their distance from each other</li> <li>but at the same time following a shared movement pattern</li> </ul> <p><img src="/static/media/boids.jpg" class="border" /></p> <p><br /> Examples of boid compositions: <a href="Boids(1)">1</a> <a href="Boids(2)">2</a> <a href="Boids(3)">3</a></p> <hr /> <h1>Semantic bridging</h1> <p>Just as with the colors algorithm, it would make sense to form a semantic bridge to describe relationships.</p> <p>What we have to do here is transform from <i>content-sensitive relationships</i> to <i>spatial relationships</i>. </p> <p>In other words, a translation from essential formal content (hard/soft, warm/cold, sharp/thump, ...) to a formal language of composition, explaining the spatial relationships between the elements:</p> <ul> <li>C from A to B</li> <li>B under A</li> <li>B at last A</li> <li>A smaller than B</li> <li>C between A and B</li> </ul> <p>A <i>solver</i> then solves this equation, and finds an optimal structure between the elements.</p> <p>Quote from <i>The Art of Unix Programming</i>:</p> <p><i>One theme that runs through at least three of the Documenter's Workbench minilanguages is declarative semantics: doing layout from constraints. This is an idea that shows up in modern GUI toolkits as well -- that, instead of giving pixel coordinates for graphical objects, what you really want to do is declare spatial relationships among them ("widget A is above widget B, which is to the left of widget C") and have your software compute a best-fit layout for A, B, and C according to those constraints.</i></p> <p>A tool that does this already is the age-old <i>pic</i>(1) unix program. It compiles pictures for troff or TeX, and describes these layouts. Amazingly, <i>pic</i>(1) is installed by default on every OS X system.</p>
