Landing gear

I've been working through the math for landing leg shock absorbers. Given the worst-case situation that it must handle (initial contact velocity, maximum acceleration, and surface gravity), the program should determine the dimensions of the legs and the constants for the springs and damping. I'm midway through though so I don't have anything to show.

One thing's surprised me so far, if I've done the math right. If the shock absorber is a critically-damped spring, the deceleration is maximum at the moment of first contact and tails off rapidly thereafter. With an undamped spring the maximum deceleration occurs at the point of maximum compression; an underdamped shock absorber would presumably fall between these two extremes. It seems to me that the ideal landing gear would just decelerate at a constant rate, to maximize the amount of deceleration relative to the length of the shock absorber, but I don't know that any landing gear actually works that way.

Combating comment spam

The quantity of comment spam has been steadily increasing. I'm now disallowing anonymous comments; we'll see if that changes things appreciably.

Hull damage

Continuing to work on my lunar-lander-on-a-disc, I finally got a basic damage model implemented. After the physics system has solved for a set of impulses to satisfy contact constraints, any impulses against the hull that exceed a threshold are scaled and applied as damage. There isn't yet any visible damage; it's just hit points. But the introduction of mortality takes this a step toward being a game.

I'm still trying to come to a big-picture understanding of damage, though. It seems like, in an inelastic collision, kinetic energy is being converted to heat (or some other deformation). I think a more accurate model might decide (based on the properties of the colliders) how to divide up the energy to be absorbed by each; and that the damage would be proportional to the energy absorbed. If this is the case it seems like the damage would be proportional to the square of the relative velocity, where in my current model it's a linear relationship.

Also this week I have begun to make a parametric hull design to allow for a range of rocket shapes and sizes. Time for a product plug:



This is the Lift-Off Rocket Playset and children love it. Buy one, invite them over, and watch the fights!

A few things you can't see in the photo: The nose has a hatch that opens to reveal seats for the two astronauts. The bed is a Murphy bed; it folds up to reveal the toilet. Beside the toilet is a roll of toilet paper and some reading material. In the back is a kitchenette with microwave and coffee maker. The top and bottom doors are designed to break away under stress to avoid permanent damage. Oh, and it has a button you can press to get noise and flashing lights out of the thrusters. This toy is an almost ideal marriage of stuff boys and girls like, which means none of them will want to be left out of the struggle over it. Which is where the breakaway doors come into their own!

Here's my rough likeness:



I got myself in over my head math-wise with the parametric model and ended up backing out slightly; you don't specify the height exactly from nose to base, instead specifying it from the top to bottom of the middle section before it's beveled by the round nose and the cropped bottom.

Upgrading the physics engine

I'm continuing to work on my lunar-lander-on-a-disc game.

This week I started updating my physics engine to match the latest version of Chipmunk. My physics library is basically a C++ translation of Chipmunk, so it's easiest to just look at the diffs in the source library and make equivalent changes to mine. I also took the opportunity to replace uses of cpHashSet with more idiomatic C++ (std::set and std::map). This reduces the amount of code in the library and makes it more type-safe.

Upgrading the library is my way of re-familiarizing myself with the code since I have a set of high-priority physics-related things to do:

• Detect impact damage
• Finish landing gear: absorb shock in all directions, have a proper foot, and break if stressed too hard
• Add hydraulic entry ramps that fold down when landed

I'm also interested to examine the new constraint model to see how things are arranged. It strikes me that you might be able to unify contact constraints and joint constraints into a single set of constraints; I'd have to look at things some more to decide if that would be worthwhile though.

Initial lander terrain triangulation

I'm back in the saddle again (barely) on my lunar-lander-on-a-disc program. (The latest released version is here, but does not include today's changes.) I am working on triangulating the terrain so I can draw it as a solid mass rather than an outline.



My first pass does the job and fits into the recursive framework for how I'm creating the BSP and outline, but it isn't ultimately what I'd like because it wastes a ton of triangles in the interior:



I could just triangulate the outline, and I may end up just doing that. It will result in long sliver-like triangles, which aren't necessarily a problem. If I decide I'd like to render the terrain in several discrete chunks that can be culled independently, though, I'd want something different. I don't yet have a solid vision for how the terrain ought to look, so I'm experimenting.

I think I'd like something that is similar to this but replaces clusters of solid triangles with larger ones, so I'm working out how to do that.

I also want to filter out those inaccessible pockets inside the terrain (and maybe the floating islands), so I'm trying to figure out the best way to do that. I have several representations of the terrain and it's a trick to figure out how to process them all. The outlines would be an easy thing to cull: just remove all the ones that wind in the interior direction. Fixing up the BSP to remove the pockets would be more of a challenge, though. I sort of want to flood-fill BSP leaf nodes. BSPs don't have readily accessible connectivity information between adjacent cells, though.

"Raytracing on a Grid" updated

Commenter SyntaxError has spotted and corrected several bugs in the code I presented in my article Raytracing on a Grid; I mention this in case anybody used the first or second pieces of example code as a basis for their own work. The code in the article has been updated and retested.

The core of the problem was that I was failing to account for the fact that zero multiplied by infinity yields an undefined result. This happened when both endpoints had identical horizontal or vertical coordinates, which you'd think I would have caught earlier.

Mini-reviews

I actually managed to play some games over the holidays, something I haven't done much of in a long time. My opinions:

Torchlight: Pretty but extremely repetitive Diablo clone. Still good for a few hours of fun.

Might and Magic: Clash of Heroes: Fantastic gameplay burdened with a generic fantasy license (saying this as a one-time Might and Magic fan). Inventing a puzzle-based battle system has been a goal of mine for a long time and I'm very impressed with the one Capybara has concocted here. I saw Critter Crunch on PSN last month and there are definite similarities. I loved the fiction surrounding Critter Crunch. Here it's the usual overwrought elves-n-paladins stuff, but you should try your best to overlook that because the gameplay's great.

Zelda: Spirit Tracks: Partway into this one. Moderately interesting. The train seems like it has potential to be a real drag.

Halo: ODST: Meh. Fight a bunch of dudes through a series of tunnels that are supposed to be a city. Some day there will be a game set in a city where you can actually go into any building and the layouts are not intentionally mazelike to compensate for hardware handicaps. This is not that day. This is essentially the Halo 3 Remix, at least in the single-player.

Assassin's Creed: (the first one) Surprisingly less polished than I would have expected given the size of the development teams in Montreal. I'm only partway into this one; I like the environments. The animation is atrocious though, with pops and hitches continually violating characters' appearance of weight.

Mass Effect: Also only partway into this one. I love their character rendering system during cutscenes. Very cinematic lighting. Of course the lip-sync brings everything crashing down. Animation is the Achilles' heel of all current CG, even $350 million epics like Avatar.

Saira: Tried the demo, decided it was a bit too frustrating for me. I loved Nifflas' previous games though. If you haven't, check them out.