I’d suggest trying an instanced static mesh component along with UpdateInstanceTransform and see if that gets you better performance. Should also reduce the number of ticked actors too.
You can look at World Position Offset in materials to give the effect you want too - could also connect the offset to a ‘per instance random’ node to give random variation in the vibration of each instance.
I have hundreds (thousands potentially) of simple blocks oscillating (trembling, vibrating, whatever you want to call the motion) based on sound input. The higher the frequency, the faster the oscillation - the louder the amplitude, the greater the oscillation amplitude.
I’m using SetActorLocation every tick to update each actor. With about 250 of these block actors (the class is a child of AActor), the framerate drops to about 1FPS or worse. If I remove just the SetActorLocation line for that class, it chugs along nicely, so that’s definitely the problem.
Is there a better way to do this than SetActorLocation? For example, would setting the component location be faster (not sure how to do that)? Or, something like rigging up a material that appears to make the actor move without actually moving it (I could probably figure that out, but if someone thinks it would indeed be faster and would point me in the right direction as to how to do it, that would be greatly appreciated)? Or any other ideas?
Thanks!
Zach
Thanks for the fast response!
Setting the World Position Offset worked like a charm. I’ll also look into trying an instanced static mesh component, just out of curiosity, but I got 0 framerate hit from adjusting the world position offset (which makes sense), so I’ll probably stick with that so I can expand to thousands or tens of thousands of these blocks.
Sure. Bear in mind though that the instanced mesh component is designed for these sorts of situations and will potentially assist with memory consumption amongst other things as you scale upwards.
To clarify - try using an instanced mesh component, but rather than translating with the call I mentioned above, keep using the WorldPosOffset. That way you get the best of both worlds- reduced memory consumption but also the dynamic movement you want.
Yeah, that makes complete sense. Working on setting that up at the moment, and will report back on performance results when it is complete.