My goal for today was to get started on the proper collision detection stuff. Beginning with adding collision spheres and writing the code to test them for collisions. But first—

Let’s throw away the particle system I made last time. It wasn’t performing well, and it wasn’t what I needed anyway. (Deleting code that’s no longer needed feels great, and I know I can always dig it up out of git if I ever want it back again.)

Also, the performance graphs are just taking up too much space on the screen right now. I’ll just quickly add a flag so I can toggle them being shown.

static int show_perf_stats;

Huh, you know what? I’m gonna want to have a debug option to draw the collision spheres too, and probably right away so I can debug them when it all goes wrong. So I should make a set of debug flags, rather than a single one just for the graphs. I’ve already got the world origin debug rendering happening, so let’s make that toggleable too.

static struct {
    int show_perf_stats;
    int draw_world_origin;
} debug_options

Now that I’ve got debug flags, I should make it so I can toggle it at runtime, instead of editing the code and recompiling. It should be pretty straightforward to add a debug console with Dear ImGui, right?

Okay, that wasn’t straightforward at all! I spent far too long googling questions about how to do things in dear imgui. But eventually I got results. I can now press backquote to toggle the console, and type text in and press enter to print the text to stdout.

So now I need some console commands, and to parse the text entered in order to find the right command. Along with the command, I need the type of args it requires, and a function to call.

static const struct cmd_list_entry cmd_list[] = {
    { "debug.draw_origin", CMD_ARGS_INT, debug_draw_origin },
    { "debug.show_perf", CMD_ARGS_INT, debug_show_perf },

If I’ve got a console, I ought to be able to see a list of commands, right? I’ll just add another command to show all the console commands, and a description of what they do.

The word "help" is being typed in the console. The terminal in the background already shows the output from it: a list of all the defined console commands and their descriptions.

Typing is a pain. A good console should do autocompletion. Shouldn’t take too long.

A little longer than expected, but now I have tab-completion working nicely! It works like the autocompletion from TextMate: if I type “deb⇥”, the text field completes it to “debug.draw”. I keep pressing ⇥ and get “debug.draw_occluded”, “debug.draw_origin”, “debug.show_perf”, and then back to “debug.draw” once again. I prefer this to the bash style of only completing the longest common prefix then listing the potential matches—but also my console doesn’t yet have a way of displaying output: I’m still using stdout for that.

So, console commands with tab completion. Not quite what I set out to do, but a very nice feature to have. And a good place to stop for lunch.

With lunch done, it’s time to get back to the physics code! But first—

I’m still going to need to visualise the collision spheres, and my debug drawing code is pretty bad right now. It’s really only set up to draw the world origin. If I’m going to be drawing a bunch of wireframe circles or spheres or whatever, I should fix up the debug drawing so that it can draw any number of lines of any colour.

Okay, now my debug drawing functions just append to a buffer of lines, and after rendering the scene, I then do one more draw command to draw all the debug lines. That means I can now generalise the code that draws the X, Y, and Z axes at the world origin to draw the origin of any other objects.

A rotated cube. Red and green arrows can be seen emerging from two sides; presumably a matching blue arrow protrudes from the side facing away from the camera.

Actually, it’d be nice to be able to see the debug lines drawn even if they’re being occluded by other geometry. But I don’t want to draw them on top of anything willy-nilly, cause that’ll just be a confusing mess of lines. I should make the occluded parts semitransparent.

The rotated cube again. No all three arrows are visible. And where the arrows are on the interior of the cube, they’re still visible, only more dimly.

While bright red, green, and blue are okay for axes (since they conventionally map onto x, y, and z respectively), I don’t much like the colours you get from fully-on and fully-off rgb channels. So for other debug drawing, I’d like to have a palette of nicer colours at hand to pick from (by hand or programmatically). A little bit of googling led me to a page about colours in American golden age comics, which had a table of the 64 colours, combined from various percentages of yellow, red, and blue inks, that were available to comic artists at the time. The colour palette looked very nice, so I sampled all the swatches and added them to my code.

The 64 colours of golden age comics.

You’ll notice that colour 63 is not shown; being based on inks, the zero-ink colour is just the colour of the paper. I didn’t want bright white as the first palette entry however, so I moved it to the end.

Great! Now I have a nice debug drawing setup, all ready to start on that physics code. But first—

Well, it’s time for dinner.

About this point I came to the conclusion that I wasn’t going to get any of the actual physics code done today. But after dinner I managed to fumble my way through drawing wireframe spheres, so that I’ll have debug rendering of the collision spheres all ready to use tomorrow.

Four nested wireframe spheres, going from yellow on the innermost, to light green on the outermost.

Still, I reckon a decent console and a decent debug drawing system is a pretty good result for today!