Hey everyone! After we released the first beta version of Multiverse Designer, we expected to spend several weeks squashing bugs and fixing technical issues. But the original build was stabler than even we expected, so we could shift our focus from putting out fires to improving the general performance of our software. In the next dev blogs, we want to explain a little bit what we are doing right now; this first post will focus on the optimization efforts we are undertaking.
The main work we are doing these days is related to optimizing all the assets we have so far in Multiverse Designer to make sure we can enable Nanite in them. Before we move on to explain how we are doing this, we have to answer the obvious question: what exactly is Nanite? As you may recall, Multiverse Designer uses Unreal Engine; for those of you who aren’t too tech-savvy, UE is a 3D graphics engine, mostly (but not only) used for games. A game engine handles much more than graphics, despite what the average gamer often thinks – it’s a complex software framework with many different features, libraries and support programs. And Nanite is one of the major features of Unreal Engine 5, the latest version of the engine.
To be more specific, Nanite lets developers import high-detailed photographic source material into games, so they don’t have to create new 3D assets from scratch -- which would still need to be optimized, on top of it! For example, without it we wouldn’t be able to use Kitbash3D assets without a significant impact on performance. A good example of this is the cyberpunk map we created during the Kickstarter campaign: many of its assets didn’t have Nanite enabled, and due to that, the map caused crashes – because its 3D assets were eating GPU memory like popcorn!
So what we are doing right now is going over all the 3D assets we have (which weren’t necessarily created for Unreal Engine) and making the necessary adjustments so they are all compatible with Nanite, in order to make them available and usable (which also means, let’s not forget it, fully customizable) on Multiverse Designer. This isn’t exactly easy, and considering we’ve got thousands of assets, it can be quite tedious too – so we have developed a tool to analyze them and make the necessary adjustments, revamping the loading system and working with some internal procedures to help bulk change assets into Nanite.
The biggest challenge we are facing is the fact that Nanite -- which allows us to use assets made up of millions of polygons - does not work on transparent objects. Our job is, for example, to take a building that contains 4 million polygons and separate it into two parts, one that has few transparent polygons and the other that has many normal polygons and apply Nanite to the second. Now multiply this by 5 thousand assets and you will get an idea of what we’re talking about!
Even so, it’s not a drag and drop thing; it does take some individual checking and tweaking. It takes time, but we’re getting there, and soon we’ll be able to move on to other tasks. The good thing is that making assets fully compatible with Nanite also has the advantage of optimizing GPU memory usage, so when this process is completed Multiverse Designer will also see great improvements in performance.
Mind you, it’s not the only thing we’re doing; in parallel, we are working in Criteria, In the next dev blog, we’ll talk about the current work in Criteria, the system we use to codify and implement TTRPG rules, and the monster/NPC generator we are creating. See you next week!