Announcement

Collapse
No announcement yet.

Please support dynamic and static batching to minimize drawcalls for mobile and low-e

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by KVogler View Post
    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.

    Leave a comment:


  • replied
    Originally posted by KVogler View Post
    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?
    There is no advantage to merge 10 meshes with 10 unique materials. This works only for merging meshes with a same material.

    Leave a comment:


  • replied
    Basically merge operation will produce a single mesh with M elements, where M is number of unique materials.
    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?

    Leave a comment:


  • replied
    Originally posted by KVogler View Post
    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.

    Leave a comment:


  • replied
    There is a tool to merge static mesh actors into single mesh.
    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?

    Leave a comment:


  • replied
    Originally posted by Nate View Post
    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.
    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.

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    +1 ue4 need this

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    @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.

    Leave a comment:


  • replied
    Originally posted by Nate View Post
    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!
    I don't think you understand what an instanced static mesh is. It does what you want.

    You might be thinking of other forms of code instancing.

    Leave a comment:


  • replied
    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.

    Originally posted by GalaxyMan2015 View Post
    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).
    Can you give a reference on which source file has the batching logic implemented? Thanks!

    Leave a comment:


  • replied
    Originally posted by Nate View Post
    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).

    Leave a comment:


  • replied
    Originally posted by GalaxyMan2015 View Post
    The engine already supports static and dynamic batching
    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:

    Originally posted by DanielW View Post
    Sadly the term 'instancing' is being used in two ways in UE4.

    Instancing of components like UStaticMeshComponent: this means the components are all sharing the same *resource*, which is the UStaticMesh vertex and index data. This saves memory. As far as draw calls go, each element of a UStaticMeshComponent will issue a draw call in each mesh pass it is in (depth only, base pass, shadow depth pass, etc). Even though every element of every instance/component is a draw call, there's a lot less state setup for UStaticMeshComponent's of the same mesh and material and they can cost ~3x less than if every UStaticMeshComponent had a different mesh and material.

    Instancing as in UInstancedStaticMeshComponent: this is referring to *hardware* instancing, which is the GPU feature that you issue one draw call and a bunch of per-instance work is done in the vertex shader. It typically reduces rendering thread overhead, but increases GPU vertex cost and has a very limited feature set, because any per-instance features (all the rendering flags on UPrimitiveComponent) have to be done in the vertex shader. By rendering meshes with low poly counts, you can get huge performance savings with this. UE4 does not yet support lightmaps on UInstancedStaticMeshComponent, but they are coming.

    Leave a comment:

Working...
X