I’m trying to print to a bitmap at a specific resolution, for use as a texture file. See attached print-screen.
If I set the scale to 2.0 dot/cm it seems to print at 1.97 dot/cm (i.e: exactly 5.0 dot/inch)
Solution: the dialogue should show the resolution it can print at, i.e: convert the value to DPI, round it, then back to dot/cm and show that in the dialogue, for example show 1.968504 instead of the original 2.0
Similarly, if I set the scale in dot/inch, changing from 5.0 to 5.1, 5.2, 5.3, 5.4 DPI makes no difference in the preview, while 5.5 dot/inch does affect the preview (and presumably the output file)
Solution: the dot/inch dialogue should not accept decimals if those are not supported.
Possibly related, If I set it to 1.0 dot/cm, it actually prints at a about 1.2 dot/cm, and when opening the print dialogue again, it shows 1.2 dot/cm as previous scale, instead of the entered 1.0.
Having the drawing units in meters or mm does not seem to make a difference.
I prefer the scale to be accurate, but if the rounding to whole DPI’s is unavoidable, it would help if the dialogue was more clear about the scale it is actually going to use when printing to the bitmap, or at least indicate that the setting is “approximate” when using dot/cm or decimal dot/inch.
“Printing” to a bitmap seems like a very strange workflow, I’m not sure why this exists, there’s no way it’s intended for what you wnant to do. Just Render, screen/viewcapture to the precise resolution you want.
DPI doesn’t really mean anything when you have the resolution set. If you want higher DPI you essentially render to a higher resolution. I’m sure there are tools out there with which you can change the dpi number in an image.
Why do people care about dpi? It’s just a number in the file, you can change it in 2 seconds, and what does it have to do with making a texture? All it affects is the default size you get if you try to print it…whoopie.
I do not want to spark a deep discussion and I also don’t remember what I had here this morning with 72 dpi.
Certainly, reducing pixel loss is @j.stolk intention here.
But for me all values are relevant also DPI, probably it is my ignorance.
When I do the math here, my calculation gives rounded 650 x 386 pixels,
this is about Edit percentage 1.5% (or rather 1.6%) percent less than what Rhino shows here.
I also think, I know where this comes from.
Again what does the ‘actual measurement’ matter? It’s just X pixels by Y pixels. It’s like what is the actual workflow going on here that people are a)using the print-to-bitmap feature, which has no reason to exist for anyone who wants to make a raster image, and b)so concerned about a dpi number? What are you doing??
You’re not getting what I’m saying. Using the ‘print to bitmap’ feature, and using it to make a texture, and fussing over DPI settings, is baffling. Sense, it makes none. What is this being used for, what is the end goal? It seems like it’s part of a workflow out of last century.
Uch, I parked here wrongly.
(
Title and 99% of the first post refers to “Print scale rounded to whole DPI” and you are talking about textures.
Then all is said
DPI is used to determine how many pixels to use for things like curve thickness and dash patterns. Beyond that it probably isn’t important for things like making textures.
I indeed don’t care about the DPI value in the image file, I only care about the scale of the image. I use the image to project my 2D Rhino drawing on a 3D object in ParaView. In my case the ParaView scripts are setup to assume the image scale is 2 pixels/cm.
So a 45m line in Rhino should end up as 9000 pixels in the output image.
I originally used 1 pixel/cm and the scale of the image was off by a very noticeable 20% because the 1 dot/cm = 2.54 DPI was rounded up to 3 DPI without any feedback.
The incorrect or lack of feedback in the dialogue was my main concern.
Only the second time I output an image the dialogue shows that the previous output was closer to 1.2 pixels/cm instead of the 1.0 pixels/cm that I had entered.
Even when set to dot/inch the entered values seem to be rounded to whole DPI’s while the dialogue does accept and show decimal numbers for the dots/inch setting.
(I have not tested if this happens for all image formats)
@j.stolk
You are driving in the wrong direction here.
2 pixels should represent a part, it doesn’t matter if it is a 1cm 1m apple or egg.
The previous speakers have said it all.
Your problem is exactly in dependency with:
SafeFrame → Action Area , by default there is - 10% border
Factor in ZoomExtends, by default the value is 1.1
You just have to decide, “save with border” or “without” !
Example with border (default settings)
Command _ZoomExtends
Capture with 9000px + 10%
Example without border
SafeFrame → Action Area 100%
Command _-SetZoomExtentsBorder …Factor 1
Command _ZoomExtends
Capture with 9000px
Thank you for this method. Currently the exact extends of my drawing varies a lot, depending on text objects, etc. (the 45m/9000px line is not the only thing in the drawing) and I would need to manually change the pixel size every time the extends changes to maintain the correct scale. I could maybe add a some small/inviable border to have a more constant extends size.
I have created a script, a mix in old Rhinoscript (RVB)
The script converts your units to pixels,
changes the viewport size accordingly (units to pixels),
zooms the selected objects to the border,
exports them with the desired scale factor,
for export _CaptureToFile is used,
after export the viewport size reverts back to the original size.
! Pay attention
_SetZoomExtendsBorder should be at 1
Minimum unit distance in viewport should be at 10 ( So 10px)
! Pay attention aggain
For example: If an object have 10000 units (e.g. 10000m), script will try to scale Viewport to 10000px.
Therefore do not overdo it.
This script can be put in a button,
to do this, apostrophe in line 1, 2, 74 must be removed.
'! -_RunScript
'(
Option Explicit
Call PrintPx()
Sub PrintPx()
Dim strView, sFactor, arrViewSize, arrRect, strObjects, dblDistanceX, dblDistanceY, arrLResult
strObjects = Rhino.GetObjects("Select objects for scale print", 0,, False, True)
If Not IsNull(strObjects) Then
arrRect = Rhino.BoundingBox(strObjects)
sFactor = Rhino.GetInteger("Change Scale Factor, default", 200, 1) 'Change default Scale Factor here
If IsArray(arrRect) Then
dblDistanceX = Rhino.Distance(arrRect(0), arrRect(1))
dblDistanceY = Rhino.Distance(arrRect(0), arrRect(3))
arrViewSize = Rhino.ViewSize
If IsArray(arrViewSize) Then
If Not IsNull(dblDistanceX And dblDistanceY) Then
Rhino.Command("-_ViewportProperties _S " & Rhino.Floor(dblDistanceX) & " " & Rhino.Floor(dblDistanceY) & " _Enter")
arrLResult = Rhino.LastCommandResult
If (arrLResult = 0) Or (arrLResult = 2) Then
strView = Rhino.CurrentView
Rhino.ZoomSelected strView
Rhino.Command "_SelNone"
Rhino.Command("-_ViewCaptureToFile _W=" & dblDistanceX & " _H=" & dblDistanceY & " _S=" & sFactor & " _L=No _B") ' Here Paramater for Export
arrLResult = Rhino.LastCommandResult
If arrLResult = 0 Then
Rhino.Command("-_ViewportProperties _S " & arrViewSize(0) & " " & arrViewSize(1) & " _Enter")
Rhino.ZoomExtents strView
Else
Rhino.Command("-_ViewportProperties _S " & arrViewSize(0) & " " & arrViewSize(1) & " _Enter")
Rhino.ZoomExtents strView
End If
End If
End If
End If
End If
End If
End Sub
')
