A Hole in the Hull
- Posted by mariteaux on August 2nd, 2020 filed in Modding
- Comment now »
So happy Pennyverse Month, everyone. I’m still in mapland and Caby still has Art Fight obligations, so we’re not quite on it yet, but we did get to play Pinede yesterday to unwind. Missed it. Feeling it already this month, so hopefully once the little left to go is complete within the next week and change, we’ll be off.
I have a lighter, non-update Quake post for you all today. I’ve finally gotten around to testing something I’ve been curious about for a while now about Quake‘s development, and my word did it make me giggle up a storm when I first saw it. Let’s talk about hulls and bounding boxes.
A basic tenant of any game is collision detection. In a game like Quake, all the collision detection needs to do is prevent movement if whatever’s being checked can’t pass through the space it’s trying to. Both the visual model and the level itself can be quite complex, and checking how these two (or two models, perhaps) are touching, say, per-vertex, was probably too much to ask of the Pentium 66s of the day. As a result, the engine doesn’t check either the model(s) nor the level for its collisions!
Well, what does it check then?
As for the models, someone (maybe Carmack) correctly realized that models are largely convex figures, at least as far as “can they fit through this” goes, and thus checking the actual model itself for that purpose was a lot of extra work for no gain. Instead, there’d be an invisible box that encapsulated the model, and all the engine would need to do is check this simple box against its surroundings to see if the entity could fit wherever it wanted to. This box is called a bounding box, naturally.
You can see the bounding box both gives the Grunt model a bit of space, especially on top, and also that his gun clips out of it a bit. It’s a rough approximation, really. Bounding boxes are the most simple things imaginable. They can’t rotate on any axis, they don’t deform, nothing. That’s good enough for fitting through doorways or around other enemies though, more than good enough in fact.
But it isn’t good enough. The engine might still chug along checking the bounding box against brushwork it very clearly can’t fit into, so a second solution was devised: take the brushwork, grow it outward by the dimensions of the player’s bounding box, and test against this mesh instead. Therefore, the tiniest spaces are already totally discounted and the engine doesn’t even need to worry about checking for those. Most enemies, being around the same size as the player, could also be checked by this second mesh as well.
QBSP calls these hulls, hull 0 being the visible hull, 1 being the player-sized clipping hull, and 2 being an additional clipping hull that’s actually grown by the dimensions of the Shambler’s bounding box (because he’s such a fatass). If you check your compile logs, you can still see QBSP building hulls 1 and 2 to this day.
---- GrowRegions ---- Processing hull 1... Processing hull 2... ---- WriteBSPFile ---- Wrote b_arrogant.bsp
Of course, I got to wondering what these mystery hulls actually looked like. After all, they’re normally not visible, right? Both the original QBSP and ericw’s QBSP have no way of building only one of the hulls, and even if you could, you still wouldn’t be able to see it, right? That’s where this gets interesting. On one of my little internet expeditions, I stumbled on the homepage of former Quake code guru Bengt Jardrup and his version of TxQBSP, one of the scene’s old “enhanced” compilers (and I think a forerunner to Tyrutils, which is what ericw-tools is based on). If you read this fascinating writeup he did on Quake map compiling and errors in the process, he explains hulls pretty thoroughly and slips this bit in in the middle, referring to TxQBSP:
The “
-hull #” option can be used to trick the compiler to build hull 0 the same way as it does for the other hulls, by expanding the brushes a bit, thus making one of the other hulls “visible”. This may help understanding how a bsp is built and get a clearer picture of what these other strange hulls are.
Naturally, I had to try it! Of course, this map has even given ericw’s QBSP a bit of trouble, so I wasn’t keen on handing it over to an even less optimized compiler only to watch it grow void holes anywhere I dared have a funny angle. Instead, I dug out the Quake map sources and set up some compile profiles, one for hull 1 and one for hull 2. I was greeted with this.
That’s pretty clearly not how DM4 is supposed to look. Yes, you can still run through this. The player clips along walls into the void, practically, but I’m not too sure how the floor’s supposed to work other than “you’re up to your chest in it”. Maybe bounding boxes are placed on hull 0 as normal, but the walls are hull 1? I have no clue.
If you think that looks fucking goofy, have a look at DM4’s Shambler hull:
As an additional quirk of hulls before I leave you with more ridiculous screenshots, if the player can’t fit into a certain area of the level, it’ll have no collision and trying to noclip into it will teleport you back into the level as if you tried to noclip into in the void. I initally thought QBSP didn’t build a hull for anything the player couldn’t get to, but the -hull 1 trick seems to prove that wrong. Maybe it tests against the visible hull for that? Not sure, but it’s bizarre.
r_showbboxes. I tried to get an angle where the bounding boxes I was actually looking at weren’t obscured by the ones in the rest of the level. Note that the bounding boxes are forever locked to the world axes rather than rotating with the visible model.
