algorithmic modeling for Rhino

It's been more than a year since the last release of Human - so I'm excited to share with you the latest version, packed chock-full of new functionality. See the release notes for details on the new features. A few of my favorites:

  • Ability to define / modify block definitions on the fly
  • Ability to embed user data into object attributes, and read it back out
  • Screen-oriented mesh and screen-oriented text for custom glyphs/sprites that always face the viewer
  • Custom per-vertex texture mapping
  • Absolute scale for lineweight, allowing you to set a line's thickness to a constant dimension of 2 meters, for instance - it will scale as you zoom in and out.
  • Curves and Points in "heads up display" components
  • All new example files + documentation

Download the components below! They will also be available on food4rhino as soon as they're approved.

Views: 8184


Replies to This Discussion

Hi Nik - what you say is strange. My Python absolutely adds an autocomplete when I type x. when the input is a color (even without a type hint). 

Also, I think you're mistaken - the color type coming out of the parameter is not a Color4f but a GH_Colour, which gets auto-unwrapped to its simple System.Drawing.Color type when you pass it through the python input (I believe). 

Andrew, indeed the pop-up menu hint for colors does kick in if I first input a color into the 'x' input of Python, and it's specific to 'x' and doesn't appear for the orphan 'y' input, so the system is being smart. I didn't expect to ever see this since it seemed so generic to just be assigning a value in the Python realm!

THANKS SO MUCH FOR THE PLOT COLOR UPDATE!!! With your help my overall Grasshopper program is becoming elegant instead of confusing.

"Monkey see, monkey do." - Nik

I recall the steep learning curve merely for Python's right click menu of data access options and type hints, but also the not-in-the-manual-since-there-is-no-manual means of adding new inputs/outputs by zooming way into the canvas view to see those little +/- buttons appear out of nowhere!


As always I love all the new inventive features.

However I think the render to screen components badly lack a name input to specify (a) target viewport(s).

Also normalized coords would be great, Or a component that gives the viewport properties so we can remap.

I see Doc.View gives the rhinoViews, and we need the ActiveViewport of each (Why is it so complicated?).

Saddly I forgot everything I knew about VB or C#...

Hi Fred, the viewport filter is accesable via the components context menu (right click)

Pieter beat me to it! All my custom display components including the render to screen components support this viewport filter - note that it also supports wildcards (*, ?) so you can specify multiple viewports together.

The problem with normalized coordinates is that it winds up being tied to the aspect ratio of the viewport - if you have a square viewport it will position one way, and a long horizontal one another. I think the script to get the viewport properties is an easy one, here's a c# example:
A = RhinoDocument.Views.ActiveView.ActiveViewport.Bounds;

That bounds object can be converted easily to a rectangle so you can get its height and width separately (or just pass .Width and .Height to separate outputs)

All my custom display components including the render to screen components support this viewport filter

had i known this earlier. don't really understand how i missed this right click option.

just to add that for multiple viewports square brackets are needed [1,2,3,4]

Fred - the next release will include a way to retrieve the size of a viewport so as to permit you to construct your own normalized coordinates.

that will make things really easier, for text to screen.

if there is an upcoming release, please consider adding the viewport filters as inputs, so that they can be triggered with if events, if its doable without problems.



Feature requests:

(1) Dynamic Geometry Pipeline (DPipeline) returns objects in the order they were created, newest on top. But to use layers as an organizing principle, I'd like the option to have the output be sorted by Layers palette order instead. This means I can work on a document and use layers for Illustrator-like stacking when I make 2D graphic art output from my objects.

(2) The LayerTable component of your plugin also fails to return layers in the stacked order they exist in the Layers palette, but alphabetizes them instead, so I lose the info needed to sort objects by layer order.

(3) Right now ObjectAttributes visibility output ignores items hidden by turning off a layer, so it's not being honest in a street smart sense. Your LayerTable component does have visibility info though, so I can kludge away to build my own filter. Ideally I need two filters for the pipeline itself, to filter out (a) hidden objects and/or (b) hidden layers.

The native Geometry Pipeline of Grasshopper has a right click option to filter out hidden objects, but it also happens to be broken and destroys the output ( ).

There's a Group by Layer option as well, but it also seems to alphabetize the layers instead of abiding by their real order.

It won't grab text either, like yours will.

Obtaining the user interface layer order was a thorny issue, here in 2013 for the developer of the Rhino madCAM plugin, so McNeel updated Rhino to fix it:

To obtain the Layers palette actual layer order information, you use Rhinocommon SortIndex, since merely finding the layers list comes back alphabetized:

However, the layer list also includes deleted layers for Rhino to access for undo commands, so you must also test for those to get the real layers:






  • Add Photos
  • View All

© 2023   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service