Elefront Bake All issue

Thanks for bringing this to our attention. Strangely, we have never come across this issue ourselves, despite having many people using it every single day to bake tens of thousands of objects at a time on a regular basis, including linked blocks.

If you’re seeing this issue on particularly large or cumbersome scripts, perhaps you could share the definition with us so that we might replicate the behavior.

We’ll look into addressing this for the next update, though if the behavior is a fundamental issue about the interaction between Rhino and Grasshopper, I can’t promise that we’ll be able to code around it. We develop Elefront as we can to address bugs and when our project load allows, so hopefully this freeware is usable enough until we put out the next update.


Thanks for your efforts! i’m a big fan of Elefront & it was truly a game changer for me.

As mentioned before, there are two things happening.

  1. when baking objects using a Grasshopper button or Elefront bake all button with the viewport in shaded mode, Rhino creates render meshes. That causes the cursor to jump into the Rhino command line. When the Rhino viewport is in wireframe mode, the cursor stays in the Grasshopper panel. I’m using keyboard shortcuts to automate various things in Grasshopper and when the cursor is no longer in the Grasshopper canvas, these shortcuts do not go to Grasshopper but into the Rhino command line.

  2. attached is a simple Grasshopper definition where the canvas freezes after bake all has completed baking everything. It does not matter whether you’re using a bake all button or Grasshopper button. The workaround is to click the button again or as @seltzdesign described just hold the mouse down for as long as the baking goes. The canvas does not freeze when you’re using the “activate” button on an individual bake objects component.

20_07_16_test.gh (19.3 KB)

Thanks @martinsiegrist for taking the time to create the example and video! Just adding to that the bug also happens if you publish the button to the RCP. If you press the button there then the RCP itself freezes and the only option is to click the button again before the RCP fully works again. So the issue is not just tied to Grasshopper, but also in a way Rhino itself.

@krahimzadeh I know this would probably be a major rewrite, but looking at the Human plugin, there the bake component does similar things, but without actually triggering anything in the Rhino commandline. Maybe Elefront can also switch to the methodology Human uses. Maybe @andheum can enlighten you how he did it! Other plugins that do similar things like the instance manager from Heteroptera have similar issues as Elefront by the way since they also trigger scripts to run in the Rhino command line.

I just came across a nice little workaround. The plugin Pancake actually has a “True Only Button” pretty much for exactly the purpose of triggering components that run in Rhino’s command line. If you use that button the UI locking issue with Elefront does not occur.

Its a good little workaround.


Hey this is interesting. Today I replaced an Elefront Bake All button with a Grasshopper Button which I’m triggering with this shortcut. When I click the button, the canvas freezes. With the keyboard shortcut it doesn’t. Your assessment with the duration of the click might have something to do with this…

So far most of the discussion I’ve seen about this issue is suggesting that it’s something deeper than the Elefront code, and probably something about the interaction between Elefront and Rhino, or maybe even Grasshopper and Rhino.

In any case, we’ve been in touch with McNeel, and are trying to sort out what the issue is. It turns out it’s actually quite difficult to suss out where the snag is since there are a lot of interwoven processes, especially in the cases where blocks are involved. Hopefully there will be a fix, either on the Elefront side, or on the Rhino side, by the time Rhino 7 comes out.

Obviously we hope for something sooner, but I don’t want to make a promise I can’t keep!

Thanks for all your efforts, Keyan.

I’d be completely screwed without the functionality of Elefront.

As you mentioned, I understand that the issues are difficult to pinpoint.

A general input probably: I’m trying to implement keyboard shortcuts more and more. So for example my latest Bake All is a button linked to the Insert key. I need to move the mouse less. In the long run I believe the entire functionality of Elefront and Metahopper should be integrated into Grasshopper.

We are testing the Elefront code for this mouse problem and trying to see if we can somehow streamline the code to handle this better. But, in order to test some of our changes, we need to dataset and Grasshopper definition to recreate the problem.

Can you wrap up the files that are involved in this and send it to us? The best place to send it to us is: https://www.rhino3d.com/upload

1 Like

When baking blocks with Elefront, the following problems occur:

Clicking Bake All Elefront button or Bake All Grasshopper button both freezes the GH canvas…

Once the canvas freezes, the way out is clicking the same button again.

By using Metahopper and the C# Script by Discourse user Mahdiyar, a button can be triggered with the keyboard, in this case Insert. This procedure does not freeze the canvas. The only downside so far is the fact, that the button has to be plugged into every Bake component, which is more effort compared to the Elefront Bake All button.

The solution with a keyboard shortcut works fine in Rhino wireframe mode. In shaded mode however, render meshes are being generated or at least that’s what I can read in the command line and the cursor end up in the command line. For the next baking operation, the cursor would have to be moved back to the Grasshopper canvas.

20_08_30_elefront_bake_all_issue.gh (36.9 KB)

PS: I really wouldn’t mind having the functionality of baking blocks with attributes as a standard Rhino / Grasshopper feature. An important detail of the Elefront Bake component is the bake name, which overwrites objects previously baked with the same bake name. Referencing / filtering geometry should work in a similar way like in Elefront. I’m not a fan of the Geometry Pipeline because it can’t be fed with generated inputs. Thanks.

1 Like

Thank you for the sample. It is happening here also, so that is perfect.

The issue is still here in V7.
It happens here with the “Bake” component.
A “trick” that seems to be working is to intersperse a METAHOPPER “Enable / Disable component” between the actual trigger and a “true” boolean serving as a trigger.

I know this is a little OT, but it’s about these pesky components that don’t have a trigger input, but only have a button on them.
It’s the case with “Reference by Bakename”… I’m trying to use it to delete the blocks that were created during the bake, as my goal is not to create instances, but simply to update their definition.

Human allows to just update a definition, but it doesn’t want points as part of the block content :frowning:

this option controls the refresh/not refresh (disable auto update)


I failed to notice that. Thanks !
Now I need to figure out how to delay the trigger do that I can delete the block instances when they are all created…

Why do we have to bake these darn “Define Block” components ?
Allowing to just modify block definitions without creating instances seems so evident…

Could there be a C# component lying around that would do just that ?

Pancake’s True-only Button probably helps with the freezing issue, and Wait Until to control the logic flow. I’m not sure.

But eventually, the all is caused by the swamp of Grasshopper manipulating blocks… :crazy_face:

Anyhow, Metahopper saves the day again.
The same trick works also to delete the unwanted instances.
I don’t know how, but the timing works each time (for now) :

Well, it works, but the problem is that I don’t want a GH button : I trigger things through Human UI.

All this would’t even be an issue if I didn’t have to delete those pesky instances…

PS : the “WaitUntil” component is really cool

:crazy_face: that’s the reason I’ve been using scripts to modify blocks

though that’s not quite the way of using those 2 components… You don’t need MetaHopper IMO

Well, if one of these scripts could fall off the truck, I’d be glad to pick it up

1 Like

Here’s another possible option, if you wanted to wait until after all the blocks are made. and want to skip the added click on the Reference by BakeName. Basically adding something that will trigger once the Bake component completes its solution.

Duly noted on being able modify embedded blocks without having to bake. Will see what I can do about adding something like that for the next release, though that’s a couple months away.

1 Like