Skip to main content
MaxArch
MaxArch
Inspiring
November 19, 2019

UE 4.24 - whats new / improved / broken

Maybe it could be nice to start a new thread every time a new UE version is launched so its easy to catch up for everyone.

My observations up to 4.24.0 p2;
+ cascaded shadow maps work again when using MobileMultiView (Quest). In 4.23 the shadows were broken with MMV.
+ UE added automatic instancing for mobile. You enable it by adding 'r.Mobile.SupportGPUScene=1' to the 'DefaultEngine.ini' (Quest). When analyzing your app in Renderdoc it will report the instances but in the TextureViewer the instances will be pitch black (reported to UE). Also, I noticed that the algorithm still misses some objects sometimes (I haven't found any logic yet why some are missed - reported to UE).
+ Vulkan is on par with OGL (in 4.23 I noticed a big fps drop) but the purple glitches are still present sometimes.
+ Oculus SDK will be updated to 1.40.0
- the splash screen is broken (Quest - reported and confirmed by UE).

Edit:
- strikethrough: fixed in new nightly build of RenderDoc



    This topic has been closed for replies.

    41 replies

    Barzum01
    Participant
    November 19, 2019
    Thanks for the info!
    Anonymous
    November 21, 2019
    Thanks for reporting! I've not played around with 4.24 much yet but hope to do so in the next few weeks.
    Anonymous
    November 21, 2019

    MaxArch said:


    + UE added automatic instancing for mobile. You enable it by adding 'r.Mobile.SupportGPUScene=1' to the 'DefaultEngine.ini' (Quest). When analyzing your app in Renderdoc it will report the instances but in the TextureViewer the instances will be pitch black (reported to UE). Also, I noticed that the algorithm still misses some objects sometimes (I haven't found any logic yet why some are missed - reported to UE).



    I finally got some time to test the auto instancing and my observations:

    - If you apply a dynamic material instance to the mesh auto instancing no longer works (generates a drawcall for each mesh) this is a realy bummer for me but probably by design? :( One potential workaround for some situations is to use a material collection parameter instead which works but of course is applied globally to all meshes then (ideally I would like to change the material on only some of the instances)
     - Physics works still works! which makes it instantly better than the default "instanced static meshes"
    motorsep
    Inspiring
    November 21, 2019

    aussieburgerVR said:





    I finally got some time to test the auto instancing and my observations:

    - If you apply a dynamic material instance to the mesh auto instancing no longer works (generates a drawcall for each mesh) this is a realy bummer for me but probably by design? :( One potential workaround for some situations is to use a material collection parameter instead which works but of course is applied globally to all meshes then (ideally I would like to change the material on only some of the instances)
     - Physics works still works! which makes it instantly better than the default "instanced static meshes"



    Probably worth reporting the issue with dynamic material instance to Epic.

    What do you mean by "physics works still works" and it's "better than instanced static meshes"? I am not sure about the relation between the two.
    Anonymous
    November 22, 2019

    motorsep said:



    Probably worth reporting the issue with dynamic material instance to Epic.


    Yeah I will report it just in case somehow it can be supported which would make it super powerful.

    motorsep said:

    What
    do you mean by "physics works still works" and it's "better than
    instanced static meshes"? I am not sure about the relation between the
    two.

    ISM Instanced static mesh components do not support Physics (the physics checkbox is greyed out and was a commonly known limitation of using them). These autoinstanced meshes still support physics which is great for my particlar use case.


    New finding: After turning auto instancing on in the project I'm currently working on, auto instancing is not working (I was testing before on a simple test project), even after removing any dynamic material instances, so there is some other limitation as well which I'll try to figure out soon. Edit: was a user error on my side


    MaxArch
    MaxArchAuthor
    Inspiring
    November 22, 2019
    @aussieburgerVR Just to be sure; You're testing in 4.24? I hope to have some time as well this weekend to test.
    MaxArch
    MaxArchAuthor
    Inspiring
    November 23, 2019
    I did a few more tests.



    Copies are NOT
    turned into instances;



    • when the copies have a different material, including
      Material Instances.


    • when the copies have different mobility


    • when making copies of actors who have the same static mesh
      inside (for instance the PickUpCube-actor in the VR example)

    • and for some reason, the algorithm sometimes just doesn't turn a few copies into instances. No idea why. You could have 4 or 20 of the same objects and a few of them would still be unqiue.


    I also noticed that when you make HISMs yourself (using an
    actor), the instances seem to break apart now based on their LOD. I'm
    not sure about the LOD part, I am about the breaking apart into
    smaller chunks though.


    Anonymous
    November 25, 2019

    MaxArch said:

    • and for some reason, the algorithm sometimes just doesn't turn a few copies into instances. No idea why. You could have 4 or 20 of the same objects and a few of them would still be unqiue.




    Strange I didn't notice that.

    I did some performance testing and the old ISM still performs better than auto instancing.
    Also once you turn physics on the actors that are auto-instanced performance is only slightly better than without auto-instancing - to be expected I guess since the CPU is tracking the physics of each actor.
    So in short still a great feature as you gain some performance without adding ISM logic, but if you want max performance go with ISMs.

    Back on 4.24 in general I've noticed different controller button behavior on the Go - it appears to be triggering Left and Right button presses on each press?? (not exactly sure what the issue is though as haven't had time to investigate further)
    MaxArch
    MaxArchAuthor
    Inspiring
    November 25, 2019
    @aussieburgerVR
    Interesting stuff. I haven't tested performance - just focused on getting it working and figuring out why some objects are not instanced in my project.

    Strange that ISM perform better. Your ISMs don't have LODs? I was under the impression it was best to use HISMs because they use lods like they should while ISMs all use the same lod. My notes on this are a few years old so maybe it has been improved since.

    I barely use the GO so haven't tested it with 4.24. Do report back please if you have found a pattern / cause/
    Anonymous
    November 25, 2019

    MaxArch said:

    @aussieburgerVR
    Interesting stuff. I haven't tested performance - just focused on getting it working and figuring out why some objects are not instanced in my project.

    Strange that ISM perform better. Your ISMs don't have LODs? I was under the impression it was best to use HISMs because they use lods like they should while ISMs all use the same lod. My notes on this are a few years old so maybe it has been improved since.

    I barely use the GO so haven't tested it with 4.24. Do report back please if you have found a pattern / cause/


    Did not test with LODs (so also didn't test with HISMs) - as the objects in my scene are all pretty close to the player.

    One other thing on object instancing if using actor blueprints you need to make sure there are no other components visible in it other than a static mesh otherwise it does not get auto-instanced.
    Show more replies
    Terms & ConditionsAccessibility statement