Unexpected History

Hello all,

I’m getting some very odd results with Rhino History. I’m hoping someone here can explain it. I think I’ve figured out the most basic steps needed to recreate what is going on in a bigger model.

Let’s start with opening this file with a 1.50 mm gem, cutter and prongs grouped together: 1.50 mm Bead and Bright with Shared Prongs.3dm (1.5 MB)

Next we’ll use linear array to make 6 of these gem groups.

Then we will ungroup the gems & prongs and delete the parent prongs on the top.

Next we’ll import this other file which has a big line of tapering gems and prongs. Something of note here is that the objects in the file above originally came from this file with the complete set of gems. They were purged and then exported into a new file by themselves. Tapered Bead and Bright with Shared Prongs.3dm (3.0 MB)

Find the 1.50 mm gem group in the tapered line (they are labeled with dimensions) and Move it. The prongs from the linear array behave as if this new set of prongs is the parent!

Why is this happening? How can these new prongs become the Parent for an array that happened before they existed? Time travel? What is going on?


Hi Mike - it does not happen here, but I think I’d need to know when you turn on History. Does SelObjectsWithHistory ring anything up after you do the import?


Hi Pascal,

I have Record History and Update Children on the entire time. I keep it on as the default.

Yes, SelObjectsWithHistory lights up all of the prongs on the arrayed gems. This is after the parent prongs are deleted and the tapered gems are imported.

I’ve got a theory, but I don’t know enough of what goes on behind the scenes in Rhino to know if it’s plausible.

  • The 1.50 mm gem group was made from the Tapered Gem file, so the objects in them have the same RhinoID. (I may bot be using the correct term here, but essentially a unique identifier that Rhino uses to track objects)
  • We array the gem group and then delete the parent prongs.
  • We import the tapered gems. Normally any duplicate objects get assigned a new RhinoID, but because the original prongs got deleted, the imported prongs get to keep their original RhinoID.
  • When we move/rotate those new imported prongs, Rhino thinks that this new prong is now the parent of all of those arrayed prongs in the file.
  • History updates the arrayed prongs to the new imported prongs.

Does any of that make sense?


Yeah… something along those lines, but I cannot repeat it with your file and get no objects with History… . I’ll try to set it up from scratch.