Import File Multiple Times With History

I need 30 of the attached model, but all of them will be a different core size while keeping the same offset.

HeadDiag.3dm (88.9 KB)

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?

Hello - OffsetMultiple should help here - just bring in all but the offset and then offset all at once.

-Pascal

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.

Hello -

! _OffsetMultiple Pause .5 Pause SelNone SelLast PlanarSrf

Is that what you mean?

-Pascal

Ok, that can be scripted. Down to 60 by hand.

History on import solves this problem 100%.

I’m never going to do this job. It’s not difficult, but rates a 10 in annoyance.

Decided to play the offset multiple…

I’ll put a link to this thread in the error report.

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.

And wiring in the 60 rails for the sweep2s and linking them to the offsets? How is this any easier than calling sweep2 30 times.

I guess I am missing the problem - it looks to me like selecting all of the curves and running OffsetMultiple once is all you need.

-Pascal

1 Like

Well, I gave up on an elegant solution and started on the manual OffsetMultiple route but it crashed Rhino.

Doesn’t matter. Bigger point is that I’m 0 for 10 on simple feature requests going back to 2013.

Good news is you can take them all off the list cause I won’t be around much longer.

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.

The is from the parent file.

image

This is the same obj from the 1st and Nth import.

  • 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.
1 Like

bump

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…

https://mcneel.myjetbrains.com/youtrack/issue/RH-56171

-Pascal

It doesn’t matter what the history command is. Any history will bug out on the 2nd import due to a naming collision on the History: Record id: {guid}.

Repro steps:

  1. Create a file with any kind of history.
  2. Import the file twice into another model.
  3. Edit a parent obj from the first model. The 1st changes and the 2nd does not.
  4. Call HistoryUpdate and the 2nd one bugs out.
  5. Call _What on all the children objects and notice the collision on history IDs.

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.