> no surprises. There is no definitive system- in fact, different parts of my code written at different times mix up the definitions! So, it is equally probable that I mixed up when Koen and I developed our ideas.

No the error was mine. :)
I knew I was 200% sure about the top normal.
When I re-aranged the numbers by using a different coordinate system, the top normal color matched the one from your screen cap, so I was on the right track...

> I've checked it out, and it seems to be really really close to the TS normals!!!! What a great step forward for us- to be able to do realistic auto-normals!!!!

yeah, but I'm confident I can still improve on it by using 34 normals for increased accuracy :
If you take the spatial diagram that Godwin showed a while ago and subdivide each of the vertical and horizontal 45° angles, you'll get smoother surfaces...
This will of course, put a greater stress on your analyser to identify the normals correctly.

> Typically a voxel model imported from 3ds has maybe over a thousand redundant voxels, which obviously take file-size and time for the game to render, even though they are never seen. So I stand by my assertion that removing redundant voxels is 'a good thing'.

I agree with you, as long there are no side effects...

> Those voxels identified on the underside of slopes are not auto-normalised (yet). They remain unchanged.

I've noticed that while testing it.

> this zipfile includes the old version of flyby's normals. THerefore, don't use that file- use flyby's new file instead!

It would be better to delete the old one and copy the new version into the zip.

> (I can't compile the vse, because my delphi doesn't have a lot of the vcls- hence me making command-line delphi programs.. :()

heheh, I had a bunch of kids asking how to use your normaliser.
They never heard about a dos box or command prompt...
I guess they are from the post-DOS period, huh? :D