Human: Place Block on new layer?

Is there a way to use Human’s Place Block component and have it placed on a layer that does not exist yet?

If I give the Attributes a layer name that does not exist it will simply place all blocks on the default layer. The layer I want to place them on does not exist and contains a timestamp, therefore it should only be created when triggering the Place Block.

I tried using the Create/Modify Layer component with a StreamFilter, similar to here: Activate create layers component via Boolean but the problem is that Place Block is triggered at the same time as Create/Modify Layer and it seems that Place Block is quicker, as it creates the layer, but the blocks are still placed on the default layer.

I also can’t use the Layer Names output of Create/Modify Layer, which only outputs on success, since it by default outputs “null”. The attributes for Place Block simply see that a layer by the name of Null doesn’t exist so it places everything on the default layer.

How can I place blocks and create a layer at the same time? Alternatively how could I trigger the Place Block immediately after the layer has been created?


human_place_blocks.gh (18.8 KB)

I think I have asked you this before and I remember you saying „rather no“. But are you able to code? I mean you seem to do a lot of those things which are not so hard to do by writing little scripts. Basically adding layers to the RhinoDocument and adding objects such as blocks to it is not really difficult once you know the basics and the correct location in the library. I mean someone could write you scripts for each of these questions, but even a much used plugin such as human is not capable in covering each usecase. So I think the real answer to your question would be: start writing scripts and learn how to attach objects to the Rhinodocument (=bake) from code. Maybe if find time later this day I write an example, if not someone else is doing it until then!

Hi Tom.
Thanks for your inputs. Yes, I am aware that scripting would “solve” all these issues, but I am right now more interested in solutions that just work and in 99% of cases it is possible to find those tools. We build a lot of large definitions and use the likes of Grasshopper exactly because you spend more time experimenting and less time debugging. So I don’t mind trying out different things and working around some limitations. The thing about writing your own scripts is good, but will only ever do exactly what you want it to, but never more. That’s why Grasshopper and all its plugins are so valuable - because it makes it easy to try things out you hadn’t thought of or sometimes even come across by coincidence. That doesn’t really happen as much when you write scripts.

So scripts are good when you have a very concrete and fixed use case or for a tool you will use for a long time, which normally isn’t that much of a goal with Grasshopper stuff. Also things don’t have to be super optimised (which would justify writing scripts), since Grasshopper isn’t realtime anyways and for the heavy stuff I don’t care if it calculates for 1 or 3 seconds.

I will also find a workaround for this problem here without having to write code for everything. I feel its more a limitation of Grasshopper and the fact that it doesn’t really have the concept of triggering events, but actually does everything in one calculation. Normally in other visual coding tools you would just trigger the layer creation and then immediately after bake the geometry to that layer.

Just to clarify - “Place Block” is not somehow quicker than create/modify layer… this is not how grasshopper works. If A depends on B, and B depends on C, then C will execute before B, and B before A, every single time. In fact, the script you posted works fine… the blocks get created on the new layer. I cannot cause them to get created on the default layer, so I’m not sure what behavior you’re seeing. I would recommend one slight modification in order to avoid the timer:

human-place-blocks-notimer.gh (17.1 KB)

Okay, very weird. If I execute the script the instances always get placed on the “Default” layer and the created layer is empty. What could be different in my GH/Rhino that it does that. I am on the latest version of both.

If I change the button for a toggle I can see that CreateAttributes says the layer does not exist even though the layer panel in Rhino says it very much does!?

I cannot reproduce anything you’re describing… I’m also using the latest rhino and GH. Please do make sure that the input to create attributes is taking the L output from create / modify layers otherwise the sequence of operations is not guaranteed.

Also perhaps try checking your version of human? I am using the one currently available on the yak package manager: Human.gha (400.5 KB)

Yes, I have reconnected to the L output, but no difference. L actually always outputs < Null >, which is probably the actual problem.

Alright, found the error, it was indeed not the latest version of Human. I was on 1.1.0. doh!

This makes sense! There were some changes to the RhinoCommon SDK between rhino 5 and 6 specifically around layers which required some bug fixes that I released a bit later :slight_smile:

Okay, thanks. I didn’t even know about Yak and taking a look now. Pretty nice. I am hoping for the day where I don’t have to keep a copy of my components folder in Dropbox to use on other machines and to give to others before opening a file or having to swap around files because something like ShapeDiver needs certain versions of plugins. I never understood the whole food4rhino thing and why its so separate to Rhino/Grasshopper. Seems weird.

food4rhino is a disaster - as a user and as a developer! I have had no end of trouble trying to keep it up to date.

2 Likes