Print Problems

I have a file with four layouts, each has a single detail view showing the model from a different angle using the “Rendered” view setting. Attempting to print or save to PDF using the print dialog causes Rhino to crash. Tried the following:

  • Change all detail views to Wireframe (prints OK)
  • Change all detail views to Pen (still fails)
  • Change paper size (same issue)
  • Change print driver (same issue)

Have also noticed the performance of the View Capture to File and View Capture to Clipboard commands is super error-prone in R6 for Mac Beta, wondering if this could be related somehow? I’ve been getting results with random white streaks through the image (when using “Scale” other than 1) and objects rendering as solid black instead of a normal display color or rendering material when using Transparency.

from “Rhinoceros Information”:
Rhino 6 SR16 2019-6-4 (Public Build, 6.16.19155.12084, Git hash:master @ cc3dd299fd2baa25b3a14b0498296db9526ae6fd)
License type: Beta, build 2019-06-04
License details: Stand-Alone
Expires on: 2019-07-19

Apple Intel 64-bit macOS Version 10.14.3 (Build 18D109) (Physical RAM: 8Gb)
Mac Model Identifier: MacBookPro11,1
Machine name: Carsten’s MacBook Pro
Language: en-US (MacOS default)

Intel Iris OpenGL Engine (OpenGL ver:4.1 INTEL-12.4.7)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height

Vendor Name: Intel Inc.
Render version: 4.1
Shading Language: 4.10
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 1536 MB
Graphics: Intel Iris
Displays: Color LCD (256dpi 2x)

Graphics processors
Intel Iris (1536 MB)
Color LCD (1440 x 900)

USB devices
Apple Inc.: Apple Internal Keyboard / Trackpad
Apple Inc.: Bluetooth USB Host Controller

Bluetooth devices

Third party kernel extensions

Third party plugins

Rhino plugins
/Applications/ “RhinoCycles” 6.16.19155.12084
/Applications/ “Snapshots” 6.16.19155.1002
/Applications/ “Grasshopper” 6.16.19155.12084
/Applications/ “PanelingTools” 6.16.19155.1002
/Applications/ “Commands” 6.16.19155.12084
/Applications/ “Renderer Development Kit” 6.16.19155.1002
/Applications/ “RDK_EtoUI” 6.16.19155.12084
/Applications/ “Displacement” 6.16.19155.1002
/Applications/ “IronPython” 6.16.19155.12084
/Applications/ “Rhino Render” 6.16.19155.1002

After turning off GPU Tesselation in Preferences and turning Antialiasing down to 2x, printing doesn’t immediately crash Rhino but the system eventually runs out of memory while the print processes:

Hi @Carsten_Rodin,

We’ve recently improved both memory handling and ViewCapture/Print commands on Mac and Windows Rhino 6. Please download the very latest Mac v6 version and test printing again. If you are still having problems we’d really like to try to reproduce the issue by testing with your model.

Rhino for Mac 6 BETA:

Updated to the latest BETA, thanks for the link. Still getting funky results from View Capture to File. This is the output file with a scale of 2…

…when the screenshot looks like this:

Using the same file (attached) I can print a wireframe detail view just fine (completes in a few seconds) but attempting to print to PDF, on a Tabloid-sized layout in the same Artistic view causes Rhino to crash.

1100 Myrtle Ave.3dm (9.7 MB)

I’ve been getting some odd result printing from a Layout Detail that is in Arctic display mode.
I deleted my PLIST and it sorted my issues.
It will wipe out your customizations but it may be worth a try:

  1. Quit Rhino
  2. Launch Terminal
  3. Type defaults delete com.mcneel.rhinoceros.plist and press enter.
  4. Wait for a moment until another $ appears. Quit Terminal.
  5. Try again

Any luck?

This fixes the print issue! Takes quite a while still but eventually manages to save a PDF as expected.

Still experiencing the same issue with View Capture to File, however.

Thanks for checking and I’m glad it sorted your printing issue.
Hopefully this will be another clue for @DavidEranen and the other developers to find the problem.