Blocking collision on a pawn with static mesh

I have very many pawns with static meshes (if I do them characters, I get the unbelieveable brakes) and I want to make them move with blocking collisions. Currently they overlap everything, including ground. The CCD is on. I tried to enable “SimulatePhysics”, my static mesh has a simple collision, and I have added mass to the pawn, but the necessary checkbox is still grayed out. The sweep does not work because it sweeps only against root component. Even this very complex solution won’t work because the other actors can also have multiple colliding components (or I don’t know something). What I can still do to have blocking collisions?

It means the static mesh asset does not even have a collider. Double click the asset and add a collider. Or use a blocking volume as a collider while the mesh serves as a visual indicator only.


When it comes to a Pawn with multiple meshes, you’d need to rely on physics to detect collision and use sliding collision. It will work OK with a floating movement component. As in, you expect this, right?

Default collision settings, only the root component simulates physics.

@Everynone, thanks, it works, at least with the ground! I have even disabled the physics (because it also hugely brakes) (if what, my GPU is 4090) and used just floating pawn movement with slight -Z component of the vector. Now I try to package the project and see FPS in the ready EXE. But there is a question: will the box collision in the static mesh be faster than the capsule because of the triangles count? Or is the capsule collision not based on triangles?

Afaik, the collision has nothing to do with the GPU (unless you we’re talking special Niagara particles). It’s all CPU busywork.

will the box collision in the static mesh be faster than the capsule because of the triangles count? Or is the capsule collision not based on triangles?

Don’t quote me on that but there exist, apparently, special optimisations for primitive colliders like boxes & spheres, making them efficient. I’d assume that a capsule is 2 spheres and a box, potentially further optimised with some close-to-the-metal binary magic. I am guesstimating.


But yes, as a general rule of thumb using plain boxes can be a major optimisation providing the scope is grand enough.

How is commonfolk supposed to enjoy the content if your 4090 can’t hack it?! :innocent:

I have tested in a packaged game and got 80-90 FPS with 7k pawns with all reduced-size textures (max 1024x1024, not including some new models on which I haven’t still do that reducing), which is, probably, not enough. Without these new pawns it was full 144 (allowed by the monitor). Which I can still do (disable)?

CPU is 4.8 GHz.
Also I have ensured that the collision works fully. Thanks again!
Also, how to construct skeletal mesh on these pawns on the client at runtime? The “Construct Object from Class” node does not work.

I’d seriously revaluate the script, running a hundred pawns with physics on does not tax my machine. And I’m nowhere nearly top end specs…


If adding some pawns breaks the performance, you have scripting issues only you can identify. For everything else:

It’s a deep dive and there are no easy answers :point_up_2: Also:

@Everynone, will “FloatingPawnMovement” work if I disable also Pawn and make them just Actors? And will actor be faster than pawn? Maybe I can disable something common that essentially breaks performance without very complex work? And:

No. There is no magical button that makes the game optimised. It’s your job to laboriously make it so. There’s a reason entire departments are created to handle that. You can Add Skeletal Mesh Component at run time.


I’d look into what you run on Tick (or every frame in a timeline / timer), especially long loops - the latter being absolute performance killers.

Suddenly my actors again stopped to move without physics! What could I disable that I shouldn’t? Here is my tick:


And here is my inner function:

Where are the long loops there? I don’t see them.

I never said you had any, merely suggested it could be and often is a culprit. And I hereby absolutely refuse to untangle that spaghetti.

@Everynone, Floating Pawn Movement works only with Simulate Physics enabled? I know it just worked without that checkbox, I have even packaged game with this movement working, and suddenly it stopped to work. The static mesh has a capsule collision, Max Speed is set to correct value, Can Walk to true. What could happen?

It does not need physics. You do not need anything special. It’s just one node. However, you’re driving it into ground with -Z. Perhaps that’s it, although that usually works fine. But then again, we do not know how the colliders look like or the surface we’re moving on.

As for now, I made the target constructions just actors, not pawns/characters, and they move with “Projectile Movement” and are blocked by the ground. Is this solution valid, or “Projectile Movement” is not suitable for the actors that are moving slowly (1.5-2 m/s) and in the different directions?

I have tested the game with full count of these actors - 70k - and all full size textures, and FPS Monitor shows near 60, but the reaction to input is near once per second, and the other actors update their position near 3-5 times for second. I understand that optimization is my work, but @Everynone, could you just say: are these results normal, regarding that the server is launched on the same machine and consuming the most of the CPU/GPU resources? And the message #14 is also actual.

Seventy thousands actors is not normal. If you want to have that many entities, you need to employ different methods:

https://www.youtube.com/results?search_query=ue5+crowds

@Everynone, but I seem to already say: this count is in the whole world, only 5-10 are visible at the same time. And is the “Projectile Movement” valid for the actors that move slowly (1.5-2 m/s) and in the different directions?

Invisible actors still compute logic. They’re just not rendered by the GPU, culled automatically.

And is the “Projectile Movement” valid for the actors that move slowly (1.5-2 m/s) and in the different directions?

I’ve used PMC to simulate fish and other strange things, it’s not the most performant thing but it worked in my case. No one can possibly produce a definite answer to your questions without knowing what you’re doing.


Why not run profiling and see what is eating up performance?

Is it possible to disable that?

Is Floating Pawn Movement More performant?

It’s sure that it is new actors because before their adding the game was MUCH more performant.