I’m using Elefront on most of my recent Grasshopper definitions. So first of all thank you Front!!!
I have two issues, currently, actually for a long time now
using the Bake All button, the Grasshopper canvas freezes after baking and I have to click the button a second time, bake everything again and then I can continue
I’m a fan of the Bake Name but for some reason the bake components overwrite Layout Print Width back to Default…
Today I updated to the latest version. My Rhino 6 is up to date too.
Bake All… as mentioned above, this button has to be pressed twice in a row. If the second click happens during the first baking process, Rhino crashes.
I just realized that when baking geometry with Elefront and the bake layers active, Rhino creates meshes and that causes the cursor to jump into the command line. That’s a problem since I want to continue manipulating my data in Grasshopper with keyboard shortcut triggered buttons.
Thanks @andheum and @Mahdiyar for your help!
The solution is simple. With the bake layers in wireframe mode, no meshes are being created, or at least no status message can be seen in the command line and when I press my keyboard shortcuts, they trigger the buttons in Grasshopper.
@martinsiegrist Could you explain what the solution was. I have the same issue, but not sure how you fixed it. The bake button in Grasshopper triggers something in Rhino, which makes Grasshopper lose the mouse-up event. Its not even exclusive to Grasshopper; if you trigger the bake button using the RCP (remote control panel) the same thing happens, where RCP doesn’t work any longer unless you press the bake button twice.
I think one solution would be for Grasshopper and RCP to trigger on mouse-down and just ignore the mouse-up event. Or for a way to trigger things in Rhino “silently” where the cursor doesn’t jump to the command line.
Ah yes, interesting, if you press the button, then wait till its done everything in Rhino, you can see that the UI button only shows the mouse-down state after Rhino is finished. So if you keep the button pressed for longer the issue is not there.
I think the simplest solution in that case would be for Elefront to trigger on Mouse-up. That should be fairly easy to do. I don’t understand how the Elefront Dev’s have never come across this issue that has been mentioned so many times in one way or another.
My solution was to have the layers where I will bake to in wireframe mode. I figured out that Rhino doesn’t create the rendermeshes when the view is in wireframe. I think I’ve had no more problems that way
You mean to set Grasshopper to only create wireframe meshes?
I didn’t know you could set a layer in Rhino to use a certain render mode. Isn’t it just by viewport?
Anyways, the problem still exists anyways. I am baking linked blocks and the problem persists. Its not even creating any meshes.
I think your solution only worked because it shortened the time for the baking to run to so little that you were pressing the button long enough. As we found out if you press and hold and let go only after Rhino is done, the problem doesn’t happen. Its a stupid mistake by the Elefront devs and I am not sure how they never came across it.
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.
As mentioned before, there are two things happening.
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.
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.
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.
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!
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
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.
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.
