Hi everyone,
After more than a year since we first released the beta, we are finally ready to release the full Version 5 update of eleFront. It is currently available on the Package Manager and will be available on Food4Rhino in the coming days.
If you are new to eleFront, you can follow the instructions here.
If you are a current eleFront user, I would recommend that you follow the instructions for installing the Legacy version alongside the new version until you have upgraded your scripts.
While we have been extensively using and testing the plugin, we of course expect there will still be some bugs along the way. Plus, some of the new features or workflows are not a direct replacement for old methods, and this is especially true for blocks, which have been significantly re-worked. All that’s to say, please take care and give yourself time when upgrading scripts to the latest version.
For more information, including a complete list of new features and how to use them, please check our website. I hope you all find it useful!
Hi Richard,
Well that’s embarrassing! Been a while since I tested it without using any Attributes. If you put an attribute into either component, it should be fine. That said, I will tackle this when I’m back in on Monday - thanks for letting us know!
Hi! I am very new to eleFront 5, I have not tried any other beta prior to the 5.1.1. But have been using elefront on the past version and loved it! with the new update, I am experiencing exactly the same problem as Richard and It also seems the data of the Ghosted Geometry didn’t pass through the first component.
Hi Hendriko,
By default, eleFront will reference geometry from the Rhino model directly, bringing the geometry along with it. To use the Ghost feature, you need to right click on the Reference component, and enable the option to use Ghost geometry.
For starters, the reason for formatting the Layer that way, when converting to text, is that it indicates the object is more complex than simply a string. You can see similar behavior for Blocks, and Block Definitions in the image above. This tells you that the thing in that data flow is a complex object that you can modify, deconstruct, etc.
The asterisk indicates that the item in question has not be synchronized with the active model. So in section (A), the layer coming out has no askterisk, but once you modify it, the thing coming out has been changed, so it helps you keep track of whether the object in your stream is the original or the modified.
However, what’s happening in your example is a bit more nuanced. Reference layers aren’t meant to be modified, and you aren’t meant to bake to them. So eleFront anticipates this, and when you pull in a reference layer, it will automatically create a new copy of that layer that lives in your document. Then, when you bake, it will create the new copy in your active document, with the objects you’ve just baked.
SO. If you look in the Layer Panel in my example, you can see the Box Block has a Reference layer style, the Cylinder Block has an Active reference style. Therefore when you explode the block, the Referenced layer gets duplicated (as indicated by the asterisk), whereas the Active one has no asterisk.
I hope that clarifies, and explains why we chose to display Layers the way we did, in the panels. Hopefully with time it won’t feel so foreign.
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.
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.
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:
