Thanks for reporting this. I believe I have fixed this bug and it should be available in tomorrow’s WIP release, but please let me know if you still see issues with this. Thanks.
Sweet, can I get the youtrack so I can keep an eye out for it?
See here.
Can you further explain this concept / give an example?
Thanks
Say you have a gh definition that creates a srf. Right now, you can only bake a srf once (A). Then you use one of srf a’s edges in a Sweep1 (AS). Currently, A, and by extension AS, cannot be updated via gh.
Baking the component again creates a new srf (B), with which AS has no relation.
Letting gh update (A → A’), means that children update via native History (AS → AS’). The new workflow would let you do something complicated in gh, knock out a bunch of easy stuff in Rhino, then go back to gh for something difficult.
Goodbye, spaghetti code. Hello, efficiency.
Epic. Thank you for the explanation!
How would the automatic re-import of Srf (AS) work then. It would somehow have to be recognized as (AS). One woulfd also have to define, when (AS + n) is finished, no?
AS is just a Sweep1 in Rhino. A was created by gh, but gh has no knowledge of AS. When gh updates A, instead of creating B, Rhino sees the change to A’ and native History kicks in to update AS → AS’.
@AndyPayne, are these gh v1 improvements also in Rhino v7? I’m trying to understand the relationship between Rhino 7/8 and GH 1/2.
No. These components are only available in Rhino 8. GH1 exists in both Rhino 7 and Rhino 8, but there are some new components which are only available in Rhino 8 (such as these). GH2 is currently it’s own stand-alone plugin (while it’s being developed) and doesn’t ship with Rhino. You can install it like other plugins via the package manager. GH2 is a complete re-write from the ground up and its a little different. It does have ways to set object attributes but it does not use these components to do so. It has it’s own methods that David wrote to do that which fits it’s new system. Hopefully that helps clarify things a bit.
I’m very impressed with the new Rhino nodes, the pass through functionality is easy to use and I love being able to have a compact graph by “hiding all unconnected parameters”. Text entity is great, materials in custom preview is great, drafting attributes, wonderful. Really happy, thanks for the hard work.
I have a long term solution I’m building that has extensively relied on Elefront and with these new nodes I’ve almost exclusively replaced everything with the native Rhino 8 nodes, with the exception of dynamic baking.
Eagerly awaiting your baking component
not sure if I’m the only one shocked by this, but Andy’s new components seem to work just fine with Human’s Bake component
@AndyPayne
I noticed a difference in behavior in GH1 on Rh8.
In Rh7, when I right-click on inputs/outputs I can use the keyboard to speed-select a menu item.
E.G. Right-Click then F to flatten
Right-Click then G to Graft
Right-Click then W then H for hidden Wire input.
Right-Click then S then S then Enter for “Select one geometry”
Can we get this for Rh8 too pls?
Or maybe there is an alternative that I’m not aware of?
Also, Some items require “enter” to finalize the selection. (e.g. if there are multiple entries with the same initial) If we also could use spacebar it would be more left-hand friendly.
Not surprised. I’ve been using a keyboard shortcut for ‘Bake Selected’
It works but there is no bake name.
Hey andy. Just curious what are the updates on the lights in blocks? Could we expect that feature this year?
Second this,
Please code in Lights as native components:
- Please consider including all types of lights, spot, linear, rectangle etc.,
- Ideally this would have size / focus parameters per light, for example being able to control the focus and scale of the spot light -
- Ideally we would also be able to set color, intensity, shadow intensity and falloff type.
- Rectangular based on rectangle, linear is based on line, spot is based on plane etc.,
Thanks, A
@AndyPayne Kudos for the new Bake component that is just formidable!
Great to see how adaptive it is too.
I notice that update works fantastically on layers but I haven’t quite got it to work on geometry. Not sure if it’s working as intended and I’m missing something or if it’s still missing some functionality. Either way, I agree with @EricM that having it Update/Replace baked rhino geometry will be a game-changer!
Hi @guido ,
Make sure you are using it in conjunction with the new Model Objects node, this node is where you define layer information, object name, render material attributes, etc. If you just feed geometry straight into the C input of the bake content component it will bake it to a “Grasshopper” layer by default.
So to have it behave how you expect you need to first feed your geometry into a Model Object component and then feed the O output of the Model Object Component into the Bake Content Component.
I think my problems lie with the button actually
this works fine, provided that query model object isnt connected to text dot on the first iteration.
Button with update doesn’t seem to be able to bake the first iteration or provide updates
The dotted line is interesting but I’m not quite sure what it means.
Insert will work with a button but if we swap to update the new iteration disappears on release.
Ahh I see, the devs will need to elaborate more but the dotted line means the bake component is expiring the referencing component.
I’ve found this usually happens if you bake to the same layer you are referencing or in your case it appears you are referencing a model Object by name and then baking that model Object again, since the model Object already has a name, you may not need to connect the name input on the model Object component, unset values on that component will mean that it carries whatever it already has with it, so unless you are changing the name to something different you don’t need to input the name again.
Also when the bake content component is left as True and Update mode, it will update the model objects with the latest info so you shouldn’t need the button (unless you are wanting a manual refresh mode)
I typically leave the update value to be true and then rely on the fact that new data upstream will retrigger the component and cause it to update
And lastly I recommend always giving it a layer name even a temp one.
Example: if you are referencing points on layer “My Parent::My Child”
I would bake the resulting geometry to something like Temp::My Parent::My Child or Bake::My Parent::My Child
This will hopefully ensure there are not conflicts between realtime referencing and realtime baking
@AndyPayne why don’t the user text component and the new bake component allow for baking keys with no attributes assigned? I would like to bake keys with empty values, so that I can fill them in easily myself and so they get ignored in the downstream components.
E: Or just to add attribute keys without affecting the attribute values for components already in the document. Like an attribute updater.