Atch (1)_APPENDIX L NETC RRL Single User Gaming and Simulation Guidance - 06 Dec 2019.odt

SINGLE User Gaming and Simulation Guidance for Ready, relevant learning (RRL)

10 September 2018

Prepared by:

Naval Education and Training Command 250 Dallas Street Pensacola, FL 32508

Introduction The vision of the Ready Relevant Learning (RRL) and Sailor 2025 initiative is that each Sailor shall have access to advanced training approaches, training materials, and references in an environment that supports Navy-provided technology and in the long term, personal smartphones and tablets. To achieve the goals of the Sailor 2025 initiative, Navy Training will employ new cutting-edge technologies such as immersive gaming and simulation content and applications.

The future of education has arrived with gaming and simulation training. With gaming and simulation, you can show realistic visual and training environments to teach complex tasks and concepts. For example, familiarize yourself with the environment of an operations floor; receive an orientation before reporting to a new duty location; or identify threats and converse with civilians in a foreign restaurant. Gaming and simulation training enables individuals to train more effectively, efficiently, and affordably than ever before.

Purpose The purpose of this document is to define Best Practices and technical content standards to ensure that single user gaming and simulation content created for RRL will perform to minimum standards on the TRANET network infrastructure and including both physical and virtual workstations, as well as future mobile and wireless devices. Multi-user gaming and simulation will be covered in a separate document due to the additional requirements for network protocols and resources.

The challenge of creating gaming and simulation training content is to find the right balance between visual complexity and resolution as it relates to an end user’s connection speed and system ability. Here is a short list of potential impacting variables:

Device and Screen size

Network traffic to and from the server hosting the content

The CPU and GPU abilities on the playing device

Other programs running in the background

Virtual Desktop infrastructure server to user endpoint bandwidth

RRL Gaming and Simulation Guidance These are meant as standards and guidelines to ensure that gaming and simulation content developed for RRL will perform on current and planned infrastructure to provide the sailor with the best training experience. In addition, these standards enforce the widest possible accessibility to training content for both classroom workstations and mobile devices.

Visual Complexity Gaming and Simulation content visual complexity should be limited unless necessary for educational impact to reduce the overall computing requirements (bandwidth, computational load, and graphical rendering) for maximum compatibility across RRL mobile and workstations. Examples of such visual complexity include rendering smoke or other effects, high detail backgrounds that interact with the user or character, high resolution textures, and movement or complexity that results in constant video like screen update. Examples of this are a character in a simulation that sways side to side while standing idle or a background that includes moving objects if it does not enhance the simulation training objectives then the extra features may not be necessary. Character clothing should be solid colors and not patterns, shapes, stripes, or digital camouflage.

This visual complexity has the highest impact on any infrastructure due to the server to client model of network traffic and screen updates. In addition, classroom student density and network infrastructure between the classroom and infrastructure servers’ aggregate bandwidth and performance limiting factors. Ultimately, this determines what individual classrooms will be able to deliver content that requires certain graphics capabilities or bandwidth requirements. It should be noted that network infrastructure upgrades are part of the phased implementation plan of RRL and thus not all classrooms and workstations meet this minimum standard as of the time of writing.

In addition to network bandwidth considerations, overall computing resources required by the gaming and simulation engine. The 3 largest areas of computing resources consumed are Central Processing Unit (CPU), Graphics Processing Unit (GPU), and Random Access Memory (RAM) used in conjunction with CPU and GPU subsystems. The proposed TRANET workstation standard for graphics acceleration is 1GB of video RAM and single graphics core processor. This advanced graphics capability is also a phased implementation across the TRANET infrastructure.

CPU Optimization To render objects on the screen, the CPU has a lot of processing work to do: working out which lights affect that object, setting up the shader and shader parameters, and sending drawing commands to the graphics driver, which then prepares the commands to be sent off to the graphics card. CPU usage is resource-intensive, so if the simulation contains lots of visible objects, it can add up. For example, if the content has a thousand triangles, it is much less resource intensive on the CPU if they are all in one mesh, rather than in one mesh per triangle (adding up to 1000 meshes). The computing resources impact of both scenarios on the GPU is very similar, but the work done by the CPU to render a thousand objects (instead of one) is significantly higher and should be avoided.

To reduce CPU utilization:

•Combine close objects together •Use fewer materials in your objects by putting separate textures into a larger texture atlas •Use fewer things that cause objects to be rendered multiple times (such as reflections, shadows and per-pixel lights) The developer should combine objects together so that each mesh has at least several hundred triangles and uses only one Material for the entire mesh. Note that combining two objects which do not share a material does not provide any performance increase at all. The most common reason for requiring multiple materials is that two meshes don’t share the same textures; to optimize CPU performance, ensure that any objects combined share the same textures.

GPU Optimization There are two basic rules for optimizing the geometry of a model:

•Do not utilize more triangles than necessary •Keep the number of UV mapping seams and hard edges (doubled-up vertices) as low as possible Note that the actual number of vertices that graphics hardware must process is usually not the same as the number reported by a 3D application. Modeling applications usually display the number of distinct corner points that make up a model (known as the geometric vertex count). For a graphics card, however, some geometric vertices need to be split into two or more logical vertices for rendering purposes. A vertex must be split if it has multiple normals, UV coordinates or vertex colors. Consequently, the vertex count in Unity is usually higher than the count given by the 3D application.

While the amount of geometry in the models is mostly relevant for the GPU, some features in also process models on the CPU (for example, mesh skinning).

Lighting Performance The least GPU and CPU resource intensive option is always to create lighting that doesn’t need to be computed at all. To do this, use Lightmapping to utilize static lighting just once, instead of computing it each frame.

Per-pixel dynamic lighting adds significant rendering work to every affected pixel, and can lead to objects being rendered in multiple passes. The developer should avoid having more than one Pixel Light illuminating any single object on less powerful devices, like mobile or low-end PC GPUs, and use lightmaps to light static objects instead of calculating their lighting every frame. Per-vertex dynamic lighting can add significant work to vertex transformations, so try to avoid situations where multiple lights illuminate a single object.

The developer should also avoid combining meshes that are far enough apart to be affected by different sets of pixel lights. When you use pixel lighting, each mesh must be rendered as many times as there are pixel lights illuminating it. If you combine two meshes that are very far apart, it increases the effective size of the combined object. All pixel lights that illuminate any part of this combined object are taken into account during rendering, so the number of rendering passes that need to be made could be increased. Generally, the number of passes that must be made to render the combined object is the sum of the number of passes for each of the separate objects, so nothing is gained by combining meshes.

Example: Consider a driving game in which the player’s car is driving in the dark with headlights switched on. The headlights are probably the most visually significant light source in the game, so their Render Mode should be set to Important. There may be other lights in the game that are less important, like other cars’ rear lights or distant lampposts, and which don’t improve the visual effect much by being pixel lights. The Render Mode for such lights can safely be set to Not Important to avoid wasting rendering capacity in places where it has little benefit.

Optimizing per-pixel lighting saves both the CPU and GPU work: the CPU has fewer draw calls to do, and the GPU has fewer vertices to process and pixels to rasterize for all the additional object renders.

GPU Texture compression and mipmaps The developer should use compressed textures to decrease the size of textures. This can result in faster load times, a smaller memory footprint, and dramatically increased rendering performance. Compressed textures only use a fraction of the memory bandwidth needed for uncompressed 32-bit RGBA textures.

Always enable Generate mipmaps for textures used in a 3D scene. A mipmap texture enables the GPU to use a lower resolution texture for smaller triangles. This is similar to how texture compression can help limit the amount of texture data transferred when the GPU is rendering.

The only exception to this rule is when a texel (texture pixel) is known to map 1:1 to the rendered screen pixel, as with UI elements or in a 2D game.

Level of detail and per-layer cull distances Culling objects involves making objects invisible. This is an effective way to reduce both the CPU and GPU load.

In many games, a quick and effective way to do this without compromising the player experience is to cull small objects more aggressively than large ones. For example, small rocks and debris could be made invisible at long distances, while large buildings would still be visible.

There are a number of ways the developer can achieve this:

•Use the Level Of Detail system •Manually set per-layer culling distances on the camera •Put small objects into a separate layer and set up per-layer cull distances using the Camera.layerCullDistances script function

Computing resources summary •TRANET proposed workstation standard is 1GB video RAM and one video graphics core •Keep the vertex count below 200K and 3megapixels per frame •When utilizing using built-in shaders, pick ones from the Mobile or Unlit categories. They work on non-mobile platforms as well, but are simplified and approximated versions of the more complex shaders.

•Keep the number of different materials per scene low, and share as many materials between different objects as possible.

•Set the Static property on a non-moving object to allow internal optimizations like static batching.

•Utilize a single (preferably directional) pixel light affecting your geometry, rather than multiples.

•Bake lighting rather than using dynamic lighting.

•Use compressed texture formats when possible, and use 16-bit textures over 32-bit textures.

•Avoid using fog, rain, waves, clouds, or movement that do not add effectiveness to the training.

•Use Occlusion Culling to reduce the amount of visible geometry and draw-calls in cases of complex static scenes with lots of occlusion. Design your levels with occlusion culling in mind.

•Use skyboxes to “fake” distant geometry.

•Use pixel shaders or texture combiners to mix several textures instead of a multi-pass approach.

•Use half precision variables where possible.

•Minimize use of complex mathematical operations such as pow, sin and cos in pixel shaders.

•Use fewer textures per fragment.

Software Gaming and Simulation content should be developed using a single software vs. multiple software products combined into complex application. Previously, content has been created using complex Adobe Flash and other obsolete gaming engines into a combined package which is unstainable. Such complex and now obsolete frameworks and supporting software binaries affect the usable lifespan of training materials. It is imperative that the content and training materials are developed using the latest supported gaming engine with contracted support agreements with the vender registered in Department of the Navy (DoN) Application and Database Management System (DADMS). NETC is currently recommending the use of Unity Gaming engine, the Unreal Engine, or CryEngine for developing RRL content. Developers should consult with NETC when using alternate software frameworks.

Scalability Gaming and Simulation content should be developed using a software and frameworks which support scaling of content delivery packages visual complexity and computing requirements (network bandwidth, computing resources, and video acceleration capabilities) for various endpoint devices to include mobile devices and network bandwidth limited scenarios. The recommended gaming engine developments frameworks (Unity, Unreal, and CryEngine) all support scaling of visual complexity for various endpoint delivery devices such as 3D graphics limited workstations and mobile devices. In addition, the NETC Training Delivery Services team should be consulted for the latest workstation and server graphical capabilities technical information when developing RRL Gaming and Simulation content. One of the key goals of RRL is to ensure students have maximum access to training materials. By ensuring that training content is created with tools that allow for both mobile and desktop training, maximum content distribution and access to the material is maintained. The content complexity and visual information should scale to provide the best user experience on the device, be it a wireless tablet or a dedicated training workstation.

Supportability Gaming and Simulation content should be developed using a software and frameworks which have significant contracted support lifetimes and are registered and approved in DADMS. In addition, it is imperative that plans for long term lifecycle management of training material should be included during the acquisition and development phases. The NETC Functional Area Manager (FAM) has developed the Training Apps Guidelines which covers in greater detail of the requirements for software and applications before they are permitted for use on TRANET.

Game Engine optimization references:

Unity https://docs.unity3d.com/Manual/UnityManual.html https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html Unreal Engine 4 https://docs.unrealengine.com/latest/INT/ https://docs.unrealengine.com/latest/INT/Engine/Performance/ CryEngine http://docs.cryengine.com/display/SDKDOC2/Performance http://docs.cryengine.com/display/SDKDOC2/Home

29 March 2019

APPENDIX N: RRL SINGLE USER GAMING AND SIMULATION GUIDANCE

Page 06 December 2019

APPENDIX L: RRL SINGLE USER GAMING AND SIMULATION GUIDANCE

Page of 06 December 2019

APPENDIX N: RRL SINGLE USER GAMING AND SIMULATION GUIDANCE

Page