As my Christmas break comes to an end, I'm catching up on some recommended reading. I've picked up a copy of Neal Stephenson's Quicksilver, and I'm glad I did.
In the small amount of teaching I've been doing over at The Bartlett's MSc Adaptive Architecture and Computation, I've emphasised the need for programmers to be fearless symbol manipulators, fearless text editors - much as students well-schooled in calculus become fearless with algebra and equations, and students well-schooled in drawing become fearless sketchers and draftsmen. Once you're literate in coding constructs (variables, loops, conditionals, data structures, etc.) they become a framework on which you can hang your ideas - the real work if you will.
Neal Stephenson's Isaac Newton is a parametric modeller, a master of bottom up systems. He doesn't care for constructing geometries where he can generate them. Furthermore, his discoveries are powered by his effortless, fearless manipulation of algebra:
"In explaining why those curves were as they were, the Fellows of Cambridge would instictively use Euclid's geometry: the earth is a sphere. Its orbit around the sun is an ellipse - you get an ellipse by constructing a vast imaginary cone in space and then cutting through it with an imaginary plane; the intersection of the cone and the plane is an ellipse. Beginning with these primitive objects (viz. the tiny sphere revolving around the place where the gigantic cone was cut by the imaginary plane), these geometers would add on more spheres, cones, planes, lines, and other elements - so many that if you could look up and see 'em, the heavens would turn nearly black with them - until at last they had found a way to account for the curves that Newton had drawn on the wall. Along the way, every step would be verified by applying one or the other of the rules that Euclid had proved to be true, two thousand years ago, in Alexandria, where everyone had been a genius.Isaac hadn't studied Euclid that much, and hadn't cared enough to study him well. If he wanted to work with a curve he would instinctively write it down, not as an intersection of planes and cones, but as a series of numbers and letters: an algebraic expression. That only worked if there was a language, or at least an alphabet, that had the power of expressing shapes without literally depicting them, a problem that Monsieur Descartes had lately solved by (first) conceiving of curves, lines, et cetera, as being collections of individual points and (then) devising a way to express a point by giving its coordinates - two numbers, or letters representing numbers, or (best of all) algebraic expressions that could in principle be evaluated to generate numbers. This translated all geometry to a new language with its own set of rules: algebra. The construction of equations was an exercise in translation. By following those rules, one could create new statements that were true, without even having to think about what the symbols referred to in any physical universe. It was this seemingly occult power that scared the hell out of some Puritans at the time, and it even seemed to scare Isaac a bit."
-- Neal Stephenson, Daniel Aboard Minerva, Quicksilver Book One pages 97-98.
Great stuff. Back to the book...
Back to our regular scheduled programming.
I've just been experimenting with a couple of implementations of 3D picking for simple scenes composed of triangles.
Picking with buffer is really simple, and can be pixel-accurate (but isn't in this case because I reduced the picking resolution for speed reasons). It requires you to draw your scene twice... once as you normally would, and once to an offscreen buffer using the triangle index as the fill colour. You then look at the colour of the object under mouseX/Y in the buffer to get the index of the picked object. It's a bit slow, but it works accurately even in this random-triangle scene.
Picking with projection projects all the triangles to screen space, depth sorts them, and checks if any of the projected triangles contains the mouse point. It's not 100% accurate, but for scenes without intersecting triangles it will be fine, and it's faster than the buffer-based method.
There are much faster methods if you're dealing with more geometry, but either of these methods should be fine for simple scenes. On the Processing board, cello points out this great tutorial for doing the same things in OpenGL. Marquee selection would be a simple extension of the pixel buffer method, and a ray-based tutorial is in the works (stay tuned).
It's worth noting that the back-buffer method documented there works for P3D (so no need to create another graphics object) but that in OpenGL the get(mouseX,mouseY) method doesn't work in the same way yet, so it requires different code (example here).
Apologies for delay with raycasting example. If anyone else wants to do it, please feel free and I'll link to it from here. Otherwise, don't hold your breath!
Here are my online references from a lecture I gave today at UCL.
This will all be assimilated into my del.icio.us page shortly.
I need to find out how 'out there' Christopher Alexander was when he started talking about architecture in terms of graph theory (trees and lattices) in his famous paper A City is not a Tree. I know that my colleagues who carry out Space Syntax research in the VR Group at the Bartlett use graph theory heavily in their work, but if I talk to a group of recently trained architects, how many of them will know anything at all about this kind of analysis? If they already have a grasp of it, then it seems to be an ideal spring-board into talking about that classic of software engineering topics, algorithms and data structures. If not, then is it helpful or distracting to talk about both topics at the same time?
NB:- I'm currently only planning an hour long lecture under this heading, so to cover any of this stuff in serious detail will be impossible. I'm still interested in answering this kind of question anyway.
Some more thoughts on turning Architects into Programmers.
I'm going to talk a little bit about "Hackers and Painters" by Paul Graham.
I can recommend reading the whole thing, if you haven't already. If you've not come across Paul Graham before, he's a LISP advocate, which means he does descend into bashing strongly-typed languages occasionally, but there is a lot of good stuff in there if you overlook the brief evangelism.
Here are some choice quotes if you really don't have the time to spare...
"What hackers and painters have in common is that they're both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They're not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better."
And...
"I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do."
It's sobering reading for those of us who consider ourselves as hackers (or pirate dwarves, if you will), especially the parts about not forcing hackers to be engineers or researchers. I wonder if the other doctorate students on my course also consider themselves as hackers in the first instance and become research engineers as a concession to accepted job roles?
I'm preparing a lecture for architects interested in learning to program. In subsequent posts, I'll be writing some notes on the kinds of things I'll be talking about. These will include, but not be limited to, the following topics:
I'll also be collecting links at delicious using the tag architectsandprogrammers.
Comments are open on this post, and I am open to suggestions. Any help (especially from architects-turned-programmers) will be gratefully received.
© Random Etc.. Powered by WordPress using the DePo Skinny Theme.