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

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

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

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

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

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

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

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

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

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

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

https://forums.ldraw.org/thread-22187-post-25384.html#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-03, 1:10)Orion Pobursky Wrote: It's file name is consistent with official files:
https://www.ldraw.org/cgi-bin/ptscan.cgi?q=tm0&scope=header

It's dimensions, however, are not correct.

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

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.

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

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

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

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

(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.)