No doubt UE4 is powerful but not without cost, that cost is performance. It’s also no secret that UE4 runs poorly on low-end pc and mobile. I would assume one reason for the poor performance comparing to other engine is the lack of dynamic and static batching support on engine level.
While Instanced Static Mesh is great for environment setup, it seems not quite useful for gameplay elements and not helping on reducing drawcalls for Android and Pre-Metal iOS devices according to @RCaloca’s post.
It would be great that all the wizards and heroes on the rendering department could show up and give more love to mobile and other low-end platform.
Or it might be a good idea for a community project to add batching support to our beloved engine?
I am pretty sure even high end projects could benefit from more batching optimizations.
I am still trying to figure out what the new hierarchical instanced meshes do and whether they work with non-foliage actors. I don’t know how it would know what is and isn’t foliage, so it should, but it would be nice to have some official information on them.
The engine already supports static and dynamic batching, I am making heavy use of this in my project. Statically batched objects uniform buffers are cached once and then reused each time during render - Objects are batched by a number of different parameters such as material to help reduce draw calls. Once I switched to using the static path for all my non movable objects, I had a massive increase in rendering performance. (bare in mind I am using custom mesh rendering).
Not sure how rendering on mobile is done, but this would benefit low end PC’s already. More than likely the deferred renderer is the cause for low end platform troubles.
I see no reason why the hierarchical instanced mesh system couldn’t be used for non foliage objects, its just mesh instancing using a new way to perform optimizations such as culling.
From my test on my iPad, it seems that’s not the case or there’re some options hidden?
I’m only start leanring graphic programming, but from my understanding, resource caching is not the same as Draw Call batching, one is for saving memory and the other is for reducing CPU overhead by reducing graphics API calls.
Here’s the quote from DanielW’s post, he explains better than me:
I think you need to be clear on what your actually wanting, as you quoted DanielW on a talk about Instancing which is not the same as batching draw calls. As I said, the calls are batched, you can see this when you view the rendering code, you add mesh batches and send them off to the renderer to be sorted and rendered, to help reduce state switching (which in turn helps CPU processing and GPU processing).
Where as Instancing is a GPU feature to be able to efficiently render the same object numerous times in numerous locations ie. foliage and other terrain meshes. Im pretty sure instancing doesnt work for mobile yet, altho last I heard it was coming (and that was a while ago, so it might already be there).
Yes, Instancing is not batching, and I want batching Sorry for confusing when quoting Daniel’s post.
Say I have 10 actors with same static mesh component and same material assigned in the map, that’s 10 draw calls ( they are cached and sorted but still 10 draw calls ). With static batching there should be only 1 draw call.
Can you give a reference on which source file has the batching logic implemented? Thanks!
@Zeustiak, instanced static mesh won’t work on my iPad 2. (there’s still 10 mesh draw calls, since it’s emulated in software)
On desktop, instanced static mesh do works. But I failed to understand how it helps on gameplay elements, e.g. I’m spawning 10 blueprint actors, each blureprint actor has 1 StaticMeshComponent (a cube) and 1 BlueprintScriptComponent (to rotate the cube), and that’s 10 drawcalls. I have no idea how to make it works with instanced static mesh without merge them into 1 blueprint actor with 1 InstancedStaticMeshComponent.
What I want from dynamic and static batching is that I should no longer care about instancing or batching, I can simply set some “batching” flag, the engine will figure out how to minimize the drawcalls for me. I guess I have been spoiled by unity after all.
The form of batching that you are thinking of is not actually going to be that effective, even in Unity it appears to be highly limited except for Static Batching. The concept is to merge objects into as few Vertex/Index buffers as possible. But you start to run into issues with culling, as now its considered one big object, or if its creating vertex/index buffers per frame to allow for culling, then you have the hit in performance from that. I think in the end, using some intelligence in building levels, you should not need that level of batching.
It would be the great stuff with such support. I’ve faced with another problem using UE for mobiles: large output package file. LibCore_UE.so weights about 70 mb and all my packages is about 100-110mb which is extreamly much for mobile store. Noone will download such big files. Such big files will never go in the Top Downloading apps.
A question here:
I dont play games on my mobile (have a PC and a PS3 for that), but I wonder why a download of 100 MByte is considered “much” on a mobile device these days.
If 100 MByte would be a huge amount, surely nobody would watch youtube videos on mobile… It shouldnt take “ages” to download either…
And the storage space on the device cant be a bottleneck either. With lots and lots of GBytes, who cares about a game of 100 MByte…
So, why are people complaining about filesizes on mobile
There is a tool to merge static mesh actors into single mesh. This is done in editor, so it’s not really a batching, as it bakes meshes into single asset. But you can use it to replace clusters of static actors with a single actor. Tool can be activated in Editor Settings -> Experimental -> Actor Merging. Should appear in Windows menu.
Is there any information on how the engine organizes the UVs for that new single mesh?
Will there be then one material element per original mesh? Bu that wouldnt help in terms of drawcalls.
The UVs are surely not repacked by the engine, so how is this solved?
If you merge meshes with a same material, there is will be one element in the mesh. Basically merge operation will produce a single mesh with M elements, where M is number of unique materials. Lightmap UV will need to be recomputed, there is an option in the tool to do it. Also tool has an option to merge materials. In this case tool will render materials into a set of textures, and compose texture atlas.
Wouldnt that defeat the goal of having less drawcalls. If I merge ten actors that have one material each, thats 10 drawcalls.
The mergerd actor would have 10 material elements, thus also 10 drawcalls…
Where is the advantage here?
Erm. It IS possible to also reduce number of drawcalls by putting textures of those materials into atlas (not in the engine, but in general/in theory). Also, if material structure is identical, and only input parameters are different, it may be possible to convert several different input materials into one. I believe using texture atlases were recommended even back when DirectX 9 performance guidelines were written.
Sorry for confusing when quoting Daniel’s post.