Hello again,
I just noticed that in Elefront 4 I can’t extract an object’s Material Attribute properly (Please refer to uploaded image) when it is set to Use Layer Material. I have to apply the material directly to the object in order to get it’s proper name. Can I request that in Elefront 5 that it can extract the proper material id regardless of the material application method? Thanks.
Hi, @elevelle @krahimzadeh . Thank you for all these efforts and the great updates.
For the block manipulation functions, I got an issue for the " insert Block" component for it seems to insert blocks into wrong weird places, please help to make notes and check.
Following is the GH file for you kindly to check.
[comes correct results in 4.22]
[but weird in 5.01]
Elefront-500_issue_insert block.3dm (932.2 KB)
Elefront-500_issue_insert block.gh (297.0 KB)
I suppose deconstructing blocks can be further cached.
And it seems referencing block by names is very slow.
Thanks everyone, for the feedback! We haven’t been responding to each post, but I am following the thread and taking notes for the next update. We really appreciate all the testing and notes. I’d say we’re aiming for an update to address some, if not all, of the bugs mentioned so far, as well as some added features, for another round of Beta testing. This will likely be in 8-10 weeks, so thanks for any and all feedback until then.
Hi, I just wanted to add something I read from a different user in another thread. I’m not a coding person so I don’t know if it’s possible but this may help solve the problem with many different needs regarding attributes. I’m also a VisualARQ user and I’m confident that at some point there will be a new parameter (maybe physical material in VA 3?) that will be missing from Elefront and people will start asking for support. So some universal slot, that might relocate the support to other developers could be helpful.
All versions of eleFront are now available via the Package Manager, and the Installation Instructions have been updated accordingly.
Not having a bake boolean input means we won’t be able to use Elefront unfortunately and still have to stick with Human. I see you added that “Bake all Elefront” button to skirt the issue, but that does not fix anything.
You need a boolean input so you can toggle it to true, run a loop and it bakes on every loop run.
Kudos to Andrew Heuman for building Human in such a clever way, that it is still the best baking plugin even without any updates.
There was also a long discussion on whether adding buttons to Grasshopper components is sensible: Triggering a plugin components button
Maybe the hack by Tom also works in Elefront.
Please consider adding a boolean trigger for bake. Everything that is hidden in a menu or an action you can only trigger by a button on a Grasshopper component breaks the possibilities of Grasshopper.
I’m often using various Bake Objects components in a single file so most times the Bake All button doesn’t make much sense.
I tried to reduce the need to move around the mouse in large definitions and thanks to other forum users I can for example hit the Insert key to bake geometry.
The boolean input is super relevant. Please bring it back.
The previous version did have the boolean input, as well as the Bake All button. We’re happy to bring it back.
As some background, here is why we took it out: Best practice is to not modify the Rhino Document until after the GH script has completed its solution. This is for good reason, because otherwise the conditions around your script are volatile / unpredictable.
For example, if in the process of baking, you delete / replace geometry that was an input for your script, or was an input downstream, you could be invalidating the rest of your script.
Consider this use case: Someone wants to bake some geometry, and then reference the new version downstream. You might think you could use the set-up below to bake and then re-reference with a single trigger.
Unfortunately there’s no way to guarantee that Grasshopper executes the Bake component before the Reference component. This is a trivial example, but I’m giving it to explain that by removing the input, you ensure that the Rhino operations and Grasshopper operations have a clear separation.
I don’t know that limiting the interaction to a button “breaks the possibilities of Grasshopper” so much as it “ensures robust behavior”.
This was an experiment (that’s part of what beta’s are for), but clearly there is a lot of demand for the toggle, so we’ll put it back.
That said, I would be interested to understand more about what you’re trying to do with looping and baking. It’s good to know how you’re trying to use the plugin, to see how we can support that in the best way, especially in a situation where it sounds like you’re doing a lot of back-and-forth interactions between the Rhino doc and the Grasshopper definition.
Regarding these comments:
I would just like to say, if you prefer Human, use Human. Andrew wrote a great plugin that is beloved by many. It also does a lot of things that eleFront doesn’t, and vice versa. We’re not trying to out-do it or take its users. We make this plugin to do what we need to do, and share it with the hopes that others find it useful and that it encourages well-structured models.
Sure, completely understand, we do the same. I added the “Bake Group” component to try to address that issue, so that you can trigger one or multiple Bake components from elsewhere on the canvas:
But I can see how this could become quite annoying if you have lots of Bake Components on the canvas and don’t want to have to create a group for each one.
Seems that I underestimated how important the toggle input was, so I’m happy to put it back. These are the kinds of things we only find out through feedback!
Thanks for the response. The Bake Group option is actually quite good. Could the Bake Group button be defined as keyboard shortcut? My definition requires Metahopper.
bake_group_insert.gh (22.1 KB)
Sorry, I did not mean to make it sound like I am comparing one plugin to another. Just wanted to mention that Human did a lot of things right. Till now I was using Elefront or Human, depending on the situation and like you say both do slightly different things.
If you could add the boolean back in that would be great.
I am totally aware of the situation you mention and it was clear that this was the reason for not having it. As soon as you rely on a lot of asynchronous things in GH or re-referencing things it gets tricky. But I think if you are at that level of GH, you probably know.
What always helps in these cases is to have another boolean output or even a string with a status message. If for example there is a success boolean output, you could use that to trigger something downstream. Similar to when you create a layer using GH, it actually outputs the layer name again, but only once the layer is actually created, so if you then bake to that layer in the same cycle, you are sure the layer is there.
Wouldn’t something like this work? Unfortunately, there appears to be no status message. Is there only a status message if there is an error? I think there should always be a status message, even when it is not doing anything, so there is no empty output.
reference_after_bake.gh (8.5 KB)
Yeah I think this is probably true, so we’ll leave it to the user!
In terms of the specific example with re-referencing baked objects, for v5 we actually return the objects themselves after baking, so you don’t need to re-reference the components (another attempt to try to keep Rhino + GH sync’ed). They are returned as Ghost geometry, so that it doesn’t eat up memory by bringing the geometry back in, unless you need it, in which case you can get the Guid.
Okay, now that is even better. So in the new plugin since you have a way around the issue, you might as well add the boolean back in for the bake, right? The Ghost geometry will only be output once the bake is complete I would assume!?
ps: I am curious what the Deconstruct Ghost (?) icon will look like 
I managed to get the Export to Rhino File component to export a Rhino file but I don’t understand how the generic export works. Deconstruct file path is a good addition.
Well, the idea was that this would make the boolean input unnecessary, but it sounds like there are lots of other good uses for it anyway (Grasshopper Player, etc. and others mentioned).
Yep!
Haha, so am I!
Yeah it needs more work. But the idea is that you can put the IDs of the objects you want to export in the second input, and the first input has a complete filepath including the file extension (so it could end with .dxf, .stp, .obj, whatever you like, and then the component will use the Rhino exporter to do it. Currently doesn’t have the “scheme” input that was there in v4, so will need to add that.
Edit: I actually just tried it, and it didn’t work, so let’s put this component in the “Experimental” category.
by the way I felt strong competition.
Pancake’s baking and block features are long-overdue and should be included in the next major release. Since Elefront is also improving the generic export feature, two plugins have more and more overlapped components. I hope Pancake, as one of my personal projects, would continue.
Just saying. 
anyway Elefront has a much larger user community.
I mentioned I was having problems with the schemes. I could export DXF files automatically but always had to confirm the scheme in the command line for Step and Sketchup export. Somehow it all of a sudden works for Step but I still have no clue what the scheme input needs to be for a Sketchup export?
