Okay, now that is even better. So in the new plugin since you have a way around the issue, you might as well add the boolean back in for the bake, right? The Ghost geometry will only be output once the bake is complete I would assume!?
ps: I am curious what the Deconstruct Ghost (?) icon will look like
I managed to get the Export to Rhino File component to export a Rhino file but I don’t understand how the generic export works. Deconstruct file path is a good addition.
Well, the idea was that this would make the boolean input unnecessary, but it sounds like there are lots of other good uses for it anyway (Grasshopper Player, etc. and others mentioned).
Haha, so am I!
Yeah it needs more work. But the idea is that you can put the IDs of the objects you want to export in the second input, and the first input has a complete filepath including the file extension (so it could end with .dxf, .stp, .obj, whatever you like, and then the component will use the Rhino exporter to do it. Currently doesn’t have the “scheme” input that was there in v4, so will need to add that.
Edit: I actually just tried it, and it didn’t work, so let’s put this component in the “Experimental” category.
by the way I felt strong competition.
Pancake’s baking and block features are long-overdue and should be included in the next major release. Since Elefront is also improving the generic export feature, two plugins have more and more overlapped components. I hope Pancake, as one of my personal projects, would continue.
Just saying. anyway Elefront has a much larger user community.
I mentioned I was having problems with the schemes. I could export DXF files automatically but always had to confirm the scheme in the command line for Step and Sketchup export. Somehow it all of a sudden works for Step but I still have no clue what the scheme input needs to be for a Sketchup export?
I guess EnterEnd would be enough.
I think there is an inconsitency in the export component. It works for DXF and Step but it requires command line interaction for SKP… I guess this could be fixed.
In the new version, we’re trying to use this function in order to avoid using the Command Line, if possible, but need to do more work to think about how the Scheme is set up. It may be that the Command Line is used once to set the scheme, and then this function is used after. Anyway, TBD.
For the existing version, I would think you could use once of these strings as the input for the scheme for the current, Command-Line-based approach in eleFront v4?
I don’t have SketchUp so can’t test it.
None of these work for me automatically.
And you don’t need Sketchup to test this
Attached is my definition and a Rhino file containing two boxes.
elefront_export.3dm (34.1 KB)
elefront_export.gh (16.4 KB)
The Material Name input is gold for people using Keyshot for rendering. Selecting specific material names will allow Keyshot to automatically assign materials on import…
I’ve pushed an update to the PackageManager that has the Boolean input for Bake components added back in. That’s the only change that’s been made for now, just to make it easier for people to continue testing. We’ll address more of the issues found so far in a bigger, later update.
You should be able to find the new version as “5.0.2-beta”. Thanks again everyone - all of the feedback is extremely useful!
Has anybody already tested this on Mac?
Yes I did try it a bit, several times. I don’t remember exactly, and I should make a more exhaustive list for developers (@krahimzadeh), but a lot of things do not work the way they’re supposed to on RH7 macOS. In my recent scripts, every time I wish to use elefront component, I know I should use legacy RH6 components only.
One workflow I am sure has lots of bugs is baking with attributes.
- it’s not possible to bake on child layers - elefront will always create (or bake on) a parent level layer.
- if one try to bake on an existing (parent level only) layer, elefront will always override all layer properties
- object color attributes are not baked
This works fine since VisualARQ 2.12.4 (VisualARQ 2 - Version 2.12.4 released)
Hi, I found elefront’s
Bake Objects loses its contents when I re-open the gh. file,
Re-referencing objects is really a useful idea if I could keep modifying the object before the bake inside Grasshopper or either keep modifying the object after the bake inside Rhino viewport. But that object synchronous possibility seems just to break if the component can’t permanently memorize the data once baked.
I just started to use eleFront currently, and am just getting started to feel like keeping attached to this great app. Thanks!
The normal workflow for this is to bake objects with an identifier such as a bake name, and reference them ‘by name’ later in the script (as per the old ‘dynamic pipeline’).
Alternatively, you could add a recorder node to the object ID’s. But using the bake name is the more common workflow.
Thanks, Patt, got it! For the alternative, I simply internalize the data inside primitive
GUID for the post workflow. I guess whenever it gets to the timing to bake, it’s maybe actually getting close to the documentation process or other things like maintaining and sorting model information; or in early prophase workflow, to reference something that contains some details to prepare for any further complexity…
The Bake component does re-reference the geometry when you bake, but as you point out, it won’t reference any geometry in if you’re opening the script, since the Bake component hasn’t been activated.
As @Patt pointed out, you can use the Reference by Bakename component (it looks like you have a BakeName provided to your bake component, so it should work fine) as a parallel stream for scenarios where you are opening the script, and want to reference geometry in without having to bake it again. So it could be something like using a Stream Gate, to choose from the Reference component only in cases where the output of the Bake component is empty.
That said, we can look at adding the re-reference functionality to the Bake component. I can see how that could be useful.