> 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