Month: May 2021

I’ve noticed a pattern when I write new programming code: I often spend far too much time polishing it up before putting it out into the world.

At some point the changes I make are not really making the code any better. Yet I’ll keep on tweaking things for a good day or two, well after the law of diminishing returns has set in.

I suspect this has less to do with perfectionism than with anxiety. When you put something out into the world, you are ceding control over it.

Sure, you are being neighborly — sharing with the world, helping others, laying a path for what may come next. But you are also being vulnerable, because at that point any errors in what you’ve created become public.

At some point pride of workmanship veers over into a neurotic tendency. I wonder how many other computer programmers suffer from the same neurosis.

Enjoy all your Mondays,
They are named for the Moon.
But try not to dawdle,
It will be Tuesday soon.

Here are the answers:

Mel: Bee keeper Mac: Computer salesman Mal: Evil genius Rod: Fisherman Sol: Helioseismologist Kit: Hobbyist Bud: Horticulturalist Gil: Ichthyologist Lee: Jeans salesman Moe: Landscaper Sue: Lawyer Leo: Lion tamer Don: Mafioso Fox: Male model Pat: Masseuse Van: Moving company exec Job: Personnel manager Art: Portraitist Tab: Restaurant cashier Bev: Soda jerk Ira: Tax collector Rob: Thief

John Davis asked how to make bumpy textures using the Noise function. I figure that this is as good a place as any to answer his question.

Because the Noise function is a continuous function, you can always take a derivative of it, without having to dive inside the Noise function to figure out how it works. You can get a good approximation of a derivative by taking finite differences, using nearby samples.

First choose small distance ε, which is small enough that it is smaller than any feature in our scene. I usually use a value for ε of something like 1/1000. Then instead of using a single evaluation of noise at surface point [x,y,z], do four evaluations: One is f₀ = noise(x,y,z), and the other three are f_x = noise(x+ε,y,z), f_y = noise(x,y+ε,z), and f_z = noise(x,y,z+ε), respectively.

Now you can just do finite differences to get an approximate derivative. In particular, you can get a vector in the direction of the derivative, which you can then set to unit length by using the normalize function: B = normalize([f_x-f₀,f_y-f₀,f_z-f₀]).

Then you can just add this into your surface normal. The more you add (say, by varying a constant C), the bumpier the texture: normal = normalize(normal + C * B).

And that’s it. You now have bumpy textures.

This is all inspired by Jim Blinn’s Ph.D. dissertation — as is so much in computer graphics. In 1977 he pointed out that you can fake bumpy surfaces not by changing the surface itself but just by changing the surface normal.

And that’s just one reason we know Jim Blinn is a genius: His bump textures technique is simple, fast to compute, and produces great looking results.

I have been receiving requests to give the answer key to my “three letter names” puzzle of several days ago. But I’ve decided to hold off for another day or so.

I would like to give people a fair chance to solve the puzzle, and I figure three days should be enough.

So I plan to post the answers tomorrow. Stay tuned!!!

Today one of my students, Zhu Wang, successfully defended his Ph.D. dissertation. The research itself is brilliant, and his presentation of it was flawless.

The meeting was slightly odd, as meetings are these days, because it was held on-line via Zoom. But that didn’t take away anything from his accomplishment or the clarity of his ideas.

These moments, when somebody goes from being a student to having their Ph.D., are very large. It’s the moment when somebody gets their license to conduct their own independent research, whether as head of an academic research lab or of a corporate team.

I love this process — even though it can be a long and arduous process — because it helps really talented and hard working people to become even better at what they do. And then they can go off and help make the world a better place.

Each of the following names goes with a profession. Can you figure it out?

Art Bev Bud Don Fox Gil Ira Job Kit Lee Leo Mac Mal Mel Moe Pat Rob Rod Sol Sue Tab Van

Bee keeper Computer salesman Evil genius Fisherman Helioseismologist Hobbyist Horticulturalist Ichthyologist Jeans salesman Landscaper Lawyer Lion tamer Mafioso Male model Masseuse Moving company exec Personnel manager Portraitist Restaurant cashier Soda jerk Tax collector Thief

It seems it’s that day of the year
When we celebrate Star Wars with cheer
    Here’s a factoid that’s fun:
    You can’t trademark a pun
Which means Disney can’t sue us, I hear

As I continue this process of digging up my own code and working with it, I am discovering some surprising things. For one thing, I don’t always agree with myself.

Back then I had a tendency to build things up a lot. Given a choice, I would generally go for the fancier and more comprehensive solution.

These days I am much more into minimalism. I am now willing to sacrifice one or two fancy features in order to make things simple for the user.

It’s as though I’ve become more Zen as a programmer. As Thoreau said, simplify.

This is leading to a somewhat odd situation: As I “collaborate” with my younger self, I find us disagreeing quite a lot.

Fortunately, it is a polite disagreement. The two of us are unlikely to resort to fisticuffs.

I’ve always thought that the best way to document some algorithms is to write a little program that animates the algorithm. Ideally the animation could be invoked right from the source code of the algorithm. Whenever anybody looks through the code, they have the option of running the accompanying animation, to show them how the algorithm works.

But it occurs to me, what about documentation for the program that creates the little animation? Shouldn’t that code be documented as well? After all, somebody might want to also know how that animation works.

If we follow this idea to its logical conclusion, we could get an infinite chain of recursion. An animated program that documents an algorithm needs its own documentation, and so on and so on. It could go on forever.

Fortunately, that’s not actually what happens. Programs that animate algorithms tend to be very similar, when you look at them as algorithms themselves. So the documentation of such programs tends to converge.

This looks like a case of convergent recursion. Which makes me happy, because it is going to save me a lot of time.