Rendering 5000 sprites in UE4 10x slower than Unity5?

Try to understand 2d performance difference between Unity and Unreal Engine, so I did a simple 2d sprites benchmark today to render 5000 sprites on screen and here’s the result:

UE4:

24 fps, 5001 drawcalls, 5000 Paper2D Sprites, cpu load 22%, memory usage 556M

Unity5:

234 fps, 137 drawcalls, 5000 sprites (same fps with or without dynamic batching), cpu load 29%, memory usage 45M
165 fps, 5001 drawcalls, 5000 quads without dynamic batching, cpu load 32%, memory usage 55M
278 fps, 2 drawcalls, 5000 quads with dynamic batching, cpu load 32%, memory usage 52M

5000 sprites in UE4:

5000 sprites in Unity5:

c0421f9ee2031374c31b910628520d0ec87eeea7.jpeg

UE4 stats:

af867f36a77a0aca01c625531fc30f34e39aad41.jpeg

Unity5 stats:

5000 spites
e9195ec0a2398810fbe09b513a6faa407384ef2d.jpeg

5000 quads without dynamic batching
1f8433e4ceb1476c6a3c3033321eef90afa3916d.jpeg

5000 quads with dynamic batching
89e7b2fadcc9f990a7e049a6a8c129673d6debd5.jpeg

You need bach the sprites in unreal or unchek the baching in unity to run the same test, or your test dont have many sense.

How to batch sprites in unreal? It would be great that we can batch drawcalls in UE4, but I simply failed to find that feature been implemented.

I have no idea :confused:

Update unity 5 test with dynamic batching off. There’s 40% performance drop after turn off dynamic batching option when rendering quads in unity 5.

You’ll want to use instancing, BUT… for me at least it never worked on mobile as a big portion of mobile hardware does not support hardware instancing. On PC my test dropped several thousand objects down to a dozen.
Never worked it out but my guess is unity does some “magic” on software which I don’t think UE4 does… yet. I really hope its something that gets looked into soonish in UE4

I’m not sure if Paper2D has any easy batching support out-of-the-box since I’ve not used it. Paper2D is a work in progress and is aimed at mobile hardware though (which does not always support instancing). You can test batching by using an instanced static mesh component setup.

In my own tests, I had around 32 million triangles on screen before I started getting a depreciation in performance.

Drawcalls is more dangerous that polys.

Looking that, even with baching you will be minus performance in unreal.

Hmm think the forum ate my last post. Sorry if it shows up again. Anyway I’m not sure if the Trello board for Paper2D is up to date. But under the TODO: Rendering column
it says Batched rendering and performance optimizations is slated for 4.8. It is the first item for that column.

it wasn’t eaten, it was just waiting for approval from a moderator, the first few posts of new members need to be approved:).

anyway back to the thread topic.

Currently each sprite component is a separate draw call. Some form of easier batching will be coming in 4.8, but you can manually batch in 4.7 by submitting multiple FSpriteDrawCallRecords in a UPaperSpriteComponent subclass, or by using something that automatically batches like a terrain spline component or tile map component.

Cheers,
Michael Noland

1 Like

One other thing to check so that you are comparing apples to apples is post-processing settings. There’s a non-trivial per-frame overhead even for an empty scene with no geometry due to the post-processing chain passes that are enabled by default in Unreal. You can turn things off in project settings … Rendering.

Cheers,
Michael Noland

1 Like

Just to clarify, all default post-processing was turned off in unreal 5000 sprites test:
ue_default_postprocess_off.JPG

Glad to hear that batching support is coming in 4.8, is the code already in master branch? And is the batching support only for paper2d or there’ll be general batching for 3d mesh too?

3D Meshes already have batching IIRC, Instanced Meshes definitely do. Separate meshes might not, though I don’t see why that would be the case.

I know that Mesh particles in UE4 are done in batches now, but they’re probably instanced meshes too.

If UE4 with the 4.8 give me something like this Make Urho2D more faster · Issue #567 · urho3d/Urho3D · GitHub then i’m gonna be much happy (About 100.000 static sprites at 60FPS), but since is a big engine, probably a 60FPS for 50.000 sprites make me fun.

About x5 times better than Unity5…

The batching support isn’t in yet, I’ll probably start on it in the next week or two. It will be specific to sprites, and the first form will be a similar interface to instanced static mesh components (but not using hardware instancing).

For 3D meshes, we have the instanced static mesh component for dynamic batching, and you can also use Simplygon if you have it to mesh merge (I think having a built-in mesh merging system is on the backlog). Loose static mesh components are not batched at the RHI level, but there is already a lot of render-thread optimization for static meshes with mobility set to Static. They still end up being multiple API draw calls, but they go down a much faster path on the render thread with fairly low per-mesh overhead.

Cheers,
Michael Noland

Interesting note about Simplygon didn’t know about it.

Ran the same test with Urho3D on my machine (in OpenGL mode):

5,000 sprites: 678 fps
50,000 sprites: 90 fps
100,000 sprites: 45 fps

Tried to run 50,000 sprites test on UE4, but failed with black sreen and no responding, have to kill it in task manager.

Another issue puzzles me is the huge memory usage in UE4 test, it took 10x more memory than Unity or Urho.

Yes, the DirectX work better in Windows than OpenGl, anyway, give good FPS amount.

That’s because we don’t get it with UE4, one must license it.