[Info] Allowable Classes for "set_attribute"

[kwalkerman]

Dan,

Good point. A quick check indicates that any point with the same x,y, and z values can access the attribute.

--
Karen

[Dan Rathbun]

@kwalkerman said:

Good point. A quick check indicates that any point with the same x,y, and z values can access the attribute.

Karen

.. thot so.

This could be bad,.. or good, depending on what your doing. If you wanted to store some explanitory text for ANY point with certain x,y,z co-ordinates like "at the hinge point" then this feature might work ok. (Of course, nil will be returned if no such "point-key" exists in the dictionary.)

[kwalkerman]

Dan,

For applications I can think of, this is actually an advantage, especially if you are using attributes between sessions, as the 'entity' attached to your particular point3d would be lost. AND, it works just like any other key for attributes.

string1 = "My Attribute"
string2 = "My Attribute"

entity.set_attribute "a", string1, "q"
entity.get_attribute "a", string2 ==> "q"

string1 and string2 are different objects, but both can reference the same attribute dictionary.

--
Karen

[jiminy-billy-bob]

Shameless bump, it would be great to add this to the online docs. (TT, if you read this...)

[eneroth3]

Perhaps it's worth mentioning that Point3ds and vector3ds are transformed along with the geometry they belong to when using move tool or rotate tool on it.

[Dan Rathbun]

Geom::Point3d and Geom::Vector3d are virtual classes. Instances of them do not actually exist in any entities collection. Sketchup::Vertex however, does have instances "in the model."

Can you be more specific? (Your statement seems vague.)

[tt_su]

Christina is correct, any Point3d and Vector3d stored in an Entity's attribute will be transformed along with the entity itself.

I don't have a list of what classes can be stored, I'll look into it.

[eneroth3]

After some tests in SU2013 I found out that these classes are not transformed when using move!, transform! or transformation= on the entity, but they are when using the move, rotate or scale tool on it.

This might be quite useful for custom animations scripts since things like rotation axes etc can be saved as attributes to the entities being transformed without be changed by the animation. When creating the mechanic parts for my railroad plugin I turned these data into normal arrays to avoid them from being transformed but perhaps that wasn't required.

[tt_su]

Poking into the source here.

set_attribute converts Ruby values into C++ types. The functions that handles it deals with the following types:

True/False
Length
Integer
Float
String
Array (Containing any of the other types)
Color
Time
Point3d
Vector3d

And if its not any of those types it appear to silently ignore it. An empty setting is written. (It'll write the key, but value will be empty.)

[jiminy-billy-bob]

Thanks for the list!

[Jim]

Does "allowable" also mean these types are converted back into their original object types by get_attribute?

(I know it does, but didn't see that explicitly mentioned in the topic.)

[tt_su]

Yes, they should. But there might be some quirks in the underlying implementation of storage, where Windows stores to the registry and OSX saves to a plist. I think I recall some escape character issues on one of the platforms - though I don't recall the details. Might have been fixed.

[Jim]

@tt_su said:

But there might be some quirks in the underlying implementation of storage, where Windows stores to the registry and OSX saves to a plist.

We were talking about attributes, not read_default, write_default. Do they act similarly?

[tt_su]

@jim said:

We were talking about attributes, not read_default, write_default. Do they act similarly?

Duh! That's just my brain not coping with the jet-lag properly. You're correct - it was read/write_default that had that issue.

...gonna go and lie down for another nap...

[Jim]

@tt_su said:

Christina is correct, any Point3d and Vector3d stored in an Entity's attribute will be transformed along with the entity itself.

What a quirky thing. Is this a side-effect of some other code, or an explicitly designed behavior? If designed, for what purpose?

[tt_su]

It's explicitly coded, though the code doesn't mention the historical reason..

[Dan Rathbun]

@tt_su said:

It's explicitly coded, though the code doesn't mention the historical reason..

OK now I understand what Christina was saying.

I agree with Jim. I can think of a situation, whee I'd save some point in the model (which is relative to the world origin, and I would be rather ticked if SketchUp applied a transform to MY attribute without MY permission.

How would / should SketchUp know what the value of my attribute was for ?

[tt_su]

If you want to ensure the data isn't transformed, convert the Point3d or Vector3d to an array.

[Dan Rathbun]

I know this. It does not negate what I said. If I store a point that is inside the group, relative to the group's origin, and move the group, ... I would not want the point to be transformed.

WHO decided that this should happen, WHEN and WHY ? (If this was for DCs, then it should only happen to attributes in the "dynamic_attributes" dictionary.)

This is the first I am hearing of this. Is it documented anywhere ?

---

It would be nice to specify things as absolute (world co-ords,) or relative (local co-ords.)
Thinking, what if we had subclasses: LocalPoint & WorldPoint ?

[tt_su]

@dan rathbun said:

I know this. It does not negate what I said. If I store a point that is inside the group, relative to the group's origin, and move the group, ... I would not want the point to be transformed.

Just saying, that is the existing behaviour. It caught me off guard as well and initially I wondered if it was a bug, but when looking at the code it was made deliberately. There are use cases for and against this.

@dan rathbun said:

WHO decided that this should happen, WHEN and WHY ? (If this was for DCs, then it should only happen to attributes in the "dynamic_attributes" dictionary.)

I don't know when, why or who. As far as I can tell this code goes way back and it doesn't mention these details.

@dan rathbun said:

This is the first I am hearing of this. Is it documented anywhere ?

It came to the attention to us (the Extensibility Team) just recently. I'm not sure if it's mentioned anywhere.

For all intent and purposes, it is what it is. We cannot change the behaviour now without probably breaking things. We do need to document it though, make it clear that Point3d and Vector3d will be transformed, but arrays will not.