DC Animate RotX issue

I’ve created a component with OnClick attribute animateslow(“RotX”,0,90). Works well, until I rotate my model (e.g. due to geolocation orientation). The component doesn’t rotate around the local X axis anymore, but around the model X axis. If I then rotate the model axis, the components still rotates around the previous global X as if it would remember the original global X axis position.
In the attached model you can see the rotated component that has been rotated around Z, and the adjusted global axes. Now try to Interact.
My expectation regarding the component behaviour was that it uses its local coordinate system. And it actually does regarding to the CS position, but not regarding the CS rotation. I would call this a bug, but then, I’m not an expert :-).
Currently I would appreciate a workaround as I need to adjust my model to the geolocation, which inlcudes rotation.
DynamicComponentIProblem.skp (81.5 KB)

rotation and position is always relative to the parent, wrap the DC with another
wrapper fix.skp (82.0 KB)

1 Like

Thanks a lot! This workaround solves my current problem.
Still, isn’t the model and thus the model coordinate system parent to a 1st level component? And I changed those axes.
Besides, it isn’t logical that components behave according to the parent cs. Should it not alway behave according to its own local coordinate system?
Hereby rotations around Z (doors, windows) aren’t a problem, because models are normally adjusted on the horizontal plane (rotated around Z). But in such case dynamic components rotating around X or Y don’t behave as they should.

Philip is correct. Furthermore this is not a workaround but rather the easiest way.

Think about what happens if you flip a component or scale it or move and rotate it. The easiest to comprehend solution is to insulate all these external transforms from the animation event rotation or movement.

Say you have a drawer in a cabinet that pulls out and in and the wall is on a 45 degree angle. Without the insulating container (group or component) how would do all the calculations? Then what happens if you try it at 30 degrees etc.

This solution is elegant and keeps the math simple and therefore not a workaround

1 Like

Yes, Philip is correct and the wrapping does solve the problem, but I see it as a workaround. I don’t see why transformation math is any simpler within a wrap than it would be just within the local component coordinate system (CS). Therefore I also don’t see any elegance in having to wrap a component into a group or component just to retain control over the transformation CS. There is even more transformations required since we have one more CS between the component and the model. So again, what is the reason that DC transformations are related to the parent CS instead of DCs own (local) CS? Where is the elegance of it? Sorry Garry, but your drawer example doesn’t explain it. In my view it would be quite simpler and more consistent and easier to understand and use if DC tranformations would relate to their own CS.