I am arraying an object along a curve.
I am deleting some child objects.
I transform the parent.
Children get un-deleted and clutter up my work space .
Hi Yianni- yes, there is a bug there- fixed in the next version if I recall correctly.
Next SR or next Rhino version?
Hi Yianni, actually, sorry, I ‘misspoke’- there was a fix along similar lines but replaying history has to restore the full array, there is no way around that.
Oh i see.
That is unfortunate
I hoped you would identify this behavior as a bug to be fixed.
See, Rhino does report that history is broken when I transform a child, yet it chooses to restore a child, causing “debris” in my document.
Is there not a logical fallacy here?
This problem has been reported and discussed several times.
I don’t recall the fundamental reason the behavior can not be changed but it currently can not be fixed.
I hear you John.
Thank you for making it clear.
what has been fixed is that a child object that is edited and there for has history broken, stays broken- it does not move back into the array if the array is updated via history. But, the array that is updated is still the full array, the broken children stay whereever they are. Logic restored…=)
The only thing we could do is to break history on all of the objects if one was deleted.
We decided that while more “pure”, that easier to break option was less useful than this odd undeleting behavior we have now.
If un-deleting a child restores history (and logic), should it also happen with mirror?
Mirror one object,
Transform the child,
Child does not rise from the dead. (which is a good thing)
Well, I can’t argue with that! I think the array process itself has to place all of the objects if it is going to place any, but I agree it is different at the top level at least from Mirror.
The difference, I would guess, is that the command needs all of the objects to re-figure the spacing along the line, so you can still edit the line if desired. With Mirror, the mirror plane cannot be updated so the relation of the remaining objects to that plane is constant.
This was driving me crazy this week (I had multiple copies of the arrayed objects updating as well), and I thought I could get around it by grouping and hiding the objects I didn’t want instead of deleting. It didn’t work, it was even worse, because while the correct number of hidden objects would stay hidden, they were not in the same positions of the sequence.
Reminded me of the problem when I have accidentally made two identical copies of a group of objects, and I use SelDup Delete, and some deletions are taken from one group and others from the other so the grouping goes wonky.
I’m also having an ArrayCrv + History problem, but with per-object assigned materials. The parent has Material1 of 6. After the history-enabled ArrayCrv, editing children’s materials will unify all other children and the parent with the same material. This is a big problem for me.
Can the material not be separate? Or at least, I’d have thought that children’s materials can be edited after the ArrayCrv command, as this is the only thing I want history regarded for.
For v6, do you plan sth like a “History Editor” which lists which transformations and properties are currently tied into history? It’d be nice to be able to isolate them.
Hi Duncan, I think ArrayCrv with history is somewhat compromised, so to speak, in how it treats objects because the number of children can vary depending on edits to say the length of the curve. I remember there were different bugs with this and other commands that have variable numbers of children needing special History treatment - I’m not sure that is the problem here, but it seems possible at least - I’ll ask…
@mikko - is this fixable, do you think? Changing the material on any of the objects in ArrayCrv with History sets them all. Object properties like wireframe display color can be set per object though, so that gives me some hope…
@pascal, @DuncanW, ArrayCrv should not be any more compromised than anything else. For example Copy command works exactly the same: By default the original and copies share the material, but you can make the materials unique by following the instructions on top of the material panel. Select the object you want to edit, in V5 click “Duplicate” to make a unique material copy, in V6 click “Create a unique editable copy”.
Thanks for your repsonses.
Unique materials are exactly what I’ve done though. Changing one child still changes all of them, and vice-versa.
Yeah, looks like material duplication and assigning isn’t working the way I thought it would. I’ll have to dig in deeper to try to figure out what actually is broken. It has nothing to do with ArrayCrv though. Seems to me assigning unique materials work if the original object material is “by layer”. Here’s what I originally did to test this: Drew a sphere, by default the material is “by layer”, drew a curve, used ArrayCrv to make multiple copies of the sphere along the curve, selected one sphere, made it use “by object” material, and then edited the material. It was only applied to that one object, and stuck through history updates.
I have spheres too and the exact same setup. But when I change any of the per-object materials on the spheres, all affected by history will assume it.
I’ve noticed the problem is fixed when cycling the material through layer/parent/per-object on the object in question. Just once to refresh the object, kind of. Then choosing per-object will stay. History stays intact.