Rotation attributes snap to relative to parent when animated


This has been bugging me since DCs first came around. I thought I had a simple workaround, but I can’t remember what it was. I’m open to either a logical explanation as to why this is OR others validating that this is in fact a bug…

The situation is when a child component’s axis is NOT the same orientation as the and that child axes is then rotated via an onClick or a redraw. It will snap to the same orientation as the parent. This does not make sense to me.

For instance, in the above screenshot of the attached “AxesJump.skp” file the Component Attributes are pretty simple. Using the Interact Tool on the thing should animate the child’s RotX value… which it does but not before snapping the axes so that it looks like this:

Ok. There might be a reason for this. Returning the RotX value to a non-set (i.e., “grey”) value of zero, I would have expected, returned the DC back to the state in the first image. Note the value of the RotX attribute in the first image and compare it to this:

I’ve effectively reset the attribute values back to where they were pre-onClick, and the child does in fact rotate “back” to zero, but its orientation is still where it snapped to, which is relative to the parent’s.

Now try this: redownload the “AxesJump.skp” file and before doing anything, right click and select Dynamic Components --> Redraw. Anything happen? Probably not.

Finally, I have attached a AxesWorks.skp file which works for what I am trying to do, but it seems unnecessarily hacky as it involves making a grandchild component whose axes is the same as the not-the-same-as-the-parent-axes child component.

Thoughts? This may have been discussed before at the old Google forums or at SketchUcation but I can’t dig anything up.

– Matt
AxesJump.skp (199.5 KB)
AxesWorks.skp (236.4 KB)

ps. SketchUp team, I am really digging this Discourse forum!

edit: Also attached is AxesElaborate.skp… which better illustrates why I am interested in this. I would like to animate multiple children whose axes is all a different orientation as the parent. This file uses the same grandchild attribute-passing hack as AxesWorks.skp.

AxesElaborate.skp (46.9 KB)


So you are saying DC’s should rotate around their own axes rather than their container’s axes? Doesn’t that mean rotations would have to be entered as relative to the DC’s current position?


Short answer is yea, I think the RotX value should be relative to the components current position, but you actually gave me the explanation I was looking for as to why it does what it does. But it seems contradictory to say the Size attributes, which describe the contents of the component. Maybe it is just the way it is :confused:

Does how it currently function make sense to you Jim? I am trying to convince myself that I’m ok with it working as designed…


It seems to me that the size attributes describe the size of the container rather than the contents. The contents get stretched to fit the container.

It does make sense for most things - except when it doesn’t as in your case. Rotations need an axis of rotation. This could either be the component’s axes or its container’s. Maybe DC’s could be re-made to use their own axes for rotations and it might work great; maybe not. The question I have is if component’s used their own axes, how could set a rotation to say 15°?