[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.