New version of Human for download

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.

Attachments:

HumanTreeFrog.zip, 143 KB
ExampleFiles.zip, 1.9 MB

Replies to This Discussion

Permalink Reply by Frane Zilic on October 24, 2015 at 8:47pm

Great news!!

This is one of the most useful plugins

Thank you Andrew,

Permalink Reply by Olivier Suire on October 25, 2015 at 1:41pm

Thanks Andrew !

Permalink Reply by Martin D. on October 25, 2015 at 1:58pm

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!

Permalink Reply by Pieter Segeren on October 25, 2015 at 2:31pm

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

Permalink Reply by Tim Halvorson on November 1, 2015 at 3:23am

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

Permalink Reply by Nik Willmore on January 9, 2016 at 9:27pm

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.

Attachments:

2015_human_examplesBROKEN_PRINT_WEIGHT.gh, 16 KB

Permalink Reply by Nik Willmore on January 10, 2016 at 12:14am

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:

http://4.rhino3d.com/5/rhinocommon/?topic=html/P_Rhino_DocObjects_O...

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

http://atlv.org/education/ghpython/#4

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

attr.PlotWeight = plotWeight

Permalink Reply by Nik Willmore on January 10, 2016 at 1:34am

The FabTools plugin ( http://www.grasshopper3d.com/forum/topics/fabtools-for-grasshopper )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.

Permalink Reply by Andrew Heumann on January 10, 2016 at 1:36am

It should be doable. Lemme take a look tomorrow.

Permalink Reply by Andrew Heumann on January 10, 2016 at 9:38am

Hi Nik - the attached build fixes the issue.

Attachments:

Human.gha, 353 KB

Permalink Reply by Nik Willmore on January 12, 2016 at 4:28am

Great response time, thanks!

Permalink Reply by Nik Willmore on January 12, 2016 at 6:49pm

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.