I work a lot with view capture to files, and so sometimes I edit the line weights just for display purposes. Make some things more clear, create some differentiation among a group of lines, etc.
I noticed that when Print Display is ON, there is no noticeable difference between 0.0mm and 0.35mm
Shouldn’t this be progressive?
Precisely speaking there seems to be a HUGE jump from 0.37 to 0.38
Can someone please look into this? It is very annoying to not have viewport feedback on such obvious line weight changes…
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.
Ai gets is right.
But w/e I am not buying Rhino 7 which I don’t need to download a WIP so that my viewport displays line weights correctly. Pretty amazing its taking you 8 iterations to get this right.
But thanks for the reply Steve, at least after 2 weeks I know now not to expect a solution and assume this as a limitation.
You are quibbling about a working display mode approximation!
Did you actually print it on a decent resolution printer and look at it on paper?
I share screen and show to clients, live, inside Rhino.
I never said PDF printing was off. That probably works fine. But it is also very hard to work and get a PDF right when you get not viewport feedback, practically guessing lineweights.
It like changing colors in layers and not having the viewport show colors, but instead you need to print to see how it will turn out. And then based on that make changes.
Edit: print on paper? You are in the past John.
Then you do non understand that your computer screen is a much lower resolution device than your printer or a PDF file.
Why do I need to understand that? Why is that even relevant? This has nothing to do with printers.
I showed Illustrator displaying OK. That it the way it should work inside Rhino viewport…
Why is so hard to admit this got overlooked? It is not working right. The very fact you are changing it in WIP 8 proves it…
Nevermind, this is not use for anyone. The matter is settled.
Best Screen and Print Resolution | Modern Postcard(or,a%20resolution%20of%20300%20PPI.
There are 25.4mm per inch.
You monitor is probably a 72 DPI resolution device.
25.4 / 72 is 0.35mm
Your display drivers can “enhance” the display by dithering pixels to smooth things out, but that explains why there is no visible line width change on the screen below 0.5mm print width.
Dear @stevebaer and dear @John_Brock
did you have a look at the other topic i posted already above ?
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.
kind regards -tom
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
Hi John,
Kind of true… back in 2005, when this gorgeous thing could do 85 pixels per inch.
Now, in 2022 this is what a thin Dell Precision (XPS like) displays in their 15" 4K monitor:
And a typical 4K 27" monitor is still very pixel-packed per inch:
case in point: there’s no way you could look as handsome as you do in this 1" profile photo I took at my 27" monitor (holding a ruler in front of it) if it had only 72 pixels wide:
Love,
G
hi Steve,
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.
Thanks,
Gustavo
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…
