LDraw.org Discussion Forums

I have posted a test release for LDView 4.4 Beta 4 to GitHub:

https://github.com/tcobbs/ldview/release...v4.4_Beta4

This release mainly contains bug fixes since Beta 3, along with a few new features. The Mac version should work better on macOS Big Sur, and has an updated icon (as well as updated LDR and MPD icons on Big Sur).

One of the bug fixes with the most potential to introduce unexpected problems involves a change to the curve smoothing. It now does not try to smooth out two facets that are joined by both a conditional line and an edge line. This can happen (for example) when a curved primitive like a torus extends to the edge of a part. This happens on part 88293, which is the part that was included in the original bug report that caused me to fix the problem. I suspect that it happens in other parts also. I would greatly appreciate it if people would let me know if they see any regressions in LDView's curve smoothing.

Note: because of this new behavior, I expanded the angle over which curves can be smoothed. This improves (for example) the hair on the Bart Simpson minifig head, and probably improves other parts as well. However, it's possible that I went too far, and it will result in areas being smoothed that shouldn't be, so please be on the lookout for that as well.

The ChangeHistory.html file that is included in the release lists all of the changes since LDView 4.3. In the macOS version, ChangeHistory.html is in the dmg. In the Windows version, ChangeHistory.html gets installed to wherever you install LDView (C:\Program Files\LDView by default). I'm actually not sure where it goes in the Linux version. Please see my Alpha 6 announcement for a list of what I feel are the most important changes relative to LDView 4.3.

Please let me know about any problems you find. The preferred way to do that is with LDView's GitHub Issues tracker. However, if you do not want to create a GitHub account so that you can do that, you can reply to this message.

My hope is that this is the last beta release before an official LDView 4.4 release.

Beta installed. I'll let you know if something goes wrong.

I got a problem with this part : 98138p19

I don't know why but the 2 following lines
1 226 .5 0 -1.5 -1.1 0 0 0 1 0 0 0 1.1 3-4chrd.dat

1 226 .5 0 -4.25 -1.1 0 0 0 1 0 0 0 -1.1 3-4chrd.dat

are not rendered correctly (maybe a 3-16chrd or a 1-4chrd instead of a 3-4chrd).

I inlined the prims with LDDP and the issue disappeared


EDIT I had a problem with this one too :98138p8f

where the line

1 0 0 0 0 -2.5 0 0 0 1 0 0 0 2.5 1-16ndis.dat

doesn't appear in the render

No problem after inlining it.

EDIT2 : And with this one : 3010pzo

the lines

1 16 0 12 -10 0 0 11.7 11.7 0 0 0 1 0 48\1-12ndis.dat
1 16 0 12 -10 0 0 -11.7 11.7 0 0 0 1 0 48\1-12ndis.dat

don't render properly.

here again inlining solve the issue (at first I used an old unofficial file since this one has been released as official in the last update that's why I chande this line)

Thanks for the report. Unfortunately, I'm not able to reproduce any of these problems. All three parts render correctly for me, on both Mac and in Windows (with primitive substitution enabled). Assuming that you are in Windows, can you export the LDView tree from your registry and email it to the LDView email address? I'll see if some setting you have is causing the problem. (If I can reproduce the problem, hopefully I can fix it.)

Also, try setting UseStrips=0 on the command line (or in the Windows Registry) to see if it makes a difference.

(2021-05-09, 19:55)Travis Cobbs Wrote: [ -> ]Thanks for the report. Unfortunately, I'm not able to reproduce any of these problems. All three parts render correctly for me, on both Mac and in Windows (with primitive substitution enabled). Assuming that you are in Windows, can you export the LDView tree from your registry and email it to the LDView email address? I'll see if some setting you have is causing the problem. (If I can reproduce the problem, hopefully I can fix it.)

Also, try setting UseStrips=0 on the command line (or in the Windows Registry) to see if it makes a difference.

I tried with 3010pzo without using commnd line and still have the issue. I'll see later with UseStrips=0 later.

When I talked about render, I should have say render of the exported pov file. no rendering problem using LDView, it was obvious for me, but it wasn't obvious for any reader, sorry.

(2021-05-09, 20:11)Bertrand Lequy Wrote: [ -> ]I tried with 3010pzo without using commnd line and still have the issue. I'll see later with UseStrips=0 later.

When I talked about render, I should have say render of the exported pov file. no rendering problem using LDView, it was obvious for me, but it wasn't obvious for any reader, sorry.

Thanks. For future reference, just to be clear, LDView is a rendering program that renders LDraw models in real-time. It can also export them to POV, which can then render them with higher quality. I am able to reproduce the POV export problem in those parts.

(2021-05-08, 6:40)Travis Cobbs Wrote: [ -> ]This happens on part 88293, which is the part that was included in the original bug report that caused me to fix the problem. I suspect that it happens in other parts also. I would greatly appreciate it if people would let me know if they see any regressions in LDView's curve smoothing.

Note: because of this new behavior, I expanded the angle over which curves can be smoothed. 

Much appreciated changes. I'll keep my eyes peeled to see if this causes other problems.

(2021-05-10, 7:32)Philippe Hurbain Wrote: [ -> ]Much appreciated changes. I'll keep my eyes peeled to see if this causes other problems.

Thanks. Just to be clear on the change, I updated the code that processes conditional lines for use in smoothing, and made it so that if there is an edge line in the same place as a conditional line, it ignores that conditional line during smoothing. This was a relatively minor change, and while it will affect file loading somewhat when smoothing is enabled, hopefully it won't be much. Also, it means that if an edge line partially overlaps a conditional line, the conditional line will still be included in the smoothing calculations.

I've encoutered a similar problem after exporting a part to pov today : 19474-f3, some triangles weren't corectly exported or rendered.

In fact the problem is on the subpart : u9418
it seem that four 1-16ndis.dat are cut by the x/z plane and that the +y pixels aren't rendered.

Once again, inlining the primitive using LDDP solved the issue.

(2021-05-17, 20:26)Bertrand Lequy Wrote: [ -> ]I've encoutered a similar problem after exporting a part to pov today : 19474-f3, some triangles weren't corectly exported or rendered.

In fact the problem is on the subpart : u9418
it seem that four 1-16ndis.dat are cut by the x/z plane and that the +y pixels aren't rendered.

Once again, inlining the primitive using LDDP solved the issue.

Thanks. I'll investigate. The previous chrd issue was caused by the clipping plane needing to swap to the opposite side of the origin for all chrd primitives that were more than half circles, so the fix was easy. (Note that this was always broken.) Hopefully this is a similar issue, with a similar fix.

(2021-05-17, 21:17)Travis Cobbs Wrote: [ -> ]Thanks. I'll investigate. The previous chrd issue was caused by the clipping plane needing to swap to the opposite side of the origin for all chrd primitives that were more than half circles, so the fix was easy. (Note that this was always broken.) Hopefully this is a similar issue, with a similar fix.

The fix for this turned out to be a lot more complicated, but I was able to make it work. It will be fixed in the next release.

What is happening here?

https://www.ldraw.org/cgi-bin/ptdetail.c.../12818.dat



The primitive substitution on this mixed-mode primitive is not made correctly. The issue is visible on the PT image, but when I open the part in the 3D preview it looks Ok. And it also looks good on my screen until I turn on the prim substitution in LDView.

It's also looking good on a pov-ray image.

[attachment=6551]

Indeed... Looks like a scaling issue, the torus is still there but too small.

(2021-06-02, 16:22)Philippe Hurbain Wrote: [ -> ]Indeed... Looks like a scaling issue, the torus is still there but too small.

To me, it looks like it is replaced with something completely different.

(2021-06-02, 16:26)Magnus Forsberg Wrote: [ -> ]To me, it looks like it is replaced with something completely different.

No, it's just that minor radius is not properly scaled (major radius looks OK)

(2021-06-02, 16:52)Philippe Hurbain Wrote: [ -> ]No, it's just that minor radius is not properly scaled (major radius looks OK)

I'll investigate. This isn't a new problem, as it affects old versions of LDView also. Having said that, "mixed mode" torus primitives (with a "tm" prefix) don't show up in the official primitives reference, and while LDView supports them, I don't remember how their filename is supposed to be formatted. I don't know if this is a case where the unofficial file tm04o2000.dat is broken, or LDView's parsing of its filename is broken. I would appreciate it if somebody pointed me to an explanation of how the filename is formatted. Also, these should be added to the official primitives reference.

(2021-06-02, 22:50)Travis Cobbs Wrote: [ -> ]I'll investigate. This isn't a new problem, as it affects old versions of LDView also. Having said that, "mixed mode" torus primitives (with a "tm" prefix) don't show up in the official primitives reference, and while LDView supports them, I don't remember how their filename is supposed to be formatted. I don't know if this is a case where the unofficial file tm04o2000.dat is broken, or LDView's parsing of its filename is broken. I would appreciate it if somebody pointed me to an explanation of how the filename is formatted. Also, these should be added to the official primitives reference.

I found this:

https://forums.ldraw.org/thread-22187-po...l#pid25384

Unless I'm misreading, the unofficial file tm04o2000.dat is mis-named. I believe that LDView is behaving correctly, and the file should be named rm04o2000.dat.

The name tm04o2000.dat describes a torus with a minor radius of 0.2 LDU, not 2 LDU like this file's header comment indicates. The name rm04o2000.dat represents a torus with a minor radius of 2 LDU.

(2021-06-02, 23:03)Travis Cobbs Wrote: [ -> ]I found this:

https://forums.ldraw.org/thread-22187-po...l#pid25384

Unless I'm misreading, the unofficial file tm04o2000.dat is mis-named. I believe that LDView is behaving correctly, and the file should be named rm04o2000.dat.

The name tm04o2000.dat describes a torus with a minor radius of 0.2 LDU, not 2 LDU like this file's header comment indicates. The name rm04o2000.dat represents a torus with a minor radius of 2 LDU.

It's file name is consistent with official files:
https://www.ldraw.org/cgi-bin/ptscan.cgi...ope=header

It's dimensions, however, are not correct.

(2021-06-03, 1:10)Orion Pobursky Wrote: [ -> ]It's file name is consistent with official files:
https://www.ldraw.org/cgi-bin/ptscan.cgi...ope=header

It's dimensions, however, are not correct.

Its filename is consistent with a torus with minor radius of 0.2 LDU (which is what you see in LDView with primitive substitution enabled). Since its geometry has a minor radius of 2 LDU, it seems clear that the intention was for this to be an "rm" torus instead of a "tm" torus. (Changing the first letter from t to r results in the correct filename for the geometry in the file.)

For what it's worth, I placed a hold vote on tm02o2000.dat stating that it should be named rm02o2000.dat.

(2021-06-03, 4:54)Travis Cobbs Wrote: [ -> ]For what it's worth, I placed a hold vote on tm02o2000.dat stating that it should be named rm02o2000.dat.

Agreed, primref makes it clear:

Quote:This suite of primitives are used to generate circular torus sections. By default all these primitives produce a torus with a major radius of 1LDu, so typically need to be scaled up in the {x} and {z} dimensions. The first character denotes whether the minor radius is smaller than (tff primitives) or larger than the major radius (rff primitives). The latter are termed reverse ratio tori.

So, a single, incorrect letter in the name caused this behaviour, and I'm the first one to create a reverse ratio mixed-mode torus primitive.

Using the LDraw Torus Generator can sometimes be tricky. Here it obviously didn't generate a correct file name, and I missed that.

I have asked Chris to rename the primitive.

Why doesn't the curve quality slider have any effect on the mixed-mode primitives?

I'm not so sure of this mix of normal resolution inside and hi-res outside is a good idea anymore.
The normal resolutions stays normal and is not replaced when I turn on the prim substitution on a mixed mode primitive.

[attachment=6554]

And I can't use a ring prim on the side. I have to use a tang prim to stay adapted to the fixed mixed mode prim.

(2021-06-03, 21:41)Magnus Forsberg Wrote: [ -> ]Why doesn't the curve quality slider have any effect on the mixed-mode primitives?

I'm not so sure of this mix of normal resolution inside and hi-res outside is a good idea anymore.
The normal resolutions stays normal and is not replaced when I turn on the prim substitution on a mixed mode primitive.



And I can't use a ring prim on the side. I have to use a tang prim to stay adapted to the fixed mixed mode prim.

The curve quality slider should affect mixed mode primitives. Up until the point where the quality is higher than 48 segments, the lower quality portion should increase in segments as the quality goes up. Once you get past 48 segments, both dimensions should go up together. (At that point, the mixed mode primitives should look identical to non-mixed ones.)

Note that due to a bug fix in LDView 4.4 Beta something, I think that half of the quality notches don't do anything. (The notches go up 8 segments at a time, but that caused problems, so I changed them to round up to the nearest 16 except for the bottom notch.)

Also, a point of clarification. LDView's curve quality setting doesn't have any effect at all on normal 48 primitives until you get it to the point that it is set to greater than 48 segments per circle. So, up until then, 48 primitives continue to look the same. Then once you get past 48 segments per circle, the 48 primitives improve in quality and look identical to the normal 16 segment primitives. And the mixed torus primitives have their 16-segment sections increase in quality while their 48-segment sections stay the same.

(2021-06-03, 22:22)Travis Cobbs Wrote: [ -> ]The curve quality slider should affect mixed mode primitives.

As seen on my image above it has no effect on the reverse ratio mixed mode primitive,
but I can see that it works on other "normal" mixed mode prims.

(2021-06-04, 14:37)Magnus Forsberg Wrote: [ -> ]As seen on my image above it has no effect on the reverse ratio mixed mode primitive,
but I can see that it works on other "normal" mixed mode prims.

I will investigate. I tested with a normal one, not a reversed one (since I didn't have a part with a reversed one handy). It should work the same for both, so if it doesn't, it is a bug that I will fix.

(2021-06-04, 14:37)Magnus Forsberg Wrote: [ -> ]As seen on my image above it has no effect on the reverse ratio mixed mode primitive,
but I can see that it works on other "normal" mixed mode prims.

I found the problem for rm primitives, and have fixed it in my local build. I will be releasing another beta (hopefully the last) RSN. (I thought that 4.4 Beta 4 would be the last beta, but I've made some changes that are big enough that I want one more test release.)

(2021-06-05, 1:15)Travis Cobbs Wrote: [ -> ]I found the problem for rm primitives, and have fixed it in my local build. I will be releasing another beta (hopefully the last) RSN. (I thought that 4.4 Beta 4 would be the last beta, but I've made some changes that are big enough that I want one more test release.)

LDView 4.4 Beta 5 has now been released and fixes this.