Today’s update is a short one. I ported my raytracer from day 02, to the Nvidia GPU: ha3k-06-raytracer
The visuals are pretty much the same. Incidentally I discovered the striations on the ground disappear if we increase the floating point precision.
Render on the GPU is 30x faster (0.05 fps -> 3 fps). That’s still not very fast.
I didn’t get video working yesterday, or anything else visually new. I will call this one a failure overall, because I have nothing interesting to show off. I learned stuff and made progress though, so it’s not so bad.
Today I wrote a simple raytracer. A raytracer is a very simple way to draw excellent graphics. For each pixel, it follows an imaginary “line” out from the viewer through that pixel into the computer world. Then it colors the pixel based on what the line hits. Unfortunately, it also takes a lot of computing power.
Matte spheres in different shades of grey. The blue in the spheres is reflected from the sky.
The motivation for this project was to learn how to make things run faster on a graphics card. I quickly realized (before I wrote a line of code) that I’d need the basic raytracer to be its own project. Having it run faster will have to be a job for another day!
A final demo scene, showing off reflectivity and metal surfaces.Note the pincushion distortion of the overall render, and striations on the ground.
I made an animated HTML + CSS cheatsheet. This took me about three days. It is not really intended for beginners. It contains stuff I frequently forget myself.
a rough cut, blow, or stroke. (the work was accomplished one hack at a time)
a quick job that produces what is needed, but not well (this code is a hack, but it works!)
Hack-A-Day is challenge to make complete one new project, from scratch, every day in November 2023.
Last year (2022), I set myself the challenge to make a software project every day, and met it. I had a ton of fun, and make a lot of cool video games and projects I can show off. This year I’m inviting the rest of the world to join me!
I’m a programmer, so I’m doing a new computer programming project every day. But you can do any kind of project, whatever you pick is great.
I’ve been pondering simple input methods for microcontrollers. One obvious idea is, a keyboard! But for some reason, my USB keyboards use a staggering amount of power compared to my microcontrollers–1W of power for my mechanical keyboards, maybe 0.1W for the regular ones.
Let’s look inside a commercial keyboard, and see if we can hook up to it:
Yikes. What’s going on? Well, let’s make our own little keyboard, and explore what’s going on. We’ll build it in three layers, or “index cards”:
The bottom layer has 6 vertical stripes. The top layer has 3 horizontal stripes. Each place they cross will be a “key” you can press.
In between them, we add a spacer layer (punched holes) so they keys are “up” by default, and you have to press them to make them connect.
This picture might help explain how they will go together:
Now we assemble:
The final keyboard has 6 x 3 = 18 “keys”. We write the hex digits plus a couple extra keys with marker.
If I attach alligator clips to the second horizontal screw terminal, and fourth vertical screw terminals, and wire a battery and buzzer with the terminals, I get a connection beep only when I press the key “A”:
In a real computer, we obviously can’t just move alligator clips around. Instead, we attach wires to all 9 posts–three outputs wires for the horizontal lines, and six inputs for the vertical lines. We output a signal on the first horizontal line, and see if we can read it from any of the six vertical lines inputs. Then we output a signal on the second horizontal line, and see if we can read it, and so on for the third. Assuming only one key is pressed (or none), we can identify the key. This “scanning” process could be done thousands of times a second, rapidly enough that it can’t miss our slowpoke human fingers.
Click to view interactive schematic (credit: Kragen)
And this is how most keyboards work. There are some special keys–Shift, Ctrl, Alt, etc might be on their very own line, since we want to detect key combos. And better keyboards can detect multiple keys being pressed at once (N-key rollover), which I think they do by having a completely separate wire to each key which multiple people tell me they do with a diode next to each key.
For the above project, I used:
Three index cards
A hole punch
Scissors
A ruler
A pen (NOT a pencil, since graphite is conductive)
9 screws, 9 nuts, and 18 washes. I selected #6 American Wire Gauge, which is about 4mm thickness
On some keyboards I’ve made, you have to press quite hard.
My multimeter takes a while to register a press. I think a microcontroller would be better.
You have to attach the terminals carefully. I think what’s going on is that you can actually put the screw exactly through the center of the washer which is actually making contact with the strips, so that only the washer is attached, and the screw doesn’t rub against the washer.
It’s of course fairly easy to mis-align anything. This is pretty easy to fix with care. I used the “spacer” grid to draw the centerpoint of the printed letters.
The screw heads are a bit thick, so it’s hard to press the keys in the column/row next to the screws. A piece of backing cardboard might fix this.
This was my third attempt. Here’s the second, using aluminium foil. It worked at least as well, maybe better, but it was harder to make. I just taped the foil down, taking care not to cover the contact points. I am told the aluminium will gradually oxidize, making it non-conductive.
And here’s one using graphite from drawing hard with a #2 pencil.. Graphite, it turns out, works terribly, and I couldn’t read a signal halfway down the index card. Despite what people have told me, I’m not yet convinced you can make a conductive wire out of it.
