eleFront v5 Now Available

@Toni_Osterlund – it is what @weekenlwk says. The geometry that comes out of the “Explode Block” component is now wrapped with eleFront attributes, allowing you to pass it to the “eleFront Attributes” component to get what you want off the object.

We have introduced a “Block Info” component that gives you quick access to top level information of a Block, much of which was only accessible in v4 eleFront through the “Deconstruct Block” component, which was computationally expensive because you had to explode block at least to the top level.

@weekenlwk - right now only the full path exists as it is how we work and it was important to us that this was the default behavior. I can see a case for having a flag allowing the user to return only the innermost child layer. You can access this now via the “eleFront Layer” component. Like the attributes component, this component is collapsible to hide the unconnected parameters.

@elevelle @weekenlwk
Ok, I see that now. Thank you.
I have to adjust my routines accordingly.

@elevelle
How about GUID of blocks? How do I retrieve those?

@Toni_Osterlund – interesting quirk. It appears that by manually selecting a block as an Extended Geometry element the knowledge that it is a referenced object is lost and it is treating it as a GH object now. I’ll sort that out at some point, however, if you pass a block object that has been referenced in an other way, the behavior works as expected.

  1. Manually selected as reference in GUID component > Works as expected
  2. Manually selected as reference in v5 Extended Geometry component > Does not work as expected
  3. Referenced using v5 Reference by Type component > Works as expected
  4. Referenced using v5 Reference by Layer component > Works as expected

Hi All,

I dont know if it is a bug or something, whenever I try to connect a elefront attributed geometry (Lets say in this case a bunch of curves has some attributes) to a curve input node the attributes are gone. Please let me know if there a way to fix it. I know i can use a data component instead of curve, but its intuitive to use curve for curve and same type for type for the data that im working.

It appears that baking block is not possible in Elefront 5
Manual bake also doesn’t work. Do I miss something?
As far as I know, baking block was possible in Elefront 4.3

Rhino 8 Beta
Elefront 5.1.2

Hi,
Yes, you can certainly bake blocks using eleFront (in fact we put a lot of effort into thinking about the best way(s) to do this). You should check the error message. I imagine it will tell you that you need to have the same number of Attributes objects as Geometry inputs. That means you need to use something like Longest List to have the same number of Attributes as Geometry:

There is some more information about the particulars of blocks here:

It still doesn’t work.

The problem is that manual bake is also not working. Nothing happens.
Block Not Baked

Thanks.

What is the error message in the Bake Component?

Message

It seems it’s failing to find the Definitions of the blocks in question, so it is not an issue with the Bake component, but will be something related to either your Rhino document, worksession (if being used), and other aspects of your script.

I would also try the following. EleFront has options for what to do when you are creating a Block definition with a name that already exists. The default is to throw an error, but you can also set it to Overwrite or Use Existing:

You could try those, to see if they fix the problem. Otherwise unfortunately I would need to look at your model / script. Happy to do that, but I know it’s not always possible for people to share their files.

Hi. Keyan.
Seems like Elefront 5 doesn’t work with Rhino 8 well.
It works fine with Rhino 7.
Did you ever test Elefront 5 with Rhino 8 Beta, not WIP?
V7
V7
V8 Beta
V8

I attached simple rhino file and gh definition.
Thanks.

V7.3dm (50.7 KB)
V7.gh (14.0 KB)
V8.3dm (39.9 KB)
V8.gh (13.1 KB)

I do want to use this new components but unfortunately they are not very reliable.

More details here: Sort a number list which contains text - Grasshopper - McNeel Forum

P.S. Elefront 4.3 it is not working anymore with Elefront 5.1.3 installed because of a conflicting name.

As far as I can tell, the eleFront components appear to be working fine. I would point you to look at what is happening in between the two as the variable, in this case the python script. While the image you shared doesn’t have enough information, I did click through to your link and was able to find more information there.

As you can see, when the object goes through the python component, it loses its reference to the Rhino Object, going from a “Reference Brep” to simply a “Closed Brep”. You can also see this because the objects no longer have a GUID - so they have lost their relationship to the model. This is why eleFront cannot find the information.

The fact it works sometimes in the Legacy Version of eleFront, is a quirk of Grasshopper where sometimes for simple operations it does maintain the reference to the original object, even after transformation. However, this is a quirk - it’s basically good luck - and should not be relied on, which is why eleFront 5.1.3 is actually more restrictive on making sure your information is consistent. It’s meant to encourage best practice.

So in this case, it is the python component that introduces the inconsistency, with how the Rhino Object is being wrapped and unwrapped, going into and out of the component. You would need to find an alternative way of ensuring the reference to the original object is maintained.

One approach would be to Detach the Attributes and sort them directly, but perhaps you want the geometry too.

1 Like

Yes, I do need to sort also the geometries and pass them further sorted to match the sorting keys.

Do you know a fix for this issue?

One day you will be able to use the new Object component in R8 GH. This does something that allows the information needed to pass through the Python component, although this version of Elefront doesn’t yet take advantage of it:


(In this example there is no Python processing of the data going on - it goes in and comes out again - to rule out any end-user code issues.)

Note that the Model Object will also lose its functionality when passed through primitive parameters (Point, Brep, …), nor does it work via worksessions (unlike elefront).

I think again this is a fluke that you should not rely on all the time. The issue is not necessarily user code, but the way the python component is processing information as it goes to-and-from Grasshopper. See this example:

  1. The python script literally just returns the input.
  2. There is no type hint, so there should be no casting.
  3. The objects still do not show as a referenced object
  4. the Guid is lost

This has to do with how python translates to/from GH.

One option is to use the Guid as the sorting Value.

Note that you will need to convert it to Text, then back to a Guid, and then to a Geometry (lower stream), otherwise the python component will naturally try to cast it to a Geometry type, leaving the reference behind (upper stream).

1 Like

Yes exactly.

Thanks, your screenshot is a helpful example.

1 Like