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: 9005


Replies to This Discussion

Great news!!

This is one of the most useful plugins

Thank you Andrew,

Thanks Andrew !

Sounds great!!! I am curious about the new block-functions! Curves and points in heads up display is another feature I have been waiting for! Keep up the good work!

They're really great Andrew, I know I'll keep enjoying/using these a lot.
Thank you!

This is really an amazing set of tools you've developed. Keep up the great work Andrew and THANK YOU!  

Plot Weight attribute acquisition is broken. The proper setting is in fact Print Width anyway. Plot Weight is only mentioned in Rhino docs as being part of a Layer State saving file.

Your LayerTable component can grab the layer Print Width settings, but that won't grab individually assigned curve Print Width settings, nor directly connect the found weights to each curve found by ObjAttributes.

I'm trying to create Grasshopper based previews of standard layer palette Print Widths to emulate Adobe Illustrator since Rhino Print Widths as well as individual curves assigned with different display types are just screen sizes, not zoom affected model widths.


OK PW ("Print Weight" = Print Width) is actually working when I use the Rhino properties tab to override the layer Print Width setting that have attached to an object, but when I switch the pop-up menu back to By Layer, it retains the custom value instead of even switching back to zero. This is a buggy drag since it gives the wrong answer of what an object really has as a Print Width.

Is this a Rhinocommon issue or something you can fix? I'll have to play with Python to find out I guess if you don't get back to me.

The relevant Rhinocommon entries are for PlotWeight, there being no Print Width entries:

An example of Python for setting PlotWeight is here, where rd is Rhino.DocObjects:

attr.PlotWeightSource = rd.ObjectAttributes.PlotWeightSource.PropertyType.PlotWeightFromObject

attr.PlotWeight = plotWeight

The FabTools plugin ( )has a similar geometry pipeline component and object attributes component, one that uses GUID between the two, and it has the exact same behavior in which only manually assigned Print Widths affect the so-called PlotWeight result in Grasshopper. Damn, so can it even be done? It also sticks with the old manually assigned number even after I switch back to By Layer:

I'll post a link to my question here over at FabTools too.

It should be doable. Lemme take a look tomorrow.

Hi Nik - the attached build fixes the issue.


Great response time, thanks!

Was this a simple fix or is Rhinocommon itself failing to update the value when By Layer is used in the Properties palette and you had to create a workaround?

Now that it works, I realize that your custom preview, which oddly enough is 0.25X too thin compared to the Print Preview viewport display option, is similarly a *screen* width not a real geometry preview that I can zoom out and see get skinnier. So I haven't created an Illustrator-like line width preview after all. When I multiply Plot Width by 4 I get the same thing as Rhino print preview mode.

Must I create memory hogging surfaces from my lines? Even then, when they overlap, they just bug out since they are using render meshes on top of each other with much confused bleed through and moiré effects.

I also have to issue a Recompute menu command to get it to update, despite your component being called Dynamic Geometry Pipeline.






  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service