Questions about consistency of image output and optimization of GBuffer image output in a vehicle configurator with MRG

Development Cinematics & Media
, ,
1

(This is a translation of a [Japanese [Content removed] by kin kyoushu.)

Thank you for your continued support.

I am currently developing a vehicle configurator using UE 5.7.1, and trying to output high-quality still images and various render passes that are identical to, or are as close as possible to, the appearance of the viewport during runtime by using Movie Render Graph.

Questions:

(1) How to ensure visual consistency between the viewport and MRG output

I understand that MRG is a tool intended for high-quality image and video output. So, I’d appreciate it if you could advise on the recommended settings to ensure that the appearance of the running configurator viewport and the MRG output are identical, or as close as possible. I am trying to find a method to reproduce the approved viewport appearance regardless of resolution while maintaining high-quality rendering features.

(2) How to ensure temporal stability

When using Lumen, I am trying to reduce subtle frame-to-frame visual fluctuations in MRG as much as possible, and achieve completely stable and consistent image output. I’d appreciate it if you could advise on the optimal settings for this.

(3) How to suppress resolution-dependent rendering differences

During a test, I observed that changing the output resolution changed the brightness of shadows and ambient occlusion, and that shadows became darker as the resolution increases. Would it be possible for you to advise on optimal parameter settings to maintain visual equivalence independent of resolution?

(4) How to manage stability and VRAM for 14K output

For ultra-high-resolution output, I’d appreciate it if you could advise on precautions to avoid performance issues and maintain stable quality.

(5) About the “Num Warm Up Frames” and “Allocate History Per Tile” settings

When using “Num Warm Up Frames,” and disabling “Allocate History Per Tile” in High Resolution Tiling in order to reduce VRAM usage, will the quality (stability) of features that require temporal accumulation, such as Lumen, still be maintained?

(6) How to improve the efficiency of GBuffer image output

Though I need to output GBuffer passes using additional post-process materials, outputting all passes simultaneously terminates the process due to a VRAM out-of-memory error. On the other hand, it takes extremely long rendering time to output them one by one. For 14K high-resolution output, are there any recommended workflows or settings that can output multiple GBuffer passes as efficiently as possible while keeping VRAM usage low?

I’d greatly appreciate any technical support that would help me achieve the highest possible output quality.

Thank you.

[Attachment Removed]

2

再現手順

  • Project description: Vehicle configurator, image output (rendering the configurator screen)

  • Maximum image output resolution: 14399 x 8082

  • Scene composition:

    • Vehicle data: A single BP actor composed of about 22,000 static meshes with Nanite enabled. When displayed, about 2,900 static meshes are visible, while the remaining static meshes being hidden.

  • Background: The background consists of simple static meshes. Lighting includes one Skylight and ten Rect Lights.

  • Rendering settings:

    • Nanite: On
    • Lumen: On
    • HWRT: On
    • MRG:
      • The “Global Game Overrides” node is deleted.
      • “Warm Up Settings” node → “Num Warm Up Frames”: 256

  • Additional post-process materials:

    • SubsurfaceColor
    • Specular
    • BaseColor
    • WorldNormal
    • Roughness
    • Metallic
    • Opacity
    • LightingModel
    • SceneDepth
    • SceneDepthWorldUnits
    • SceneColor
    • PreTonemapHDRColor
    • PostTonemapHDRColor
    • SeparateTranslucencyA
    • SeparateTranslucencyRGB

  • System configuration:

    • OS: Microsoft Windows Server 2022 Standard
    • GPU: NVIDIA Quadro RTX A6000 48GB
    • CPU: Xeon Gold 6426Y (16C/32T) 2.5 GHz
    • Memory: 64 GB
    • OS drive: 699 GB
    • UE project drive: 9.78 TB
      [Attachment Removed]
3

Hello,

1) There are a number of Screen Space based systems in the engine. You can try and disable both Screen Space options in Lumen GI and Reflecitons as well as any ScreenSpaceAO if its being used. Motion vectors is also somewhat based on screen size so try and rely on Temporal Samples for any motion blur as much as possible. Its also possible mesh and/or texture LODs are different between render and editor. You can try and lock to a certain LOD is there is a a specific mesh or texture that is giving you problems. In MRG in the Game Overrides node you can choose to lock to LOD0 for both meshes and textures.

2) Disabling Screen Space calculations can help here as well. Do you know if the flickering is coming from Lumen GI or Reflections? You can increase Final Gather quality for GI and Reflection Quality as well to try and send more samples. Also, if you are getting flicker on material that has rough reflections, you can increase the Max Roughness to Trace in the PPV as well.

3)What sort of shadows are you using: legacy Shadow Map, VSM, or RT? If you are using the legacy shadow maps, you should consider VSM or RT shadows, with RT being the most consistent. If its RT shadows you can increase the samples on the light. If its VSMs you can try to mess with these cvars. They come with a cost to render time though.

r.Shadow.Virtual.OnePassProjection 0

r.Shadow.Virtual.SMRT.AdaptiveRayCount 0

r.Shadow.Virtual.SMRT.RayCountLocal 16 (or more)

r.Shadow.Virtual.SMRT.SamplesPerRayLocal 8 or 16

4) It looks like you have already found the High Resolution tiling in MRG. You can Page to System memory if you are running into VRAM issues which will use CPU ram but will increase render time. Are you able to tell what is giving memory issues aside from just a large render? Are you streaming your textures? Are they properly compressed and mipped, etc..?

5) Its possible that you might see some settling in the beginning of your render if Lumen/Physics do not properly have time to settle. 256 frames sounds like a lot though.

6) The way MRG works is that it renders everything that it needs for a given frame, across all layers, then sends that all to the “output merger” in one batch. The output merger determines how to send all that rendered data to the needed files on disk. Once the frame completes and the output merger is holding the raw rendered pixels, the VRAM should be released, but there may be an increase in system memory while the render data is being written out. And even though a lot of your extra passes is data that already lives in the buffer MRG still needs to allocate another buffer in VRAM to write the normals, etc because PPMs are generic and the materials that are getting normals, etc just happen to be accessing the gbuffer. So, unfortunately, there is no great advice here other than to decrease the amount per render.

[Attachment Removed]

4

[mention removed]​

(This is a translation of a Japanese post by kin kyoushu.)

Thank you for your response and continued support.

I have a few questions regarding your response.

■ Regarding your response to item (4), specifically:

“Other than simply having a large render size, do you know what may be causing the memory issue? For example, are you streaming textures? Are those textures properly compressed? Are mips being generated correctly?”

I am using texture streaming, with r.streaming.poolsize set to 8196.

The texture compression and mip-related settings are as follows:

[Compression]

  • Compress Without Alpha: False
  • Editor Show Final Encode: True
  • Editor Defer Compression: False
  • Compression Settings: NormalMap (BC5)
  • Oodle Texture SDK Version: False
  • Maximum Texture Size: 0
  • Lossy Compression Amount: Default
  • ASTC Compression Quality: Default
  • Cook Platform Tiling Settings: FromTextureGroup
  • Preserve Extremes When Compressing With Oodle: False

[Mip]

  • Mip Gen Settings: FromTextureGroup
  • Num Cinematic Mip Levels: 0
  • Global Force Resident Mip Levels: False
  • Do Scale Mips for Alpha Coverage: False
  • Use Improved Image Processing: False
  • Mip Load Options: Default
  • Virtual Texture Prefetch Mips: 0
  • Normalize after making mips: False

[Questions]

Is it possible that these settings can be contributing to increased VRAM usage? Also, if there are any recommended settings that minimize VRAM usage as much as possible while still maintaining rendering quality, I’d appreciate it if you could give any advice.

■ Regarding your comment in item (5), “256 frames sounds like a lot though.”

Would it be possible for you to provide some guidelines for determining an appropriate value for “Num Warm Up Frames” depending on the project content and rendering resolution?

I apologize for asking so many questions, and thank you again for your continued support.

[Attachment Removed]

5

Hi! Ask as many questions as you like :slight_smile:

  • Normally when we see VRAM issues its due to textures. You mentioned you are using Movie Render Graph. In your Game Overrides node make sure you are not disabling texture streaming in the graph at render time. This is the culprint a lot of the times. In Movie Render Queue (the older config) texture streaming is disabled by default. So if you are using the older configs you may want to load the Game Overrides menu and not override any texture streaming here.
  • If you load your textures in the Statistics window does anything jump out? Any uncompressed textures or any non-mipped textures? If you have not used this window before it can be found at Tools-> Audit-> Statistics. Change the left side pulldown to Texture Stats. And the right hand side to All Streaming Levels. Have a look at the Format column and make sure you don’t see anything that looks like it says “PF B8G8R8A8”. Those are effectively uncompressed textures. Or Max Dimension // Current Dimension that can possibly point you to any non-mipped textures. Or just generally any huge texture here.
  • After that you can run a “Memreport -full” to get a sense of your memory footprint as a whole. Something may jump out here. When you’re rendering you can hit the ~ key to get a command prompt in the render window. There you can run a memreport to see whats happening.
  • But if the is a culprit of just a large render resolution you are a little limited to whats available to you in the High Resolution Tiling section of the Deferred Renderer node. With Page to System Memory being something to lean on here at the cost of performance.

For the 256 warmup frames, I didn’t have any other reason to comment other than that we never normally need to go that high. There is no real guidance here other than to just provide enough for lumen/physics to properly settle and/or content to spawn.

[Attachment Removed]