Presentation for the SPRV Meetup #6 about the techniques used to have our game, Apocalipse Rider, running great on the GearVR

1. Development and Optimization of
GearVR games using Unreal Engine

2. Who am I?
• Professional Games Developer since 2008
• Mostly working on mobile games
• First worked with VR development in 2014

3. • Unreal Engine
• GearVR
• GearVR Games
• Optimization

4. Unreal Engine
• Created for the game Unreal in
2008
•
• Currently in the 4th version

5. Unreal 4
• Released in 2012
• We did chose it for the “Dinos do Brasil” project
• Excelent lightning and materials
• Good VR support at the time

6. Unreal 4 for GearVR
• We had familiarity with it
• Some mobile optimizations that Unity3d had weren’t availble on
it.
• Even so, we delivered a game that had a good reception and paid
its development

7. GearVR
• Virtual reality headset from Samsung in colaboration with Oculus
• Has lenses, interial sensor, a trackpad and one or two buttons
• Its brains is compatible Samsung Galaxy Phone

8. GearVR

9. GearVR
• A bit more than a plastic box
with some lenses
• Has the same intertial sensors
than the rift, way more
acurate than the phone ones

10. GearVR
• A Back button and a trackpad
• Optional Controllers

11. Gameplay
• The player can look at virtual objects
• They have acces to a trackpad
• The back button has limited use
• The user can have a joypad or motion controller(Not required)

12. Think your gameplay
• The player can gaze at virtual objects and interact using the
trackpad as big button

13. Think your gameplay
• Moving the head can have direct action in the game.
• But, just orientation

14. Think your gameplay
• Although it can be not very acurate, you ca use gestures in the
trackpad

15. Thinking about performance
• Low framerates induce more VR Sickness
• You want that the players have a good experience with your game

16. Thinking about performance
• The GearVR has Asynchronous TimeWarp, which
translate the image based on head movements
• Animations and head locked objects can look strange
• Black borders

17. Thinking about performance
• Oculus will reject your game

18. Thinking about performance
• Ideally you will want to run
at 0 or 1 CPU and GPU levels
• You don’t want to see this
screen

19. Galaxy S6
• Weakest, and cheapest, device compatible with the GearVR
consumer edition
• Our perfomance target

20. Galaxy S6
• 2 CPU cores at up to 1.5 GHz
• 8 GPU “cores” at up to544MHz
• Will overheat in about 10 minutes at those frequencies

21. Profiling on GearVR
• Android device monitor
• Stat Unit
• stat startfile
(SD/UE4Game/nomeDoJogo/Saved/Profiling/UnrealStats/level/level.ue4
stats)
• Other stat commands work, but reduce performance and are hard to
read

22. Problems
• Number of drawcalls
• Number of ticking objects
• Move overlap Events
• Shading cost

23. Drawcall
• The engine defines some properties and send then to the GPU
• The data goes through the driver

24. Drawcalls
• Common mobile problem
• Each Mesh/Material sends a drawcall
• Avoid more than 50 in the same frame
• Don’t go over 100

25. Drawcalls
• Unreal doesn’t batch meshs
• One could ask an artist to merge then
• Or you could try the merge actors function of the Editor

26. Drawcalls
• Avoid many materials on one object
• Avoid many objects

27. Drawcalls
• One trick we used was rotating the wheels using the vertex shader
• Based on the Robot Recall Blimps

28. The wheels keep on turning

29. The wheels keep on turning

30. Tick
• In our second game we had many moving
objects
• Each one moved itself on its tick event
• We put managers to handle objects movement

31. Tick
• This cut about 3ms of our processor time
• Still not enough

32. C++
• The enemies manager was moved to C++
• This reduced our processing time in another 2ms
• Those changes moved our game time from 14ms to 9ms per frame

33. Move Overlap
•The device was still heating up pretty rapdly
•Next thing we noted on our profiling was the
time updating the overlaps

34. Move overlap
• Each moved objevt moved its collision mesh
• After that all collision and overlap events were recalculated

35. Move Overlap
• Our game could ran on simplified physics model
• All the collision detection was then done on our custom code

36. Move overlap
• We also turned off the option to generate Overlap Events in each
one of our game objects
• Our game time was further reduced to about 6ms

37. Nativization
• Since the version 4.12 Unreal Engine has an option to nativize the
blueprints
• We had already experimented some success using this feature in
another project

38. Nativization
• But the project wasn’t packaging using it
• Later we found that accesing enums in level blueprints caused it.

39. Nativization
• Moved the enum access to other classes, then it worked
• With nativization we cut another 1.5ms
• Probably would’ve be more if we weren’t already doing
things in C++

40. Other things
• We also started moving some distant objects at 30fps
• And stopped moving meshes while they weren’t being seen

41. Results
• After all those optimizations, the game was taking only 4ms to
process the gameplay
• Good in keeping the framerate and also minimizing the overheat

42. Graphics
• We wanted missions in different times of day
• We even thought about adding some missions from the sunset until
evening

43. Graphics
• Early in the project we decided to keep the player somewhat
static and move the world
• It is a game about avoiding other cars and it would be kind of
boring if those cars were static

44. Graphics
• This made using lights baked by the editor
infeasible
• We tried dynamic and stationary lights

45. Graphics
• At first we were below even 30fps
• Turning the shadows off increased performance
to 45 fps
• With a bit more optimization we reached 50fps

46. Graphics
• But we needed 60fps
• We forego using the Unreal Lightning pipeline
and implemented our own
• Once again based on the Robot Recall Blimp

47. Graphics
• We used the material editor to shade our objects

48. Graphics
• On some materials we didn’t use normal mapping and abused a bit
the material editor

49. Graphics

50. Graphics
• We run our gameplay scene in unlit mode

51. Graphics
• Our draw distance is relatively short
• We then made the objects show up smoothly

52. Graphics

53. Graphics

54. Graphics
• In mostly static scenes you can use static lights
• Then, for objects with a little movement you can use this option
• Remember to set a big enough lightmap resolution

55. Graphics

56. Graphics

57. Thanks!
• Questions?
• @vvecchi (mostly in portuguese)
• vinicius@vrmonkey.com.br