Bug or Feature? Some attribute values affect other copies...

matthew.robert

Thanks Scott,

I am pretty sure you have explained that before too, I somehow have trouble getting it to sink in but it is starting to make sense.

I am trying to wrap my head around the role these 5 things have:
Custom attributes
non-custom attributes
Attribute values (or "fields")
Instance
Definition

Is it correct to say that attributes are stored in the definition but it is the actual attribute values that are stored in either the instance or definition?

A little experimenting makes it seem like initially a custom attribute value is stored in the definition BUT if an instance is edited then the (apparently inherited) value is stored in that instance as well as passed to non-edited instances (sort of).

Here is some experimenting I have done that illustrates what I get and don't get:

Make a simple one-shell DC and make 3 copies (with the Move/Copy tool) for a total of 4 instances.
"attach" the LenZ attribute and set it to =100 in one of the instances. All change, although they require a right-click redraw to reflect the "=100" change. This makes sense because that attribute value is stored in the definition. Changing one changes all (again, redraw required to see change).
"attach" the RotZ attribute to one of the instances. It only shows up in that one, but that makes sense because it is always there in the background, no? It can be attached to all instances and each one can have its own value or formula. This makes sense because this value is stored in the instance as are all the position and rotation attribute values.
(here is where I start to get confused). "attach" a custom attribute called "foo" to one of the instances. Without entering a value, I can see this attribute is now attached to the other three instances automatically (not to be confused with the RotZ attaching in the previous step which only shows up after it is attached to each one, but again that is because RotZ is always really there, it just cannot be seen/edited all the time unlike custom attributes which are not always there...) Anyway, this makes me think that the actual Attribute itself is like a box that is waiting for me to put something in it (value) and that box is attached to the definition because I saw it in all instances.
Give "foo" a value of =100 (I happen to be doing this in the original that I made copies from with the Move/Copy tool, maybe it does not matter). This value is now displayed for each instance... making me think that it is attached to the definition.
Change the "foo" value in the same instance that the original value was entered to =200. Again, the value in all instances changes reinforcing notion that it is a definition-stored value.
Change the "foo" value in one of the other instance to =300. All of the instances reflect this EXCEPT the one that was edited in steps 5 and 6... Where is the value stored now? It is as if it is a conditional storage where it is stored in the definition UNLESS the instance value has been manually edited. But it gets more confusing considering that the other copies that have not been manually edited will now inherit this value. Go to each copy and enter a different value for "foo". The "foo" value now appears to be unique and thusly instance-stored.

7.5. Grab an instance of this DC from the Components Browser, the last edited "foo" value is the one that comes along for the ride. Is there a "foo" value being stored in both instance and definition then?

This is a tangent issue of confusion but somewhat related. Attach the "LenZ" attribute, whose value is somewhat understandably stored in the definition. Set its value to "=foo" in one of the instances. Now right-click redraw each instance. Well, ok, NOW it seems to work in tricking a definition-stored value into being unique which contradicts what I had found out before:


I thought I could trick the copies to have different values by making an intermittent custom attribute and then setting the size attribute to equal that, but the actual custom attribute values are tied as well.

And I now see why I thought that earlier. If Step 8 were to happen right after step 6 it would appear that the custom attribute value was definition stored and not instance stored.

Is there a reason that custom attribute values are initially inherited in other instances and subsequently inherited from edits if not manually entered?

Phew... my head is going to asplode. I think by typing all this out I might understand better how things work, but they why is still not sinking in. I am not sure if it is related to all this, but the next item I want to wrap my head around is at which point or at what sort of edit is a unique definition created.

Your comments on my comments would be greatly appreciated Scott! (or any other DC savants)

-Matt

Chris Fullmer

Well said. I agree there are some inner working I wish I had a better understanding of. Hopefully in time I'll get all of this down solid too. Here's something I noticed though,

In #7, I got the same results. The first box does not get the updated Foo value. But it will if you "redraw" the DC. So the custom attribute is actually stored in the definition, it just isn't being updated until the redraw, kind of like you described in #2.

So try that, see if that answers the rest of the confusion in 7.5-8. We need a chat room where or a conference call or maybe Scott wants to have a nice sit down with us who really want to understand some of these things. Scott, you wanna fly us out to Boulder? Or maybe next time your in Mountainview we can have a DC conference

Chris

Chris Fullmer

Another thought on the stored on instance VS. stored on definition question continuum:

The Len values can also be stored per instance too, right? My understanding is that light grey value is showing the instances current Len value. If you add an "=10" to any instance, it will then be stored on the definition (and turn black instead of light grey), meaning all instances of that component will adhere to =10 (perhaps a manual redraw will be required to see this though). But the light grey values are showing the instance's Len values. You could add a menu option to the 3rd copy of the component that would allow the user to enter a value for the LenX. The menu option gets add to ALL component instances. But if you select the 4th copy and change that value, then only the 4th copy will recognize thee new LenX. Redrawing the other copies will not change them. So that is effectively a way to say that the Len value can also be stored per instance, not just per definition I think.

Chris

matthew.robert

@chris fullmer said:

In #7, I got the same results. The first box does not get the updated Foo value. But it will if you "redraw" the DC. So the custom attribute is actually stored in the definition, it just isn't being updated until the redraw, kind of like you described in #2.

Nice catch, I see that too now. Dang, right when I had convinced myself that it was an instance stored thing.

matthew.robert

@chris fullmer said:

But if you select the 4th copy and change that value, then only the 4th copy will recognize thee new LenX. Redrawing the other copies will not change them. So that is effectively a way to say that the Len value can also be stored per instance, not just per definition I think.

Chris, if you watch your Component Browser, is a new instance created when you change the 4th copies value that way?

edit Initially that is what I suspected would happen (a new unique instance would be created) but I went through the motions and surprisingly it does not, so yeah... it sure does look like that method makes the Len value somewhat of an instance stored value.

matthew.robert

@matthew.robert said:

@chris fullmer said:

In #7, I got the same results. The first box does not get the updated Foo value. But it will if you "redraw" the DC. So the custom attribute is actually stored in the definition, it just isn't being updated until the redraw, kind of like you described in #2.

Nice catch, I see that too now. Dang, right when I had convinced myself that it was an instance stored thing.

So this is interesting. I found out that if you enter "=100" in one instance in that step, and then refresh all the copies, each copies "foo" value reflects the change regardless of what it was. This would point to it being a definition stored value. BUT if you just enter "300" (or any number) without the "=", then it is treated as if it is an instance stored value. Only that instance changes. Also, referencing the "foo" value in the LenZ (a positively definition-stored value) will work if it has a "=" or not.

The including or not including of the "=" is why I was experiencing this:

@matthew.robert said:

This is a tangent issue of confusion but somewhat related. Attach the "LenZ" attribute, whose value is somewhat understandably stored in the definition. Set its value to "=foo" in one of the instances. Now right-click redraw each instance. Well, ok, NOW it seems to work in tricking a definition-stored value into being unique which contradicts what I had found out before:

@matthew.robert said:

I thought I could trick the copies to have different values by making an intermittent custom attribute and then setting the size attribute to equal that, but the actual custom attribute values are tied as well.

And I now see why I thought that earlier. If Step 8 were to happen right after step 6 it would appear that the custom attribute value was definition stored and not instance stored.

Anyway, I think my entire step 8 can be ignored now because it seems to depend on if a custom attribute value starts with "=" or not.

matthew.robert

@matthew.robert said:

Is it correct to say that attributes are stored in the definition but it is the actual attribute values that are stored in either the instance or definition?

I am going to venture a guess of maybe on this. The reason is multiple instances of a component that has a custom attribute attached to it can be brought in from the Component browser. The custom attribute in any one of those instances can be removed. It appears to only detatch itself from that instance, but there is still only one copy in the Components browser.

Incidentally, I am really keeping an eye on the Component browser to figure out exactly when copies are created and when they are not.

matthew.robert

FWIW, I found a little hack to keep a size attribute attached to the definition, but still be somewhat unique as if it were stored in the instance, at least for one situation.

I have a wall that in one shell, needs to equal the parent!LenX. In another shell, I want the same wall to be equal to the parent!LenX but minus 2parent!wallwidth. If I put LenX =parent!LenX-2parent!wallWidth, and then manually redraw the one that should be the entire length, it gets shortened.

What I did was add a custom attribute to the wall component (that I think the value is stored in the instance, I've gone back and forth on that). This custom component contains either a 0 or 1. The 2nd shell that has the shorter wall gets a value of 1 and the longer one gets a value of 0.

This way, I can use the LenX formula of:
LenX =parent!LenX-2parent!wallwidthoneORzero

I still only have one component, but it works in both situations. For the most part, I have found having a custom attribute that has a 0 or 1 multiplier has been really helpful in various situations. It works nice too in keeping "hidden" copies' values at 0 so there is not a ton of hidden geometries:

copies =parent!lenx/lenx*not(hidden)

ChrisTH

Just saw this thread as I'm experiencing similar issues with the attributes of copied components being 'linked'.

I don't see a general resolution (in the above thread) of the issue or info forthcoming about which attributes are 'instance-bound' and which are 'definition-bound'.

FWIW I'm trying to change the material attribute of each child copy independently, based on certain value of a parent attribute. Each child has a formula + if statement as the material attribute. If I adjust the formula of one copy's material attribute it propagates to all of them.

Is there a way to make the material an instance-bound attribute or else can anyone suggest a script workaround where the parent can set the material of each child independently?

TIA,
Chris.

ChrisTH

OK, NVM... I just found the "Make Unique" right-click option.

This has solved my particular issue