UDN
Search public documentation

ViewModes
Licensees can log in.

Red links require licensee log in.

Interested in the Unreal engine?
Check out the licensing page.

Questions about UDN itself?
Contact the UDN Staff

View Modes

Document Summary: This document lists the various View Modes available in game and in the editor.

Document Changelog: Created by Joe Graf; updated by Andrew Scheidecker, Dave Nash, Niklas Smedberg, Daniel Vogel, and Daniel Wright.

Modes

View modes are mutually exclusive rendering styles. A viewport can only have a single active view mode. In the editor, the view mode is selected using the right combo box in the viewport's toolbar. In the game, the view mode can be changed using the viewmode command.

viewshowflags.JPG

Wireframe

This mode shows the wireframe of all meshes.
Command: viewmode wireframe"

wireframe.JPG

Brush Wireframe

This mode shows the wireframe of actors and CSG brushes. The BSP wireframe is hidden. This mode only works in the editor.

brushwireframe.JPG

Unlit

This mode shows the diffuse channel of the material used by each mesh.
Command: viewmode unlit

unlit.JPG

Lit

This mode displays the material used by each mesh affected by lighting. It is the default mode in the game.
Command: viewmode lit"

lit.JPG

Lighting Only

This mode displays meshes with a gray material affected by lighting.
Command: viewmode lightingonly

lightingonly.JPG

Light Complexity

This mode displays meshes with a solid color based on the number of lights affecting the mesh.
Command: viewmode lightcomplexity

The mesh coloration in viewmode lightcomplexity indicates the number of lights affecting a mesh that are not skylights or lightmaps, according to the following scheme (defined in YourGameEngine.ini):

#Lights: Mesh Color
0: (R=0,G=0,B=0,A=1)
1: (R=0,G=255,B=0,A=1)
2: (R=63,G=191,B=0,A=1)
3: (R=127,G=127,B=0,A=1)
4: (R=191,G=63,B=0,A=1)
5: (R=255,G=0,B=0,A=1)

Note that light complexity is something that is important to view in game, as most dynamic lights are spawned during game play (e.g. muzzle flashes, explosions, etc).

lightingcomplexity.JPG

Texture Density

This viewmode is used for two things:

  • To check that you're spending the high-res textures on surfaces that matters the most (e.g. close to the camera and not high up on roof tops).
  • To check if you have a high-res texture placed next to a low-res texture (sharp contrast in texture resolution), which can look bad.

The viewmode displays meshes with a color that represents the texture density, or the number of texels per world space unit. High density will be red, medium density green and low density blue. This can help you reduce sharp contrast between high-resolution polygons and low-resolution polygons, and also help you make sure you are spending the texture resolution where it matters the most.

The threshold parameters for low, medium and high density are defined in BaseEngine.ini and you can override these three values for each game.
The parameters are MinTextureDensity (default 0.0), IdealTextureDensity (default 13.0) and MaxTextureDensity (default 55.0).

Command: viewmode texturedensity

texturedensity.JPG

Shader Complexity

The Shader Complexity viewmode lets you visualize how many pixel shader instructions were executed on each pixel. The total complexity is calculated as the number of instructions used to render emissive plus instructions for each lighting pass and the translucent pass. Note that fog, post process, distortion and other effects are not counted. The cumulative instruction count is then mapped to bright green for the cheapest pixels to dark green, then dark red, then bright red for the most expensive pixels. These settings have their defaults in BaseEngine.ini:

  • ShaderComplexityColors=(R=0,G=255,B=100,A=1)
  • ShaderComplexityColors=(R=0,G=255,B=0,A=1)
  • ShaderComplexityColors=(R=63,G=191,B=0,A=1)
  • ShaderComplexityColors=(R=127,G=127,B=0,A=1)
  • ShaderComplexityColors=(R=191,G=63,B=0,A=1)
  • ShaderComplexityColors=(R=255,G=0,B=0,A=1)
  • bUsePixelShaderComplexity=True
Indicates that pixel shader complexity should be accumulated, otherwise vertex shader complexity will be accumulated.
  • bUseAdditiveComplexity=True
If this is true, complexity = emissive + lighting passes + translucency. Otherwise complexity = last pixel drawn from emissive, lighting and translucent passes. Using opaque translucency can be useful when you are trying to narrow down which pass is the most expensive. Note that vertex complexity is always opaque, so complexity = last pixel drawn from emissive and translucent passes. (Lighting passes are excluded)
  • MaxPixelShaderAdditiveComplexityCount=300
The instruction count which will be mapped to bright red when bUsePixelShaderComplexity==True and bUseAdditiveComplexity==True.
  • MaxPixelShaderOpaqueComplexityCount=100
The instruction count which will be mapped to bright red when bUsePixelShaderComplexity==True and bUseAdditiveComplexity==False.
  • MaxVertexShaderComplexityCount=100
The instruction count which will be mapped to bright red when bUsePixelShaderComplexity==False.

Only instruction count is used to calculate shader complexity, which may not always be accurate. For example, a shader with 16 instructions, all texture lookups, will be much slower on all platforms than a shader with 16 math instructions. Also shaders which contain loops that are not unrolled will not be represented accurately by the instruction count, this is mainly an issue for vertex shaders. Overall the instruction count is a good metric in the vast majority of cases.

A couple of things to notice when using additive pixel complexity:

  • Be sure to look at shader complexity for your level both in the editor and in game (or PIE). This lets you narrow down whether the level is too expensive or gameplay elements, such as dynamically spawned effect lights, are the cause of poor performance.
  • Anything with static lighting should be green, because only the emissive pass is rendering these objects, so they are very cheap. If static objects are unexpectedly red, make sure you have your lighting built.
  • Terrain will often be red, even with lighting built, because the combined terrain material is so expensive. It is important that you make each layer's material as simple as possible, since terrain often covers a lot of pixels.
  • Particle systems will usually be red because of the massive amount of overdraw. When optimizing particle systems it may be useful to change the color mapping scale (by changing the max value), but remember to change it back!

For vertex complexity:

  • Translucency will be red because of the extra instructions needed to calculate fog per-vertex.
  • Anything GPU skinned will be red.

This viewmode is currently only available on PC running on shader model 3 cards, and is incompatible with simple lightmaps.

Command: viewmode shadercomplexity

shadercomplexity.jpg

Editor-only modes

Property Coloration

This mode permits the visualization of actors with specific property value. Mark a property by shift-clicking on the property in the property window. Then, enable the "Property Coloration" show flag in an editor viewport, and all objects of that type with the same property value will be highlighted in red. Objects with the same property value can also be selected via the right-click menu.

Currently, the property comparison is exact. A light with brightness 1.0, for example, will not be considered to have the same value as a light with brightness 1.001.

Occlusion Preview

This mode enables the visualization of engine frustum culling and occlusion. Activate it by clicking the right-most eye button on a perspective level viewport (labeled in red below; new button art forthcoming).

original.jpg

With the Occlusion Preview mode enabled, the other viewports are considered occlusion children and will render only what is being rendered in the occlusion parent view.

This viewmode is useful to de-clutter wireframe views, as well as for previewing occlusion (ie: determining what exactly is being drawn by the engine for a particular view).

Below is a before/after image of one of the ortho viewports, where occlusion viewmode is disabled on the left and enabled on the right. The pink view frame shows where in the world the viewpoint of the occlusion parent is.

ortho.jpg

Below is another before/after image, this time of a child viewport that was set to a perspective view and moved to a different location.

perspective.jpg

Show flags

For a list of the various Show Flags in the editor, see the Show Flags page.