Bump mapping does not behave predictably

[colincornaby]

Plasma's bump maps do not work as normal bump maps. They're implemented as normal maps - but they can only add highlights instead of providing depth. This works well in Eder Kemo where there is lightning - but generally removes detail when attempting to bump map.

The attached screenshots show this issue. In one screenshot the normal map is only used to apply extra highlights (in the style of the shipping engine) and in the other the normal map is allowed to move add and remove light. The second style is how a normal map would typically work.

(These screenshots are from the Mac client, not the original D3D client.)

It's not clear which is the correct behavior. There following is a comment from the code (DXPipeline.cpp):

// The bump textures created so far have very strong blue components, which make anything
// bump mapped glow. The ideal fix would be to have the artists adjust the blue component
// to a better (lower) value, so there would be a little extra illumination where the bump
// is straight out into the normal direction, to complement the lateral illumination.
// Attempts so far have been unsuccessful in getting them to get a better understanding
// of bump maps, so I've just zeroed out the contribution in the normal direction.

There seems to have been a misunderstanding between the original artists and developers. Normal maps tend to have a strong blue component because almost all normals will point away from the texture into space. This implies a disagreement on how bump mapping should have worked in Plasma. It's possible the normal maps were intended by the artists to be implemented as typical normal maps, but the developers had something else in mind.

With that said, there are several approaches we could take:

• Assume that if the original artists provided normal maps that the bump assets should be interpreted as normal maps. This could change the appearance of bump mapped textures in the game.
• Assume that the developers were correct here. They were the ones providing the finished game - and therefore bump/normal maps should actually behave as highlight maps. They should never subtract lighting and only add.
• Implement both approaches. We would not treat existing assets as bugged - but would add a new option for proper normal mapping to be used in new ages.

[dpogue]

I think the big question here is what we're able to do in terms of making DirectX rendering match whatever we choose. It would be bad for Age builders to get wildly different effects depending on what platform is used.

[colincornaby]

I'll continue digging on that. D3DFMT_Q8W8V8U8 sounds suspiciously like the format we need - except there is some discussion online that format may not work with standard normal maps. Most discussion of those formats has been lost but I'll keep searching.

The method Cyan uses for the fixed function pipeline will always have accuracy issues because it doesn't affect the lighting of the material - it's entirely a post material overlay. We could probably simulate the subtraction of light. Maybe it could be another blend as part of the material render. But it takes a few stages to do.

[colincornaby]

This sample seems relevant to our problem:
https://github.com/edgeforce/directx8/tree/msdx8/samples/multimedia/direct3d/bumpmapping/dotproduct3