As some of you know, I'm working on a Dark Engine static model addon for Blender:
http://sourceforge.net/p/blenderbitsbobs/wiki/Dark%20Engine%20model%20importer-exporter/
The tool is still incomplete. This thread is for discussions of ways to improve it, update announcements, and bug reports.

Latest snag (resolved 15 May 2014)
One problem that I haven't been able to tackle for a long time is packing lighting normal vectors (the ones at the corners of polygons). In Dark Engine models, the three-component vector is crammed into four bytes (with a terrific loss of precision for anything other than zero, one, 0.5 and the like). For example, the 00 0c 00 00 sequence in a .bin would be 0.0, 0.0, -1.0 (straight down).
Here's what the leaked model header says about the compression format:

// Each element, x,y,z has 1 bit of sign, 1 bit of integer, and 8 bits
// of fraction, for 10 bytes total.  So the x, y, and z values of each
// lighting normal can be extracted in the following manner:
#define X_NORM(norm) ((short)((norm>>16)&0xFFC0))/16384.0
#define Y_NORM(norm) ((short)((norm>>6)&0xFFC0))/16384.0
#define Z_NORM(norm)  ((short)((norm<<4)&0xFFC0))/16384.0

This bit about light extraction doesn't extract enough to shed on how you actually pack three floats to get there. Previously, I tried using the leftmost bit in each component for the sign and the remaining nine bits for the absolute value (an integer on the 0 to 256 scale), like so:

Code:
def pack_light(xyz):
    result = 0
    shift = 22
    for f in xyz:
        sign = int(f < 0) * 512
        val = int(abs(f) * 256)
        result |= (sign + val) << shift
        shift -= 10
    return pack('<I', result)
This resulted in obvious shading artifacts (http://5.firepic.org/5/images/2014-02/21/h26n6fgntr52.png). Then I tried using two's complement values for negative components:

Code:
def pack_light2(xyz):
    result = 0
    shift = 22
    for f in xyz:
        fi = int(f * (511 + int(f < 0)))
        result |= (1024 * int(fi < 0) + fi) << shift
        shift -= 10
    return pack('<I', result)
And this is the current situation. The results are better, but the lighting is still weird on movable subobjects.
It turns out that the compression format is a strange mix of plain values (as written by the first snippet) and two's complement values (as written by the second one), often for the same vector. Worse still, the two's complement values are not necessarily used for negative components. Can someone here help me understand when to use which method (or suggest a better solution)?

Could you give me the bits for each corner for both of the bin's inside the zip?
Numbered like in the picture.

In that model there are only two shared lighting normals, which are the same as the polygon normals in the absence of smoothing:

• (0.0, -1.0, 0.0) / bytes (LE): 00 00 30 00 / binary: 00000000001100000000000000000000 / dec: 3145728
• (0.0, 0.0, 1.0) / bytes (LE): 00 04 00 00 / binary: 00000000000000000000010000000000 / dec: 1024

I see

So for this example.
test3.bin should result in something like
0.0, 1.0, 0.0
0.0, 0.0, -1.0
?

I somehow expect for test4.bin to get 0.5

Seems like looking at the part of the leaked source that actually uses the unpacked data would provide the best information on how to pack it.