Implementing a real-time minimap using SceneCaptureComponent2D and Render Targets in Unreal Engine 5.3.
This project is a minimap implementation built in Blueprints with Unreal Engine 5.3, developed following this Udemy course. The minimap is a focused technical exercise: a single UI feature, but one that requires understanding how Unreal’s rendering pipeline can be tapped to produce a live top-down view of the world and display it inside a UMG widget.
You can watch the prototype in action here: YouTube
The Core Technique: SceneCaptureComponent2D and Render Targets
The standard approach to a real-time minimap in Unreal doesn’t involve any special minimap API — it uses the same rendering machinery that drives the main camera, redirected to a texture. The two components involved are:
A SceneCaptureComponent2D is a camera-like component that renders the scene from its own viewpoint into a target texture rather than to the screen. Attached to the player character and positioned high above it looking straight down, it produces a continuous top-down render of the area around the player. Unlike the main camera, it doesn’t drive the viewport — its output goes to a UTextureRenderTarget2D asset.
A Render Target is a texture that can be written to at runtime. The SceneCaptureComponent2D writes its rendered output into the Render Target every frame (or on a configurable update interval). This render target is then assigned as the texture source for an Image widget inside a UMG HUD, which displays it as the minimap on screen.
This pipeline — SceneCaptureComponent2D → Render Target → UMG Image widget — is the complete data flow of the minimap. Its elegance is that no custom rendering code is required: it reuses Unreal’s existing render path and lets the GPU handle the projection.
Camera Setup: Projection and Field of View
The SceneCaptureComponent2D positioned above the player needs to be configured carefully to produce a useful minimap image. Two settings matter most:
Orthographic projection is generally preferable to perspective for minimaps. Perspective projection produces foreshortening — objects near the center of the capture appear larger than objects at the edges — which distorts the player’s sense of distance and direction on the map. Orthographic projection maps world units directly to screen pixels, producing a consistent scale across the entire minimap area. The orthographic width controls how large an area the minimap covers.
Rotation: the capture component needs to rotate with the player if the minimap is player-relative (the player arrow always points up), or remain fixed to world north if the minimap is world-aligned (north is always up). Player-relative minimaps are more intuitive for navigation but require the widget to compensate for the camera rotation when displaying directional indicators.
Performance Considerations
The main cost of a SceneCaptureComponent2D minimap is that it triggers an additional render pass every frame — the scene is rendered twice: once for the main camera, once for the minimap capture. On complex scenes, this doubles the draw call overhead for everything within the capture volume.
Several strategies mitigate this cost:
Update frequency: the SceneCaptureComponent2D doesn’t need to update every frame. For a minimap, updating every 2-4 frames is typically imperceptible and halves or quarters the capture cost. This is configurable via the bCaptureEveryFrame flag combined with a timer-driven manual capture.
Capture layers: the component supports a custom visibility channel that controls which actors are included in the capture. Excluding actors that don’t need to appear on the minimap — detailed environment props, particle systems, foliage — reduces the draw call count significantly. Only geometry that is meaningful at minimap scale needs to be captured.
Render target resolution: the minimap widget is typically small on screen. A 256×256 or 512×512 render target is usually sufficient and far cheaper than a full-resolution capture.
Displaying Map Markers
A render-only minimap shows terrain and structures, but players also expect to see dynamic markers — their own position, enemies, objectives, waypoints. These can’t be baked into the render target because they change position at runtime.
The standard approach overlays the render target image with a separate widget layer that draws markers as icons positioned relative to the minimap’s world coverage area. Each marker’s world position is converted to a normalized UV coordinate within the minimap’s coverage bounds, then mapped to pixel coordinates within the widget. This conversion is a simple linear transform: markerUV = (worldPosition - minimapCenter) / minimapWorldSize + 0.5.
The player marker typically rotates to match the player’s facing direction, providing orientation context that the top-down terrain view alone doesn’t convey.
Reflection
The minimap is a good example of a feature that seems like it should require specialized support but is actually composed entirely of general-purpose engine primitives used creatively. SceneCaptureComponent2D exists for many use cases — security cameras, portals, rear-view mirrors — and the minimap is just one application of the same underlying mechanism.
The main architectural lesson is the separation between the captured render (handled by the SceneCaptureComponent2D and Render Target) and the dynamic overlay (handled by a separate UMG layer). Trying to render markers directly into the Render Target would require custom shaders or drawing to the texture at runtime — keeping them as a separate widget layer is significantly simpler and keeps each concern in the right system.
In C++, the setup is identical: USceneCaptureComponent2D attached and configured in the constructor, UTextureRenderTarget2D assigned as the capture target, and the marker position math handled in the widget’s NativeTick or via event-driven updates bound to actor movement.
Nicolás Bertoa 
Leave a comment