Hi Remy - at present, the explode blocks component will successfully explode blocks within blocks. It operates recursively, exploding them all the way into usable geometry in one go. Do you simply need to access the geometry, or do you need to be able to somehow address all the layers of hierarchy, as in a structured data tree based on the levels of nesting for instance?

Hi Andrew, when I bake JustifiedText3d, the color is lost, that's why I keep using the cluster who published few months ago, but what seems to me useful is the script (getSystemFonts). could help me how to connect the script font to cluster? or fix this please, thanks in advance.

Erick.

Hi Andrew, 

is there a special reason why justified text takes forever, once you input grafted lists?

Thanks,

Phillip

hi Phillip -

This is a great question. To be honest I currently have no idea!! Something I'm working on. Thanks for mentioning it - Glad to know it's not only on my machine.

Hi Andrew,

Thanks for sharing this very useful plugin. Just one question- I am trying to get several blocks to orient along a surface by connecting my existing grasshopper definition originally made for a brep to the one that you describe in "create block instances to Rhino." Everything is working except for the vector that orients the brep along the surface is lost when plugged back in to boxB in the Box2Box button- that is, it just creates a block that is rotated about the z axis but distorted about the other axes. Is there anyway to plug in this information into boxB, or can boxB not be rotated about the x or y axis (this might be what you mention in the conversation with Frane below, but I am not sure if there has been an update)? Retroactively turning copied geometry into blocks would also solve my problem, although I guess this is quite a complicated task.

Thanks,

~Yuval

Hi Yuval - can you upload your definition? I'd be happy to take a look, but from your description it's hard for me to tell what the issue is. The box to box transform component requires boxes as input, which can be oriented however you want; if you give it other geometry, it will automatically calculate the world-oriented bounding box around that geometry, which might be the source of the problem. 

Hi Andrew, 

Thanks for the incredibly quick response!

I am attaching the definition and the rhino file.

Orient%20object%20to%20surface%20normal_BLOCKS.gh
Test.3dm

Hi Yuval -

As I suspected, the problem is that you're passing Breps instead of true "box" objects to the box to box transform component. When you convert a brep into a box, it calculates the world-oriented bounding box, losing all of your orientation information. If instead of converting to a brep you simply move and orient the box itself, this problem should go away.

Also, in order to avoid null bounding boxes, I would recommend either 1. making sure that all the objects on the "Grips" layer are blocks or 2. using the sort by type component to make sure you're only giving objects of type Rhino.DocObjects.InstanceObject to the BlockExplode component. 

See the attached for a working example. 

Orientobjecttosurfacenormal_BLOCKS.gh

P.S. are you making a parametric climbing wall? :)

Perfect, thanks so much!!

Coming soon....

Unbearable itches...

GOOD~Waiting for updata

404 :(

Food4Rhino is taking forever to update! Here are all the latest components - remember to delete any old versions before installing. 

Human.zip

Many many many thanks for this amazing release!! ;-)

Great work! Solves a lot of issues when interacting between GH and RH objects.

Thanks.

...though I expected you to go for this guy with the new logo:

just want to say the great tools have saved me again. 

:)

you keep saving my the time and trouble of leaving my GH comfort zone... which is both great and bad (for learning..) i guess.

so again, thanks a lot

:)

the layer table component does not reveal sub/nested layers.

i am able to get them by referencing an object on the sub-layer, then feeding that data into the attributes of the objects i wish to bake to it...

so, a silly problem with a simple workaround, but i thought i'd mention it in case no one has yet.

thanks for a great set of tools.

Hi Andrew,

Couple of questions and recommendations.

- Would be useful if the Type input of the Dynamic Geometry Pipeline accepted * so we could just reference all the geometry from Rhino

-Is there a bug with the Custom Preview with Lineweights? The line weights don t seem to change really.

Thank you

Hi doompop - you can choose "any" or "all" or "default" for the type - any and all are the same, "default" just chooses those that are enabled in the normal pipeline: points, curves, meshes, and breps. 

As far as I know the custom Preview with Lineweights is working fine - if you specify a number for thickness (in pixels) you should see it change. It is not like plot weights in Rhino which are specified in mm. 

Oh that s great!

It s not obvious because it's not included in the options of the description of the TYPE input. Thanks for the explanation.

My bad for the Lineweights. It works great. I was trying to assign it to Breps, assuming the thickness of the Brep edges could be varied in the preview. Then realized it s for curves.

Great stuff!

Thanks a lot!

@doompop - good points, both. I'll update the wording of the description and see if I can extend the custom preview to work on Brep edges as well. Should it work on mesh wires too? I'm not sure that would be desirable...

That's great!

I image it would be useful for presentation purposes and visually separating objects. I imagine it would be more complicated with Meshes as there would be outline curves and internal curves etc. but if it s something feasible don t see why not to have it!

Thanks a lot!

Andrew, quick catch. The 'surfacemap' component's description is: applies a cylindrical texture map to a mesh

Instead of a surface texture map to a mesh?

Hi Nick - thanks for the note - fixed. here's the latest: Human.gha

Thank you very much

Hi this is super awesome thank you!

Got a issue with the Hatch Pattern tho.

It looks like hatch table will not load the default patterns already loaded in a rhino file until I use/preview them once, when for example I create a hatch in the rhino environment manually. It is not a terrible problem but is kind of annoying when I'm working with a rhino object free definition (not rhino document specific) but still need to create a hatch manually before all the create-hatch to work (and if they are in a cluster already, I will have to manually open and save all of the different cluster before it will work again).

Thank you again!

Thats a great thing, thank you!

But how can I bake groups using human?

Jun - Yes, this is a known issue. Something changed in the way hatches are handled by rhinocommon. I unfortunately don't know of any workaround other than what you describe...

Philipp - you can bake groups by assigning group indices to the object attributes before using the bake geometry component. 

SWARM INTELLIGENTE from Esmaeil Mottaghi on Vimeo.

Hi Andrew,
I have a dumb question :D
Is possible have a gradient color/thickness on the same curve?
Or I need necessarily to split the curve and setting for each "subcurve" their properties?

Thanks!

hi mirko...

i think this definition can help you :)HUMAN.gh

hi Esmaeil,
thanks but I don't mean that.. What I'm trying to understand is if possible apply a gradient, color or thickness, on a curve without splitting it in a series of subcurves

不知道怎么下啊

Great plug-in, thanks for sharing it! I've just discovered a strange bug when I try to use the Custom Preview Materials component in a definition where I've clustered other components. If I try to add a bitmap to the diffuse or transparency channels, the maps fail (meaning the object previews as a solid, white material). In some cases it will accept a map smaller than 512x512 pixels. Without clustering, the component works fine with any size image. The component isn't part of the cluster or receiving data directly from the cluster. Just wanted to call it to attention. Thanks again!

Hey Andrew! Great work on this plugin. While working with the Item Selector component I noticed that the layer order doesn't match the layer structure in my Rhino file. Instead, everything is sorted in order by which they are created.. From a workflow standpoint this starts to get very confusing when my projects will regularly grow to A LOT of layers. Is it possible to have the selector match the structure from Rhino?

Hi Tim - this one-line c# script should get you a "sort index" property for all layers that you can use to sort the output of the layerTable component.

    A = RhinoDocument.Layers.Select(L => L.SortIndex);

I don't do this naturally - I use the layer index by default so that as new layers are added/rearranged, the entire order of the set doesn't change in unpredictable ways. The SortIndex changes every time you click one of the headers (Sort by color, linetype, visibility, name, etc).

Thanks for the response Andrew. So I have used the script to gather the layer indexes and sort them but I'm not sure how to apply your suggested sorting techniques. (By Material, Color, etc..) My thought or question is this: Can there be a unique identity number tagged to each layer as it is created? This way, no matter how I choose to organize my layer hierarchy in Rhino, Grasshopper can track along and not break the connection. In the example image, this simplified Rhino file is focusing on the facade development. I typically have separate top-level layers for each major component of the project similar in scale to Revit Worksets. It would be ideal to keep the flexible layer control from Rhino and have Grasshopper responding. 

- The other thought was a selective sort. So, for example, my top level layers are organized by a number (03-Facade, 04-Interiors, 05-Lobby, etc..) but then keeping the nested layers in their current organization inside.

- Final thought. Maybe I am simply overthinking this and I need to adjust my layer naming strategy from the beginning to be more methodical. What do you think?

2015-0925-Capture%2004.PNG

2015-0925-Capture%2003.PNG

Hi Andrew- I got it working. You can see in the image that I was able to extract the naming preface. The example added to brand new layers to my Rhino model tagged with "04-" and you can see how they are used to sort the data. I wasn't aware until now there was a separate text sorting component. The result in the 2 panels on the bottom right is a sorted list either by full name or layer name. This little move should really help stay organized moving forward. Thanks for helping to clear this up for me!

As I've been working and adding new layers with GH iterations, the layer will shuffle and get screwed up. How were you thinking to use the persistent layer ID to match? When the C# code gathers up the data, it was giving me an error because there were more IDs than layers to match.

Hi Andrew - loving these tools! I've been working on a definition to let me animate and render a point light along a curve, but have come across a roadblock: the CreateLight component doesn't allow access to all of a light's properties. Specifically, I'm looking to change the Decay option and to radically increase the light's intensity (giving CreateLight a maxed-out intensity of 1.0 in GH results in a light intensity of only 10% of what I need in Rhino).
Am I missing some way to alter these properties? I tried using LightProperties to grab the attributes of an existing reference light, but the intensity just went back to 1.0). Any thoughts?
Thanks,

Hey Andrew -

is there a way to move already existing layers with geometry in them into sublayers?  i'm working up a definition that turns off a bunch of layers when importing geometry from Revit, but i'd also like to move those layers to an 'off' layer automatically. 

Hi Dan - 

Try the attached script. It will move an existing layer to be the child of another existing layer. MakeChildLayer.gh

You are a beautiful human.

Hey all;

I have a problem, I used the "Render Tet to Screen" Component, the problem is that it goes behind the scene's objects when I'm rotating the view ... is there any way to solve the problem?

I have a excel number set that i'd like help assigning relative line thickness to at different directions. For example, at 10 north would be thicker than 5 East, 3 South, 7 West, etc. I took the spreadsheet reader to extrapolate the data, then sort and partitioned to make a relative range of data. From there, I was looking to assign line thickness and typology and a direction, but I'm a little stuck. Any help would be appreciated. 

test.gh

Hi Bomin Kim - 
without your excel document or the plug-in you used to read excel, the document you've attached doesn't help me help you very much. However, there are two basic ways to think about lineweights using Human:

1. Line thickness in Grasshopper Display. For this, use the "Custom Preview Lineweights" component, and supply the lineweights you want and the curves/lines you want to display. It has two modes - Relative (the default) where the supplied number is a pixel width, regardless of zoom, and Absolute, where the supplied number is provided in the units of your document, so that a line will always display as "20 cm" thick and scale with your zoom.

2. Line thickness in Rhino object Attributes. For this, use "Create Attributes" and supply your desired lineweight to the "plot width" input - then feed both these created attributes and your geometry to a "Bake" component. This will bake your geometry to the Rhino doc with the proper plotweight - which will show when you print, or if you enable "PrintDisplay" in the rhino command line.

Hope this helps - if not please supply a little more information so I can get closer to the problem at hand.

I am really pleased to see the new version! It is great to see you have included the Viewport properties. I have two comments:
1. The "modify viewport" is missing a camera up setting.
2. When the viewport is switched to parallel(orthographic) view, the CPlane and Camera position will drift in the background. When you then switch back to projection view, the camera will be far from the target. It also seem to drift more if the updating is more rapid. Is it a Rhino bug? I do not think it's specific to the Human plugin. Video: https://www.dropbox.com/s/buns398xf59de6u/Grasshopper_Viewport_Drif...

Is there anything to do with this?