Runtime Screenshot Pro

Scenes that look their best only after the Path Tracer has resolved them are awkward to document. You get the lighting, the bounce detail, the soft contact shadows — and then the usual scramble to get that frame out of the running session as a file. Runtime Screenshot Pro is aimed squarely at that moment: it captures an image from the current viewport while the session is live, and it is built with Path Tracing specifically in mind rather than treating ray-traced rendering as an afterthought.

It is a Blueprint-based plugin. Everything runs from one node, nothing needs to be dragged into the level, and the tool is pitched at beginners as much as at people who already know their way around a Blueprint graph. That framing matters more than it sounds — most capture workflows ask you to place an actor, wire up a few pins, and remember which settings survive a packaging pass. Here the setup is deliberately narrow.

One Blueprint Node Between Play and a Finished Frame

The whole capture action is a single BP node. No scene actor, no drag-and-drop step. You call the node, it takes the screenshot, and the work is done. For a task that usually gets bolted onto a project late in the schedule, that brevity is the feature.

The node also fires an On Screenshot Captured Event. That is the hook for anything you want to happen next — the moment the image exists, the event tells the rest of your Blueprint logic that it can move. Without that, a capture node becomes a guess about timing: you call it, then you wait and hope. The event turns it into something you can chain.

Choosing Raster or Path Tracer While the Session Is Running

Rendering method is set at runtime from inside the tool, so a single build can take a quick raster capture or a Path Traced one without a relaunch or a project-settings detour. RTX support is described as on the way rather than present, so the current choice is between the two methods that are already in place.

Path Tracing has a reputation for instability under capture, and the plugin addresses that directly: a parameter exposed in the Blueprint node is there to tune away the Path Trace crash. It is a small thing on paper and a substantial one in practice, because a crash mid-capture costs you the frame and the session state along with it.

Setting Up Render Output

Output size is configured through the node as well, with two routes available: a viewport multiplier, or a resolution set manually. The multiplier keeps captures proportional to whatever the viewport is doing; the manual route pins an exact size. Either way, the resolution you pick has a direct cost — a capture generally takes somewhere between half a second and two seconds, depending on resolution and the hardware in the machine. Larger frames sit at the slower end of that window.

What the Capture Actually Covers — and What It Doesn't

The scope here is narrow and worth understanding before it becomes part of a pipeline. Capture happens on the current viewport, or the current camera view. A camera that is not looking at anything will not produce a usable image, and UI is not captured at all. If a screenshot needs to include interface elements, this tool is not the one for that job.

Hardware support has a firm boundary: AMD GPUs are not supported. That is stated plainly and without qualification, so it belongs in the earliest planning conversation rather than the troubleshooting one. On the plugin-compatibility side, Runtime Screenshot Pro works alongside the Kickstart Blueprint Library.

Two further restrictions are worth flagging for teams working in packaged builds. The tool is not compatible with the NVIDIA DLSS Frame Generation plugin. And Depth Custom Mask is not supported in a packaged build — an Unreal Engine issue rather than something the plugin introduces, but a limitation you will meet all the same if that pass is part of your capture setup.

A Long-Term Support Plugin Still Growing

Runtime Screenshot Pro is positioned as an LTS, long-term support plugin, with continued development explicitly part of the plan and more features described as coming. RTX rendering method support is the named item still in progress. For production use, that framing sets an expectation: the node you wire up now is intended to keep working, and the surface area around it is expected to grow rather than freeze.

Where It Fits in a Working Pipeline

The natural home for this is any project where the runtime session and the final look are the same thing — architectural walkthroughs lit with Path Tracing, environment showcases assembled in engine, product or portfolio scenes where the in-editor view is already the shot you want. In those cases the alternative to a tool like this is a manual screenshot key, a window grab, or a separate render pass that costs more time than the frame is worth.

It suits capture tasks that are triggered from inside the game logic, too. Because the action is one node with a completion event, you can fire a screenshot at a scripted moment — after a sequence finishes, on a keypress you already handle in Blueprint — and let the event carry on with whatever comes next. No actor in the scene means nothing to clean up afterwards and nothing to exclude from the build.

Treat it as a runtime stills tool with a defined edge: current viewport only, no UI, NVIDIA hardware only, and a short pause while the frame is written. If your capture needs sit inside those lines, the single-node setup and the runtime raster/Path Tracer switch remove most of the friction. If they don't — layered UI composites, AMD workstations, DLSS Frame Generation in the stack — plan for a different route rather than working around the tool's stated limits.

Explore Similar Assets

• Runtime DataTable
• Runtime Gizmo (Transform Tool)
• Runtime Load FBX
• Runtime Spline Builder
• LevelController2 (Transform Levels At Runtime In Realtime)