Solar analysis of Leshan topography
As I’ve been working increasingly within Grasshopper, I’ve gotten more and more reluctant to go through convoluted workflows to produce and process images. The prospect of baking and rendering, processing and exporting a Make2D, distributing lineweights, compositing layers and adjusting color balance has become more offputting than it already was. Beyond an aversion to rendering, I’m also quite keen on Matthew Allen’s argument that the screenshot inhabits a realm that combines the finalized aesthetic product of print representation and the intimate process orientation of computing in a way that conveys both the objective result and the prospective possibilities of computational design.
However, I also can’t ignore the part of my brain that learned how to lineweight during hundreds of hours bent over a sheet of mylar with a rapidograph back when I began architecture school. Against this ingrained standard of judgment, Grasshopper has always provoked a cringing aesthetic engagement. This was especially true in the earliest days when there was no alternative to the red-green preview (this was especially grating when compared with the elegance of Generative Components at the same time, or even CATIA’s clumsy khaki-on-purple-gradient).
Perforation Attractor Definition from 2008, circa GH0.1
Since then, of course, Grasshopper has consistently added customizing options to the interface and output to the point where the red-and-green screenshot has—happily—lost the signifying caché of “parametric design” and gone back to the connotation of simple or introductory-level work that it usually represents in practice, today. Still, the available screen options remain somewhat unsatisfying, lacking the desired graphic engagement.
Currently, the best solution to this problem is probably the Human plugin, and in truth, the definition I’m posting here doesn’t do anything that Human can’t also (in fact, I went looking in the Human code for guidance from time to time). On the other hand, I tend to prefer script components that I can dig into and edit directly to compiled plugins, and there is not so much documentation out yet for accessing the grasshopper DisplayPipeline in ghPython.
In particular I’ve found the variable lineweight script to be extremely helpful in conjunction with high resolution screens or large View Captures ( -‘_ViewCaptureToFile B ) to prevent the lines from completely disappearing, but also to give the images more depth. Also included in this definition is a planar texture mapping for meshes that allows a nice continuity across multiple surfaces when using a pattern, like a hatch, for the diffuse and transparency bitmaps. Finally, I also put together a script for drawing graphic callouts on the front plane of the viewport with consistent pixel dimensions giving them the appearance of graphic overlays. The ViewTrigger script prompts a redrawing whenever the camera location changes, keeping the popup windows in place on the screen while also saving grasshopper from the lag of redrawing them continuously. These popup windows can be texture mapped with an image file like the clock graphic in the image at the top of this page or combined with other grasshopper components like the 3D Text Tag in the image below.
Custom Display Pipeline
Not every element of the DisplayPipeline has been implemented here. In particular one should note that this component will display anytime the boolean toggle is set to True—even when the component itself has its Preview setting turned off, when the canvas is switched to a different definition, or the grasshopper window is closed without exiting the plugin. Further investigation of the different document events is needed. There also seems to occasionally be some interference when two or more of these scripts are active at once. I haven’t been able to isolate the cause yet, but toggling the misbehaving one on and off usually fixes the problem.