Error with OSMesa version of LDView

[Orion Pobursky]

I'm having a problem with the OSMesa version of LDView used by the PT. It's not rendering some things correctly in some case and I can't seem to figure out why. Attached is the one of the problematic files. It renders fine with the Windows build and in Lasse's buildinginstructions.js but as you can see by the image below, the Linux OSMesa version doesn't
   

As this is generated by code, there may be some sort of error in the file that I'm not noticing.

[Travis Cobbs]

I'm having a problem with the OSMesa version of LDView used by the PT. It's not rendering some things correctly in some case and I can't seem to figure out why. Attached is the one of the problematic files. It renders fine with the Windows build and in Lasse's buildinginstructions.js but as you can see by the image below, the Linux OSMesa version doesn't


As this is generated by code, there may be some sort of error in the file that I'm not noticing.

I believe that this is caused by a bug in Mesa. I reported the bug over a year ago, but nothing has been done about it. I spent quite a bit of time trying to modify LDView to work around the Mesa bug, but failed. The bug is in a portion of OpenGL functionality that is too fundamental to LDView's rendering for me to avoid the functionality, and all the things I tried to work around it ultimately failed.

Here is LDView's GitHub issue regarding the problem. Note that while this issue refers to the Qt version of LDView, the problem only occurs when using a Mesa-based graphics driver, and also affects the OSMesa version of LDView, which by definition relies on Mesa.

Note that I believe that the problem only happens when a model includes parts that use color 16. They then are supposed to inherit the color of their parent model (which would of course be a submodel that is referenced with a non-16 color number). But due to the Mesa bug, this doesn't work. I did a quick check of your model, and since the tyres are indeed specified using color 16, I am confident that the Mesa bug is the source of the problem.

[Orion Pobursky]

Look like I'm going to have to go back to the old way generating images instead of trying to simplify things by cramming all the files into one MPD.

[Orion Pobursky]

I wonder why I haven't run into this error with the part image generation?

Also, moving all the official parts out of the mpd didn't work. I guess I'm misunderstanding the nature of the bug.

[Travis Cobbs]

I wonder why I haven't run into this error with the part image generation?

Also, moving all the official parts out of the mpd didn't work. I guess I'm misunderstanding the nature of the bug.

I misread your file when I looked at it the first time. It's not doing what I thought it was doing. I thought it was using color 16 to refer to the tyre (2997.dat) in step16.dat, but I now see that it is not doing that. However, I still feel that the problem is triggered by the Mesa bug that is related to nested colors. Try changing all 4 of the references to step36.dat from color 0 to color 16 to see if that helps.

In other words, update the following:

Code:

1 0 251 -54 -180 0 0 -1 -1 0 0 0 1 0 8880 - step36.ldr
1 0 251 -54 500 0 0 -1 -1 0 0 0 1 0 8880 - step36.ldr
1 0 -251 -54 500 0 0 1 -1 0 0 0 -1 0 8880 - step36.ldr
1 0 -251 -54 -180 0 0 1 -1 0 0 0 -1 0 8880 - step36.ldr

Change it to the following:

Code:

1 16 251 -54 -180 0 0 -1 -1 0 0 0 1 0 8880 - step36.ldr
1 16 251 -54 500 0 0 -1 -1 0 0 0 1 0 8880 - step36.ldr
1 16 -251 -54 500 0 0 1 -1 0 0 0 -1 0 8880 - step36.ldr
1 16 -251 -54 -180 0 0 1 -1 0 0 0 -1 0 8880 - step36.ldr

The reason this doesn't affect the parts tracker is because LDView flattens all of the geometry in each part before drawing it. Since the parts tracker only renders one part at a time, it cannot trigger this bug. Flattening all of the geometry from all the parts in the model would in theory avoid the bug, but LDView does not allow you to do this due to the huge amount of memory it would require.