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.
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!
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?
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.
