quizzical quincunx

posted at 14:10 on 2009.06.29

What does three hours of work get you? A Mersenne Twister, the above image, and the revelation that, according to this book, Perlin is blissfully unaware of the finer points of Knuth shuffling. (This should not be construed as an attack on the rest of Perlin's work, which is responsible for much general awesomeness in subsequent cinematography.)

Graphics geeks will recognize this immediately; for the other 99.99% of humanity, it's an example of Perlin noise. This is the first intelligible thing to come out of my graphics term project, in which I plan to explore the exciting world of procedural generation. CG artists will commonly blend several instances of Perlin noise at different frequencies (16 pixels for my test image) to generate more complex textures. These textures are then applied to objects in the scene.

Why did I bother implementing a more complicated random number generator? Let me count the reasons:

The default implementation uses the full 32-bit integer range and provides an incredibly long period.
I now know exactly how my RNG works. (To be fair, I'm a bit fuzzy on the details of all those bit-shifts...but it feels good to roll your own!)
Python uses it since Python 2.3, which is a ringing endorsement in my books. (I'm told it has become something of a defacto standard.)

The bottom line is this: I'm going to be generating a lot of random numbers in the course of my project, so I might as well get a good (but still algorithmic - no /dev/urandom reads!) source of them.

Next up: I'll probably tackle Voronoi cell textures and attempt to actually texture-map a procedural texture in OpenGL. I'll also be continuing to post raytracer updates here, so keep posted! For information on the ever-changing state of my team's Real-Time Programming project, see the PsychOS blog.

Shady Business

posted at 10:17 on 2009.06.22

Here's the same picture as before, with one important difference: the spheres look, well, spherical. Between dancing under the stars (and early-morning fog!) and class, I've somehow managed to find both the time and requisite sanity to implement Phong shading. Given libraries for vector operations, this is a relatively trivial task; nevertheless, it adds a whole new dimension (yeah, I couldn't resist) to rendered images. I'm also computing shadow rays to get the nice (albeit somewhat pixelated) shadows on the occluded parts of spheres. Next up: box and mesh intersections, supersampling, and hierarchical rendering. I'll keep posting progress images as I go along.

Here’s Shooting a Ray at You, Kid

posted at 11:13 on 2009.06.20

(Yes, I finally saw Casablanca a couple of weeks ago.) Exhibit A: the first meaningful image produced by my raytracer for CS 488 Assignment 4. It's a binary intersection image; it shoots a single ray from the eye through each pixel, rendering it white iff the ray intersects an object. I'll tackle Phong lighting next. For those outside the Graphics/CS bubble, Phong lighting is a relatively crude but efficient way to model the way light interacts with objects. As you can see from the Wikipedia page, it allows us to shade surfaces, thereby giving the impression of depth.

In general, raytracing is an attempt to model the way vision works. Production-quality raytracers will model reflection, refraction, transparency, scattered reflection from rough surfaces, and any number of other real-world phenomena to impart as much realism as possible to the final image. Maybe I'm strange, but I think that's cool - thanks to CS 488, I now have an appreciation for exactly how much programmer effort and CPU time go into, say, Pixar's rendering pipeline. (6-90 CPU-hours per frame, according to their site!)

One last note: although the raytracer project is by no means large, it's hefty enough that ad-hoc cp -r source control won't cut it. To that end, I've decided to give Git a spin. First impressions are positive: it's fast in all the ways that Subversion isn't, and it's ridiculously easy to set up over SSH.

On the Right Trackball

posted at 06:48 on 2009.06.17

And here is the completed spherical Trogdor (of uniform density?) You might notice a circle drawn across his beautiful Phong-shaded polygons; that's part of a virtual trackball. Roughly speaking, this allows you to rotate the model as though the scene were contained in a sphere. (Also: that site uses a rather inefficient way to get the angle between the two projected vectors - can you think of a fast approximation?) Other user-interface goodies: you can select individual joints and rotate them, causing Trogdor to coil up or flex his shapely back-arm. You can also move Trogdor around.

Just remember: if you hear from me only sporadically this term, it's because I'm doing super-fantastic-awesome things like modelling Trogdor and driving model trains. All in the pursuit of higher education!

Burninate the Graphics Lab

posted at 00:23 on 2009.06.16

It's CS 488 Assignment 3 time, which means I get to play around with hierarchical modelling - and what better way to do so than to construct the very likeness of Trogdor? (Yeah, it's a stretch. You try modelling anything with only transformed spheres.) BURNINATE!!!!!

« newer