cyubeVR Update — Mod Compatibility Status & Broken Mods List

[img]{STEAM_CLAN_IMAGE}/31813012/a3c450a827e0e528c9dbc622119d548c60b3f03b.jpg[/img] [b]Hey everyone, Update 59 for cyubeVR is live![/b] This is a really big technical change. It took quite a while to finish and has been tested in the beta build for a long time. Hopefully the wait was worth it! Previously, cyubeVR was using the last version of Unreal Engine 4, that's Unreal Engine 4.27. Now it uses Unreal Engine 5.6. Updating a game from UE4 to UE5 means a lot of things need to change in the background, and the first goal with the engine update was to have it work as identically as possible to UE4 - just a solid updated technical foundation in the background that makes future updates much easier than trying to work with an outdated UE4 base. And only after that, the focus was on adding new visuals-improving features from UE5 that you surely have heard about from other games by now (Nanite, Virtual Shadow Maps, DLSS 4.5), so it can look way better than before! From other games you might know that there were definitely some [i]bad[/i] examples of using Unreal Engine 5 where the devs did not properly spend the time to optimize the Unreal Engine 5 features or choose which Unreal Engine 5 features make sense to use, and also earlier Unreal Engine 5 versions were generally not as well optimized themselves. With cyubeVR the goal was to be a good example for how to properly update a game to UE5: Only use the UE5 features that actually make sense, spend a lot of time optimizing the performance ideally for UE5 and make sure to do many measurements against UE4 to make sure nothing accidentally becomes slower than before the update. And also don't update to early UE5 versions, but wait until Unreal Engine 5.6 which is way more optimized than earlier UE5 versions. The most important point: You are not forced to use any of the new UE5 features, the goal of this Update is that if you choose to still only use the UE4-rendering-features, you also only pay the performance cost they had in UE4. Unreal Engine 5 should not be fundamentally "slower" than Unreal Engine 4, unless you actually enable new graphics features of UE5 that bring improved visuals. That's how this is implemented in cyubeVR now. All the previous graphics options still exist, nothing was replaced by anything slower, only new UE5 graphic options were added additionally. Of course, when there are really big technical changes, it has the potential to introduce new bugs. This update was tested by beta testers in the [url=https://discord.gg/cyubeVR]official cyubeVR Discord[/url] through 55 separate beta builds over a long time, but with big technical changes some new issues might only happen on very specific PC configurations, so it's always possible that something doesn't quite work as perfectly yet as it did in UE4 and no one has noticed it yet. So to make this maximally safe and not disruptive even if you might encounter some new issue with UE5, this update is specifically designed so that it does not change anything at all about how savegames of the game are handled, your saves are still fully compatible to the UE4 version of the game, and you can even switch back and forth between the UE4 and UE5 versions of the game with exactly the same world. While the default version of cyubeVR is now Update 59 using Unreal Engine 5, you now have the new option to select the "UE4-Update58" version in the properties of cyubeVR on Steam if you have any reason to go back to the UE4 version temporarily while you encounter issues with the UE5 version. Just make sure to actually report any issues you find so they can be fixed in UE5, because eventually the game has to be able to get changes that are no longer backwards compatible with the UE4 version, so at some point in the future upgrading your world to be played with Update 60+ will mean you won't be able to get back to playing it with the UE4-Update58 version any more - but that is not yet with this update. So, what are the big technical changes an update to UE5 brings? Let's go through the biggest ones one by one. Let's start with something you ideally shouldn't feel: [img]{STEAM_CLAN_IMAGE}/31813012/18b90b98eb88cbfeda0cb3e13fd65cf50e05cdb0.png[/img] [h1] DirectX 12 [/h1] cyubeVR now renders through DirectX 12 instead of DirectX 11. This is a really big change in the background, but ideally something you should not notice - it's just about how the game talks to the GPU. DirectX 12 allows for more parallel rendering and improved performance. [img]{STEAM_CLAN_IMAGE}/31813012/18b90b98eb88cbfeda0cb3e13fd65cf50e05cdb0.png[/img] [h1] OpenXR [/h1] Previously, cyubeVR was using the OpenVR API to talk to your VR headset. OpenVR is directly linked to SteamVR - so in practice this meant you have to use SteamVR to play the game. OpenXR in contrast is more open and flexible, and does not *require* SteamVR - but it also still works great through SteamVR. Running the game through SteamVR is still the most reliable and most tested way to run the game, but now with OpenXR you have many more additional options, like using Virtual Desktop with the VDXR runtime. Depending on which VR headset you use (and there really are many VR headsets by now!) other OpenXR runtimes might give you improved performance compared to using SteamVR. Updating a VR game from OpenVR to OpenXR is quite painful for VR devs, a lot of things like all interaction profiles for different types of controllers need to be completely re-created for doing the switch. So if you encounter any issues with button bindings or things like that, make sure to report them so they can be fixed. [img]{STEAM_CLAN_IMAGE}/31813012/18b90b98eb88cbfeda0cb3e13fd65cf50e05cdb0.png[/img] [h1] Nanite [/h1] Now let's talk about something fun that actually gives a very noticeable boost in visual quality! This update adds new options for the View Distance and for the Foliage Quality that switch from using traditional rendering to using Unreal Engine 5 Nanite! This can be controlled separately for chunk rendering (the blocks in the world) and foliage (trees, grass, flowers) rendering, but often enabling Nanite in both cases should make the most sense. The big noticeable change Nanite gives is *no noticeable LOD changes, no LOD pop-in while walking around, everything should simply look like "max quality" all the time even in the distance, while at the same time using significantly less GPU memory". When simply comparing rendering the same amount of detail with non-Nanite vs Nanite, Nanite is a bit slower, but the more triangles there are to render, the more benefit there is to using Nanite - so Nanite is a feature that makes sense the higher the visual quality becomes. On very low settings where visuals are considered much less important than framerate, it does usually not make sense to use Nanite, but if you're using a high-end GPU like a RTX 4080 and you want to have *the best possible graphics while still being performant", that's the case where Nanite really starts to shine! cyubeVR has supported a really high view distance since a long time, often described as "near-infinite view distance", through regular LODs, so the world was becoming less and less detailed the further away from you it was rendered. You might have noticed previously that if you walk away from your builds, after a certain distance they start to look more and more "blocky" because individual blocks get combined to larger blocks in the distance. Now with Nanite, it's possible to actually render a view distance of 200 chunks (3.2 kilometers / 2 miles) all with the same maximum quality, no detail loss at all in the distance, every individual block you placed still visible! Nanite is much more efficient at rendering very large amounts of triangles and doing so without requiring huge amounts of GPU memory. Additionally, with Nanite enabled, you can actually use a significantly higher view distance now compared to before if you were limited by your GPU memory, because Nanite is just so much smaller in VRAM. And you might have noticed RAM and VRAM became a bit expensive recently, so anything that helps to require less of it is really useful. On the "View Distance" setting there is now the new "Nanite" option, which means rendering a view distance of 200 through Nanite. Rendering through non-Nanite is still possible the same as previously, just the new "Nanite" option was added. So you can test what works better in your case. The first time you enable the "Nanite" option it takes a while to load the whole view distance into the proper cached format for Nanite, but after that loading the world with Nanite should feel just as quick as loading it with Nanite disabled. [img]{STEAM_CLAN_IMAGE}/31813012/18b90b98eb88cbfeda0cb3e13fd65cf50e05cdb0.png[/img] [h1] Virtual Shadow Maps [/h1] Unreal Engine 5 added a new type of shadow rendering called "Virtual Shadow Maps", usually abbreviated to "VSM". It's a more modern way of rendering shadows. Similar to Nanite, when comparing just rendering the same previous quality of shadows through VSM, VSM would often be a bit slower, but VSM scale better towards higher quality, so they allow to have way more shadow resolution at only slightly higher performance cost. What this means in practice is more detailed shadows, that you can for example properly see individual leaves of trees cast shadows instead of a somewhat blurry shadow of the rough tree shape. In general, shadows are really expensive to render in a game like cyubeVR with a fully open world with dynamic time of day where the sun is constantly moving and all shadows need to be updated every frame - so regular shadows also always were quite expensive to render in cyubeVR and took up a significant part of the overall GPU frametime, and that's why VSM are actually not much more expensive since they generally scale well in such cases, especially since Unreal Engine 5.6 (in older Unreal Engine 5 versions VSM was significantly less o