So as part of my second component to my dissertation I’ve written a document explaining my own LOD workflow and processes I’ve used compared to industry practice. This is the document below.
The reason for the process of LOD is to save on computer resources. It certainly isn’t necessary to draw high poly models which are not near the camera since that level of detail will never be seen. It is, therefore, the common industry practice in these scenarios to swap out to lower poly count models with increasing distance. It is, therefore, my curiosity which has made me want to understand the problems associated with the production of LOD spaceships in a modern, real-time game engine.
How I Arrived at my Chosen Poly Counts
The first few weeks of research lead me to games relevant to spaceship modelling, such as Elite Dangerous (Frontier) and Star Citizen (Cloud Imperium Games) to gain a better understanding to the poly counts used in LOD modelling. I managed to achieve some accurate high poly count results from Elite, in which I used a program which extracted the in-game spaceship models. These extracted models could then be placed in Blender/3DS Max to get a poly count. My findings showed that around 30,000 polys were being used for high poly models. My understanding of poly counts used for the medium and low LOD models came from FSDeveloper forums in which a 40% poly count reduction was estimated with each LOD. This is how I arrived at my poly count figures, with an 80% poly count difference between a High and Low LOD.
-Mismatched UV sizes causes problems were the texture will become stretched larger or compressed smaller depending on the UV size. This problem became ever the more pressing by the high poly counts I was using. It was also essential that my noise modifier, through which my greeble was applied had UVs which shared the same texture density. Though this could have been solved by matching the UVs size by eye it meant I couldn’t guarantee consistency, let alone the amount of time this would take. Fortunately, this is problem had already been solved by a program called Textools. Textools takes your selected poly’s density and copy’s it to another selected poly, increasing/decreasing till they match, ensuring the UVs will share the same density. Though you often have to break apart several polys because they’ve been pushed out of the 0-1, you can now prove that a smaller UV will have the same density as a larger poly, thus a given texture will be consistent across a given mesh.
To begin my LOD process I wanted to explore how Zbrush dealt with retopology with models and UVs made in 3DS Max. I’d already become familiar with Zbrush, using it for my advanced greebling technique, and knew it had a decimation master or “Poly Remover” capability. There were two conditions to LOD I had to follow, one I had specific poly counts to aim for and two a need to retain UVs I had already constructed. Decimation Master allowed the preservation of UVS and a percentage cut of the current poly count. My Zbrush results revealed however, it had struggled to take out polygons in an efficient manner whilst holding onto the UVs. Holding onto the UVs forced Zbrush to conform to the UVs rather than retopologizing the mesh its own way, this process left the mesh with high valence vertex’s and unevenly distributed polys. This resulted in an untidy mesh which had led to the compounded problem of the textures losing UV stability, meaning the texture became stretched. This attempt of retopology in Zbrush didn’t produce my expected outcome and so I moved into testing LOD inside of 3DS Max itself. Inside of 3DS Max, using the modifier “Pro Optimizer” you could also retain texture and UVs and then aim for a percentage you wish the final poly count to be. The results of this test were far more successful, with the mesh retaining its UVs, and therefore the texture I’ve made. The mesh had slightly been broken in parts due to the process of retopology, but I can either repair some parts or leave it, with the knowledge that the Low LOD will be hardly visible. Pro Optimiser had also completed a good job in retaining the models silhouette as I went through Med and Low LOD this was also a big plus, as the model retained the core shape of the model, meaning it was still recognisable with increased distance. Since this process yielded the best results in terms of mesh quality/UV protection/Texture preservation, I used the “Pro Optimizer” modifier for retopologizing my spaceships.
The processes of sharing the same texture density across a model and the successful retopology of a model is essential for texture preservation. Texture preservation was important as I wanted all my textures to transfer between each LOD, with the main reason to reduce work and save time, an important commodity with the industry. My textures originated with my advanced greeble technique, building it into my workflow allowed me to create intricate organic detail without having to spend months modelling it from scratch. It involved having to build a tillable greeble alpha channel which included the likes of panel detail, pipes, and grates to give depth and detailing to a surface. Following a workflow document, I maintained a consistent application of this alpha channel to my model, with the main selection being to use the models UVs, only possible from having the same texture density. From there PBR materials were extracted and when applied to my model those of which looked high detail but without any addition to the poly count.
Though my research I’ve come to understand the processes of LOD and its three main areas of focus to achieve optimized models for a real-time game engine, those being, Retopology, Texture Density and Texture Preservation. Though testing and failing many techniques I’ve come to understand the limitations but also the advantages of difference pieces of software on my quest to create quality LOD models.