In the Editor my Lods look fine but in VR they are popping in far too early. Do you need to double them for VR or am I missing some optimisation setting that is making them come in too early.
I’ve tried sg.ViewDistanceQuality=3 and r.ViewDistanceScale=1. Maybe my config files aren’t set up correctly. I can’t see to get the cooked or packaged game to look like the Editor.
Looking like the editor was a huge problem for me! It took me a year, what I found so far. Go to project settings, find framerate settings, turn off framerate smoothening and also turn off fixed rate. Apparently VR devices are going to use the framerates they want no matter what you do, so telling it any framerate just confuses everything. Also make sure you build in 64 bit.
I’ve noticed the same thing comparing LODs in the editor compared to through the headset. The transition between LODs is super noticeable in VR.
I guessed this was just down to the hardware display differences but now you mention it I think the way UE calculates the screenspace fraction of a mesh to choose it’s LOD could be incorrect resulting in the visible lod changes. There is something odd happening anyway…
I ended up going through all my static mesh LoDs and halving every value, that seemed to make it about the same as it looked in the Editor.
I still had issues with skeletal mesh LoDs but realised that was because I had been messing around with the scalability settings so much that they were lodding early.
It seems much better now although it could be a bug in the VR screensize calculation but I would find that surprising (I’m using UE4.24.2).
Thanks for the advice about LOD values. It seems a tedious thing to have to do and isn’t great if you are using the same meshes in VR and for desktop.
You can’t be persuaded to file a bug report for this can you? See what Epic have to say…
Hello, sorry to bump an old topic, but have you found a solution to fix LOD for Skeletal mesh on VR? Because there is no param like r.StaticMeshLODDistanceScale .5 for Skeletal meshes
It’s possible LOD handling in general is just plain broken for high resolution displays. I come to this conclusion because in multiple locations in the engine, the projection matrix used in the ComputeBoundsScreenSize function is calculated using a hard coded screen size of 1920x1080. (Some are wrapped with WITH_EDITOR others are not.)
This results in the calculated size being far smaller in VR than when setting up LOD break points in the editor.
@ruggy In Scalability.ini, under the [ViewDistanceQuality@#] category you can add r.SkeletalMeshLODBias=# to bias the result, but it’s not a true solution.
When the “Auto Compute LOD Distances” option is checked under the LOD Settings for a static mesh, that mesh will automatically transition between LODs depending on the current screen size of the mesh (how much of the display the mesh takes up). As the screen size decreases, we can swap to higher (rougher) LODs without a visible loss of detail.
Screen size is calculated using the spherical bounds of the mesh, the distance from the viewer, and the FOV of the display. FOV must be taken into account because higher FOVs will make a mesh of the same size and position appear relatively smaller on screen.
The same object viewed from the same position at 60 FOV (left), and 90 FOV (right).
In order to fill users’ peripheral vision and allow looking left and right, HMDs use significantly higher FOVs than typical desktop applications. However, because the displays are viewed from such a close distance, not all of them can be seen at once, leading to a smaller “effective” FOV. This may lead to LOD swaps occurring earlier than desired and being overly apparent to viewers. There are two possible approaches to fix this problem:
Disable “Auto Compute LOD Distances” and set LOD distances manually for problematic static meshes.
Use the CVar r.StaticMeshLODDistanceScale to apply a direct multiplier to all static mesh auto LOD distances. Note that higher values decrease the distances required for each transition, and vice/versa. Using a value of 0.5, for instance, will double the distance required for each LOD transition.
For (StaticMesh) - r.StaticMeshLODDistanceScale 0.5 (From 0 to 1)
For (SkeletalMesh) - r.SkeletalMeshLODBias -1 (From -1 to 1)
How “LODBias” works:
Default value: 0 (uses the LOD configured in the editor).
Positive values: Shifts the LOD selection towards lower levels (simplified geometry).
Negative values: Shifts the selection towards higher levels (detailed geometry)
Alternative method:
If you want to apply the change to all objects, you can use the console command during gameplay: r.ForceLOD 0
This command disables all LODs for all meshes (static and skeletal), forcing them to use only LOD 0.
Use with caution as this may reduce performance on low-end devices.
Also for individual (Meshes) you can use blueprint as in the picture
