koobas.hobune.stream
Incorrect meshes after non-uniform scale?
Create empty GameObject
Add an imported mesh/prefab to it (a Unity primitive will do, too)
Modify scale of parent to be non-uniform (e.g., strech or mirror one axis)
If you now modify the rotation of the child in the Inspector transform field, the mesh distorts correctly according to the non-uniform scale (note that for Unity primitives, the attached collider will not scale correctly, but that's not the issue here).
However, if you modify the rotation any other way - either by dragging the rotation Gizmo in the Scene View, by attaching a rotation animation, or by modifying transform.localEulerAngles via script - the mesh is NOT updated correctly! It just keeps the current mesh deformation and rotates this deformed mesh locally around the selected axis. Only after modifying any of the Inspector transform fields, the mesh is recalculated and flips into the updated deformed state.
Calling mesh.RecalculateBounds() after modifying transform.localEulerAngles does not change the behaviour. Also, using transform.Rotate() or setting transform.localRotation instead of transform.localEulerAngles doesn't help, either.
So my question is, what does the Inspector transform do differently, or more importantly, what do I need to do to correctly update the mesh after modifying its rotation?
EDIT: Some further info: The problem is still present in the current version 3.4.2f2. Also, it seems to depend on the import type/format whether a mesh shows this problem or not. After testing several imported meshes I had available, it seems that:
the problem occurs if the mesh is a Maya .mb, Blender .blend, .fbx file, or a Unity Primitive.
the problem does not occur if the mesh is a 3DMax .max file.
This is of course just circumstantial evidence, the actual reason whether a mesh shows this bug or not might be something else. For example, I did find a .max file where the bug occurs, 10 other .max files worked.
UPDATE: This problem seems to be fixed for the rotation Gizmo in 3.5.x , but not for modifying the rotation via script.
I hope your issue has been fixed, but I just have to throw some kudos your way, because part of the description of your issue has just fixed my custom character editor. I've been pulling my hair out over this for weeks. Thank you SO, SO much.
"the problem occurs if the mesh is a $$anonymous$$aya .mb, Blender .blend, .fbx file, or a Unity Primitive. the problem does not occur if the mesh is a 3D$$anonymous$$ax .max file."
Solid gold. I exported a test cube, and it scales perfectly. Now all I have to do is re-export all my armors and weapons and characters and... Well, it sounds daunting, but methodic labor is far better than $$anonymous$$r-jerking troubleshooting. You may have spared me a heart attack.
H Wolfram! I also stumbled on to this strange problem.
Just as you say, recalculate/etc has nothing to do with the issue.
For me, the solution is: disable, and then enable, the mesh. So for example,
// annoying disable/enable trick that sometimes seem necessary ...
GetComponent(MeshCollider).mesh = theMesh;
GetComponent(MeshCollider).enabled = false;
GetComponent(MeshCollider).enabled = true;
{Just as Wolfram says below "And the amazing thing is, it even works if you simply set active=false; and immediately after that active=true; , all in the same Update() call."}
To be clear I have to do this at run time as well, programmatically, to make the mesh "take". I hope this is relevant to the exact problem you're having.
Hm, I can no longer reproduce the first part of my problem (using the Scene View Gizmo) with the current version 3.4.2f2. Which version are you using? Haven't tried the scripted methods again, so can't say whether they still have the problem.
Update: Whoa. Ignore that. I was testing a model that didn't have the bug. It seems it depends on the model; I extended my question to reflect this.
And your solution does work, thanks! And the amazing thing is, it even works if you simply set active=false; and immediately after that active=true; , all in the same Update() call. Apparently the "active" flag is a setter, which by itself changes additional internal flags/settings when written to.
Hi Wolfram, yes understand exactly what you mean. It's a little bizarre!
Did Not find a solution for the deformation...In the end a quick fix was to make the child independent from its parent..(solves all problems in the world)...and have a script to keep updating its position towards the parent all time...
