I’d made a rather disconcerting discovery - the scaling behaviour of an actor hierarchy is totally different from that of rotation/translation. Usually you’d expect a child actor to follow a parent actor as the latter rotates/translates/scales. But while a child actor will correctly follow a parent actor as it translates/rotates, it doesn’t do so for scaling! As an example, see image A below, which shows the parent actor’s transform(take note where its axes are pointing).
You’ll see that the child actor gets scaled along its own Y-axis and NOT along the parent’s Y-axis. In other words, scaling a parent actor actually causes a child actor to apply that scaling in its local axes instead of the parent’s axes. This is clearly not the expected result, especially when one considers that translating/rotating a parent actor doesn’t cause such unintuitive behaviour in the child actor. In mathematical terms, this means the child’s world transform is SxCxP instead of the expected CxSxP(where C=child’s local transform relative to parent, P=parent’s transform relative to world, S=scaling transform relative to parent). For translation/rotation, the child’s world transform is correctly SxTxP/SxRxP respectively(where T=translation transform relative to parent, R=rotation transform relative to parent). I’m sure this isn’t a bug per se, but rather a feature by design(though the purpose escapes me), so is there a flag somewhere in the engine to revert scaling behaviour to “normal”?
Thanks for the response, I’m glad someone else pointed out the same problem. I just hope the developers will seriously consider the glaring inconsistency between the way scaling of a parent actor affects a child actor vs the way translation/rotation of the parent affects the child. In the meantime, perhaps you might shed some light as to why scaling was done in this peculiar way?
It’s the most straight forward method of parenting an object. The child/parent relationship for components are of course created to make sure that the child followed the parents transform, but generally uniform scaling is used when objects are attaching in this way. It’s just something that we hadn’t encountered internally until it was reported by OhiraKyou.
I agree, the general use case for scaling might be uniform scaling. But even then, it’s still incorrect for the general case where the child actor isn’t centered at the parent’s local origin(the child’s origin would be expected to shift in tandem with the parent’s local scale when transformed to world space, but the current implementation of scaling will not exhibit this effect). And not to forget it becomes even more incorrect for non-uniform scaling. All in all, I feel this method of scaling doesn’t make much sense(can’t think of any sensible use case). Practically all other game engines I’ve used don’t do this - they just treat scaling in the same consistent manner as rotation/translation.
My sentiments exactly!
This sort of “local scaling” only makes sense in a modelling application where you might conceivably wish to scale things in this very unusual way, but even then it’s not useful most of the time…let alone in a game engine!
The worst is the glaring inconsistency compared against translation/rotation - we don’t see child objects translating/rotating in their own local spaces do we? So what’s with the “exotic” scaling?
At the very least, make it an option to choose whether or not to translate/rotate/scale child objects in their local spaces whenever we transform the parent objects…not force such behaviour without rhyme or reason!
Any news about this? It seems it have been more than a year and the issue is still present. This weird scaling behaviour and the fact that we can’t change the pivot location and rotation, makes it harder to do cartoony stuff with squash and stretch.
