MAXLancer (import/export for 3ds Max)

[Treewyrm]

Automatic hitbox BHV validation (new feature for upcoming release)

Pretty much everyone at some point had a nasty surprise of having a shot that clearly was going to hit a ship hull but instead it passed through as if nothing was there. And so the subject of hitboxes and the issues with them come up time and time again. One thing I'd like to separate right away is when something like this happens because of network lag but that's a different story altogether. This is just about situation when lag isn't the cause, like you're firing a stationary object.

For a long time it was a manual and tedious testing, unfortunately it's least effective too.

First let's look what goes into .sur file. A hitbox file contains one or more parts. These parts correspond to parts of compound model hierarchy in multipart models (main hull, wings, engine, base doors, etc). Each such part will have bounding sphere and bounding box that must contain everything else in their volumes. Center of that sphere is also used as center of mass and target point when object or individual part is being targeted in game. These spheres used in initial test and also used for visibility check to perform offscreen culling.

Next each part in hitbox is broken into one or more individual convex hulls. A convex hull is a mesh that isn't concave. Because any concave shape can be broken into multiple convex shapes hitboxes are made of those. This is a standard procedure for practically any rigid body physics, modern games continue to use the same approach (with a few adjustments and optimizations). To avoid performing costly tests on every individual hull they form up a hierarchy of bounding box volumes. In this structure every node must be within the volume of its parent node while any leaf node have convex hulls associated to them. This way hierarchy is used to determine which hulls must be tested while discarding the rest. This part of optimization is very common.

Think of this hierarchy as boxes stacked inside other boxes. Now should a box (that is supposed to be inside another) has its position and dimensions physically placing it partially or completely outside the holding box this isn't going to work right for the algorithm. Collision detection relies on having this data be valid. It can tolerate some margin of error, things don't have to be bit perfect but there's only so much window for error before results become invalid.

For a longest time the only viable tool Freelancer community had at its disposal was obj2sur, which processed input .obj file into .sur. Unfortunately it has a few very nasty bugs and one in particular results in generating invalid hierarchy where some individual nodes will have invalid position offset causing them to be partially or completely outside of parent node boundary. The offset drift has accumulative effect meaning the more hulls a part has the more likely the entire sections will be cut off erroneously. And that's why shots end up passing through the hitbox.

In MAXLancer hierarchy visualization can be toggled on in Import Rigid Dialog by enabling "Volume Hierarchy" (which replaces old "BSP Nodes" checkbox).

When hull wireframe is gray - it is valid: all points are contained within immediate hierarchy node volume. Yellow means some points are outside the volume, collision may work but it can be unreliable for this hull. Red means all points are completely outside the volume and most likely this piece is going to be completely unhittable. Nodes themselves have similar color indication to mark them apart from valid ones.


Vanilla li_dreadnought, despite being one of the more complex hitboxes there are no errors.


A certain ship in mod where some parts have their volumes drifted away to the point certain hulls are completely outside their volumes.


Li_elite that was re-exported in MAXLancer (its hitbox and hierarchies within reconstructed from vanilla hulls imported into 3ds max) showing no sign of offset bug.

tl;dr: Automated hitbox testing aims to drastically reduce need for manual testing, to diagnose issues with existing hitboxes much quicker. Physics in Freelancer might be quirky but when hitboxes are made correctly it's actually quite robust, most issues stem from bugs in obj2sur. Until obj2sur is fixed or Lanceredit supports import/export all hitboxes should be made in MAXLancer instead.