RPI Samples

AssetLoadTest

Description
The AssetLoadTest sample can be accessed by using BaseViewer's Samples → RPI/AssetLoadTest menu.

This sample demonstrates Atom's ability to quickly load meshes and render many objects at high frame rates. It renders a grid made up of selected models and materials. The models and materials can be set to reload at a regular cadence. It is also possible to see the effects of pushing new transforms to each draw every frame.



Debug Menu

Switch (Materials / Models) Every N Seconds
When checked, the (materials / models) on all of the objects will be randomly reassigned based on the (materials / models) white list.

Update Transforms Every Frame
When checked, this pushes a new transform to each draw individually each frame. This is useful to test the performance of large numbers of moving objects.

Lattice Width / Height / Depth
Controls the number of objects to render. Maximum objects for this test is 20x20x20 = 8000.

Materials
Shows a list of available materials. Materials can be added or removed from the white list. Only whitelisted materials will be applied to objects in the scene.

Models
Shows a list of available models. Models can be added or removed from the white list. Only whitelisted models will appear in the scene.


Test Cases (with expected results and screenshots)

Test Case 1 - Basic Functionality
1 Run the RPI/AssetLoadTest sample. There should be no errors, warnings, or asserts.
2 If the model or material white lists are empty, add one material and model to each (the defaultPBR material and cube model work well).
3 Make sure the whitelisted model displays with the whitelisted material.



Test Case 2 - Model and Material Reloading
1 Add some additional models and materials to the white list.
2 Make sure both switch models / materials every second is selected.
3 The models and materials should reload and shuffle positions every n seconds.



Test Case 3 - Displaying Many Models
1 Turn off model and material reloading.
2 Remove any models from the model list with large polygon counts -

a. Cube, Suzanne, or Sphere work well, Bunny does not since it's polygon count is high
b. The point with this test is to stress out the CPU side of the renderer. If the models are too complicated, then the bottleneck will be the GPU.

3 Increase the width / height and depth to 20. It may take several seconds to create all the draw packets when clicking the last slider to 20.
4 Once all of the draws have been created, it should render at a reasonable framerate. Check View→Framerate Histogram to see current framerate.
5 Turn on "Update Transforms Every Frame". This should cause all of the objects to start rotating, along with a small drop in framerate.



Automation
Currently not available.

This sample works well as a performance test, so we should add automation support to allow

• Setting the materials / meshes in the white list.
• Controlling the width / height / depth of the lattice.
• Allow reloading of the materials or meshes on demand.

Platform Support
This sample should work on all supported platforms.

AuxGeom

Description
This example aims to use all types of AuxGeom Draw.

Debug Menu
No debug menu for this example, just Mouse & Keyboard control the camera.

Test Cases (with expected results and screenshots)
This is the whole level, it will require camera navigation to check each of the cases


The cases can be broken down into several groups:
Shape Draws


Box Draws

Triangle Draws




Line Draws


Point Draws


Depth Control Tests





Shape Draws
This test draws a 3d grid of shapes.
3 Layers of Shapes
Top: Cylinders
Middle: Cones
Bottom:Spheres


Each Shape in 3 vertical layers
Middle: DepthTest On & DepthWrite Off, DepthTest Off & DepthWrite On
Bottom: Opaque & Translucent


If you line up the middle rows you can see them overwrite each other like this


Each Shape with 3 styles
Wireframe, Solid, Shaded


Each Shape in 4 different sizes & orientations




Box Draws
This test draws a 3D grid of boxes
OBB = Oriented Bounding Box
AABB = Axis Aligned Bounding Box

5 Rows
Top: local space AABB converted to OBB and placed with a transform
2nd: world space rotation OBB , offset by draw transforms
3rd: world space OBB
4th: transformed AABB
5th: plain world space AABB.


3 Columns
Wireframe, Solid, Shaded.


4 different sizes and orientations



Triangle Draws
This tests the various ways of submitting raw triangles to AuxGeom

Mass submit single triangles

This test submits 120K DrawTriangle calls to build up the plane.

Single Colored Opaque and Translucent Triangles

This test draws 2 rows of intermingled opaque and translucent triangles. One row is 8 calls to DrawTriangle and the other is made of 2 calls to DrawTriangles. Both rows should look the same and the translucent triangles shouldn't incorrectly draw over another triangle

Cubes of Triangles

This test draws 4 boxes using triangles. 2 Boxes are multicolored to test color interpolation. 2 Boxes are single color. One box of each color type is translucent.

Line Draws

Crosses

This test draws 2x2 3d crosses, one row is transparent, the other is opaque. One column is Black, the other is multi colored.

Pyramids

This test draws 2x2 3d pyramids. One row is transparent, the other is opaque. One column is Black, the other is multi colored.

Single Colored Poly Lines

This test draws 2x2 single color polylines. One row is transparent, the other is opaque. One column is open, the other is closed.


Point Draws
This draws 3 intersecting planes of points.

The red points are drawn by individual calls to DrawPoint. The green points are drawn with a single call to DrawPoints. The blue points are drawn with a single call to DrawPoints, each point has a different translucency value.

Depth Test
This test draws a series of cubes with depth testing and depth writes toggled to validate we see the expected result. The left side is drawn using AABB's and the right is drawn using triangles. Both sides should produce the same result. The red cube should draw over the green cube. The blue cube should draw over all the other cubes. The yellow cube should draw over the green cube but behind the red and blue cubes.



Platform Support It was checked on Windows with DX12 and Vulkan.
Unverified on Mac, iOS, Android, & Linux.

BistroBenchmark

Description
The BistroBenchmark sample can be accessed by using BaseViewer's Samples → RPI/BistroBenchmark menu.

The long term goal for this sample is to show many different features of Atom, and allow profiling of all of these systems working together. Currently it is rather simple, and just uses the Bistro model, a directional light, physical sky, and one global image base light.


The sample loads automatically, and plays 10,000 frames over a fixed path. To allow for easy screenshot comparison, specific frame numbers always exist in the same location no matter the frame rate. Higher frame rates simply lead to the test being completed more quickly.

Test Cases
The Bistro sample is made to run completely automatically, and is ideally used with automation. To test manually:
1 Open the Bistro Sample.
2 Let it run to completion.
There should be no errors or crashes over the course of the run

Metrics
After the camera fly-through is complete, a screen is presented that gives the performance metrics for that run. An XML file named bistroRun_#.xml is also stored to Cache\BaseViewer\pc\user\benchmarks\ with the statistics, where # is an integer timestamp.


Automation
Specific frames can be captured in the bistro benchmark using the "-screenshot" command line option followed by a comma separated list of which frame numbers to capture. The list should not include spaces, so something like "-screenshot 100,101,102". The Bistro benchmark always runs for a specific number of frames, so it should be possible to compare two frames with the same number. The file name follows the format "screenshot_bistro_n.dds" where n is the frame number. -screenshotFolder can also be used to set the location that these screenshots are saved to.

Platform Support
The bistro sample should run on all platforms.

Decal

Description
This sample is a testbed for the Atom Decal system. It projects a large number of decals onto various objects with different materials and settings.

Screenshots


Automation
This sample can be run directly with command line -sample RPI/Decals. Decals.bv.lua is the file that controls the BaseViewer automation testing.

Platform Support
Decals are a core feature and should run on all platforms that Atom can run on

DynamicDraw

Description
This sample demonstrates how to create and initialize DynamicDrawContext and render several triangular pyramids with different render states by using the DynamicDrawContext.

The primitives rendered in this samples show render state change which include: face cull modes, primitive types, depth states and blend states. It also include drawing with different viewport.

Debug Menu
The DynamicDraw sample can be accessed by using BaseViewer's Samples→RPI/DynamicDraw menu.

On the example's sidebar menu there are several check boxes which are using to show/hide the draw call for certain render states.

CullMode::None. Renders a triangular pyramid without face culling when it's checked.

CullMode::Front. Renders a triangular pyramid with front face culling when it's checked.

CullMode::Back. Renders a triangular pyramid with back face culling when it's checked.

PrimitiveTopology::LineList. Renders a triangular pyramid using line lists when it's checked.

Alpha Blend. Renders a triangular pyramid with alpha blend enabled when it's checked.

Alpha Additive. Renders a triangular pyramid with alpha blend enabled when it's checked. The blend mode is additive.

Per Draw Viewport. Renders a triangular pyramid in a viewport over top left corner of the window when it's checked.


Screenshots

Automation
The automation test for this sample is BaseViewer/Scripts/DynamicDraw.bv.lua.

Platform Support
The sample should work on all platforms

Screenshots



Automation
The automation test for this sample is BaseViewer/Scripts/DynamicDraw.bv.lua.

Platform Support
The sample should work on all platforms.

DynamicMaterialTest

Description
This sample demonstrates that we can make multiple independent instances of a material, and update those material instances' properties in real time. These features are an important foundation for supporting gameplay scripts that update the appearance of objects.

All of the objects in this scene are using the same material asset, but they each have a unique instance of that material. (The objects could all share the same material instance, which is better for performance, but then their appearances could not change independently). There are a few different materials available for use. In each case, the material continually oscillates its appearance.

There is a small performance panel that shows how long it takes to update all the materials, and the average time per material.





Debug Menu
The first three options control the size of the lattice, to add or remove objects. The "Enable Dynamic Updates" checkbox can be used to pause the color cycle. There is also a readout of the number of objects in the lattice.

Test Cases (with expected results and screenshots)

Test Case 1 - Basic Functionality
1 Run the RPI/DynamicMaterialTest sample. There should be no errors, warnings, or asserts.
2 Navigate around to get a good view of the lattice of objects. The colors should all be oscillating as shown in the gifs above.
3 Toggle the "Pause" setting. This should pause the color cycle.
4 Toggle the "Pause" setting again. This should continue the color cycle.
5 Adjust the Lattice Width, Height, and Depth. Notice the number of objects on screen change accordingly.
6 Switch between the various Materials that are available. Notice the different appearance and performance characteristics.

Test Case 2 - Stress Test
1 Run the RPI/DynamicMaterialTest sample. There should be no errors, warnings, or asserts.
2 Navigate around to get a good view of the lattice of objects. The colors should all be oscillating as shown in the gifs above.
3 Gradually increase Lattice Width, Lattice Height, and/or Lattice Depth to push the system to its limits.
4 Watch for errors including:

a. Errors, Warnings, or Asserts reported.
b. No crashes.
c. All objects continue to show the oscillating color behavior (see screenshot below for example failure case; notice the white objects).

Note: I have been able to get all the way up to 20x20x20 without issues; I'm not sure whether that's possible on all hardware. The framerate was terrible though :)




Metrics
Check the "Total Material Compile Time" metric shown at the bottom right. Expected relative performance should be something like below for 100 objects (5x5x4 lattice). Note this will vary depending on the performance capabilities of your computer, but the relative ratio between the different materials should be similar to the ratios shown here.



Automation
None at this time.

Platform Support
This should work on all platforms.

MaterialHotReloadTest

Description
This sample makes changes to source data files to test the hot-reload of material and shader assets. It works by copying data from txt files in BaseViewer\Materials\HotReloadTest\TestData, using them to create Atom source data files like .materialtype, .material, .shader, and .azsl files. A set of buttons provide a convenient way to trigger these data file changes. Just click one, wait for a few seconds, the Asset Processor will bake the updated data files, and you'll see the viewport refresh to show the latest material.

The readout at the bottom of the screen provides some information about which shader variant is being used, for example "Root" or "Fully Baked".





Debug Menu
The menu consists of a set of buttons for updating source data files. Clicking each button will update a data file in the BaseViewer\Materials\HotReloadTest\Temp folder with new content. This will cause the AP to reprocess the asset and reload it in the runtime.

The buttons for HotReloadTest.material, .materialtype, .shader, and .azsl all affect the striped square in the middle. The change caused by each button should be pretty self-explanatory. For example, "Wavy Lines" will update HotReloadTest.materialtype to make the pattern have wavy lines instead of straight lines.

The HotReloadTest.shadervariantlist buttons will affect which shader variant is used to render the square in the middle. This won't have any visual impact on the square itself, but the rectangle underneath will show which variant is being used. Clicking the "None" button should result in always using the "Root" variant. Clicking "All" should result in always using the "Full Baked" variant. Clicking "Only Wavy Lines" or "Only Straight Lines" will use either the "Fully Baked" variant or the "Root" variant depending on whether the material is rendering straight lines or wavy lines.

Each source data file has an indicator that shows what the status of the asset in the Asset Processor: Missing, Queued, Compiling, Compiled, or Failed.


Test Cases
Automated: Run the script materialhotreloadtest.bv.luac
Manual: Click each button, wait until processing finishes, and you should see the viewport updated accordingly.
Expected screenshots are shown below.

Mesh

Description
The Mesh sample can be accessed by using BaseViewer's Samples → RPI/Mesh menu.

It's a simple sample that displays a single mesh which can optionally have its material overridden with one of your choosing. Various meshes and models can be pinned for quick access later. The skybox is a fixed representation of sunset, and it uses a fixed global image based light for lighting.



Debug Menu
Enable Material Override: Override the material(s) set on the model with a single material from the list.

Materials: Select a material on the list to override the default material on the model. Materials can be added and removed from the Pinned list by clicking "Pin" or "Unpun". The Pinned list provides easy access to a few materials instead of having to scroll through the whole list.

Mesh: Select a mesh on the list to choose which mesh displays. Meshes can be added and removed from the Pinned list by clicking "Pin" or "Unpun". The Pinned list provides easy access to a few meshes instead of having to scroll through the whole list.

Camera Controller: Select which camera controller to use. ArcBall allows spinning around the model (Right-click drag to orbit. Mouse wheel to zoom. Middle-click to pan). NoClip is similar to a first person camera (WASD to move. Hold Shift to move faster. Right-click drag to turn).



Test Cases
Test Case 1: Start sample Start the Mesh sample and there shouldn't be any errors or warnings. The screen shouldn't show any meshes, only an empty background (not necessarily the same one shown here).


Test Case 2: Select Meshs
Ensure "Enable Material Override" is turned off. Select several different meshes from the list. Each should display with its default materials.

Selecting bistro_research_exterior.azmodel should look like this (after navigating around using the NoClip Camera Controller):


Select testdata/objects/cube/cube.azmodel and make sure it looks like this (colored squares with numbers, and a faint bevel shape around some of the squares)


Other examples:


Test Case 3: Override Materials
Turn "Enable Material Override" on, and try several different materials to make sure they override the default material on the mesh.



Test Case 4: Material Details
Turn "Enable Material Override" on, try several different materials, and click the "Material Details..." button (at the very bottom). This should open a dialog that shows a table of which shaders are involved, what shader options were used to request a variant, and the list of baked shader options in the supplied variant.

(No screenshot provided at this time because the test case is failing).

Automation
N/A - We may add automation in the future to select a specific mesh and material combination.

Platform Support
This sample should work on all platforms

MSAA

Description
This sample loads a new pipeline with MSAA enabled and a very simple scene. It is intended to make sure that the MSAA path executes without error.
The user can select different MSAA levels and also different objects to render via the UI menu:


Test Cases (with expected results and screenshots)
As the MSAA number increases, he edges of the rendered object should be increasingly smoother and noticeably demonstrate less stair-stepping.

MSAA disabled:


MSAA 2x:


MSAA 8x:



Metrics
Performance metrics should not be necessary as this sample is intended to test correctness.

Automation
MSAA_RPI_Test.bv.lua

Platform Support
Tested Vulkan and D3D12 on AMD and Nvidia hardware

MultiRenderPipeline

Description This sample creates two RPI render pipelines (with same template) for one RPI scene with some features enabled for the scene. It's used to verify features could work properly with more than one render pipeline.
The second render pipeline may use the same main camera as first render pipeline or use another camera.

Screenshots
Screenshot 1: start the sample
Main window


Second window


Debug Menu
There are some options can be toggled on/off in the menus in the sidebar.


Second RenderPipeline
Enable second pipeline. This is to create a second render pipeline for the scene in a second window. When click it again, it will close the second window as well as remove and delete the second render pipeline.
Use second camera. When it's unchecked (default), the second render pipeline will use the same camera as the first render pipeline and you will see the same rendering result in both windows. Check it to create a different camera and used it for the second render pipeline.

Features This includes a list of features can be enable/disabled for current scene. The list might be extended in the feature when there are more features are added.
This it for user to identify individual features and see if they function properly in each render pipeline. Usually the feature should function normal when the second render pipeline is disabled.
Enable Depth of Field. Enable or disable depth of field for the first camera. Note: the second camera shouldn't be effected by this option.
Add/Remove Directional Light. This is to add or remove a directional light in the scene. This directional light casts shadows.
Add/Remove Spot Light. This is to add or remove a directional light in the scene. This directional light casts shadows.
Enable Skybox. This is to enable or disable skybox for the scene.
Add/Remove IBL. This is to add or remove an Image Base Lighting to the scene which will light the objects in the scene.

Test Cases
Test Case 1: Start
Start sample with second render pipeline on. The two windows should have same output (screenshot1).

Test Case 2: Compare features with same camera
Enable second render pipeline. And keep 'Use second camera' unchecked.
Turn on and off each features in 'Features' menu.
The output of each window should be same.

Test Case 3: Compare features with different cameras
Enable second render pipeline. And check 'Use second camera' option.
Turn on and off each features in 'Features' menu.
When 'Depth of Filed' is enabled, the first window should have depth of field enabled, but the second window shouldn't have any depth of field.
For the spot light and directional light, it should have same effect with the lighting one different objects and also have generating shadows.

Automation
N/A ATM - In the feature, we may capture screenshots for the two render pipelines (when they are using same camera) with different feature on and compare them.

Platform Support
Currently, we are using a second window for the render of second pipeline. This is not supported by mobile platforms and console platforms.
The supported platforms are: PC with DX12; PC with Vulkan.
This sample may still run with other unsupported platforms. But there will be only one window.

MultiScene

Description
The MultiScene sample creates two RPI scene with different content in each scene and there are two windows can render each of them independently.
This sample is for validating feature graphics work properly in two separated scenes.

Screenshots
ScreenShot1 Main window which renders first scene


Screenshot2 Second window which renders second scene


Debug Menu
This is a button in 'Multi Scene Panel' to toggle on/off the second window.

Test Cases
Currently, there is no specific control for this sample. We just need to make sure this sample run with supported platforms without issues.

Automation
This sample can be run directly with command line -sample RPI/MultiScene.

Platform Support
The second window will only open on Windows (both DX12 and Vulkan), Linux and Mac.

MultiViewSingleSceneAuxGeom

Description This test is to validate that AuxGeom can send some draws to all windows in a scene and others to only certain windows. The test opens a second viewport that shows all the contents of the main viewport, plus some extra or repeated parts. For more info on what the draws are see the AuxGeom sample page.

Debug Menu
No Debug Menu.

Test Cases (with expected results and screenshots)
Main Viewport Contents


Secondary View Contents


Platform Support
Should run on PC DX12, PC Vulkan, & Mac.

Readback

RenderTargetTexture

Description
This example shows how to use a render target as a texture for a mesh's material. It create a raster pass at runtime which output a persistent color render target. Then set the render target as a texture for a standard PBR material which used for a mesh instance.

Debug Menu
The RenderTargetTexture sample can be accessed by using AtomSampleViewer's Samples→RPI/RenderTargetTexture menu. The sample has a debug menu on the right side screen.


Next Frame: switch to render the next frame to the render target. The frame will be looping from 1 to 4
Show Preview: show the preview of the render target at the left bottom of the screen.
Update Per Second: the sample will switch to next frame automatically every one second.
Current frame: the index of current frame. The value ranges between 1 to 4.

Screenshots
Frame 1


Frame 2

Frame 3

Frame 4

**Automation ** The automation test for this sample is o3de-atom-sampleviewer/Scripts/RenderTargetTexture.bv.lua

**Platform Support ** The sample should work on all platforms

RootConstants

Description
This samples demonstrates the use of root constants to pass information quickly from CPU to the shader. It uses root constants to pass two parameters: a transformation matrix and a material index. The object matrix is update every frame so meshes rotate around their axis. The "material" in this example is just a simple color. Each mesh have it's own color that doesn't change.

There's no SRG updates after initialization.

Debug Menu
Camera control with the mouse and keyboard.

Test Cases (with expected results and screenshots)
All three meshes should be spinning.


Platform Support DX12, Vulkan and Metal

SceneReloadSoakTest

Description
This test's goal in life is to crash! It loads a bunch of objects, updates their materials every frame, unloads all the objects, and repeats this process forever. The test uses varying delays each cycle to try and discover timing-sensitive issues. In theory this test should be able to run indefinitely, but it has been known to discover stability issues and crash within seconds.

Important Note This test causes the screen to flash a lot. If you are sensitive to flashing lights, consider asking someone else to run this test case. Even if you aren't particularly sensitive, don't stare at it for long, you might feel nauseous ... seriously.

Debug Menu
n/a

Test Cases (with expected results and screenshots)
Test Case 1
1 Run the RPI/SceneReloadSoakTest.
2 There should be no errors, warnings, or asserts.
3 There will be 125 objects displayed, and they will all flicker on and off. (Don't stare at it! See the warning above)
4 You should see some oscillating colors on the objects at times; though it won't happen on every cycle.
5 Go get some coffee.
6 Come back in 5 minutes. If the test is still running, consider it passed.
7 Feel free to soak it longer than 5 minutes if you want to.


Note the camera angle has changed since these screenshots were taken, but the basic idea is the same.
Metrics
n/a

Automation
There is an automated test case that soaks just for a few seconds.

(Maybe at some point we could make the script soak for longer when running on Jenkins, but we don't want to make developers wait that long locally, and we don't currently have a way for the tool to detect whether it's running on Jenkins or not).

Platform Support This should work on all platforms

StreamingImage

Description
StreamingImage sample can be accessed by using BaseViewer's Samples → RPI/StreamingImage menu.
In Atom, immutable textures which are usually created from asset files converted by image files are called streaming image. They usually contains mipmap data which can be streaming in after the textures are created and used at runtime. In Atom's RPI library, StreamingImage represents on streaming image object and StreamingImageAsset is the asset type for streaming image.

This StreamingImage sample is to test, profile and visualize streaming image's streaming process as well as testing the streaming image's hot reloading function.

This sample does:
1 Load, create, stream and render some images which include power-of-two (POT) sizes and non-power-of-two (NPOT) sizes.
2 Create two 3d images and render them on screen.
3 StreamingImage hot reloading test.

Screenshots
Screenshot 1. Streamed image view.


Screenshot 2. 3d image view.


Streamed Images
There are 40 images will be loaded from StreamingImageAsset and created when sample started. After the images are created, their high level mipmaps will be streamed in.

The are also rendered on the screen when they are created even before all the mips are streamed in. There is time and memory profile data will be shown in the Streaming Profile menu in the side bar. Check the Debug Menu section for details.
The files of these images are located under \dev\BaseViewer\Textures\Streaming folder. The first 36 image files are streaming0.dds - streaming5.dds, and these files have POT sizes. The last 4 image files are streaming0.png~streaming3.png. These files have NPOT sizes.

The layout of how each image is rendered on the screen:


3D images
This sample creates two 3d images and render them on the screen when "3d image view" is turned on by using "View 3d Images" button in side bar menu.
The first images contains 7 slices which each slice are copied from 2d images which are created from file and have same sizes.
The second images contains 3 slices which are single color images.
The render of these two 3d images are render each of its slices on the screen.

StreamingImage Hot Reloading Test
The sample initially loads an image reloadtest.dds and render it on the screen (the top left image in default view). When user click the "Switch Texture" button in the side bar menu, it will overwrite reloadtest.dds by using streaming3.dds or streaming11.dds. Because of this overwrite, AccessProcessor (AP) will detect file change with reloadtest.dds and reprocess this file. Once the BaseViewer receives the asset changed event from AP, the sample will create the StreamingImage and the reloadtest.dds rendered on the screen will be updated.

Debug Menu
This example has a side bar menu with some controls over the example.


Image type view
The button under this section can switch the current display between render streamed images (default) or 3d images.
Hot Reload Test
The button "Switch texture" will copy streaming3.dds or streaming11.dds to reloadtest.dds by turns. Once the button is clicked, the reloadtest.dds rendered on the screen will be updated after few seconds.
Streaming Profile
The section provides some information about the image streaming process.
Streaming Image Count
The total number of images which are loaded and streamed in when start this sample.
Load and Create Images
The total time of load all the image assets (which are required by creating the StreamingImage objects) and create StreamingImage objects. This doesn't include the time of loading images' high resolution mipmaps which are not required for creating StreamingImage objects.
Create Images
The total time of creating StreamingImage objects only. This time is included in 'Load and Create Images'.
Streaming Image Mips The total time of streaming in all the mipmaps of all the images. This includes the time of load image mipmap assets from disk to cpu memory then upload them from cpu memory to gpu memory.
Initial Image Memory The total memory of the StreamingImages after they are created. This doesn't include the high resolution mipmaps. (Note: due to the NPOT images which don't have mipmaps, this number is larger than it usually be)
Final Image Memory The total memory of all the StreamingImages after all their mipmaps are streamed in.

Test Cases
Test Case 1: Start sample
Start the RPI/Streaming Image sample and there shouldn't be any errors or warnings.
The screen should look like the screenshot 1 after the example started and all images loaded.

Test Case 2: Display 3d Images
Click the "View 3D images" button under Image Type View menu in side bar.
The screen should be same as screenshot 2 and the Button's text changed to "View Streamed Images".
Click the same button again, the screen will change back to the screenshot 1.

Test Case 3: StreamingImage Hot Reloading
Click "Switch texture" button.
Wait for few seconds and the image for reloadtest.dds on the screen should be changed.

Repeat the process, the image will be switching between these two images:



Metrics
TBD

Automation
N/A.

We may add automation in the future to:
1 Capture a screenshot (without imgui menus) after certain seconds after the example started when all textures loaded and streamed in. This is to test all the textures can be loaded properly within certain amount of time.
2 Capture a screenshot in 3d image view.
3 Capture a screenshot after certain seconds when trigger hot reloading for certain seconds. This is to test that hot reloading is functional.

Limitation
The Streaming image hot reloading function will only work with BaseViewer application but not BaseViewer launchers. This is because the hot reloading requires connection with AssetProcessor which launchers won't have the connections.

Platform Support
This example should work on any supporting platforms.