eleFront Beta Available now!

Is there a way to automatically replace EF Data Descriptions with Relays? EF became an integral part of my workflow but exporting my definitions to other people or some services like Shapediver can be problematic.

Hello again,

I’m testing out Elefront 5 again and I can’t seem to bake an object into an existing layer. But if I use Elefront 4 it works. Also I noticed features that I think need to be improved:

  1. Boolean toggle input for “Bake Objects” component - It’s gone. Please bring it back.
  2. Material attributes from “Get Rhino Attributes” - It would be better if it’s added in the outputs. Also it’s missing in the deconstruct attributes, unlike in Elefront 4.
  3. Materials Table w/ selector feature request - It’s actually in Elefront 4 already in the “Define Attributes” there’s an option to plug in a value list for the material. But I’m requesting a separate component for it so there will be more control for materials attribution. It’s not possible right now to plug in multiple value lists.

Elefront Bake to existing layer problem.gh (9.6 KB)

Elefront Bake to existing layer problem.3dm (777.7 KB)

Hello - yeah, Materials haven’t really been implemented anywhere in this release just yet. It’s at the top of the list.

I’ll look into the layer issue.

Regarding the Boolean toggle input - in what circumstances were you using it before? If you want to trigger multiple components at once, the Bake All and Bake Group components should provide the functionality you need. If you are trying to trigger the bake component programmatically (that is, trigger it using the boolean result of another GH component), that could cause some issues. Removing the input was the safer approach, but we’re interested to hear if there’s a scenario that requires it.

Hello, Keyan

The scenario I’m talking about is if I want to only update 1 long Definition. I usually place all my Boolean toggles at the left-most side of the canvas. So if I have a very long Definition and there’s no option for Boolean input, then I would have to scroll very far to the right just to click and bake the single Definition. Also when I cluster my definitions, I usually include the Elefront Bake component in it so I can set a Boolean toggle as an input for my cluster. Now, imagine if I have multiple definitions that depend on a sequential baking, I wouldn’t want to group all of it in a single bake. Having individual control is good, I think.

4 Likes

Triggering Bake while running a grasshopper player script would be another scenario requiring a Boolean Toggle.

3 Likes

Grasshopper player is a very good example, also for the other component.

Interact Rhino Object component could solve the problem from the first post:

The same as in Bake Objects component there is no wire input to trigger the component, and also we can’t feed the type of action (Select, Hide, Show, Isolate) other than from the popup list.

Buttons and popup lists with options are elegant, and handy to use most of the time, but sometimes wire input is needed.

Do you think that adding Deselect option would be possible?

1 Like

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.

image

1 Like

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)

1 Like

I suppose deconstructing blocks can be further cached.

And it seems referencing block by names is very slow.

1 Like

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.

2 Likes

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.

3 Likes

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!

1 Like

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.

1 Like