Alright, I can't post code until the HTML stuff is fixed but I would
like to return to lighting as promised:

Caliban's info had more information that I'd like to share, especially
on the lighting issue which I'm a little worried about and would
appreciate input from GOM and Casuir (or modellers in general)
to see if this is viable.

Quad block 8: light indices in rgb, ambient occlusion in .a

As given to me, is .a a reference to a structure element?

From the village.world file (not correct ne_village etc file)
these are mostly 0 0 0 byte number.entires BUT occasionally
they have 1 0 0 byte number entries.

Quad block 9: light attenuation, ambient occlusion in .a

These seem to be mostly byte number 0 0 0 entries.

What am I worried about? Where do you put these things
in Milkshape so they can be modified and put back in game?

Here's what Caliban's software guy sent along, I think this is telling
about how they use these constructs: I'm afraid to quote, given
what happened to my previous posts so I'll leave it in blank verse:

11 - we don't store binormals for settlements, in shader we get them by normal cross tangent - we can do it as we don't do texture mirroring on buildings (but we do on characters)


used by our static lights which are preevaluated during conversion. Each mesh can be effected by I think 69 static lights. Per vertex we store indicies to 3 of them and attenuation (intensity) of these 3. During real time we have a table of 69 colors, look up color based on index and multiply it by attenuation. This way we can have them flickering by changing color table. You can disable them by setting attenuations to 0, and ideally setting index to 0 so it doesn't run off the table.


Ambient occlusion - we normaly uesd the one from indicies. The one from attenuations is used only for animated blocks - we interpolate between these two as the animation progresses. So it's ambient occlusion of the block at the end of the animation.


4 - texture coordinates - stored as 4 bytes (color class, watch out for byte ordering), each coordinate is stored in 16 bits in fixed format, by looking at it it seems 2:14 format. (so -2 to 2 range, stored in bias form in 0..4 range so we don't have to store sign). This is code we use to decompress it back to floats (shader code, but should mostly compile in c++ if you replace types)

After this was some shader code which was requested to not be released
so we stop here.

Anyway, my problem is how do we recover this data which needs
to go back in the settlement file if we can't put it in Milkshape to modify it
but it still needs to be there? Showstopper? or am I just ignorant of
the solution>