don't

kevin quain suggests sorting your itunes playlist by title and filtering by the word "don't" to find out everything that itunes doesn't want you to do. here's what it told me:

don't blow your top.

don't come around here no more

don't download this song

don't download this song

don't give up

don't look back

don't lose my number

don't push.

i must have downloaded the third song a couple times.

the last post is an outlier. i have thought often about deleting it and have avoiding writing anything here as i've contemplated whether or not to do so. i don't think i will.

it's a time of deep work, making a number of things.

out, brief spot.

Patrick's ex-girlfriend confronted him again tonight, after the police have REPEATEDLY told her not to contact him. He really, REALLY hates to bring his personal life up on his blog, but he feels the the social pressure that will result is worth it. DO NOT CONTACT ME AGAIN.

solar hot water

My landlord woke me so his contractor could inspect the blocked up fireplace on my floor. He's having a solar hot water system put in.

What amuses me is that the contractor was doing his best to convince me that it was good for the environment, without having asked what I thought.

This has me wondering how many people believe that solar heat is not good for the environment.

why am i here?

Blogs and Facebook and Twitter. They're interesting. I put a lot of one-way stuff on them. People reply to facebook the most, twitter next, and here rarely. Accessibility? Or having it put in front of you more for the other two places than for here, where you most likely explicitly check. It affects how you use them. This, and another work-centric blog, have become more self reflective, but in a deliberately filtered way. They are thoughts that might be interesting to someone else, but are more relevant to me. The act of publishing them coerces me into being more organized than I would be in my journal. Half the reason to write is to deliberately reflect; the other half is the act of writing. It keeps your chops up, as they say, whoever they are. Facebook and Twitter writings are more specifically for the entertainment of others. Perhaps it's good not many have found their way here, as it would change the nature of the text.

In all cases, you're hearing from a deliberately managed character, of course.

why are you here?

Uncommunication is a wonderful thing. So much can be said while so much is not being said. And so much can be said by not saying what is unsaid while something else is being said.

Daybreak

Battlestar Galactica ended the way I always wanted to see a show end. But we rarely shows end this way. It took it's time. It had all the action and excitement. But then the writers gave a resolution to all the characters that still needed one. We find out where they are going, if not knowing their later stories.

The shot of Ron Moore reading National Geographic was self-referentially priceless.

candleholder cake

just a quick note of thanks to folks by the names of mark, chris, and maya for the discovery of candleholder cakes!

improv coding with an audience

occasionally, i have had to write code with an audience. i have long since known that it is not a strong part of my skill set to do this by improv. betty edwards, in her book, "drawing on the right side of the brain," argues for the philosophy of right-brained vs. left brained thinking. in computer science terms, left brained thinking is your sequential, logical side, which steps through things one piece at a time. right-brained thinking is your parallel processing side, which processes everything at once and just "sees" things. when i am writing a paper, i am using my left brain, since i am trying to logically anticipate the reader's response to each sentence i write. I want to write a sentence that makes them think about things the way i want them to so that what i am saying is clear. when i am drawing, i am using my right brain. there is almost no conscious thought. i play with what i see and just run with what's intuitive to make a picture. i have no idea what time has passed or what music i am listening to, if any.

when i first learned to code, i thought with my left brain. i thought through things one line at a time and made sure each line worked to say whatever it needed to say so that the computer could compile it into voltage differences that allow it to go do something useful with itself, if we hook up our circuits right. i eventually started to think of code with my right brain, however. i think of it now as a concise mathematical statement that needs to work on its own as a whole. each line is not separate; they intertwine together to make things say what they need to say as a concise entity.

when i talk to an audience, i am analytically watching their faces and listening to their tone of voice to see how they respond, and i adapt my level of detail and redundancy of statement based on their reactions. it's very left brained.

i am very bad at improvising code in front of a class. so i write my lecture notes, as everyone does. and then i rewrite them as i think about what questions students might ask. and i plan a couple lectures ahead to let things "gel" in the back of my mind, so that i have a better idea of how well they will work before presenting them. of course, smart students ask me questions that catch me off guard, which might head down the road of a different explanation but i steer things back to where i was going, regardless. not out of a sense of correctness, but because i know full well that if i head down another path, the right-brained/left-brained battle will stalemate and either my communication will break down or my solution will be wrong, or more likely, both will suffer. richard williams, in his book, "the animator's survival kit," shows a newby animator (the author) asking an experienced animator (milt kahl) if he listens to classical music while he works. turn the page. milt expands in size tenfold, and says "of all the sssstupid #@$#$@$#$ questions iiiiiiiv'e ever heard!!!! iiiiiiiiiiii never heard such a f$%$%#$%$#%$ stupid question! i'm not smart enough to think of more than one thing at a time!!!" that's me writing code from scratch. that's also me communicating to an audience. and animating too. they don't mix and match at all well.

as to the music question, i sometimes have it on, but i usually have no idea what's playing; it's completely blanked out of my thinking. the only time i found music to be specifically useful was when animating some fire in one of these movie films that comes out every now and then. i had my fire animation, some reference footage, and the adjacent fire shots playing on screen together, with nin's "burn" on repeat. it worked, helping to get the feel of fire out of jos's discretization of the navier stokes equations. the emotional feel of the music and shot were different, but the emotional feel of the music and fire motion were the same. that's rarely the case.

i recently had the opportunity to improv code with an audience. i was way way off my game. i learned a lot from it though, in terms my personal limits. sometimes i really am only smart enough to do one thing at a time.

Rasterization vs. Ray Tracing and the Size of your Data

We all learn about rasterization and ray tracing in introductory computer graphics classes if we are computer graphicists. But, at a fundamental level, what it the difference? Teaching computer graphics has made me think about these things again. As an exercise, challenge yourself to write pseudocode for each algorithm in exactly 4 lines. Then keep reading.

I asked a number of graphics PhD students to do this tonight, and they dove straight into details about projecting triangles and computing viewing transformations, etc. But there is a fundamental difference at a much higher level that interacts with the way we make data to affect the computational complexity of these algorithms. My 4-liner versions of the algorithms look like this:

Rasterization:
for each shape:
for each pixel:
if the shape is visible in the pixel:
compute the color and draw it in the pixel

Ray tracing:
for each pixel:
for each shape:
if the shape is visible in the pixel:
compute the color and draw it in the pixel

These look almost exactly the same. We're really just swapping the order in which we iterate over data. But renderers, in practice, have to process a _lot_ of data. Way more than we can hold in memory, in the case of film quality scenes. And performance is tied to data locality, since data locality lets us avoid having to move stuff in and out of memory a lot, which makes things really slow. That constant on the memory transfer is big.

In either algorithm, we have to make an image, so we bite the bullet there and keep the image data around. It's also of fixed size and usually fits in memory, so it's not much of an issue. Shape data grows without bound, however. My experience in film production tells me to be careless about the size of your shape data until it becomes a real problem for other people, because artist time is really really really expensive and processor time is just expensive (until you hit your memory limit, where it becomes a constant multiplier on the next artist down the pipeline). So we push the size of shape data over the limit of what fits in memory on a regular basis.

Rasterizers deal with this by only processing each shape once, throwing the current shape data away at the end of the inner loop and ignoring global appearance interdependencies. Shapes are expensive to read in (we're accessing disks here), but it's O(n) in terms of how many times we read in shape data.

Ray tracers usually have to read all the shape data multiple times, since a lot of it has to get tossed out of memory _for each pixel_, since many shapes will often push memory limit bounds all on their own. And then ray tracers figure they've taken the performance hit already, so why not try to solve some of the global appearance interdependencies while we're at it. And now we have brute force solutions to the rendering equation, if we have good BRDFs. O(n^recursion depth), if my big oh is right (my math is bad on Fridays). Yikes. So we do things like bounding recursion and probabilistically killing recursive calls to keep this under control. Even if we completely ignore global appearance interdependencies, we have O(kn), where k is our number of pixels.

And when n is big, as it is for high-quality algorithms, that can mean days or weeks instead of minutes.