Rotation in authoring adds random CompositeScale component

I have a bunch of meshes that were quickly exported from a modelling program and just as a quick correctional measure I rotated all the objects to the correct orientation because the axis in Unity is different.



When I have this rotation applied, the resulting entities have this random CompositeScale component added to them:



The component disappears when no rotation is applied. Is this a bug? I don't want scaling to apply on my entities because apparently scale isn't supported yet in unity physics.

I'm using entities 0.11.

Is this a bug or something intended with the conversion workflow and transform systems? Rotation shouldn't have anything to do with scale especially if I can spawn an entity without rotation and then edit the value myself for the same effect without this extra 4x4 matrix clogging up my chunks.

 

I'm seeing the same thing, and it's quite annoying. When I remove the rotation, the entities are fine - except it looks wrong. In my case, there's also no actual scale (it's all "unity-scaled", i.e. (1,1,1)).

 

Are you experiencing this with entities 0.14? I haven't tested this again but it's annoying that this is still an issue.

 

well, i don't know if this is an issue or intentional because of some convoluted reason i don't understand. Hence the point of the post!

 

I haven't. I'm on Unity 2019.4 and can't update to 2020 due to the mess they've created with VR, so I'm hoping that I can work around the issues I run into with 0.11 (I may actually be able to fix this specific issue in the package, if it doesn't get any updates anymore, anyways).

 

Turns out this happens in Unity Physics, in ConversionExtensions.PostProcessTransformComponents(...) to be precise. I'm not sure why this would be true if scale is (1, 1, 1), just due to a rotation - but when I comment the whole thing out, the issue disappears (and there are probably now new issues that I'm not aware of ;-) ):

Code (CSharp):

1. if (math.lengthsq((float3)worldTransform.lossyScale - new float3(1f)) > 0f)
2. {
3.     // bake in composite scale
4.     var compositeScale = math.mul(
5.         math.inverse(new float4x4(rigidBodyTransform)),
6.         worldTransform.localToWorldMatrix
7.     );
8.     manager.AddOrSetComponent(entity, new CompositeScale { Value = compositeScale });

 

Nice work finding the cause! I can confirm on my end that when the physics package isn't installed this issue doesn't occur.

Though, surely the post processing of transform components should happen in the core entities package where...the rest of the transform processing happens.

 

As far as I understand this (which is quite limited - I have just started working with DOTS / Unity Physics quite recently), scaling is a tricky thing with physics while it's much easier to handle for rendering. Plus, entities need to be unparented in certain cases (possible all cases) to play well with the physics simulation, so that adds another constraint that only exists when Unity Physics is being used.

If you look at the context of this specific code, it is related to the unparenting - and you get a message about that in one of the Unity Physics authoring components.

So, I believe it does makes sense to keep that for Unity Physics only.