Incorrect Colours On Linux/QT Version

[dannytip]

Describe the bug I'm having an issue where the linux version of LDView renders a models colours incorrectly compared to windows/mac.

Here is a screenshot from mac (notice its the correct red colour):

Heres the same model loaded up on ubuntu:

To Reproduce Steps to reproduce the behavior:

1. Download the mpd file: http://omr.ldraw.org/files/722
2. Open the mpd with LDView on ubuntu
3. See error

Expected behavior The outputs should match between platforms.

Platform

• OS: Ubuntu Linux 22.04
• LDView Version v4.4.1
• CPU Architecture X86-64

Both models were rendered using the same LDConfig.ldr and assets.

[tcobbs-bentley]

@pbartfai can you reproduce this?

[pbartfai]

@tcobbs-bentley same coloring issue on Fedora 36.

[pbartfai]

Same issue on OSMesa, so this is not a Qt specific problem.

[tcobbs]

I reproduced this and determined via a test build that glPushAttrib/glPopAttrib are either broken or limited, and this causing the problem. This is a problem I have seen in the past, so the code includes checks for a #define that can avoid using glPushAttrib and glPopAttrib. @pbartfai if you define _GL_POPCOLOR_BROKEN in your build, it should fix the problem. I guess future Qt and OSMesa builds should always define this. I don't know why this hasn't caused problems in the past, since it appear that it messes up colors on a lot of models (including LDraw's car.ldr).

[pbartfai]

I have built both OSMesa and Qt versions with _GL_POPCOLOR_BROKEN defined but the problem is still there.

[tcobbs]

@pbartfai It's not really a solution, but does changing Memory Usage to Low or Medium fix the problem after defining _GL_POPCOLOR_BROKEN? (I had mine set to low to assist in my debugging, and I get correct colors with both Low and Medium as long as _GL_POPCOLOR_BROKEN is defined, but badly messed up rendering if it is set to High.)

[pbartfai]

Tested on Fedora with both Qt & OSMesa with all possible memory usage mode and no improvement, problem was always there.

[tcobbs]

As far as I can tell, this is caused by a bug in Mesa. I committed a fix to the existing _GL_POPCOLOR_BROKEN that fixes it for me with the OSMesa version of LDView:

https://github.com/tcobbs/ldview/commit/e897c90f22131af50b6aa14a4269fa46cb9ec46c

@pbartfai Please build with _GL_POPCOLOR_BROKEN defined and let me know if it fixes the problem. If it does, I'll add code to make this a setting that can be configured at run-time. Compiling with this #define definitely slows down execution.

[pbartfai]

Problem fixed by e897c90 but the performance became extreme poor. Without the fix the FPS was around 23 for the model above. With the fix applied it went down bellow 1.

[tcobbs]

Let me see if LDView has a mismatched push/pop that is causing the problem on Mesa but not on other renderers.

[tcobbs]

@pbartfai What is your memory usage setting? I wouldn't expect this to have such a dramatic effect on performance when memory usage is set to High. (Note: since it seems hard to believe that Mesa's glPushAttrib/glPopAttrib are completely broken, I'll still try to see if LDView is doing something wrong. However, in my testing on my Mac, the max stack depth used is 3, so it doesn't look like LDView is pushing more than it is popping. OpenGL guarantees that the attribute stack has at least 16 entries.)

[tcobbs]

Actually, for me high doesn't work right with _GL_POPCOLOR_BROKEN defined during build.

[pbartfai]

Colors are wrong with memory usage high, but performance if back to original.

[tcobbs]

I tracked this down to a bug in Mesa 3D. I was able to create a small amount of test code to demonstrate the problem, and then reported the problem on the Mesa 3D bug tracker:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/7122

I tried a bunch of different things to try to work around the Mesa bug, and didn't come up with anything that worked. (In low and medium memory usage settings for LDView, I did come up with a workaround that worked, but it was extremely slow.)

@dannytip You can work around the problem by editing the model so that instead of using color 16 for the red bricks in the train sub-models, it uses red (color 2). This is obviously not a solution to the problem, but I tried everything I could think of to deal with the broken Mesa 3D code, and nothing worked.

[dannytip]

@tcobbs thank you for all your efforts trying to resolve this. From your response i guess the QT version uses Mesa too? I will also keep an eye on the mesa issue, hopefully they will pick it up soon. I plan on using LDView via command line so can use either version.

[tcobbs]

@dannytip It's my understanding that the Qt version uses the system OpenGL, which is often Mesa. You should be able to verify this by going to the Help menu in LDView and selecting OpenGL Driver Info. @pbartfai, is this correct? When I configured my system (with an nVidia graphics card) to use nVidia's proprietary drivers (and X11, not Wayland), LDView didn't use Mesa in the Qt version. LDView didn't work properly using the default Gnome environment. I'm not sure if it was using Mesa or not. (I didn't check.)

[pbartfai]

@tcobbs correct.

[dannytip]

@tcobbs @pbartfai thanks for the clarification.