> > 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...

well, I too realised I'd swapped coordinate systems while programming the normaliser- compared to the rest of the voxel section editor anyway.

There is no 'right' answer. Just so long as we all agree now! :)

> > 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...

:( unfortunately, those shards would be really hard to detect. The reason I was keen on godwin's diagram was that it actually represented the facings that we could easily implement in the easiest and most reliable facings-detection algorithm.
> This will of course, put a greater stress on your analyser to identify the normals correctly.
golly! wouldn't know where to start!

> > 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...

clearly it should be something that isn't done automatically or behind the modder's back- it is something they deliberately choose to do, say a menu option as it currently is.

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

> I've noticed that while testing it.

glad someone tested it :D

this was infact a bug introduced by not understanding the way that westwood voxels work. I assumed that because things were shrunk approximately 80%, this would hide the holes. However, whilst this shrinking helps on flat planes, on slopes further internal voxels are required. Any voxel 'optimiser' can now understand this and not remove those needed voxels! :cool:

> > 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.

yes, but only dedicated modders are going to use that tool now. The mainstream will wait for it to be in Koen's voxel section editor 1.5. Besides, I'm stalling because I don't want to be mis-using the abscnc site space.. ;)

> > (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

well, even people who missed that bit of our computer heritage should realise that the command-prompt is very much alive today... I use it all the time. In a graphical gui you do things in the order that designer/programmer envisaged- it is very difficult to make the output of one program the input to another etc.