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.
Tuesday, May 15, 2007
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.
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.
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.
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.
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
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.
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.
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.
Subscribe to:
Posts (Atom)