This is probably the difference between 1 pixel width and 2 pixels wide. You may want to try the Rhino 8 WIP. PrintDisplay has been modified to display thicknesses in model distances and you can apply a scale to it. This should allow for gradual changes in thickness instead of the abrupt change you are currently seeing
It is okay to just admit that somethings get overlooked or not properly implemented.
This is NOT a 1 pixel difference, (note the arrow sizes too). In any case, pixel display should be proportional to line weight thickness. This means that 0.37 can’t be 1 pixel wide, because then 0.13 gets to be 0 or 1 again.
Also, it does not follow that 0.37 and 0.38 get a visible difference of 1 pixel. The math is wrong. And this is basic math we are talking about here.
not test if anything was updated for the last SR’s … but for me it does not only look like a “how is line width or weight” displayed on screen vs. paper.
In the post above i created some lines in rhino and checked the result in Adobe Ilullustrator and Affinity Designer…
for me it looks like line width below certain threshold are rounded up somewhere between the actual properties of the curve in Rhino and the output in the pdf.
thanks for improving this aspect for screen and for pdf export.
Hi Tom, sorry I have not looked at the other topic yet. I was trying to answer a question about PrintDisplay while waiting at the dentist office (which is why I wrote “probably”) and now I’m wishing I didn’t.
I bookmarked your post and will try to investigate
The old PrintDisplay code rounds values to whole numbers since it uses some older functions in Rhino that require whole numbers as input. When the value jumps from 1 to 2, the arrow size will be double. We also force any value less than one to be one which is why very thin items don’t seem to change
This new fancy code you have now for scaling… could you copy>paste it into the ‘ViewCapture’ command’s folder?
Look what happens currently when we upsample a viewcapture, it looks nothing like what we see on the viewport anymore. And that is never what we intend to do when we want higher resolution output from viewports’ content.
I see. Although it does not help, luckily I am actually very keen about the inner workings of Rhino. Some other user might interpret you are trying to defend the current state of things.
If doubles were not an option back then I think you should have assigned 1 pixel to each line weight.
0.10 = 1 pixel
0.20 = 2 pixels
0.30 = 3 pixels
I also don’t see the correlation between the scaling factor of arrow and pixel width: You could have chosen any sequence an interpolate the values across the different line weights. Or is scale factor also limited to Integers? In that case just use 1, 2, 3, 4, 5 etc for every other line weight. In any case, for what I had read Arrow command has never been robust.
Like I said, or bad implementation or limitation. Same thing for the user.
I guess Illustrator is just making magic then… must be splitting pixels in half or something…
I sometimes feel you guys forget what it is to be an user. Most don’t really care about the why’s or how’s, we just want it to work as expected.
Do I want to know why it doesn’t work? No.
Do I want to know how Rhino is doing stuff? No.
An acknowledgement from your part would be very much more welcomed than technical excuses.
Something along the lines of:
“I see this, and it should work as you describe. If you care, the reason it does not has to do with old Rhino code never getting updated to new technology and stuff. I am sorry you are facing this issue but I am afraid nothing can be done to solve this right now… Will probably be fixed in Rhino 8”.
Instead of this:
‘Working’ for who? Definitely not for the user. I don’t know what is worst, this being a bug or actually intentional…