[Info] Allowable Classes for "set_attribute"

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.

Dan Rathbun

... ya know how much we hate these "secret behaviors"!

tt_su

@dan rathbun said:

... ya know how much we hate these "secret behaviors"!

I sure do. Unfortunately some of this is very old code going way back before what the source control system has any info about. Occasionally someone who's been around long enough from the early days will recall why something was made the way it was - other times it's one of them mysteries.

eneroth3

My railroad plugin relies heavily on these data being transformed. When a track is manually moved the bezier control points are moved with it and read by the extension so it knows where the track is located and trains can run on it. I was quite worried how to code this until I accidentally ran into this behavior. It can be really useful and if you don't want it it's easy to store the coordinates in an array instead of Point3d or Vector3d (which is what I do in another part of the plugin).

However this really really really should be documented!

tt_su

@eneroth3 said:

However this really really really should be documented!

Indeed. I'll look into this next week to check out what you indicated to be inconsistencies. That worries me.

Aerilius

If I understand it right, an attribute with the same Point3d object that an entity uses (for example directly obtained from the entity face.vertices.first.position) will move with the entity.
A clone/copy of such a Point3d (like point + [0,0,0]) might have initially the same position, but does not show this behavior.

If this behavior is documented, then it's fine. If it is decided to cleanup/simplify it by removing that behavior, we could (?) still use a Point3d relative to the entity/group's boundingbox origin, which will move with the entity. Does that make sense, Christina?

[Info] Allowable Classes for &quot;set_attribute&quot;

[Info] Allowable Classes for "set_attribute"