cancel
Showing results for 
Search instead for 
Did you mean: 

UE 4.24 - whats new / improved / broken

MaxArch
Level 7
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



41 REPLIES 41

Barzum_01
Level 3
Thanks for the info!

aussieburgerVR
Level 7
Thanks for reporting! I've not played around with 4.24 much yet but hope to do so in the next few weeks.

aussieburgerVR
Level 7

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
Level 8






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.

aussieburgerVR
Level 7

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
Level 7
@aussieburgerVR Just to be sure; You're testing in 4.24? I hope to have some time as well this weekend to test.

MaxArch
Level 7
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.


aussieburgerVR
Level 7

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
Level 7
@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/