Hi guys,
(@pascal, I don’t know how’s in charge for this since it might be a hybrid mesh/history thing)
I notice that joining two meshes breaks history.
If I make a polar array of a mesh and then joins a new face to the parent then it breaks history.
But if I add a mesh face to it then the children are updated.
I think Join should keep the first object’s id so history isn’t broken.
Cheers.
Hi Jorgen - yeah, that should work, it seems to me - thanks for pointing it out.
Hmmm, thinking…
So, Stitch in V7 does what you suggest… I’m wondering if it really makes sense for Join - would you expect the same for Breps?Maybe so, but it has never worked this way and I don’t know if I know what the possible consequences might be.
-Pascal
Me neither, but if we can extract a face we should be able to join. It’s kind of what modelling is all about in my book… 
I mean, join keeps layer, material and all other kinds of data intact, so I think history should reflect that too.
Well, this is fairly simple to explain (and I think you know the explanation already)… History is based on object ID. Like with all other Rhino objects, when you join two or more of them, the original meshes are deleted and a new object is created with a new ID (one object=one unique ID). This is even the case for disjoint meshes. Thus, the ID change will break any history relation the original object(s) had with potential children.
Some types of modifications to one object can (could) possibly retain the original object ID and thus keep history intact. However, joining is probably not one of them, as that means two or more IDs become one - probably pretty difficult to decide which ID among the originals should be retained, so trying to keep the history link would be unreliable in any case.
Yeah, I guessed it made a new ID, but I don’t think it should.
No, not really. Just keep the first one in the array, just as Rhino has done for decades when joining surfaces and deciding what material to keep, what name to keep, or which layer to put it on 
Yeah, but those are object attributes and not the ID. What you are asking is certainly possible - in some cases at least by replacing an ID with another - but that simply means the user will always need to remember which object to pick first.
And, in the case of joining or Boolean operations or whatever that changes the object ID - suppose you have a number of objects involved but the result is not a single object. Which ID’s do you choose? In the end there will just be a lot of exceptions and arbitrary assignments…
But It surely is better to be forced to remember which element to pick first to keep the right information, as opposed to know with certainty to loose any history, wouldn’t you agree?
Then you just pop up a message stating that the operation broke history. It happens all the time anyway
But I can’t think of any situations where discarding the original ID is important, do you?
Depends on what “important” means. I’m not disagreeing with you that it wouldn’t be handy in certain cases, but the current system has the advantage in that it is consistent and predictable across all cases, including Joining, Trimming, Splitting, Boolean operations, etc. Trying to make what you want work would require modifying the code for all of those and more, and creating cases for this, that and the other situation - depending on how many objects are involved and what the result is.
I share your point of view there, but it limits the core of history. Joining should keep ID imo. We are after all working on the same object 
Anyway, it would need testing and not only speculations though.