Greetings! My name is Rafael Ferrari, and I'm the CEO of Skullfish Studios, a company from Brazil that develops content for virtual reality devices. I’m writing this guest blog on the Arm Community about the work we at Skullfish are doing involving optimizing our VR game; Lila's Tale, for mobile VR based on the "GPU Processing Budget Approach to Game Development" guide written by Roberto Lopez Mendez of Arm.
To give you a bit of my background, before Skullfish, I was a Lead Developer at Black River Studios/Samsung, and worked on titles such as Finding Monsters VR and Rococo VR. Our main team also worked on various well known VR titles, like “Rock’n Rails” for the Gear VR. Over time and a lot of hard work we acquired a solid background on the game building process, and together we wanted to apply that in our company. Out of this we decided to found Skullfish Studios.
After a lot of hard work we arrived at the planning stage of our design. We started by making a list of the key deliverables we wanted to achieve for our first game:
Our objectives were clear at the beginning of this project and remained the same throughout the building process.
One of the most important aspects for VR applications is the optimization process. Even more so for mobile VR if you want to attain great graphics, stable FPS and an extended gameplay time.
So for us, based on our planning objectives, the optimization process started on the first day!
Our game scenario would be described as a sphered dungeon, where the camera is in the center, and you can play the game by just looking around and interacting with simple dots. Our plan for the game was to have more options for scenarios, colors, and different levels; so we knew that it wouldn’t make sense to be artist dependent. We couldn’t depend on our artist to make each level with the correct size and props in it, as this would make our design process slow. With that in mind, we came with the solution of a custom Level Editor.
After we have all the meshes and the level tests ready, we can polish and add lights. In the main gameplay, the whole scenery is dark, and the camera has the ability to generate a spotlight on it. Our main character, Lila, will follow the light, because she is afraid of darkness!
An interesting question you may have is; what can we do to have a lot of colors on scenario using a spotlight, but ensure we don’t mess with the performance? The answer is; lightmap combined with custom shaders. We have a custom shader that can read the lightmap color and subsequently change its color, so you have the impression that everything is dark, faking a spotlight on the camera. With this technique, we can keep the lights of the level pretty complex, using baked lights, giving a great impression overall. We just used one real-time light for Lila.
Because of this process, we can make Lila’s Tale pretty stable. Our main developer tool has always been Mali Graphics Debugger (MGD). With MGD, we could calculate our GPU and CPU budget. Here is an example of the budget for the main target device, S7:
Samsung Galaxy S7: octa-core Arm CPU and Arm Mali-T880 MP12 GPU
•12 GPU cores @ 650 MHz – 12 x 650 M single cycle operations per second
•Target FPS: 60
•Res = 2,560 x 1,440 = 3.68 M pixels
•Num. Verts = 671,436
fragCycleBudget = (130 M cycles/frame) / (3.68 M pixels) ~ 35 cycles/frame/pixel
vertCycleBudget = (130 M cycles/frame) / (0.67 M verts) ~ 194 cycles/frame/vertex
Our Fragment budget is 35 cycles, per frame, and per pixel. And our vertice budget is 194 cycles. So, using those formulas, let’s check the result of LIla’s Tale:
As you can see on the images above, we are totally on target! On frame budget, we have just 11 cycles. We could go until 194 cycles. And on the fragment budget, we have 8 cycles! This give us space and the confidence to improve the game or increase performance other areas of it and keep the gameplay long enough with a stable FPS.
Another important thing we are using at Lila’s Tale, is to use Single Pass as the Stereo Rendering Method. To read up more on this method please see the Unity documentation on single pass stereo rendering. With this technique we could save a lot on vertices rendered and draw calls. This is what gives us space to improve our game even more within the limitations of the devices. We used MGD to take a couple of images of the debugging to show the difference between Single Pass and Multi Pass stereo rendering:
As you can see, we could save almost half of what has been drawing, by just changing from multi-pass to single-pass. The good part is that in Unity is really simple to choose between both rendering types: you just need to change an option on stereo render as shown below:
With all the processing budget we save here, we could improve our quality settings and go for highest anti aliasing settings. In Arm GPU’s, you can use 4xMSAA almost for free! This is awesome, because in VR, one of the most important things is to have the anti aliasing pretty smooth, so you can get more immersion for your users. On Lila’s Tale, with all the performance saved, we are going to 8xMSAA with 60FPS! Below is a couple of images showing the difference between the MSAA types:
To conclude, you can see for us at Skullfish Studios, it is really important to understand what you want from your game from the very beginning of the planning stage. You have to plan from the first day with optimization and performance limitations in mind. Creating scope, space and opportunity to artists and designers to create awesome and beautiful experiences. Tools like Mali Graphics Debugger help us a lot on the game development process, making sure we are on the budget, and where we need to improve on the game.