Fix #3320: Incorrect colors for 3D draws

[Nico8340]

Fixes #3320 (an old bug caused by an incomplete, unfinished piece of code)

[tederis]

Although I assume it works, the origin of these coefficients isn't clear for me. Can you elaborate on how they were found?

[Nico8340]

Although I assume it works, the origin of these coefficients isn't clear for me. Can you elaborate on how they were found?

The bug only appears for 3D lines, not for 3D material lines, because the code was already there. The solution comes from the code of 3D material lines.
@tederis

[tederis]

Although I assume it works, the origin of these coefficients isn't clear for me. Can you elaborate on how they were found?

The bug only appears for 3D lines, not for 3D material lines, because the code was already there. The solution comes from the code of 3D material lines. @tederis

I see now, you just copied the behaviour from CMaterialLine3DBatcher. But I still cannot understand how exactly it fixes the problem. Why should it be divided by two? This is not directed at you, I just want to comprehend.

[Nico8340]

I see now, you just copied the behaviour from CMaterialLine3DBatcher. But I still cannot understand how exactly it fixes the problem. Why should it be divided by two? This is not directed at you, I just want to comprehend.

This is a very good question, because if we draw as a postGUI, then this is not necessary. This is probably caused by a bug / behavior of DirectX.
@tederis

[tederis]

After a little research I have found that the problem is indeed comes from the color correction pass (as I pointed out in #3320). This pass isn't fixed and it changes the colors every frame. So you can see that the division by 2 doesn't fix that, but only masks the problem. Moreovere, there is no constant that can fix it.

That means that 3D material lines still experience the problem. I think that the division should be removed from CMaterialLine3DBatcher as it makes colors inconsistent with other dx functuin and makes it difficult to correct colors using getColorFilter function. Unfortunately this PR also doesn't fix the issue.

[Nico8340]

I removed the division from both batchers.

[Einheit-101]

Finally no more getColorFilter to fix the dx rendering? Nice.

[Nico8340]

Finally no more getColorFilter to fix the dx rendering? Nice.

This patch only removes divide by two from the line batcher, so it doesn't provide a real solution to the problem, it can be used uniformly and correctly with getColorFilter, but a future patch may include a real solution to the problem.