About Me

I'm just someone struggling against my own inertia to be creative. My current favorite book is "Oh the places you'll go" by Dr. Seuss

Thursday, December 20, 2007

Bouncy Pixelly Creature

This makes me happy.
Pixels make me happy.

Thus, I wanna make a bouncy pixely creature person thing, made from good ol fashioned homegrown pixels, CSS sprites, and javascript. But the road would not be easy going.

Step #1.

Design, using pencils, the creature that I want to create

Step #2.

Break the thing down into seperate individual movable body parts, that can be animated

Step #3.

Model the parts in 3D and render from all angles that will be visible, 360 degrees around, above and below at some reasonable interval, (say, 8*8?)

Step #4.

Trace over the renders to give the parts some hand drawn pixelly juice.

Step #5.

create dom elements for each body part.
create javascript routines to move a body part to any arbitrary on screen coordinate, and switch the frame to any arbitrary frame in its body party category.

Step #6.

Create springs for each limb

Step #7.

Figure out how ventrella did the upright stance for his creatures. Creatures need balance!

Tuesday, December 4, 2007

Helma's documentation is confusing. Here's what _parent really means.

helma's documentation has this to say about _parent

The _parent entry contains a comma-separated list of properties of objects of this type to be used as parent. Objects must know their parent in order to generate correct URLs in their href() function.

_parent = property1, property2.collectionX, root.collectionY

If an entry in the _parent item does not contain a dot, it is interpreted as an object property of the current object that acts as the object's parent. If an entry contains a dot character, the part after the dot is interpreted as a collection in the parent object in which the current object is contained. If the _parent is specified as "root", it is not interpreted as a property of the current object. Instead, the application's root object is used as parent object.


Hrrrwhat?

This is confusing, because _parent is a very specific and tacked on solution to a very specific problem with how helma is architected.

Helma works by mapping a javascript object graph to a url space. Helma lets you map the same object or collection of objects to more than one part of the URL space. There frequently comes a situation where you'll want to generate a link on an html page to a specific object: Say you have a wiki page with a link, and an object representing the page it links to. You'd want to be able to generate the URL to that linked to page on the fly.

Helma provides a function on each object: the href function. This href automatically generates a URL which points at the object that it's called on. So for instance, root.wiki.pages[547].href() may return the url /wikiprogram/wiki/pages/547/. The problem is that an object has no way of knowing which url you want, if it can be accessed by more than one url.

The problem comes when that page 547 is also in another collection. Say, root.wiki.history.pages[547]

Which url should href return? /wikiprogram/wiki/pages/547/ or /wikiprogram/wiki/history/pages/547/ ?

What helma does is pick whichever url that you access the object from *first*, after the application is started, and use that URL henceforth. That is, unless you specify _parent in type.properties.

So, in the page prototype's type.properties file you can add


_parent = root.wiki

and the href function for that object will always return /wikiprogram/wiki/pages/547/

if instead you specify

_parent = root.wiki.history

then the result will always be /wikiprogram/wiki/history/pages/547/

Thus, _parent lets you choose the canonical URL for an object.

The documentation quoted above appears to indicate that _parent can do more than this, but that is something that will have to wait for another post, since I have not yet deduced what that is.

Sunday, November 11, 2007

JSON, XML and the Relational Model part 3

Okay, let's talk XML. What is XML in terms of the set theory concepts from the last part.


Let's start with an element. An element in XML looks like this:


<element
attribute1="value"
attribute2="value"
attribute3="value">
Content
</element>


Okay, so an element consists of a few parts. We have the element name "element". we have a set of attribute names {attribute1, attribute2, attribute3}. The set of attribute names has all the properties of a set that I laid out in part 2. Each attribute forms one half of an ordered double. Finally we have content, which ultimately, is a tuple of nodes, with all the properties of a tuple discussed previously.

A node can be an ordinary text string, a cdata section or another element. Thus, we come full circle, and demonstrate how xml nests.

The key point here is that in XML you cannot nest in a set. To put another way, an attribute value cannot contain an element, or a tuple of elements. The only opportunity for nesting in XML is nesting a tuple of nodes in the content of an element.

What this ultimately means for XML and JSON together, is that JSON ends up slightly more expressive than XML, since it places no such restriction on data structures. Any of the JSON elements (object, array, string, number, etc) can be placed in either an object value, or an array value. (Set and tuple)

There are many approaches to conversion of XML to a JSON notation, or Javascript object. The following article on XML.com describes one approach:

converting between xml and json

One thing you may notice in that article, is that the approach taken is generally insensitive to whether an aspect of JSON or XML is a set or a tuple. The goal appears largely to be a conversion that produces the most aesthetically pleasing example code. No attempt seems to be made at understanding either format, or their logical differences and similarities.

In that mapping scheme, The attributes of an element become JSON object properties, and an @ is prefixed to the property names. This runs into no difficulty, since as I've covered, attribute names in XML are a set, just like property names in JSON. There is no mismatch here. Also, the names of that element's child elements become JSON object properties on that very same object. This will run into problems. In fact, the author of that article encounters the problem on page 2:


An attempt to map a structured XML element...



<e>
<a>some</a>
<b>textual</b>
<a>content</a>
</e>


...to the following JSON object:


"e": {
"a": "some",
"b": "textual",
"a": "content"
}


yields an invalid result, since the name "a" is not unique in the associative array.



Indeed, it is not a valid conversion. The author is mapping an XML tuple, to a JSON set, but a set is not a tuple. Does the author then conclude that it is an invalid approach, scrap it, and try and think of something better?


So we need to collect all elements of identical names in an array. Using the patterns 5 and 6 above yields the following result:


"e": {
"a": [ "some", "content" ],
"b": "textual"
}


Now we have a structure that doesn't preserve element order. This may or may not be acceptable, depending on whether the above XML element order matters.


Oof. Nope. Instead, this approach scrambles the data even further, in an attempt to preserve those pretty code samples on the first page of the article. The author then goes on to conclude:


This example demonstrates a conversion that does not preserve the original element order. Even if this may not change semantics here, we can do the following:

1. state that a conversion isn't sufficiently possible.
2. tolerate the result if order doesn't matter.
3. try to make our XML document more JSON-friendly.




The first conclusion is assuming that this arbitrary scheme the author has devised is the only *Possible* way to convert from XML to JSON. The second conclusion is assuming that there are situations in software design where you can get away with bad logical mistakes. And the third conclusion is strangest of all. He is concluding the problems with the conversion are not due to logical mistakes in the scheme, but are due, he believes, to JSON being inherently *less* expressive than XML. I hope that I have already demolished that conclusion at the start of this blog post.

However, if you are still not convinced, stay tuned for my alternate conversion scheme in part 4.

Another dream I had

a 3d video game with a vast world, with many realms. Each realm has a race of people, who are either helped by, or under the tyranny of some flying demon. Each realm also has a "Flying Demon", whom you can ride, but only if you solve some riddle, or defeat them in battle, or solve some other puzzle.

from that point forward you can summon a flying demon to ride. Each one will have some unique ability, such as speed, stamina, altitude, tight handling, transportation, transformation, and so on.

There is an over arching goal, in that the entire world is under threat by a species of what may be called "Gaia parasites", who feed directly off the planet's life energy. As you travel the planet, the previous realms you encountered may become infected, and mutate the creatures there. The goal would be to revisit every realm, and find the solution to this global menace.

why were you traveling in the first place? You are an alien, and you are trying to find the uberdemon that can travel between planets, so you can go home.

Tuesday, September 18, 2007

JSON, XML and the Relational Model part 2

In math, there is something called set theory.

In set theory, there is something called a set.

A set is simply a list of items with two rules. One of the rules is that order is not significant:

{1,3,2,4} is the same set as {3,4,2,1}


The other rule is that repeats are not significant:

{1,1,2,3,4,3} is the same set as {1,2,3,4}


A set can contain more than just numbers. It can contain anything, such as words:

{Julie, Bob, George, Ringo}


and even other sets:

{{5,3,1},{7,9,2},{3,2,1}}


In set theory, there's another concept called a tuple. A tuple is basically the same as a set, except that the two rules above do not apply. For a tuple, order does matter, and you can have repeats.

These two concepts: sets, and tuples, are the basic building blocks for the three popular data formats listed in the title of this series (And many more). There are plenty of other useful concepts in math for data structures. However, computer languages seem to stick mostly to these two for structured data.

Since JSON is essentially a javascript object, it follows javascript's rules. Here's an example of JSON:

{ 
example:"Object",
name:"bob",
array:["George","Ringo","Paul"]
}


As you can see, this is basically a set, with the members
example:"Object"
,
name:"bob"
and
array:["George","Ringo","Paul"]


each of these members is a double: a tuple with two members. For instance, the first member is the tuple
{example, "Object"}
. The array tuple,
(array:["George","Ringo","Paul"])
is also a tuple with two members.
{array, ["George","Ringo","Paul"]}
. The second member of this tuple, is also a tuple.
{array, {"George", "Ringo", "Paul"}}


So we can see that JSON is composed rather simply of nested sets, tuples, and values. Tuples can contain other tuples, tuples can contain sets, sets can contain tuples, and sets can contain sets.

Monday, September 17, 2007

JSON, XML and the relational model Part 1

When we think about computer data, it's often in the form of trees. You see it in the folder structure on your computer's hard drive, in the html document in your browser, and even in the way we classify species.

The tricky part is, what do you do when your data doesn't fit into a tree?

You have a folder of photos from that trip to Costa Rica, and you use one of them in a design project. Do you leave the photo in the Costa Rica folder, or do you move it to the Images subfolder in your project folder? Or do you keep a copy in both? Does it bother you that your computer is storing the same data, in two places, redundantly, simply because it can't comprehend the idea that a resource could be relevent in two places?

The relational model solves that problem, but at a certain mental cost. It is not particularly expensive, it is just a mental mode that people in western society are not used to using- It is a verb oriented model, rather than a noun oriented model. We are used to nouns. Things just are this way, that way, the grass is green, the house is brick, the cheetah is a cat, the platypus is a trieme.

okay so what's the relational model about? Most technical people will tell you it's about tables, but that's rubbish. Ignore them. The idea behind the relational model is that instead of organizing data based on what it *is* or *has* or *belongs to* by arranging it in a heirarchy, you instead describe how it is related to other things. So that photo was *Used* in project b, and *taken* in costa rica. Costa Rica was *photographed* by Dayne, Dayne *created* these photos. These relationships create links between your bits of data, big and small, like photos, or documents, or names, or places.

so how does navigation work? when you want to find all the photos from costa rica type in
get place:"costa rica", photo

if you don't like typing, such queries can easily be created point and click style, with the data that's already in there.


get -> place -> costa rica -> photo
put person thailand person
edit thing denver place
create design arizona thing
photo melbourne


Then the system works out automatically what "costa rica" and "photos" have in common.

I really like the relational model, and I really hate categories. Yeay verbs, boo nouns. Yeay relationships, boo heirarchies.

Friday, September 14, 2007

How I revived the semicolon

I was searching my own name in google, (as I often obsessively do), to see what the e-world thinks of me. Just as a lark, I searched a common misspelling, and found someone on del.icio.us that linked to a post I made to a mailing list. This was the post, and reasoning that influenced David Heinemier Hannson, to use semicolons in the urls of his popular Ruby on Rails framework. Since David is one of what they call "The Alpha Nerds" on the interwebs, this is kind of like the uber nerd version of someone like Bruce Lee deciding that aviator hats are a really cool idea, after having a deep philisophical conversation with me. And then all the other martial arts experts proceed to comment "Bruce Lee is pretty cool, but what the fuck is with the aviator hat?"



so that I may bask in my own glory and personal brillliance, I give you, the people who haven't given up reading in frustration, the post that will ensure the semicolon's place in your browser bars for years to come:




It would seem that my discovery of a rarely used aspect of the HTTP
url scheme, namely the semicolon ; has led to perhaps a level of
unjustified excitement and advocacy. Intent is very difficult to
gleam from carefully reading a spec, despite, or perhaps because of
the high standards specs are held to for preciseness and lack of
ambiguity, which encourage a sort of unnatural writing style which in
all honesty is hard to read and easy to misinterpret. That aside, I
have a question after reading a set of documents by Tim Berners-Lee,
which are more geared toward the intentional side of things rather
than the specification side of things, which you will find here: <
http://www.w3.org/DesignIssues/Axioms.html >

Regarding the issues I'm concerned with, this is my interpretation of
the document, and you can tell me whether it's incorrect or not:

*For REST, it is mostly important that GET have no side effects, and
anything which does have side effects be implemented with POST (or
mail).

*forward slashes, as mapped to unix heirarchical structures are used
merely as a matter of convenience, and due to the principals of
opacity, are not neccesarily significant to the resolution of a URI,
except regarding the resolution of relative URI's in which case, such
interpretation should be defined per URI scheme, with client support.
Forward slashes do not indicate a resource, but the entire URI
indicates the resource, and it's entirely up to the server how to
find that resource based on the URL. No procedure for internal URI
resolution is explicitly defined.

*That http defines such a scheme for resolving relative URI's for /
style urls, but not yet for semicolons as indicators of parameters
(though TBL provides such a scheme as a possibility for implementation)

*Therefore, virtually any symbol, including but not limited to
forward slashes and semicolons can be used for the purposes of
mapping to arbitrary data topologies, at the discretion of the URI
scheme designer, which can be interpreted and resolved by the server
in whatever way is appropriate. In addition, a great deal of this
flexibility is left in the http scheme to be used at the discretion
of server programmers. As long as opacity is observed, and URI's
remain idempotent nouns.

*To this add the additional constraint given by roy fielding that
this can only be done as long as the nature of the URI scheme is
clearly communicated by the server to the client. In other words,
there is no assumption made that the client will be able to infer a
URI scheme from a base URI without explicit communication that such a
URI scheme is in use.

*Notable exception is the # fragment identifier which is reserved for
use by clients, and to be defined when registering the mime type for
a document.

*TBL then demonstrates the flexibility of URI's by laying out his
Matrix URI scheme, that is using the ; and = symbols to specify a
matrix information space, which is distinctly incompatible with a
heirarchical space. This does not imply that ; has any inherent
meaning relative to the REST or uri model, but as a scheme designer,
TBL is using it to represent a type of information topology being
made available by a server.

If one is to take all the above statements as true and accurate
interpretations of REST, then solutions to certain problems become
available, which are not possible, or are awkward under a naive
surface impression that REST requires URLS to contain only forward
slashes / to represent information topologies. It is beginning to
look to me that this impression has more to do with Aesthetics, and
search engine technologies, than any specific requirements of REST.

A problem this interpretation potentially solves, for instance, is
that of multiple views of the same information resource. Usually,
this would be accomplished through content negotiation. However this
is only effective if your multiple views all have distinct mime
types. If you have for example, a resource such as < http://
example.com/blog/posts/53 > representing an article on a blog, you
may have a non editable view, and an editable view.

In an ideal world this sort of thing could be specified using a
fragment identifier, such as < http://example.com/blog/posts/53#edit
>, however for this to work on a practical level, it requires client
support which is not likely, and somewhat incompatible with the
fragment identifier scheme defined for html/xml

Another option is to use the forward slash < http://example.com/blog/
posts/53/edit >
However it seems logically innacurate to state that a view is a
hierarchical child of the resource, rather than something more
lateral, or directly related.

If the bullet points above are accurate, then it becomes possible and
reasonable to use a semi colon, or any other appropriate symbol to
represent a lateral space, such as a view. Matrix notation seems
appropriate, since such a view system can be seen as a "matrix" (or
tensor) with 1 axis, and english words representing named points
along that axis.
< http://example.com/blog/posts/53;view=edit > < http://example.com/
blog/posts/53;view=display> < http://example.com/blog/posts/
53;view=hatom>. This makes sense to me as viewing a slice or
subsection of a single resource, which includes multiple possible views.

The caveats being how relative URL's are resolved by clients, whether
the server supports this level of flexibility, and whether
appropriate mechanisms are employed for informing the client of the
URI scheme in use (such as hrefs along all points on a matrix
allowing navigation)

This may be overintellectualizing a simple problem, but the main
purpose of this post is to verify if I have my bulleted
interpretations correct, otherwise my conclusion may be false.

Wednesday, June 13, 2007

Online color schemer.

Okay, there's hundreds already, but they all miss the point a bit. A color has three perceptual attributes, Hue, Lightness, and Brightness, (Or HSV, HSL, etc etc)

The majority of the online color schemers only harmonize ONE attribute, Hue, while either ignoring the other two, or leaving it at the whim of the user.

Another thing online schemers ignore is the PROPORTION of color to be used. A color scheme that works for 3 equally distributed colors, is different from one that works with one predominant color, or two predominant colors. The way an accent color works is decidedly different from the way a body color works, and color schemers ignore this as well.

Most color schemers ask for one color, and harmonize the rest based on that. Well what if I have two colors! A client has two colors that must be used, how do I harmonize off of that if I can only input one color?

Okay so I could just ignore the color schemer programs, and do the whole thing by eye, right? That kind of defeats the purpose of these programs existance does it not? Why make them or have them, if in the end they are completely useless?

Todays idea is, a color schemer that isn't a sack of shit.

Friday, June 1, 2007

What is Design?

This is one of those ideas that is not just a "cool idea", or something that I just have a random kink or obsession about. This project would be genuinely useful to me. Enough that I have seen other designers do exactly the same project, design organizations, such as AIGA, and others.

The problem essentially is that most people really don't understand what graphic design, or design in general is, or what its value is. It also happens to be these very people who would benefit most from design.

What I need, as a designer, is a booklet, a manual, or something that is easy to read, well designed, and not only explains why design is a valuable thing, but demonstrates it in a clear and obvious way.

It perhaps shouldn't go into too much detail about how to design something, but through popular examples.

For instance, the most obvious example is the iPod. Now, hindsight is 20/20 of course, but according to the logic of those who don't understand design, the iPod should have been a failure. The iPod wasn't the first mp3 player. It wasn't even the first hard drive based mp3 player. It was more expensive than other music players when it was first released, and still is. In terms of hardware, it doesn't have as much capacity as other players, and didn't when it first came out. It doesn't play as many formats as some. The iPod was even the last digital player to play videos. About the only obvious advantage it's had is that it's slightly smaller than the others. If you look at it in these terms, it's a complete mystery why the iPod has been such a success.

There are other examples too. The branding for chipotle, the architecture of their restaurants. Starbucks, flckr, and others. With no obvious advantage over competitors in a purely statistical standpoint, it's clearly the superior design which gives these companies the win.

There are smaller scale examples too. The clarity of communication in a sparse design which makes good use of negative space, vs. a crowded design which sees empty space as wasted space. The direct financial benefit that comes from designing an ecommerce site to channel viewers into becoming buyers- Design has a direct and real relationship with conversion rates in this arena.

Design is important, and it's not always easy to explain why verbally. A handout for potential clients would be invaluable.

Tuesday, May 15, 2007

City Paintings

Series of paintings, 8x2', divided into 16 1x1 quandrants. Huge project, one of those ridiculously complex ideas.

Essentially each painting would depict a street in the Melbourne CBD..

So, one painting would be "Flinders Street", another would be "Collins Street", another would be "Bourke Street". Each street is exactly 8 blocks long, so each block would map to a 1 foot long section in the painting.

The painting would depict a street level view, with the street running horizontally down the middle of the painting, the north side of the street sitting rightside up vertically on the upper half, and the south side of the street upside down on the lower half.

It would have a very flattened perspective.

Once I finish all the CBD streets, I may then tackle gertrude street and smith street. Who knows, Maybe Colfax is next.

Thursday, May 3, 2007

Wanna make your own videogame?

The 6 Indie Mistakes

this article really sums it up. Have an idea, and want to see it become real? Prepare to work really hard for it. The bigger the idea, the harder you must work.

Tuesday, May 1, 2007

Particle Mosiacs

Take 1 photo. Add a particle simulation. Add a particle to the simulation. Watch as this single particle floats around the screen. It is attracted to bright areas. It looks at its immediate surroundings, and locates the direction in which it will find the brightest pixels, and it goes in that direction. As it does so, it gobbles up the light, and adopts its color. As it gobbles up the light, it grows in size, until it settles into a position in which it cannot move to an area which is any brighter than the one it's already found.

Add another particle. It behaves much the same as the last particle, except that it cannot occupy the same space as the previous particle. It is repelled by its presence.

Add another, which behaves as the previous particles, but is repelled by them.

Keep adding particles until the entire canvas is covered in these hungry particles that cluster around the brightest areas, and are nourished by them. The largest particles will be covering the brightest areas, while smaller, malnourished dark particles will have been sequestered to the dark corners of the image.

Once this ecosystem has been saturated, the boundaries of each circular particle can become loose, like jelly. each boundary becomes a new particle simulation, each circlular boundary subdivided into smaller interconnected particles. The interconnected particles are attracted to eachother, and in isolation, pull together, like the skin of a bubble. Their resting state is the size of the original particle, at this resting state, the particles are repelled at exactly the correct distance for this resting size to occur.

At the same time, all the particles across the entire canvas are attracted to eachother- or more specifically, they are attracted to the particles nearest to them.

While the compulsion is for the boundaries to remain circular, there is a stronger compulsion to spread out, and meet with the surrounding boundaries, and form a more complex shape. The forces at work across the canvass will eventually come to a balancing point, where no more movement will occurr. This resting state will be composed of a number of well fitted shapes, colored appropriately, and sized according to brightness. They will be well enmeshed together, and form a faceted image which maintains organic and geometric qualities at once.

Lighting in context

There is a computational photography technique in which a subject is placed within a sphere/dome of lights. The subject is then photographed with each light illuminated one at a time, resulting in a number of photographs equal to the number of lights. These photographs can then be composited together and modified in such a way as to simulate any possible lighting condition. This is achieved by taking a "lightprobe" of an environment and mapping it to the spherical dome of lights- such that each light matches the color and intensity of that corresponding space in the light probe. Or more directly, each photograph which corresponds to a particular light in the light dome is modified to appear as though that particular light had the color and intensity of that cooresponding space. This modification and mapping is done with each photo in the set, and they are all summed together into a single "Exposure", and you end up with virtual lighting.

Isn't it an interesting situation then, if you take this virtual lighting concept, and you combine it with the fact that modern macintoshes are equipped with a camera which is easily accessed from software, and facilities for taking screenshots of the current scene on the screen of the computer. These two could be combined into a sort of "light probe", such that a photographed object could appear on screen and look as though it were lit at the back by the other objects on screen, and lit at the front by the room surrounding the computer.

This illusion could be perfected by a measurement of the brightness of a typical computer screen, combined with exposure information from the iSight. These would be fairly standard across the models of macintosh equipped with built in isights.

Thus a dynamically lit widget could be produced, quite probably with the help of quartz compositor's easy access to isight, and easy integration into widgets.

Sunday, April 15, 2007

On bad artistic assumptions

In creativity, I cannot stress enough the importance of research. This is not an idle bit of advice. In teaching or learning, there are many such rules and practices, which are taught and given without argument, expected to be accepted. As a student you may accept unquestioningly what you are taught, at least for the purposes of the course and the grade. Without the reasoning to back it up though, such lessons do not become knowledge, but instead become religion. Knowledge is something that you can demonstrate, and if prompted, give a convincing argument why such and such is so. Religion is merely a set of rules that you follow, without knowing why. They are in other words, a set of assumptions.

This is all very abstract without an example, so I will demonstrate now why research is important, and why a creative should not take it for granted.

Some time ago, I made a Totem painting. The basic idea I had was to paint on a 2' by 8' masonite board, a Totem Pole composed of a number of various mass cultural characters, such as the cat in the hat, kermit the frog, mickey mouse, etc. Collaged with this was images of various scenes I picked out of searching through various japanese websites and books; imagery from japanese culture; modern and traditional. While the painting was generally well recieved, it wasn't a *great* painting, and this was not due to the quality of paint I used (admittedly poor), or how much time I spent making crisp lines (not a lot).

The reason it wasn't a great painting is due to the rushed assumptions I made in the conceptual phase. The worst assumption, was the ethnocentric viewpoint that totem pole design is simple, and primative, and thus easy to imitate. The really stupid assumption that totem poles were merely stacks of heads, and yet another bad assumption that it's possible to encapsulate the subtleties of an entire culture by merely selecting a few images.

The truth is, totem pole design is as nuanced and delicate an art as font design, or classical architecture. There is a balance of line, volume, and flow which is not easily mastered. Additionally, totem poles are not merely heads- they are entire bodies, deformed yes, so that the head is the most prominant feature. But the body is still there nonetheless. There is cultural context in these deformations which again is not easily mastered. This sense of cultural context is also missing in my rushed and crass choice of japanese imagery. These assumptions, spelled out, seem obviously stupid. But these sorts of assumptions are not easy to notice, especially when you are rushed. They are not easily noticed because one does not typically think about what assumptions one holds, until they are prompted in such a critical way.

The most difficult thing about learning, is being flexible enough to recognize where you are making assumptions, and maintaining the will to discard these assumptions when it becomes necessary. This is something a teacher cannot do for you. This is why research is important: It shows you what reality IS, not what you expect it to be.

Research research.

Tuesday, April 10, 2007

Efficient typing system

skeleton post- fill in details tomorrow.

1. tedius repetition in task of typing on a mobile phone or gaming device.

2. Computers designed to eliminate repetition

3. Statististical prediction

4. Automatic adaptation

5. Other applications

Programming Language

1. Why create a new programming language?
I have an idea for a programming language. There are hundreds already though, why create a new one? I firmly believe that the bulk of programming languages are missing the point. They don't lack effort or thought, many are theoretically sound, many aren't. Some of my favorites are Lisp, Ruby and APL.

What's lacking in the world of programming languages though, is the perspective of a designer, because frankly, every programming language I see is ugly. Every programming language I have seen, to one extent or another flagrantly disregards the history and culture of punctuation and symbology. They abuse symbols, assigning them meaning they were never meant to have. These programming languages force their readers to cross their eyes, and ignore their years of cultural training to follow the specific and unique logic which applies only to the world of programming. The relatively high density of brackets, and nesting lead to a visual ambiguity which requires an expert, and a good code formatter to decipher. Code should not be code.

And why should code be beautiful, you may ask? The end users don't have to look at it, and the programmers should be clever enough to deal with any sort of cryptic obfuscation, and difficult to type out structure. They are professionals after all! Sure, but the key point is, they are also human. Difficult to read, and hard on the eyes code leads to more mistakes, more fatigue, and over all a more grueling experience. Your average person can usually look at a gramatically incorrect sentence, and immediately sense that something is wrong. Your average programmer doesn't necessarily have this ability with a line of code. Due to the haphazard and thoughtless design of programming languages, you still have to read through word for word, symbol for symbol to figure out why something doesn't work, why something is illogical.

I think there's a better way. I think there is room for a humanistic programming language. I think it's time for one too. There is currently no technical reason it is not possible. The *only* reason we still code using these brutal machine languages, is due to the short history of computers, and their original strict limitations. These limitations no longer exist, but the assumptions that we built from those limitations still do. Let's work to improve this.

2. Design goals

It's easy to lose sight of your goal, in the midst of the process of creation. See my earlier post about creative briefs. Ruby on Rails has a number of design principles. there's Don't Repeat Yourself, and the principle of least surprise, for a couple of examples. A humanistic programming language should have some basic guidelines to enforce a certain amount of self consistancy.

Here is the space where I will keep my working list of HPL ideals.

Respect the punctuation

Don't violate the history, culture and meaning of symbols. We are no longer limited to just what's at the top of the keyboard, above the numbers. Nowadays, we have the entire Unicode symbol library at our command. Let's find appropriate symbols, and use them for their appropriate meanings.

Whitespace is not irrelevant

Having a standard indentation style has proven invaluable to the open source projects that have enforced it. Having a common visual expectation for the code makes collaboration that much easier. Let's not rely on humans to enforce the visual style. We have computers for droning repetetive tasks like that.

Dielects over Bloat

In the real world, different professions each have their own specific languages. Think about the show ER, and the sheer amount of latin they use just to get around having to tediously describe in detail every little thing. Verbal shortcuts. The same should apply to programming. If I'm making a web application, don't make me tediously describe the process of retrieving information from a form, or persisting data in a database. We know in advance we need to do these similar tasks many times. Provide shortcuts for doing them.

Loops are a bad solution to an old problem

The typical tasks which need to be performed by loops is well understood by now. Some task needs to be performed on a list of things, a tree needs to be traversed to find a needle in a haystack, etc. Make syntax for the task, not the computer's method of performing it.

Syntax for the task, not the method

nuf said

Brackets are bad, nested brackets are worse

Brackets are actually visually useful, as long as the opening and closing bracket are on the same line, and there are no other brackets nesting in or around them. Once you break them out into multiple lines, nest them, and worst of all, have a line with nothing but a bracket, things start getting confusing and visually ugly. A closing bracket visually points to the left. If it's on its own, it is pointing at nothing. It is closing and resolving nothing. Combine it with nesting, and reading a page of code becomes a game of matching opening brackets to closing brackets. How can you debug your code, if you have no idea what is going on in it, and it is not visually obvious that you have made a typo? XML endevoured to solve the matching problem. How? More brackets! MANY MORE BRACKETS. Great. I think we can do better.




3. Parallelism


4. Relational integrity

5. MVC enforcement

6. Event Model

7. REST architecture provides a means for sharing work, without working to share.

8. Internet provides a means for automatic distributed super computing.

Sunday, April 8, 2007

The value of the creative brief

During the development of an idea, it's easy to lose sight of your original vision. You begin to see new things in your work, and it carries you in new directions. Often during this process you end up with something very different from that which you originally intended to create. During the process, you forget the problem that you set out to solve, and judge your work purely on its aesthetics, or the feeling of the moment.

The creative brief is the solution and recognition of this situation.

A creative brief is a written, detailed description of the design problem to be tackled. It is not simply a statement of the problem (a brochure needs to be created), but also gives you relevant facts about the client, their target market, the market goals they wish to achieve, their history as a company, the intended message which needs to be conveyed, and any other relevant information. A good creative breif gets beyond the simple question of "What do you want", and instead sets in a number of parameters which define a "space", what is often referred to as the "Problem Space". Within this defined space exists viable solutions, and beyond it lay non solutions. In theory. A really good design process will recognize when a creative breif is inadequate, and midway through redefine the problem, perhaps in different words, perhaps from a different perspective. For instance, a creative brief might stipulate that the client needs a business card for her florist business. A designer, after some meetings with the client, might redefine the problem as "The client wishes to attract more business from engaged couples, and stay within a budget of under $4000"

The key here, is the more detailed you get, the more you crystalize a vision of what the problem *really* is, the more productive the design process becomes.

Through each revision, and at the end of the process, ask yourself: "Does this *really* solve the problem?". be thoughtful and honest to yourself (or others) in giving the answer. If you answer no, ask yourself why, and you will understand what revisions need to be done. If you answer yes, be careful that you are not deceiving yourself. There is no such thing as a perfect solution- But within a problem space there are many possible solutions. Is this the best one?

This may seem stupidly obvious, but in this complex mesh of theories and processes that is the design process, it is easy to lose sight of what is obvious, and get lost in the details of implementation.

The aftermath of the flood.

I had a conversation with my friend Dano, and I thought of a few more things about ideas.

'The progression of design history has not been a progression of new ideas, but the identification of new aspects of the same old problems."

It's not the ideas through history that have been important. That is just the part that people notice. They don't notice why they came up with the new idea. They don't think about the fact that it didn't come from nowhere.

I think to a large extent, as a designer I have been fixated on coming up with the next big thing, the new great idea. In doing that, I lose sight of the fact tat the people that came up with the last great idea didn't do it on purpose. They found a new aspect of an existing problem that nobody noticed before, or they did notice, but were too afraid to openly acknowledge that it exists.

Dano then tells me that he is the "Exact same way". He wants to come up with something great and new, and he psyches himself into getting nothing done, and making nothing but shit along with it. He wonders why he can't just do things without thinking "How can I be completely original", and suggests that this is perhaps too lofty a goal to set yourself to.

It's a bit like a chinese finger trap. There's an element of selfishness in wanting to grab some small bit of glory for yourself. But in order to get there you have to completely forget that you want that. You have to convince yourself that you don't, and you're just out to solve a problem. You also have to accept that there's a very good chance that it won't turn out great, and not let yourself be dissapointed when it doesn't. Just figure out what went right, what went wrong, and move on.

The great solutions come out of honesty; honesty to the problem, honesty to yourself, honesty about the solution. Don't let cultural biases, or your ego get in the way of perceiving something about the problem. Don't succumb to the forces that tell you to ignore it, the forces inside you that want to be seen as good, and smart, and talented, and better. Instead listen to the littler voice inside you that says the emporer has no clothes.

The flood

The important thing to remember about ideas, is that they are not important. This will probably violate a lot of people's feelings about ideas, but it's true. Ideas are cheap. It's the execution that matters. This is why I have no problem writing all my ideas out here. It doesn't serve me any function to jealously keep all my ideas secret, in fear that someone will steal them. I am not the scriptwriter that accuses the producer, who rejected my script, of stealing the very ideas within it. The value of ideas has become very distorted in modern western culture. This could go on to become a lengthy discussion about copyright law, but that is not why I am writing this post.

So, let's take it as a given that ideas are a dime a dozen. Suppose I fill this blog up with a dozen ideas a month. How do I determine which ideas are worth pursuing? Which ones should I invest real time in bringing to reality? I Think this is related to the question I asked in the first post. How do you define a person? Another (more sexist) form of the question is "What is the measure of a man". It's a question about measuring the potential of a person. It's a question about predicting what that person is likely to do in the future. Depending on how you look at it, it's also about how a person is percieved. It seems shallow, but social perception is important. So when you are judging a person, what factors go into your judgement? What do you look for to decide whether someone is a genius, or a peasant?

Perhaps it is what a person has done in the past. If it is, then really, you are judging a person based on what ideas they chose to act upon, out of the sea of ideas. So one must choose carefully, as the ideas one chooses, determines who they are, or at least how they will be judged.

Many people will chose ideas based on their marketability. Perhaps there's a certain cool factor. Perhaps they've fallen in love with a particular technology. (lots of people have fallen in love with AJAX, lately). Most people don't think about the criteria they use for choosing what to act on. They just do things because they feel good, or they do things because they think it is expected from them by other people. Some people just have a really nice hammer, and are out looking for things that look like nails. Others just want to be seen doing the same things as everyone else, and desperately want to be thought of as cool or normal.

As a Graphic Designer, I am trained to start with a problem. Once I've established the exact nature of the problem, I must think of as many possible solutions as possible. The flood of ideas. The more you can think of, the better. The idea that wins, is the one that solves the most aspects of the problem. The progression design history has not been a progression of new ideas, but the identification of new aspects of the same old problems. Modernist architecture fullfilled all the needs of a human being, through the triumph of science.

That is what the architects thought. They've thought of the optimal size of the kitchen, the living room, how many bathrooms there should be, where they should be located, how high the ceilings should be, what the best materials are, how to give just enough space to someone so they don't feel cramped, but not so much that high density living is not possible.

They forgot that humans don't like living in featureless boxes. So Postmodernism is about the discovery of the human aspects of problem solving. Unlike modernism, Post-Modernism doesn't strive for purity, or the triumph of man over nature. Post modernism accepts everyone and everything for exactly what it really is. Post modernism doesn't reject history, it doesnt' reject science, it doesnt' reject pointless decoration or starkness. Post modernism is the relentless search for new aspects to old problems, and it has erased the boundary lines for future eras of art, and replaced them with a smooth continuous forward march away from the myopia of modernism.

So how do I choose which ideas to pursue? I don't. The best thing to do is choose which problems to pursue, and investigate as many aspects of the problem as I can, in a thoughtful and methodical way. The ideas will sort themselves.

Saturday, April 7, 2007

Voxels

What is a voxel? it's like a 3 dimensional pixel. It is short for "VOlume piXEL". It's a very simple concept which has been used in countless applications, from medical imagery to videogames. The basic idea is a 3D raster, each element of which stores attributes such as color, transparency, density, normal, and countless other possible things, or subsets of these. The classic Demoscene demo is the voxel landscape. (not true voxels, but possibly an impressive demo nonetheless).

I have been obsessed with voxels. Why? I think there is one application of voxels which has been underserved: 2D style games. Rapid development of Pixel art. Imagine the standard 16 bit games with multiplane parallax backgrounds. Now imagine them with many more contiguous planes, 3 dimensional objects in the background smoothly passing by in perfect perspective. Not flattened cardboard 2D paintings, but fully 3D props rendered with a 1voxel=1 pixel style engine. Most voxel rendering engines I see make the grim mistake of rendering a voxel with many pixels, creating an ugly pixelated look. Imagine 3D worlds with the tidy detail which is given to 2d pixel art. You can get a taste of it at the metroid cubed site here http://pages.infinit.net/voxel/home.htm

I get excited at the potential of this guy's work, but saddened to see it wasted in cheesy 8-bit style graphics, and reliving old games, and old gameplay models.

Like many, I have been dissappointed in the graphic quality of games since the playstation arrived. 3D graphics in videogames are consistantly ugly as sin. Their bicubic scaled textures filling the screen with vomited blurs of pixels.

I want a 1pixel=1voxel world. A 1pixel=1voxel oriented graphics editor. A 1pixel=1voxel oriented game engine which combines the flexibility of 3D with the exquisite detail and lush beauty of 2D pixel art graphics.

1. The Basics.
Each voxel can store a color, and an opacity. Most of the time, opacity is a simple on/off switch. Either it exists or it doesn't. It can be full alpha, which significantly slows down the rendering of the voxels. The result is a smooth density cloud- this is what makes voxels useful for medical imaging. Newer game engines are using voxels for more realistic clouds and smoke effects.

2. Normals.
what is a normal? In 3d graphics parlance, a normal is a point in 3D space which is the terminal of a line that is perpendicular to the angle of the surface at a specific point on a surface. In other words, the surface normal defines what direction a surface is facing. One can determine how well lit a surface is by measuring the angle between the light source, the surface, and the normal. This is a very simple cross product, then arc tangent operation.

With voxels, each voxel can have its own surface normal. Many voxel engines determine the surface normal automatically based on a voxel's neighbors. This produces a very legoish appearance to your voxel models. It is possible to smooth this out by taking into account more neighbors. I think a better idea, is to model first in a standard 3d modeller, then remember the normal of a surface when converting from the standard model to your voxels.

Thus, a voxel model can be more than just a flat colored grid of 3d pixels, but dynamic per voxel shading is possible, with very smooth appearance to the surface.

Some other very handy things can be done with normals though. You can find the contours of a voxel model, and use them to add cel shading style lines. Here's how it works: Simply give your voxel model a shell of invisible voxels, just a 1 voxel thick coating. Then, render the shell voxels if their normals are parallel or near parallel to the camera. This is a common technique in polygonal cel shading. This is an application of the same principal at a pixel level of precision. Essentially what this does is render a pixel next to any "surface" which is perpendicular to the camera. This will be the object's contours, what we normally perceive as its edges.

The beauty of this is that the exact shape of the shell can be tweaked and modified to exactly how you need it to look, at a pixel level. What's more, this can do more than just outlines. Pixels which only render when their normals are pointing a certain direction away or towards the camera, can be used for view specific pixel level tweaks. Is one view particularly awkward? just tweak it a bit. This is the same basic principle as hints in vector fonts.

3. Simulations.
Since every atomic element of the object is defined as a point, this opens the door for a vast variety of particle simulations. Particles in simulations can be made to behave like liquid, smoke, jelly, springs, strings, cloths, solar systems, bouncyballs, pendulums, rag dolls, etc. Voxel positions can be attached to particles in a simulation, allowing characters and objects to realistically bounce, flow, explode, melt, stretch, fall down, trees grown, geological simulations producing realistic voxel landscapes. The possibilities are endless.

4. Sprites.
Remember the opening title screen for Yoshi's Island? It's basically a 3d island composed of a number of 2D graphics attached at some point on their base to a 3d plane. The plane rotates around carrying the graphics with them, creating the impression of a 3d island while keeping the cartoony detailed appearance that only dot graphics can achieve.
If I create my voxel paint program, I want this effect to be achievable as any other voxel effect, and combinable with any amount of voxel graphics. Just attach a 2d graphic to a voxel, and the 3d calculations take care of themselves.

5. Isometric.
One comprimise that I don't think any pixel art purist will object to, is that I intend that my ideal voxel rendering engine not apply perspective to its voxels. the scaling of the voxel has the potential to destroy the 1pixel=1voxel idea. At the very least, a perspective engine should not scale a voxel any larger than a pixel.

6. Sub Surface Scattering
This is a popular effect in computer graphics for simulating the appearance of skin. In order for it to be realistic though, an object needs to have an interior. For humans, the interior must be red and meaty. In a voxel object, the interior is already there.


How will I make this all work? what programming language shall I use? What sort of game will I make?
I haven't decided yet. Maybe flash. Maybe java. Maybe SDL and C. Maybe all of the above? Perhaps anyone who happens to read this has an opinion? Who knows.

Am I web 2.0 now?

Okay so I have a blog now. perhaps unlike the thousands of other people who also have blogs, I don't expect anyone to read this. (But if you are reading this, I'm deeply sorry.) Why did I start this blog? Because I have too many ideas in my head to keep track of. I don't have enough time to implement all of them, but I also don't want my ideas to pass silently into oblivion either. I have tried windows notepad files. I've tried mac stickies. I've tried livejournaling. I've tried physical notebooks, and the running thread is that I have too many systems for recording ideas, and my head is busting at the seams.

Who am I? Who is anyone? How is a person defined? Is a person the sum of their experiences? Is a person the resume of things they have accomplished, the list of jobs they've held? Is a person a composite of the thoughts and opinions they hold? Is it the unique matrix which defines how a person responds to perceptual events, their personality? I am barely a person by any of these standards, but I exist anyway, so I may as well make the best of it, until I die or something kills me. I am just a person who has ideas.