Game Engine Testing and Scaling Issues

After having a discussion with my supervisor last week, I've realised that there are a few technical areas of my project that need to be considered, which I will talk about and show work that I have currently done for these issues.

The first of which is FPS (Frames Per Second), the optimum frame rate of which a scene can run at containing game assets, lighting, and so on. My latest model iteration stands at 354, 145 polys and 713, 422 tris. This is largely in part due to the tank treads, which I will be creating iterations off in order to reduce the poly count. Regardless, this would be too high for an in game asset, and be more appropriate for a cinematic cutscene instead.

Through doing a little research on the polycounts of vehicles in games today, I found that there a lot of factors to consider. Elements such as the console platform the game is being made for, the genre and the game engine used play a big part. So whilst there are games with lots of character that use vehicles, such as lost planet, with 30,000-40,000 for its robots, there are others like Forza 4 with a minimum of 400,000 to 1 million polys. These factors have an important part to play in a vehicles construction.

Article on Kotaku that talks about Forza Motorpsport 4's features, including the 400,00 to 1 million poly counts for its vehicles. 

So I've decided that I will continue to model the high poly model, texture it, and then create an optimised lower poly count version that could be used for in game. This will allow me to show off the model, but at the same time show off its practicality as well. In terms of a platform, this model would most like be for be used in a Xbox One or PS4 console title.

Also, Deciding on how it would function in game is important. For instance, a game with just robots fighting would allow for a higher poly, whereas if its a drive able vehicle in say a First person shooter would have to have a lower poly count, to make by for any other vehicles on characters poly counts in the same area.

In the meantime, I found that testing the frame issue was important. In 3ds max alone, panning around the model can make the FPS leap between 70-110 fps. For an optimum result, 60 FPS would be best for an in game model. There's some topology that could easily be scaled back to help with this issue, though this mainly affects the low poly model rather than the high poly model.

In order to test the FPS, I decided to implement  my current model into two game engines: UDK, and Unreal Engine 4.

My first test was in UDK. To begin with, I exported the entire model merged together as an FBX in 3DS MAX, and attempt to import it into UDK. However, my first attempt failed, as it turns out for a single asset UDK can only handle a maximum of 65, 535 faces or verts on a model. So I had to go back into Max, split up the pieces further, and re-import into UDK. This took a few attempts to get right.

Once in the standard UDK scene, I found a few issues. First, it was obvious that my scale was off. Since I've been working on the design currently by eye, I have yet to set a proper scale for the model, so this is something to be dealt with in the coming days. Also, certain parts came in with visible modelling issues, such as the tank tread pieces.

UDK import issues. 

Model distortion issues with the tank treads.

Working pieces in UDK, but with the wrong scale.

Correct scale, and looked pretty good, but the fps issues were a problem.

UDK full model 2.

However, I was able to place all the working pieces together and get an idea of how it would look. Unfortunately, the frame rate  was sticking to a constant 108-120 fps, which wouldn't work well for a in game scene. Safe to say, it was quite the hassle getting the model into UDK, and has made me realise it's not the best choice for my High-poly model.

In comparison, Unreal Engine 4 was far more successful. There were no issues when it came to importing the model, and I also discovered it automatically brings in textures attached to the model in the export, which saves time have to manually bring these in separately from the model. Although again the scale was off, it was easy to scale down. Also, UE 4 had no problems frame rate wise, easily running with my model in the scene at a steady 30fps. So when it comes to implementing the model in engine, I'll definitely be making use of Unreal Engine 4 for this task.

UE4 Screenshot 1.

UE4 Screenshot 2.

In regards to my earlier comment about the scale of my model, its become clear that clarifying this issue is paramount to my work. To begin with, if the scale is drastically off, i'll have to rescale each piece separately, and have to rest the x-forms, otherwise it will cause texture issues in the long run. Also, getting a correct sense of scale will make it clearer to the viewer exactly how big it is. So for the time being, I have modeled a basic ladder to give you a sense of scale, as ladders a good comparison object in relation to a human's height.

Tank model with the added ladder, which gives a better idea of its size. 

So as the post shows, its not just about making a pretty looking model, but one that functions as well as it looks. By having taken these aspects into consideration, I will be able to make much more efficient models for this project overall.

Further updates to come.