If I import the model, history works on the first one, but not the second. If I insert the core as a block, I have to create the offsets, surfaces, and organize layers 30 times. Any ideas?
I get that I can offset multiple on 30 crvs, but that still leaves me creating 90 surfaces by hand.
Why won’t history just work on the nth import? I know history doesn’t work inside of a block, but that sure would be nice right about now. There’s got to be a better way of doing this.
Sounds like something Grasshopper might be able to do easily (making a uniform offset on originals of varying size and building surface geometry from it.
I think Grasshopper would be more painful to wire up 30 offsets, into 30 sweep 2’s, into 60 planarsrfs, into 30 intersects, into…
It doesn’t matter, I’m prob losing my job at this point. And that’s fine. My quality of life In Rhino has been too awful for too long. All the development is going into subd, and jewelry workflows have been ignored.
These are daily annoyances:
FlowAlongSrf - can’t use groups, doesn’t play well with cylinders, preserve structure useless
Blends - no history on continuity proportions, can’t edit while history locked, can’t preselect blend to edit.
Lock Children - no warning a command will fail, no way to toggle mid command, no option to turn off and continue, no exceptions for commands. You either accidently break history or redo commands all day.
SelParent/Child - can’t deselect before select
CurveThroughPolyline - can’t join control polylines for history enabled symmetric patterns
DragMode - not integrated into Gumball (view)
BlockManager - modal dialog instead of dockable window
Blocks History - no history in block, not all commands support blocks, and there’s no history if you mix regular objs and block sub objs in a command.
Rebuild and Join - can’t keep input and preserve history
How GH works is you “wire up” one offset to one Sweep2 to two planar surfs…etc. Then you feed your algorithm a list of 30 parameters (the offsets) and you have 30 different objects.
As painful as this was, I would hope this history bug gets a youtrack.
The problem is that 1st import reuses IDs from the import file and Nth imports generates new obj IDs to avoid a collision, but forgets to gen new history record IDs.
Editing 1st import triggers history on 1st import.
_HistoryUpdate _All triggers history on all Nth imports
Editing Nth import reports “History updated xx objects.”, but Nth children are not updated.
_HistoryUpdate _All reports “History failed to update xx objects.” I’m assuming these are on the 1st and any other Nth import, because they all share the History Record ID.
So, I think what you did not say up top is that you are offsetting with History, then importing the file, is that correct? You are not importing the file as posted, it also includes the offset with history…correct? And, for now, if you import the file as you posted it (no offset) and copy it 30 times scaling as you need, then OffsetMultiple, does that not work to offset all at once?
At any rate, importing multiples, if it is as I said, ought to work with individual histories intact, and does in other cases - I’ll get this on the pile…
I say “history bugs out” because the unintended behavior depends on the command used to create the history. In this example, Pipe causes the 2nd import’s child follow the 1st import’s parent crv.
There’s a couple of commands that don’t play well with paste/import history. I’m making a list and will type them up. So far it’s BlendSrf and Sweep1/2.
Without those cmds, it was hard to make the bottom of the bezel match the finger size. I can’t think of any other surface creation commands that allow you to match continuity. Still, I came up with a workaround using Loft Loose.