When developing content for Virtual Reality (VR) projects, certain steps must be taken to ensure that the user will have the best VR experience possible. In the following Best Practices guide, we will cover all you need to know to provide the user with the best possible experience when viewing your project using GoogleVR.
GoogleVR Rendering Options
While combining Unreal Engine and GoogleVR can produce some very immersive VR experiences, there are some rendering features that Unreal Engine can not perform while using GoogleVR due to hardware limitations. Many of the restrictions that you will encounter are similar to limitations for mobile devices. However, because of the unique rendering requirements for GoogleVR, there are few extra things that must be considered. In the following sections, we will cover what these requirements are and how they can affect your GoogleVR project.
Monoscopic Far Field
Monoscopic Far Field Rendering (or, more accurately, Hybrid Monoscopic Rendering) is an advanced rendering feature for VR Mobile applications being built in Unreal Engine 4 (UE4). Generally, Monoscopic Far Field Rendering improves the performance of levels containing a significant amount of distant content. The reason that Monoscopic Far Field Rendering improves the performance of levels having a lot of distant content is that distant objects are rendered only once for both eyes. At Epic, we've observed that rendering distant objects this way yields significant performance improvements for VR Mobile applications.
Mobile HDR
Mobile HDR will not work with GoogleVR, and it should be left disabled.
Post Processing
Due to the demanding rendering requirements for GoogleVR, many Post Processing features, unfortunately, will not work. Below you will find a list of all the Post Process features that will work with GoogelVR.
| Post Processing Section | Feature Name | Description |
|---|---|---|
| Auto Exposure | Exposure Bias | Can be used to increase or decrease the scenes brightness. |
Materials
Creating and interacting with Materials for GoogleVR projects is very similar to creating and interacting with Materials for other projects. You still use the Material Editor to create Materials, and you can still use many of the Material nodes you find in the Material Editor. However, there are a few restrictions/considerations that must be adhered to when making Materials for GoogleVR to ensure that what you make will work properly with the hardware.
| Material Input Name | Description |
|---|---|
| Base Color | Base Color defines the overall color of the Material. |
| Roughness | Roughness defines how rough or smooth the Material appears overall. |
| Metallic | Metallic defines how metal-like the Material is. |
| Specular | Specular defines the intensity of the reflections, or how shiny the material is. |
| Normal | Normals add surface detail that would otherwise be too costly to model. Surfaces with normal maps can look wrinkled or bumpy, as opposed to perfectly flat or smooth. |
| Emissive | Emissive helps to make parts of Materials glow, like they are emitting light. |
| Opacity | Opacity helps to define how translucent a given pixel is, on a scale from 0.0 to 1.0. |
| Opacity Mask | Opacity Masks allow individual pixels to be completely opaque or completely invisible. |
Please keep in mind that the both Translucent and Masked Materials can be very expensive to render, especially on hardware like Smartphones. Whenever possible, you should use Opaque Materials, since they are much cheaper to render.
Material Shading Models
Due to hardware limitations, only the following Material Shading Models are available for use in projects that use the GoogleVR.
| Shading Model Name | Description |
|---|---|
| Default Lit | Default Lit is, as the name suggests, the default shading model and will likely be the one that you will use most often. This shading model makes use of direct and indirect lighting, as well as specularity for reflections. |
| Unlit | The Unlit Shading Model only outputs Emissive for color, making this perfect for special effects such as fire or illuminating objects. |
Try to use the Unlit Shading Model as much as possible with your GoogleVR projects, since it is the cheapest to use.
Material Blend Modes
Material Blend Modes describe how the output of the current Material will blend over what is already being drawn in the background. When creating content for the GoogleVR, the following Material Blend Modes are available for use.
| Blend Mode | Description |
|---|---|
| Opaque | For a solid object, Opaque is the cheapest material. But, as its name implies, it has no support for translucency. That means it will never create overdraw, and rendering one pixel of the material will always take the same time, depending on the complexity of the Node Graph. |
| Masked | If you need some pixels not drawn on your material, this is the way to go. The material only creates overdraw for the area that is masked out. But each pixel drawn by the material is either 100% opaque, or 100% transparent. The bigger the area that is masked out, the more overdraw is created. |
| Translucent | This is the most expensive BlendMode. It can look like a Masked and Opaque, but will have an additional effect on performance regardless of actually being transparent or not. |
| Additive | Is a cheaper alternative to Translucent. It does not need to sort the pixels, they just get added to the scene. Because of this, Additive materials can only brighten the pixels that they cover. Black pixels on the material do not affect the scene. |
| Modulated | Along with Additive, Modulated blending is another cheaper alternative to Translucent, but it multiplies its color intensity by the colors that already exist in the scene. Because its colors will be mapped to the range of 0.0 to 1.0, Modulated materials can only darken the scene. White pixels on these materials will not affect the scene. |
When using the Modulate blend mode make sure to disable Separate Translucency or your Material will not compile correctly.
Mobile Specific Material Settings
On the Main Material Node under the Details Panel, you will find a section called Mobile. The settings contained here are for helping to lessen Material rendering costs on mobile devices.
| Property | Description |
|---|---|
| Fully Rough | When enabled, saves some shader ALU instructions and one sampler. This effectively disables Specular while maintaining overall reflective energy. |
| Use Lightmap Directionality | When disabled, lighting from light maps will be flat but cheaper. |
Customized UVs
Customized UVs enable you to perform certain operations in vertex shaders rather than pixel shaders to help avoid dependent texture fetches. This offers an excellent way to claw back much-needed performance when doing simple things like UV manipulation to make a texture title more than it currently does. Whenever possible, make sure to do all UV manipulation using Customized UVs, especially when developing content for GoogleVR.
Customized UVs are currently only implemented for certain component types such as Static Meshes, Skeletal Meshes, BSP, Landscape, and Mesh Particles.
Reflections
GoogleVR does not support Screen Space Reflections(SSR) which means you will only be able to generate reflections that come from Reflection Capture Actors that are placed in levels. Also, keep in mind that the reflections that are generated from the Reflections Actors will not be of very high fidelity due to hardware limitations.
GoogleVR & Content Setup
When creating art content for your GoogleVR projects, there are few things that you need to keep in mind to ensure that your project can run as smoothly as possible. In the following section, we will cover what you need to be concerned with when making art content for GoogleVR:
Content Hard limits
Due to certain hardware restrictions on mobile devices, the following restrictions must be adhered to when creating content. Failing to follow these restrictions will result in your project not working.
- All mesh types can have up to but not over 65,000 vertices due to the lack of 32-bit index support on mobile hardware.
- Skeletal Meshes can have up to but not over 75 bones.
Mesh Considerations
When creating Meshes to use with your GoogleVR Project the following information needs to be kept in mind to ensure that what you are creating will work with GoogleVR.
- Use as few Material IDs on 3D meshes as possible to save on draw calls.
- Make sure to make use of Static Mesh LODs whenever possible.
- Keep an eye on your 3D meshes polygon count and try to keep it as Low Poly as possible.
- Make sure that all static models have a 2nd UV set so they can make use of Light Mapping.
- Whenever possible, try to make use of Impostor Sprites to replace far away Static Meshes as they are much cheaper to render.
Texture Considerations
When creating Textures to use with your GoogleVR project the following information needs to be kept in mind to ensure that what you are creating will not be detrimental to your project's overall performance.
- Textures can not be bigger than 2048 pixels in either the X or Y dimension.
- Textures sizes must be in a power-of-two sizes on each axis. For example, an image could be 128 or 256 pixels wide, but not 129.
- It is recommended that no more than 128 MB of textures be loaded at any given time, although loading up to 512 MB of Textures into memory is possible with GoogleVR.
- Use square Textures (equal width and height, such as 1024x1024 pixels) whenever possible, as they make more efficient use of memory.
- Wherever possible try to use Texture Atlasing to reduce the number of Textures needed in memory.
- RGB Texture Masking / Packing is an excellent way to cut down on unique Textures in memory.
- Only TC_Default and TC_NormalMap compression settings should be used. They are the only two that will work on mobile platforms.
Level Considerations
Getting the maximum performance out of your Levels on GoogleVR is a delicate balancing act that will require time to get just right. The following suggestions can help you quickly identify areas of your Levels that might cause performance issues:
- Always make sure that the Level's lighting has been built to ensure you get the best performance possible. The Editor provides a red "Lighting needs to be rebuilt" error message to let you know when this needs to be done.
- Make sure that all the lights in your Level are set to Static as the other lighting options can be costly to render.
- Check to see if your Level is making use of Precomputed Visibility and if not, make sure to add one to the Level and rebuild lighting to enable it in the Level's World Settings.
- Draw calls for the entire scene should not be greater than 100 for any view. This can be seen with stat openglrhi on the device, stat d3d11rhi in ES2 previewer on PC.
- The total triangle count of the Level should not be greater than 100,000 from any view. This can be seen with stat openglrhi on the device, stat d3d11rhi in ES2 previewer on PC.
- Be very careful in how Translucent and Opacity Masked Materials are used in the Level, as they are costly to render.
- Make sure to Performance Profile your Level often to make sure you catch any performance issues sooner rather than later.