Hi,
Can we please have more baking options built into Grasshopper?
There are two very good and popular sets of tools which among their goodies, have baking components: Human and Elefront, some of their functionalities overlap and treat things differently. From time to time I struck into those differences, learn about them, times go by and I forgot all those nuances… so I repeat this process.
I think such an important task as baking shouldn’t be resolved by 3-rd party plugins.
Example:
Revit wall from Graphical Element component, which should be baked as block, is not accepted by Human plugin.
There are occasional problems to bake geometry with the given material.
Selected material to bake with is ignored and new material with the same name is made.
I’m not sure how it would work if one would want to incorporate special attributes such as VisualARQ Section Attributes. (Elefront’s BakeName doesn’t work with VA Objects)
Also, having special baking components for different elements can clutter GH definition quite a lot.
Ideally, I would really like to see a baking “future-proof” solution provided by McNeel, where special attributes made by different plugin creators would bake as they should.
To shrink all that wishes to the most important/basic stuff:
Bake & Replace previously baked objects - currently dealt with by “BakeName” in Elefront and “Delete Prior Bakes” in Human. There should be an option like that. How about Ctrl + Insert as a keyboard shortcut for that?
Select baked stuff - similar to the very convenient Zoom option, but with selection.
Some time ago I started to Bake & Replace Revit elements with Elefront’s BakeName, but it was with extracted element geometry (not as blocks) and with rather simple stuff - I didn’t discovered any problems. Now I switched to baking blocks, we will see how I will roll with that.
The same goes for your plugin and baking geometry with texture mapping - fortunatelly Elefront bakes them ok.
McNeel includes Kangaroo, presumably as part of a deal with @DanielPiker.
There are a few other plugins that are similarly popular, created by people who seem dedicated to this field in the long term, and that provide near-essential extended function.
So what I’m getting at is: if McNeel integrated plug ins by people like maybe @andheum or @Michael_Pryor as native/included, (maybe after looking carefully at everything and culling redundancies) and expanded on the precedent they set with Kangaroo, I would see Rhino7 as certainly worth a slightly higher price.
Of course I have no idea how their pricepoint decisions are made, nor do I know how the guys who put all that effort into plugin creation make money (presumably it’s a loss leader?). Would there be a problem where full integration actually weakens these guys’ ability to use their plugins to market their services, because separate downloads draw more attention to them?
I dunno. Just spitballing here. But it sure seems like taking the cream of the crop of plugins and fully integrating them might be good for users, McNeel and the plugin authors all at the same time.
If it wasn’t convincing I will bring my failed experiment from a couple of minutes ago.
Because it touches Rhino inside Revit and VisualARQ I’ll allow myself to mention @kike and @fsalla.
I wanted to make something nice for me. Everyone who is there for some time knows about the problem with hatched patterns and clipping planes. Actually, hatches were something that convinced me to buy VisualARQ (I told to myself - In case I wouldn’t use any of VA functions, at least I will have nice sections).
So… something nice for me, was to bring Revit geometry and replace it with VA geometry.
By doing so, I was also about to replace Revit materials with prepared VA Styles - this way I would get very nice representation inside Rhino.
Because my Revit file is changing quite a lot I found Elefront’s BakeName a very convenient way to update imported geometry.
And here comes the incompatibilities and surprises I was writing about earlier…
Elefront can’t write Attribute User Text (which as I suppose BakeName solution is based on) to the VA Walls so I can’t use BakeName functionality.
I can explode VA objects and then normal Breps work just fine with BakeName but AFAIK VisualARQ doesn’t have GH components to apply Section Attributes to regular Breps. (Even if it had, still producing native VA Walls with BakeName is impossible)
In conclusion, it’s a real pity when on the same end of the process you find that there is a bottleneck that you can’t go through and many functionalities of Rhino go to waste. Because of that, those bottlenecks should be controlled by McNeel directly so if a problem like that happens, at least I know who to beg to solve it.
This won’t handle all the features you are discussing but a year ago I spent a few weeks hacking this Python code to bake (and delete) geometry by layer with custom materials:
Introduced and explained at greater length a few weeks earlier:
It was agony digging through the forum (ten years of requests for this capability!) and the Rhino APIs.
It works well enough for me but someone who knows what they’re doing might be able to take it further. There is no indication from McNeel that they plan to do this or even understand the need for it.
Sorry, can you elaborate?
BakeName with Breps works just fine without it.
I can’t assign any Key, Value or Name if I try to bake VisualARQ Wall From Solid.
I can assign: layer and color.
Assigning material instead of picking right one it creates new material with the same name.
Yes, it works fine with regular Rhino/Grasshopper objects (besides the Material attribute, if I remember correctly, sometimes it works, sometimes it doesn’t). I am using Elefront quite a bit.
In this case, I’m talking about baking a special kind of object from the VisualARQ plugin.
As shown on your screenshoot would not work, because I can’t write any BakeName to VA Object - thus I can’t reference it by BakeName.
Manually modyfing anything after baking defeats the purpose of using convinient option such as BakeName (which should save me time).
Manually I can do much more, but as I mentioned earlier, my input geometry changes quite a lot and I refuse to manually tweak it every time I update it.
I do appercitate your efforts to help me with it.
