SetActorTransform breaks collision for InstancedStaticMesh

Hello everyone,

I am working on some procedurally generated buildings for my project, and found a rather unpleasant bug. I have an actor called SegmentRoom, which currently consists only of one InstancedStaticMesh. It has all collisions on and generates a floor of given dimensions, exposed on spawn. I spawn it from the level blueprint, and If i feed the transform to the Spawn node, everything works fine, I can stand on the floor and colide with it properly. HOWEVER if I spawn at some other location, and then use SetActorTransform on the ReturnValue of Spawn node, the collisions are gone. I fall right through any instance created with InstancedStaticMesh.

Tests I did:
Added a normal StaticMesh - it retains it’s collisions, ISM stil looses them.
Using SetActorLocation / SetActorRotation Nodes separately - collision lost.
Turned on all the fancy opcions in under Physics of ISM - no effect,
All possible combinations of Sweep and Teleport on SetActorTransform node - no effect.

I am working on 4.12.5

Thanks in advance for any help, or a workaround at least. I know that for a simple room I could probably make a floor another way, but I am going to create some more advanced assets this way, and many times I will NEED to transform the actor afterwards, because each segments has components that mark where he can connect with others, which are added in construction script according to exposed parameters.

Hello Sellis Simoh,

I have a few questions for you that will help narrow down what issue it is that you are experiencing.

Quick questions:

  1. Can you reproduce this issue in a clean project?
  2. If so, could you provide a detailed list of steps to reproduce this issue on our end?
  3. Could you provide screen shots of any blueprints/setting that may be involved?

Okay, so here goes reproduction of the problem:

I created new blueprint project with third person template and started assets. I created an actor called ISM (consisting only of default root and Instanced Static Mesh Component),Set mesh of the component to default cube, and in construction script I told it to create an instance at it’s root, in world space. (I use the same method for my original project, except any procedurality would go here)

Actor:

98668-ism+-+hierarchy.png

Defaults for ISMComponent

Construction Script:

So far so good. Now, in the Level’s Event graph if I spawn one ISM actor at given location, everything is good, If I spawn it and in the very next frame move it - collision is broken.

Just now I ran some additional tests. As before, no combination of sweeping/teleporting on SetActorLocation helped. I put a delay between spawn and moving to eliminate possible origin of the problem being execution within one frame. I added instance using local space, not world.

And then I found a fix.
It turns out that if after moving you call “UpdateInstanceTransform” with ANY settings, colision updates. Even feeding tha instance it’s own current transform back is enough.

I am not an expert in unreal, but for me it seems that when instances are moved externally, dragged with the actor, their colision hulls get left behind. Further evidenced by the fact that if you place the actor correctly (with updating of instance transform) and then move it elsewhere “the bad way”, you can still stand on it’s previous location, as if it was there. (Standing on it when it is taken away results in being pulled waist-deep into the ground, though)

I don’t know neither how hard / suboptimal would it be to tell ISMComponent to force update of transforms on all it’s instances when it’s moved, nor if it’s perhaps intended behaviour, because instanced static meshes were designed to create inexpensive static scenes rather than to be moved around. But in any case I am willing to help and provide you with any information needed. I hope I helped :slight_smile:

Sorry for not replying here but in the thread, I got confused. Anyway, replication is there, in an answer below

Hello Sellis Simoh,

After reading over your reproduction steps I was able to do a bit more digging and find that this is a known issue (UE-13673) and that it has been resolved internally. This solution will be available in a later release of the engine. I hope that this information helps. Thank you for your time and information.

Make it a great day