[Scooby_Doo]

Lighting is all messed up and if you look at the darken area you see speckles all over the place.


This is how it looks like without it:

[Vasudan Admiral]

You'll need to upload the normal map for that - can't tell from the pics sorry.

[Scooby_Doo]

http://scoobydoo.freespacemods.net/Problems/epee0-normal.tga
http://scoobydoo.freespacemods.net/Problems/epee1-normal.tga

[Vasudan Admiral]

Yeah that's what I thought actually - your normal maps are in the wrong format. FSO takes DXT5_NM formatted textures only - and they look different to that standard type you posted. Easy enough to fix.

If you don't have it already, use this: http://developer.nvidia.com/object/photoshop_dds_plugins.html to save that kind of tangent map as a DXT5_NM. All it is is the green channel stores up down normal info and the alpha channel stores left right normals.

Also, are you using two 2048 res maps + glowmaps + shine maps + normal maps on a single small ship? If so you'll need to fix that down to a single 1024 res before you make taylor do something horrible to you with a chainsaw.

[Scooby_Doo]

Oh you wanted the actual DDS files, then these are the ones:
http://scoobydoo.freespacemods.net/Problems/epee0-normal.dds
http://scoobydoo.freespacemods.net/Problems/epee1-normal.dds

They're already in DTX5_NM format. I already use the nvidia's photoshop plugin.  As for the size, yes everything gets a final downgrade to 1024 before conversion, besides don't we all already have 4870s 

[taylor]

That issue with the normal maps is believed to be a geometry issue with the model.  The hi-poly Faustus has the same problem (or one of them does anyway), where it is just dark and you tend to only get little specs of light on it.  Unfortunately I don't know exactly what sort of geometry error causes this, since I never had a chance to investigate it further last year (as it only happened for one released model).

I recommend just checking for any sort of geometry problems, bad normals or whatever, and maybe you can find the cause.

[Scooby_Doo]

Think I fixed it.  Simply added a Edit Poly then collapsed the model again, why it worked, I have no clue. 

[Flipside]

Conversion hiccup possibly?

[Vasudan Admiral]

I did think it very odd that you had them in the wrong format - I was pretty sure you'd been making them correctly for a good while now, but didn't have time to check for sure.

Anyway, I *think* this error can be caused by wonky vertex normals rather than face normals (which would make the face invisible if they were on the wrong side) - so it might be related to the smoothgroup problems I suspect the max exporter has. That said though, did you actually use the max exporter in this case or was it via a DAE?

Also, Taylor - do you remember where abouts that problem occurred on the Faustus? It's since been reconverted for the next MVPs to fix a number of other geometry issues it had, so I'd better check the new one for that sort of thing when I get home tonight.

[taylor]

Also, Taylor - do you remember where abouts that problem occurred on the Faustus? It's since been reconverted for the next MVPs to fix a number of other geometry issues it had, so I'd better check the new one for that sort of thing when I get home tonight.

The entire thing was messed up actually.  It was a little more difficult to notice right away with the Faustus (since it did sort of work), but you could replicate the bug quite easily in the ships lab by moving the ship around it's X/Y axis.  As you flipped it around the lighting would change, slowing moving the "dark side" all around the model.  The sparkling pixels would best be noticed inside the engine wells, and on the rotating section when you had that "dark side" positioned just right.

That lighting issue was a problem on the Faustus well before normal maps came about even (noticed it soon after the model first hit the MediaVPs).  I had mentioned it at the time but never really followed up on it.  Adding normal maps just exaggerated the issue 100x, so that it became impossible to miss.

[Scooby_Doo]

Anyway, I *think* this error can be caused by wonky vertex normals rather than face normals (which would make the face invisible if they were on the wrong side) - so it might be related to the smoothgroup problems I suspect the max exporter has. That said though, did you actually use the max exporter in this case or was it via a DAE?

Using DAE more or less exclusively if possible.

[Vasudan Admiral]

The entire thing was messed up actually.  It was a little more difficult to notice right away with the Faustus (since it did sort of work), but you could replicate the bug quite easily in the ships lab by moving the ship around it's X/Y axis.  As you flipped it around the lighting would change, slowing moving the "dark side" all around the model.  The sparkling pixels would best be noticed inside the engine wells, and on the rotating section when you had that "dark side" positioned just right.

That lighting issue was a problem on the Faustus well before normal maps came about even (noticed it soon after the model first hit the MediaVPs).  I had mentioned it at the time but never really followed up on it.  Adding normal maps just exaggerated the issue 100x, so that it became impossible to miss.

Ok, thanks - I'm going to tentatively call it fixed with the internal MVP version - as I can't see anything out of the ordinary upon careful examination both with and without textures.

Using DAE more or less exclusively if possible.

That could still possibly be a smoothgroup problem. If you don't mind - next time you have a problem like this -(weird lighting effects, crashes upon conversion/saving as POF etc.) could you try clearing the models smoothgroups and then re-defining them as the LAST thing you do on the model? I suspect smoothgroup issues might be behind more conversion problems than we realise. Just a suspicion at this stage though.