[LDView] LDView 4.5 Released

[Travis Cobbs]

LDView 4.5 is now available.

You can download this release from the LDView Downloads Page.

While mostly a bug fix release, there are a lot of bug fixes, with perhaps the most important being fixing downloads from the updated ldraw.org server (for unofficial parts and parts library updates).

You can see the full Change History here.

[Gerald Lasser]

Thanks a lot Travis!

Download works! Love it!

[Willy Tschager]

Thanks for the new version!

* It is not a good idea to change the FSAA multiplier with a (large model loaded) as LDView become unbearable slow or freezes.

* Changing the FSAA multiplier causes the LEGO logo to disapear

* There is noise when saving via LDView's screenshot which wasn't in 4.4.1:

Picture via LDView 4.4.1
   
Windows Screenshot LDView 4.4.1
   
Picture via LDView 4.5 - Note the noise at the pavement
   
Windows Screenshot LDView 4.5
   

w.

[Philippe Hurbain]

LDView 4.5 is now available.

You can download this release from the LDView Downloads Page.

While mostly a bug fix release, there are a lot of bug fixes, with perhaps the most important being fixing downloads from the updated ldraw.org server (for unofficial parts and parts library updates).

You can see the full Change History here.

Thanks Travis!
There may still be a problem with automatic part download. While trying to view 50231c03.dat (https://library.ldraw.org/tracker/30025), I got a truncated 50231c03s01.dat at line 291.

[Travis Cobbs]

Thanks for the new version!

* It is not a good idea to change the FSAA multiplier with a (large model loaded) as LDView become unbearable slow or freezes.

* Changing the FSAA multiplier causes the LEGO logo to disapear

Is this new behavior in 4.5 that did not exist in 4.4.1? I don't remember making and FSAA changes.

* There is noise when saving via LDView's screenshot which wasn't in 4.4.1:

Picture via LDView 4.4.1

Windows Screenshot LDView 4.4.1

Picture via LDView 4.5 - Note the noise at the pavement

Windows Screenshot LDView 4.5

Your LDView 4.5 shots are at a different angle from the 4.4.1 ones. Can you repeat the test using the same angle for both, or send me the model?

[Travis Cobbs]

Thanks Travis!
There may still be a problem with automatic part download. While trying to view 50231c03.dat (https://library.ldraw.org/tracker/30025), I got a truncated 50231c03s01.dat at line 291.

I believe that you opened that file with LDView 4.4.1 and so already have the corrupt subpart downloaded on your computer. Since the file hasn't changed on the server since LDView 4.4.1 downloaded and corrupted it, LDView believes that the local file is up to date. If you delete the file from <ldraw>/Unofficial/parts/s, then reopen the parent file, LDView 4.5 should download the subpart again, and it should be correct this time. (When I loaded 50231c03.dat with LDView 4.4.1, it had the exact corruption you mention. After deleting the subfile and trying again with LDView 4.5, it was correct.)

[Max Murtazin]

Many thanks, Travis! 

By the way, a question/feature request

Could it be changed how type 2 and 5 lines work for shading? At the moment, LDView basically throws everything in the same bin without considering how exactly they are meant to interact. Most importantly, complementary conds and line 2 over line 5

For complementary conds, there are cases when original conditional lines of primitive are "overshadowing" original conds — angle formed by line and control points of original cond is sharper, thus leading to condline appearing when it's not meant to — best example would be complementaries on new npeghol prims

For line 2 over line 5, there are cases when line 2 appears in same place as a primitive line 5. It leads to an odd behavior of faces sharing vertex normals, when they are not meant to. Npeghol8 will be a good example, specifically a line 2 inside of it at the end of cylinder

Can't provide pictures unfortunately rn, can do that later tomorrow

[Gerald Lasser]

I believe that you opened that file with LDView 4.4.1 and so already have the corrupt subpart downloaded on your computer. Since the file hasn't changed on the server since LDView 4.4.1 downloaded and corrupted it, LDView believes that the local file is up to date. If you delete the file from <ldraw>/Unofficial/parts/s, then reopen the parent file, LDView 4.5 should download the subpart again, and it should be correct this time. (When I loaded 50231c03.dat with LDView 4.4.1, it had the exact corruption you mention. After deleting the subfile and trying again with LDView 4.5, it was correct.)

I had to delete also a few files that 4.4.1 downloaded, as I am updating the Instagram posts, I downloaded a lot of parts today with 4.5 and so far I did not run into any issue with any part.

[Travis Cobbs]

Could it be changed how type 2 and 5 lines work for shading? At the moment, LDView basically throws everything in the same bin without considering how exactly they are meant to interact. Most importantly, complementary conds and line 2 over line 5

For complementary conds, there are cases when original conditional lines of primitive are "overshadowing" original conds — angle formed by line and control points of original cond is sharper, thus leading to condline appearing when it's not meant to — best example would be complementaries on new npeghol prims

Unless I am misunderstanding, there is nothing I can do about this. I would say that the part in question is technically wrong, and that perhaps a new primitive (without a complementary cond at the edge) is needed. The complementary conditionals at the edges of circular primitives are real geometry in the parts, and will be drawn based on their geometry. It isn't feasible to try to figure out what is next to them to decide if they are correct or not: that way lies madness.

For line 2 over line 5, there are cases when line 2 appears in same place as a primitive line 5. It leads to an odd behavior of faces sharing vertex normals, when they are not meant to. Npeghol8 will be a good example, specifically a line 2 inside of it at the end of cylinder

LDView already checks for conditional lines that match edge lines, and removes them from the list of conditional lines used for smoothing. However, when I say "match" here, I do mean "match": both ends of the conditional line need to be the same as both ends of the edge line (with relatively forgiving rounding). For performance reasons, I don't think I can have it look for partial overlaps.

[Philippe Hurbain]

I believe that you opened that file with LDView 4.4.1 and so already have the corrupt subpart downloaded on your computer. Since the file hasn't changed on the server since LDView 4.4.1 downloaded and corrupted it, LDView believes that the local file is up to date. If you delete the file from <ldraw>/Unofficial/parts/s, then reopen the parent file, LDView 4.5 should download the subpart again, and it should be correct this time. (When I loaded 50231c03.dat with LDView 4.4.1, it had the exact corruption you mention. After deleting the subfile and trying again with LDView 4.5, it was correct.)

Sorry for the false alarm! Not this exact scenario, but I had my LDDP still calling the 4.4.1 version...

[Max Murtazin]

Unless I am misunderstanding, there is nothing I can do about this. I would say that the part in question is technically wrong, and that perhaps a new primitive (without a complementary cond at the edge) is needed. The complementary conditionals at the edges of circular primitives are real geometry in the parts, and will be drawn based on their geometry. It isn't feasible to try to figure out what is next to them to decide if they are correct or not: that way lies madness.

LDView already checks for conditional lines that match edge lines, and removes them from the list of conditional lines used for smoothing. However, when I say "match" here, I do mean "match": both ends of the conditional line need to be the same as both ends of the edge line (with relatively forgiving rounding). For performance reasons, I don't think I can have it look for partial overlaps.

Huh, okay, thank you for the answer!
For complementaries tho, I think that maybe there could be a check that compares parent conditional lines and subpart conditionals, and ignore conditionals from the subpart if they have match in parent?

[Travis Cobbs]

For complementaries tho, I think that maybe there could be a check that compares parent conditional lines and subpart conditionals, and ignore conditionals from the subpart if they have match in parent?

Unfortunately, that won't work either, since complimentary conditionals are designed for there to be an overlap. In the case of two adjacent curved primitives the overlap is with two primitives, but there are legitimate cases where the second conditional would be in a part.

[N. W. Perry]

I didn't notice this before, but it seems I've lost the ability to reliably highlight edge lines in the Model Tree. (They still do it, but it's very hit-and-miss, as it was before the release of 4.4.)

I wonder if it's just something in my preferences that I have to re-create, or is it possible this broke somehow in the update to 4.5?

[Travis Cobbs]

I didn't notice this before, but it seems I've lost the ability to reliably highlight edge lines in the Model Tree. (They still do it, but it's very hit-and-miss, as it was before the release of 4.4.)

I wonder if it's just something in my preferences that I have to re-create, or is it possible this broke somehow in the update to 4.5?

I just checked on my Mac, and edge lines still highlight fine for me (including showing through solid geometry when they are occluded). I'll test on my Windows PC when I get a chance.

[Magnus Forsberg]

Try picking another colour on the veiwer by clicking on the colour box.

   

[Travis Cobbs]

I didn't notice this before, but it seems I've lost the ability to reliably highlight edge lines in the Model Tree. (They still do it, but it's very hit-and-miss, as it was before the release of 4.4.)

I wonder if it's just something in my preferences that I have to re-create, or is it possible this broke somehow in the update to 4.5?

Just to confirm, you do have edge lines enabled on the Geometry page, right? Because if LDView isn't drawing edge lines, they won't highlight even when you select an entry in the tree view for an edge line (or a parent file like 4-4edge.dat).

[N. W. Perry]

Try picking another colour on the veiwer by clicking on the colour box.

Did that. Still gives the same result. (By the way, how do I switch back to the default color?)

Just to confirm, you do have edge lines enabled on the Geometry page, right? Because if LDView isn't drawing edge lines, they won't highlight even when you select an entry in the tree view for an edge line (or a parent file like 4-4edge.dat).

Yup. And I can confirm, they are highlighting, but they're very hard to spot, and do not appear to be in front of other geometry.

I should clarify, I'm talking about type 2 lines here. If I highlight, say, a rect or box primitive, its edge lines light up bright and bold and on top.

[Travis Cobbs]

I should clarify, I'm talking about type 2 lines here. If I highlight, say, a rect or box primitive, its edge lines light up bright and bold and on top.

I do see a difference between highlighting a file that contains type 2 lines and highlighting the type 2 lines themselves (although for me they still do get highlighted, and still show through blocking solid geometry). Since there shouldn't be a difference, I will start by trying to fix that, and then I'll see if it solves your problem.

I created an issue in my GitHub repository: https://github.com/tcobbs/ldview/issues/78

[N. W. Perry]

I do see a difference between highlighting a file that contains type 2 lines and highlighting the type 2 lines themselves (although for me they still do get highlighted, and still show through blocking solid geometry). Since there shouldn't be a difference, I will start by trying to fix that, and then I'll see if it solves your problem.

I created an issue in my GitHub repository: https://github.com/tcobbs/ldview/issues/78

Yes, that definitely sounds like the same behavior I'm getting. Perhaps the effect is just more pronounced for me. Here are a couple of screen shots to illustrate the difference as I'm seeing it, using a random part.

First, I select a box5 primitive. All of its faces and edge lines light up good and strong:
   

Now, I go inside the box5 prim and select its edges individually. They still light up, and they still show on top of other geometry, but they're much dimmer—to the point where you can't even tell that some of them are highlighted at all:
   
(Interestingly, the screen shot actually looks somewhat better than the actual program window on my system.)

Just for fun, I also tried opening the box5 prim itself, in case the issue had something to do with recursive subfiles, but it made no difference.

[N. W. Perry]

Oh—now this is interesting. I tried individually selecting the edges and faces within the box5 prim, and then the edge lines did light up strongly! In fact, as soon as I select just one face, in addition to the edges, then all of the edges turn bright:
   

Note, however, that the faces selected this way are opaque, whereas faces selected at the next higher level of the tree, as well as those in a selected subfile, are transparent.

[Travis Cobbs]

I do see a difference between highlighting a file that contains type 2 lines and highlighting the type 2 lines themselves (although for me they still do get highlighted, and still show through blocking solid geometry). Since there shouldn't be a difference, I will start by trying to fix that, and then I'll see if it solves your problem.

I created an issue in my GitHub repository: https://github.com/tcobbs/ldview/issues/78

While investigating this, I have determined that the problem only happens when Antialiased lines are enabled on the General tab of preferences. Can you confirm that the same is true for you?

[Magnus Forsberg]

Can you confirm that the same is true for you?

Confirmed.

[N. W. Perry]

While investigating this, I have determined that the problem only happens when Antialiased lines are enabled on the General tab of preferences. Can you confirm that the same is true for you?

Confirmed as well. The issue goes away if I deselect that option.

[Eugen]

Latest LDView wrongly shows parts colored in "Yellow (14)" with a "Blue (1)" color instead:

MPD file attached in this topic first comment:

• forums.ldraw.org/thread-28440.html
  

LeoCAD version: LeoCAD-Linux-4fce4313-x86_64.AppImage

   

LDView version: ldview-git-Build42.42.glibc2.29-x86_64.AppImage

   

[Orion Pobursky]

I'm not getting the same error. Below is my screen shot.
   

[Eugen]

I'm not getting the same error. Below is my screen shot.

Gerald Lasser just tested too, and said that on Windows it has no issue too, but there is some issue in MPD file markup:

My windows 4.5 doesnT' do that.

But looking in the file (and at the picture) it seems that it replaces yellow with the colour used before the last yellow part. in your file this is mostly blue, but also red on some occasions.

and if the previous colour is a transparent one, it picks even one before

interesting.

I'm using Linux version (would say nothing about Windows).

More details about bug I see - it seems like LDView changed parts with the same one color not just to another, but diversed to few different colors.

I just re-edited all the models colors manully and set integrated submodels color to be "Main (16)".

Updated MPD file is attached to this comment.

In LeoCAD it shown correctly (as before).

   

But in LDView all the "Red (4)" parts are diversed into "Yellow (14)", "Black (0)", "Blue (1)" and "White (15)".

   

[Orion Pobursky]

This might be the bug in OSMesa that Travis references here:
https://forums.ldraw.org/thread-27722-po...g#pid51345

[Eugen]

This might be the bug in OSMesa that Travis references here:
https://forums.ldraw.org/thread-27722-po...g#pid51345

So, this is a Linux-specific core bug.

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.

They added a "label". But just a usual label, where the bug is really critical.

   

[Orion Pobursky]

I tested the original file and a modified version that uses color 16 with the LDraw server version of LDView (a non-GUI Linux build) and they both rendered correctly. 

Curious, I went back to the file where I originally found the problem, the 8880 model, and downloaded that. It also rendered correctly this time. 

So now I'm confused.

Below is the rendered image from the LDraw server version of LDView:
   

[Eugen]

with the LDraw server version of LDView (a non-GUI Linux build) and they both rendered correctly.

Probably, due to headless LDView for Linux uses OSMesa, while Linux GUI version uses Mesa, and LDView GUI version for Windows might be uses some other OpenGL implementation.

OSMesa is a bit different from Mesa: https://docs.mesa3d.org/osmesa.html

So, headless LDView for Linux with OSMesa does not have a colors handling bug.

[Orion Pobursky]

So, headless LDView for Linux with OSMesa does not have a colors handling bug.

It did though, that's the reason I reported the error to begin with. Also, OSMesa uses Mesa so the bug should persist.

[Travis Cobbs]

Latest LDView wrongly shows parts colored in "Yellow (14)" with a "Blue (1)" color instead:

MPD file attached in this topic first comment:

• forums.ldraw.org/thread-28440.html
  

LeoCAD version: LeoCAD-Linux-4fce4313-x86_64.AppImage



LDView version: ldview-git-Build42.42.glibc2.29-x86_64.AppImage

There is a critical bug in Mesa 3D (that I reported slightly over 2 years ago) that causes this problem in LDView when running with Mesa 3D as the OpenGL provider. I tried and failed to work around it.

[Orion Pobursky]

There is a critical bug in Mesa 3D (that I reported slightly over 2 years ago) that causes this problem in LDView when running with Mesa 3D as the OpenGL provider. I tried and failed to work around it.

What's weird is that the OSMesa version in use by the library was affected by this bug but now seems not to be.

[Travis Cobbs]

What's weird is that the OSMesa version in use by the library was affected by this bug but now seems not to be.

I think either you are misremembering, or you changed a setting for the library renders. With default settings in LDView, the bug would not affect renders of parts, since their geometry gets flattened in a way that masks the Mesa bug. The same does not happen for models. (Due to the geometric complexity involved, this is not an option for models.) See here:

https://forums.ldraw.org/thread-27722-po...l#pid51350

[Travis Cobbs]

There is a critical bug in Mesa 3D (that I reported slightly over 2 years ago) that causes this problem in LDView when running with Mesa 3D as the OpenGL provider. I tried and failed to work around it.

One more thing: If you change the top-level model references to use color 16 instead of another color, it will probably work around the LDView problem. Note that I am not saying that using 14 at that level is wrong; it's not. But due the details of the Mesa bug that shows up in LDView, making that change should make the problem go away.

At least for the Transport-1.ldr subfile, it does not appear that any of the parts are referenced using color 16. This means that the color 14 you use when placing Transport-1.ldr in the model is completely ignored. I suspect that the same is true for Transport-2.ldr, Transport-3.ldr, and Transport-4.ldr. Assuming this is the case, you should be able to modify the following four lines in the file:

Code:

1 14 -40 0 0 1 0 0 0 1 0 0 0 1 Transport-1.ldr
1 14 160 0 250 1 0 0 0 1 0 0 0 1 Transport-2.ldr
1 14 -30 0 350 1 0 0 0 1 0 0 0 1 Transport-3.ldr
1 14 160 0 0 1 0 0 0 1 0 0 0 1 Transport-4.ldr

Update them to instead be:

Code:

1 16 -40 0 0 1 0 0 0 1 0 0 0 1 Transport-1.ldr
1 16 160 0 250 1 0 0 0 1 0 0 0 1 Transport-2.ldr
1 16 -30 0 350 1 0 0 0 1 0 0 0 1 Transport-3.ldr
1 16 160 0 0 1 0 0 0 1 0 0 0 1 Transport-4.ldr

After that, LDView should render the model correctly.

[Orion Pobursky]

I think either you are misremembering, or you changed a setting for the library renders. With default settings in LDView, the bug would not affect renders of parts, since their geometry gets flattened in a way that masks the Mesa bug. The same does not happen for models. (Due to the geometric complexity involved, this is not an option for models.) See here:

https://forums.ldraw.org/thread-27722-po...l#pid51350

I know for part renders that this bug doesn't happen, but for OMR render it absolutely was as referenced here:
https://forums.ldraw.org/thread-27722.html

I went back and re-rendered the exact same model that I posted in the above thread. This time, the error I was getting (as shown in the picture I post) did not reoccur. As far as I can tell, I'm still using the same settings as I was last time which are the same settings for all of the PT.

Here's the current result, which looks correct to me:
https://library.ldraw.org/omr/sets/908

I'm not sure if the OSMesa distro that Ubuntu 24.04 is providing has this bug fixed or if there's something else going on but it's odd.

[Travis Cobbs]

I know for part renders that this bug doesn't happen, but for OMR render it absolutely was as referenced here:
https://forums.ldraw.org/thread-27722.html

When you said "library", I took that to mean the parts library, not the OMR.

I went back and re-rendered the exact same model that I posted in the above thread. This time, the error I was getting (as shown in the picture I post) did not reoccur. As far as I can tell, I'm still using the same settings as I was last time which are the same settings for all of the PT.

Here's the current result, which looks correct to me:
https://library.ldraw.org/omr/sets/908

I'm not sure if the OSMesa distro that Ubuntu 24.04 is providing has this bug fixed or if there's something else going on but it's odd.

It's possible that Mesa fixed the bug without noticing my bug report, which is still listed as open:

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

[Eugen]

Update them to instead be:

Code:

1 16 -40 0 0 1 0 0 0 1 0 0 0 1 Transport-1.ldr
1 16 160 0 250 1 0 0 0 1 0 0 0 1 Transport-2.ldr
1 16 -30 0 350 1 0 0 0 1 0 0 0 1 Transport-3.ldr
1 16 160 0 0 1 0 0 0 1 0 0 0 1 Transport-4.ldr

After that, LDView should render the model correctly.

I have tried it and attached updated file yesterday: https://forums.ldraw.org/thread-28440.html

• MPD file: Milky Way Magic Chest (updated).mpd
  

It does NOT fixes issue in LDView, but diverges to more colors.

Here is screenshot made with clean install latest LDView AppImage from Peter Bartfai's OBS (both, ldview-0-Build1103.8.glibc2.29-x86_64.AppImage and ldview-git-Build42.43.glibc2.29-x86_64.AppImage produces the same look).

Note that there are all 3 possible issues the same time (parts with translucent colors are not affected):

1. some parts fully switched to wrong color;
   
2. some studs swiched to wrong color, but parts stays in correct color;
   
3. some studs stays in correct color, but parts switched to wrong color:

   

In LeoCAD all looks correct instead (as it was before the change too):

   

[Travis Cobbs]

I have tried it and attached updated file yesterday: https://forums.ldraw.org/thread-28440.html

• MPD file: Milky Way Magic Chest (updated).mpd
  

It does NOT fixes issue in LDView, but diverges to more colors.

I'm sorry it didn't fix it. I'm not sure why it sometimes works and sometimes doesn't. Having said that, I am still convinced that the problem is due to the bug in Mesa.

[Eugen]

I'm sorry it didn't fix it. I'm not sure why it sometimes works and sometimes doesn't. Having said that, I am still convinced that the problem is due to the bug in Mesa.

I just wonder why LeoCAD has no issues with colors, as it also uses Mesa.

As LDView might be uses different methods than LeoCAD, could be LeoCAD code in some way helps to workaround issue?

Or LeoCAD's GL render uses fully different Mesa's API calls than LDView's GL render?

[Eugen]

I'm not sure why it sometimes works and sometimes doesn't.

I just found that correct colors shown in two cases:

1. if "Lighting" turned OFF ("BFC" and "Texture studs" states does not affects colors)
   
2. if "Lightning" is turned ON, but "BFC" and "Texture studs" turned OFF ( "Specular" does not affects colors)
   

Here are also screenshots for all the cases I've found so far. Hope this would helps to investigate this issue.

1. "Lighting" OFF
      
   
2. "Lighting" ON + "BFC" ON
      
   
3. "Lighting" ON + "Specular" ON + "BFC" ON
      
   
4. "Lighting" ON + "Specular" ON + "Texture studs" ON + "BFC" ON
      
   
5. "Lighting" ON + "Specular" ON + "Texture studs" ON + "BFC" OFF
      
   
6. "Lighting" ON + "Texture studs" OFF + "BFC" OFF
      
   

[Travis Cobbs]

I just wonder why LeoCAD has no issues with colors, as it also uses Mesa.

As LDView might be uses different methods than LeoCAD, could be LeoCAD code in some way helps to workaround issue?

Or LeoCAD's GL render uses fully different Mesa's API calls than LDView's GL render?

I strongly suspect that LeoCAD's renderer is completely different from LDView's. One thing to keep in mind about LDView is that I originally wrote the renderer over 20 years ago, and it is based on OpenGL 1.x functionality. I'm guessing this is why a fundamental feature (glPushAttrib/glPopAttrib) could be completely broken and stay broken for years without anybody bothering to fix it. (Note: the Mesa bug report has an extremely compact example that demonstrates the bug.)

[Travis Cobbs]

I just found that correct colors shown in two cases:

1. if "Lighting" turned OFF ("BFC" and "Texture studs" states does not affects colors)
   
2. if "Lightning" is turned ON, but "BFC" and "Texture studs" turned OFF ( "Specular" does not affects colors)
   

Thanks for the further details. Unfortunately, since it only happens in the Linux version and not Windows or macOS, I'm still convinced that broken Mesa OpenGL drivers are to blame. It does sound like option 2 should produce reasonably ok renders.

[Eugen]

 It does sound like option 2 should produce reasonably ok renders.

Yes, both are ok: 1 - for instruction and stylish renders; 2 - for more realistic renders.

I may also recommend to add my workaround notes somewhere in LDView docs and in readme on GitHub.

Here is GitHub Markdown code for the note (feel free to edit it):

Code:

> [!NOTE]
> For Linux users expiring issues with incorrect colors in LDView, try the next workarounds:
> - turn "Lighting" OFF (for flat colors mode)
> - turn "Lightning" ON, but turn OFF "BFC" and "Texture studs" (for shaded mode)