Hmmm, I can’t wrap my head around all this just yet, sorry.
When I reference something and want to bake modified content to a new layer, until now it was simple because I could concatenate the layer output with something else. To do this now I need to remove the 'Layer: ’ info. The asterisk also isn’t really helpful when using the layer name as a filter.
To be honest at this point I’m not happy with the current development of eleFront and I’m hoping @AndyPayne comes up with a native bake component so I can get rid of eleFront completely.
The name of the layer as a string is available as an output on the Layer component. You can see the old workflow compared to the new one.
And here you can see that this mirrors the set up in the native components from the Rhino WIP (actually the text version of the layer is even more complex there).
It’s all meant to just bring more clarity to when you are operating on a Layer object, versus when all you have is a simple piece of text. As you can see, we’re similarly excited about the features coming from McNeel, and have tried to make the eleFront experience feel natural and familiar for what’s coming. Hopefully the new features will reduce the need for many of eleFront’s features - it will be that much less code for us to maintain or field questions for. In the meantime, we needed a tool to suit our purposes and we wanted to share that with others in case they found it useful. If you don’t find it useful, well… full refund!
Thanks for the additional explanations. Makes sense now. I’ve been using your plugin for a few years and I’ve suggested it to many colleagues or here on the forum when helping other users…
I’ve built most of my definitions around eleFront so naturally that creates a few problems going from one version to the next.
Thank you! That makes sense and the baking works when the attribute lengths is the same. Thank you for your assistance!
Really cool, thanks for your continued work on this. It has been one of the core plugins for me since R7. One thing I did notice is that the layer referencing in the released version is still markedly slower than the legacy version:
5.1.2 has been pushed to the package manager to fix this bug.
Thank you, I’ve tested it, and appears to be working fine.
Works in the old, but not in new.
Exploded block content loses information.
it seems that you should use the elefront attributes component，seeing below, to get the attributes from objects.
In addition, how could I quickly extract the layer name instead of the full path?
@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.
Ok, I see that now. Thank you.
I have to adjust my routines accordingly.
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.
- Manually selected as reference in GUID component > Works as expected
- Manually selected as reference in v5 Extended Geometry component > Does not work as expected
- Referenced using v5 Reference by Type component > Works as expected
- Referenced using v5 Reference by Layer component > Works as expected
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
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.
What is the error message in the Bake Component?
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.