Philipp - look at the first comment on this page, the files are there. I am still awaiting approval on my Food4Rhino page.

great job! I was hoping for blocks in GH for a long time...

THANKS. 

The only thing that I find odd so far is that when I reference a block, the bounding box is centered in the origin of the UCS based on the insertion point of the block. I think it would be more intuitive to get a plane indicating the local coordinate system of the selected block and that the bounding box matched that/those specific selected blocks...

Hi Frane -

The reason the component is set up this way is to allow you to use the component to read blocks in order to place more instances of them. Look at the "Create Block Instances" example to see how I'm using the bounding box output this way. Which of the following would be most useful to you:

1. As you suggest, a plane indicating the insertion frame

2. A transformed bounding box (oriented on that frame) encompassing the transformed instance

or 3. the transform of the block instance itself. 

The only reason I hesitate with #1. is that it doesn't tell the whole story - blocks have new positions/rotations but may also be scaled nonuniformly, sheared, etc.

Hi Andrew

I think the insertion frame and the transformed bounding box would be useful information for a more direct use, like selecting a specific block and rotating it around its insertion point. It would allow to manipulate blocks almost like any other rhino referenced geometry.

Since there might be transformations in the selected block(s) it is also useful to have something like a "reset tranformations" component to get that "original" centered version.

funny.. i was just searching the forum for a way to bring lights into gh - obviously now there is one! will start testing.. thanks!

hello andrew,

so far i can say great job! would be definitively nice to support also the other light types in the future. I noticed that the light intensity is always 100 after baking. bug?

Is there a chance to have the light visible in the viewport before you bake them? or would that require a kind of support from grasshopper?

would be great anyway have lights that can move around and change their intensity or direction..

Thank you Andrew! Very useful!

Hi Christian -

Unfortunately there is no ability to preview the lights without baking them. However, I could add a component which will automatically delete the objects on a particular layer before baking them - allowing you to at least give the appearance of dynamically manipulating the light objects in Rhino. I've done something like this in the past to use rhino 5's built in shadows for sun studies. Stay tuned for the next release!

Oh and I'll take a look to see if there's a bug in the light intensity.

Ah - Though intensity is on a scale from 1-100 in rhino, it's actually 0-1 internally. You can give it a value of .43 and it will show up as 43 when you bake it. I will change the component to make this clearer - good catch!

Hello Andrew -

sounds like a feasible method. looking forward to that. also of course it would be great to be able to control the built in sun system.

a component like that would definitively make sense as rhino 5 offers great options to tune the display modes. theoretically it should be then possible to display rhino shadows or for example textures on dynamic geometry from gh or do i get it wrong?

Great tools Andrew!

thank for your job. 

a wish - it will be so nice to customize fonts for text tag...

New release of HDT Reference components added to the Food4Rhino page - check it out! New features include ability to explode hatches, delete objects on layer, and specify custom fonts for 3d text tags.

thank you Andrew!

guys! do you know how can I attribute and bake some object after creating object Attributes with the "ObjectAttribute" component?

Dhruv - I usually use either an expression component with "Contains" or the "String Match" component on the text output of the text object info component.

Davide - Since there are already so many custom bake scripts out there, I didn't supply one with HDT utilities. However, I realize that the existing bake solutions preclude the possibility of using some of the more special aspects of object attributes, like groups or linetypes, so I will include a bake utility with the next release of the plug-in, one that accepts a boolean to bake, a list of geometry, and a list of objectAttributes data to assign. 

Thank you for answering! including a bake boolean into HDT objectattribute will be the icing on the cake. Your oddon is realy useful and the tree frog too. thank you for the work!

Hi Andrew,

Could there be a ZUI for adding Data-Sets to GraftByData?

The Entwine workaround doesn´t seem to work...

Thanks,

Phillip

Hi Philip - I will think about this. ZUIs like that are a bit of a nightmare (for me anyway) to code, although I have successfully implemented them in the past. In the meantime, I think if you did a longest list matching with your paths input, it should work - the current requirement is simply that the input data and the paths have the same number of items.

Please Andrew,

Can you tell me if I can recover blocks in blocks?

Blocks include children and parents.

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!