Activating “Simulate Physics”, both in editor or in c++ code while playing, on Static Mesh that is a child of a scene component used as root, causes the child mesh to translate to origi (0, 0, 0), while the actual actor remains at the same position.
Without any logical reason, the child mesh Relative Location is set to the opposite of the Absolute Location of the Actor, so the sum of these 2 is always 0, 0, 0; the child object always ends up in the axis origin.
I don’t know if this happened in 4.6, but i’m sure it doesn’t happen if the Static Mesh is also the root component.
I’ve recompiled and my code is fine, it’s a bug in the engine.
It also happens at runtime if i SetSimulatePhysics(true), and in the editor, when i click Simulate Physics(True).
System Specs: Win8.1 x64, Intel i7 2600K, 8GB Corsair, Nvidia 670GTX 3GB.
There is no relevant Log.
Thank you for reporting this. I’ve been able to successfully reproduce this and have submitted ticket UE-11266 for this issue. Once a fix has been submitted I’ll update this post.
i might have a clue of what is going on since i managed to bypass the bug at runtime.
the problem i had only happened when i was trying to “manually” update the position of a Child Static Mesh, together with it’s father, in code.
Is you set the WorldLocation of the RootObject, and then in the following line, you set the RelativeLocation of the ChildObject, the Relative Location gets calculated from the position the RootObject was in the previous tick, or anyway, before the previous line.
This means that the Change you just made to the World Location of the root, doesn’t get considered when you set the relative location of its child in the same tick, and so the result is that the root of the object is moved where you want, but the relative location of the previous object become messed up and sometimes goes to the Origin and sometimes remains in the previous tick position.
i think this is also the cause of the bug described here.
I’m also struggling with this issue, and I really need the GetMeshLocation to work. Do you happen to have an estimation for when this bug would be fixed, or which version it would be coming out in Tim?
Sorry no update at this time. A lot of the devs were at GDC this past week so things are moving kind of slow at the moment. Once any relevant update has been made I’ll post the information here.
Hi Tim, as it’s been a while just checking when we can expect a fix for this issue; I’ve run into the same problem that and jechli described and looking through 4.9 release notes it sounds like this issue is still extant. Thanks for looking!
There hasn’t been any movement towards a fix as of yet due to other priorities. It has been marked as “To Do” but there is still no time frame for when this will be addressed. I’ve bumped the community interest in seeing this one fixed. Once there is a fix I’ll post an update back here.
Hi I discovered a workaround and thought of posting it here in case others find it useful. In short - calling RecreatePhysicsState() on my dynamic static mesh component fixes the origin reset issue. I’m calling it just after setting the mesh’s location but before simulating physics. May not work for all cases, but it does seem to help with a some of the physics oddities I’ve been facing with dynamic mesh components.
I discovered this when I noticed that for skeletal mesh components (which also exhibit this issue) simply resetting the collision profile to any dummy and back had the side-effect of fixing a bunch of physics issues including one where OnComponentHit wasn’t being called upon Hit. RecreatePhysicsState seems to have the same effect.
Another workaround I discovered (especially for dynamic mesh components which are spawned at runtime) is to not simulate physics at the same tick where the mesh is created. i.e you use a timer or queue-ing mechanism of some sort. This presumably gives the mesh a chance to set up its internals.
In summary - calling RecreatePhysicsState() on your mesh component is worth a shot if you’re facing weird physics bugs on dynamic mesh components. Hope this helps.
