Welcome to the Oculus Developer Forums!

Your participation on the forum is subject to the Oculus Code of Conduct.

In general, please be respectful and kind. If you violate the Oculus Code of Conduct, your access to the developer forums may be revoked at the discretion of Oculus staff.

UE 4.24 - whats new / improved / broken

MaxArchMaxArch Posts: 195 Oculus Start Member
edited November 2019 in Unreal Development
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



«1

Comments

  • Barzum_01Barzum_01 Posts: 7
    NerveGear
    Thanks for the info!
  • aussieburgerVRaussieburgerVR Posts: 252 Oculus Start Member
    Thanks for reporting! I've not played around with 4.24 much yet but hope to do so in the next few weeks.
  • aussieburgerVRaussieburgerVR Posts: 252 Oculus Start Member
    edited November 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"
  • motorsepmotorsep Posts: 1,481 Oculus Start Member

    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.
  • aussieburgerVRaussieburgerVR Posts: 252 Oculus Start Member
    edited November 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


  • MaxArchMaxArch Posts: 195 Oculus Start Member
    @aussieburgerVR Just to be sure; You're testing in 4.24? I hope to have some time as well this weekend to test.
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    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.


  • aussieburgerVRaussieburgerVR Posts: 252 Oculus Start Member
    edited November 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)
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    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/
  • aussieburgerVRaussieburgerVR Posts: 252 Oculus Start Member
    MaxArch said:
    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.
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    edited November 2019
    @aussieburgerVR An update from UnrealEngine support:

    1. Different materials will have different draw calls
    2. Mobility should be static (PickupCube for instance does have mesh as root component, but they are moveable)
    3. Different LODs = different meshes.

    I also forwarded your remarks (ISM speed & physics). Maybe they can confirm if this is intended.

  • aussieburgerVRaussieburgerVR Posts: 252 Oculus Start Member
    MaxArch said:
    @aussieburgerVR An update from UnrealEngine support:

    1. Different materials will have different draw calls
    2. Mobility should be static (PickupCube for instance does have mesh as root component, but they are moveable)
    3. Different LODs = different meshes.

    I also forwarded your remarks (ISM speed & physics). Maybe they can confirm if this is intended.

    Many thanks for posting here I was just about to contact Epic support to find out the same info :)

    In regards to number 2 though I don't fully get it as movable blueprint actors are auto instanced in my case (they have static mesh root componement though so maybe that is the reason?)
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    edited December 2019
    the inputs (forward/right) for the GO are changed (deprecated). MotionController(R)Thumbstick(Y) and MotionController(R)Thumbstick(X) dont work anymore.

    OculusGo(R)TrackpadY and OculusGo(R)TrackpadX don't seem to work as well.

  • motorsepmotorsep Posts: 1,481 Oculus Start Member
    4.24 was released earlier today :) Now we just have to wait (and wait) for Oculus to release it with integrations :blush:

  • aussieburgerVRaussieburgerVR Posts: 252 Oculus Start Member
    MaxArch said:
    the inputs (forward/right) for the GO are changed (deprecated). MotionController(R)Thumbstick(Y) and MotionController(R)Thumbstick(X) dont work anymore.

    OculusGo(R)TrackpadY and OculusGo(R)TrackpadX don't seem to work as well.


    As per the release notes:


    Action bindings that use MotionController keys need to be updated to use bindings for each platform the project is targeting. Blueprints that read MotionController keys directly need to be updated to use the action system instead.
    Deprecated: MotionController keys are now deprecated and have been replaced by keys specific to each controller model.
    What is meant by the Action system? They unfortunately did not provide any documentation on the changes needed



  • MaxArchMaxArch Posts: 195 Oculus Start Member
    edited December 2019
    In the inputs I find these options for the GO. I tried the TrackpadX en Y inputs but didn't work. Contacted Epic to see how / what to enable again.

  • MaxArchMaxArch Posts: 195 Oculus Start Member
    Can anyone test the new auto-instancing for mobile (Quest)? Just add 'r.Mobile.SupportGPUScene=1' to the 'DefaultEngine.ini'. It works but most of the times, it doesn't do a 100% (or 50%) job for me. Many copies are still unique while some are instances. I can't find any logic in why 'its breaking' so much. I have been back-and-forth with Epic on this after the first preview builds but they can't reproduce it. It could be a nice performance win without having to do anything for it yourself.

  • motorsepmotorsep Posts: 1,481 Oculus Start Member
    @MaxArch
    Maybe it makes sense to wait for integration release ? Maybe Oculus will fix up rendering there ?
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    @motorsep Its an UnrealEngine 4.24 feature so Oculus integration won't change this. The feature is working a bit but not as intended.
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    edited December 2019
    A lod bug in 4.24 - reported but not acknowledged yet by Epic.
    - a 3d model (a chair) is created in Blender and imported as FBX in UE.
    - light build is ok - no warnings or errors
    - then create some LODs for the imported model using the SM editor.
    - light build now reports overlapping UVs and the result looks bad.
    - deleting the lods or re-importing the fbx doesn't fix this. need to delete the asset and import again
    - no difference if you make the lightmap UVs in Blender OR have UE create them at import.Importing as OBJ is same issue.

    Anyone can confirm this?
    Using the default binary UE 4.24 (and GPU lightmass plugin)

  • mvillarmvillar Posts: 1
    NerveGear
    MaxArch said:
    A lod bug in 4.24 - reported but not acknowledged yet by Epic.
    - a 3d model (a chair) is created in Blender and imported as FBX in UE.
    - light build is ok - no warnings or errors
    - then create some LODs for the imported model using the SM editor.
    - light build now reports overlapping UVs and the result looks bad.
    - deleting the lods or re-importing the fbx doesn't fix this. need to delete the asset and import again
    - no difference if you make the lightmap UVs in Blender OR have UE create them at import.Importing as OBJ is same issue.

    Anyone can confirm this?
    Using the default binary UE 4.24 (and GPU lightmass plugin)

    Yes MaxArch, I've been dealing with the LOD system lately and I can confirm you it is indeed bugged. What's actually happening is that somehow after you create new LODs, the property "Light map Coordinate Index" switches back to "0", instead of "1" or whatever value you entered for your lightmap UVs. Manually entering a "1" makes nothing as the number automatically changes to "0" or even better the editor crashes XD. Looks like the StaticMesh editor is not able to find a second UV channel even though it is shown in the UV channels previewer.
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    edited December 2019
    @mvillar thanks for the confirm and explanation. Fowarded the info to Epic and hoping we get a fix 'soon'.
    Update: send Epic more info as requested - they are investigating. In 4.23 it still works so importing in 4.23, creating lods there and migrate to 4.24 is a workaround for now.
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    edited December 2019
    MaxArch said:
    In the inputs I find these options for the GO. I tried the TrackpadX en Y inputs but didn't work. Contacted Epic to see how / what to enable again.

    Replying to myself here; trackpad inputs of the GO are broken in 4.24 - confirmed by Epic. No workarounds at the moment. Vote here to get it fixed. https://issues.unrealengine.com/issue/UE-85917


  • motorsepmotorsep Posts: 1,481 Oculus Start Member
    I wonder if we will get UE 4.24 with integrations before Christmas.. I doubt it :/
  • NoirQNoirQ Posts: 5
    NerveGear
    For the Go, i made some input progress by setting my inputs to be Touch, and sticking:
    [OculusTouch.Settings]
    bGoKeysMappedToTouch=True
    In my defaultengine.ini

    I've not dived too deep on this mind, but it at least let me use the triggers. (I think the config bit is right, but I am not 100%)
  • aussieburgerVRaussieburgerVR Posts: 252 Oculus Start Member
    MaxArch said:
    MaxArch said:
    In the inputs I find these options for the GO. I tried the TrackpadX en Y inputs but didn't work. Contacted Epic to see how / what to enable again.

    Replying to myself here; trackpad inputs of the GO are broken in 4.24 - confirmed by Epic. No workarounds at the moment. Vote here to get it fixed. https://issues.unrealengine.com/issue/UE-85917



    damn guess I won't be switching to 4.24 until that is switched. The 'good' news is they have a fix version of 4.24.2 listed there - fingers crossed it really happens!

    motorsep said:
    I wonder if we will get UE 4.24 with integrations before Christmas.. I doubt it :/


    not much point getting a Oculus 4.24 integration until that is fixed else Oculus will just need to update it again shortly after :D
  • FeroxDFeroxD Posts: 41
    Brain Burst
    edited December 2019
    MaxArch said:
    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



    Thanks for that info coz i spent so menu hours with the splash screen and now i find your post. Also, we don't have nodes from the splash screen for "Show splash screen" or "Hide splash screen" on the 4.24.
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    MaxArch said:
    @mvillar thanks for the confirm and explanation. Fowarded the info to Epic and hoping we get a fix 'soon'.
    Update: send Epic more info as requested - they are investigating. In 4.23 it still works so importing in 4.23, creating lods there and migrate to 4.24 is a workaround for now.

    Again replying to myself; the create lod bug is confirmed by Epic. In their response they stated;; "Please be aware this issue may not be prioritized or fixed soon". Please vote for it here https://issues.unrealengine.com/issue/UE-86009

  • motorsepmotorsep Posts: 1,481 Oculus Start Member
    4.24.1 Hotfix has been released
  • MaxArchMaxArch Posts: 195 Oculus Start Member
    @motorsep Too bad the changelog mentions nothing that was mentioned in this topic. Will test tomorrow if I have the time.
Sign In or Register to comment.