1
Launch the sample map
The sample boots into /Game/Maps/TF_TargetFrameShowcase. Open /Game/Maps/TF_TargetFrameTestMap if you want a simpler tuning sandbox.
TargetFrame Runtime Suite
Make UE5 games hit target FPS on mainstream PCs automatically.
Welcome to TargetFrame! This plugin benchmarks the machine, classifies the hardware, chooses a safe rendering posture, optionally selects supported vendor upscalers, and continuously protects the frame budget while keeping UI crisp and reducing manual graphics micromanagement.
UE 5.7 sample project
PC-first runtime governor
Nanite-aware runtime control
Optional DLSS / FSR layer
Optional triangle-aware culling
Vendor + VRAM policy
Telemetry + debug UX
Target: stable frame budget
Approach: benchmark + runtime policy
UI path: separate secondary percentage
Start Here
Quick Start
If you want to validate the sample quickly, this is the shortest path from project open to observing live policy changes.
2
Use the runtime UX
First run shows guided setup automatically. Returning sessions stay compact and expose the menu through the launcher button or F10.
3
Watch policy feedback
Toggle the debug overlay with tf.DebugHUD 1 and tf.DebugHUD 0. If you want to validate the optional upscaler or triangle-culling paths, enable them in Project Settings first.
Sample Layout
Project Map
The sample project is intentionally compact. These directories are the ones you will touch most when integrating, tuning, or packaging the plugin.
Scalability.uproject
Config/
Content/
Maps/
TF_TargetFrameShowcase
TF_TargetFrameTestMap
UI/
WBP_TargetFrameExperience
Plugins/
TargetFrame/
Config/
DefaultTargetFrame.ini
Source/
TargetFrame/
Source/
Scalability/
Scripts/
CreateTargetFrameExperienceWidget.py
CreateTargetFrameShowcaseMap.py
CreateTargetFrameTestMap.py
Plugin core
Plugins/TargetFrame contains the subsystem, settings surface, Blueprint library, and the UMG-backed UX host widget.
Sample game layer
Source/Scalability wires the widget into the player controller and exposes the debug HUD, showcase flow, and test-map flow.
UI asset
Content/UI/WBP_TargetFrameExperience is the composed UMG control surface used during play.
Regeneration scripts
The scripts directory can rebuild the showcase map, the test map, or the current widget blueprint if you want to re-author sample content.
Integration
Installation and Wiring
TargetFrame can be used as a plugin runtime service, a drop-in menu widget, or both. The sample ships with both patterns already connected.
Project Settings surface
Open Project Settings > Plugins > TargetFrame. The plugin exposes grouped controls for benchmark behavior, governor thresholds, direct upscaler integration, triangle-aware culling, Nanite policy, VRAM/vendor rules, UI separation, telemetry, and diagnostics.
Blueprint integration points
The Blueprint library exposes StartTargetFrame, SetTargetFrameTargetFPS, ApplyTargetFramePolicy, GetTargetFrameStatus, GetTargetFrameSetupSummary, and GetTargetFrameProjectCapabilities.
Widget route
The sample player controller loads the widget blueprint at runtime. You can swap it for your own UMG asset or reuse the C++ host in another project.
Recommended sample validation flow 1. Start the project. 2. Observe the default showcase map or open: /Game/Maps/TF_TargetFrameTestMap 3. Open the menu: - Launcher button - F10 4. Toggle debug overlay: tf.DebugHUD 1 tf.DebugHUD 0 5. Enable optional direct upscaler integration only if your packaged runtime exposes the vendor plugin cvars. 6. Enable optional triangle-aware culling only after tuning triangle thresholds and distance limits for your content. 7. Re-run benchmark from the menu if you want to observe profile selection again.
First Run
Guided Setup and Onboarding
The first-run experience is meant to reduce fear: detect the hardware, explain the recommendation, and give the player a simple next step instead of a dense wall of sliders.
Detected hardware card
Summarizes machine tier, GPU brand, benchmark score, and available graphics memory without drowning the player in low-level jargon.
Recommended flow card
Explains the target FPS choice, upscaler posture, UI resolution posture, Nanite posture, and whether low-VRAM mode or triangle-aware culling was needed.
Persistence
The onboarding completion flag is stored in GameUserSettings.ini under [TargetFrame.UserExperience].
Design rule
Onboarding should explain confidence and safety. Detailed levers belong in the control panel and diagnostics.
Runtime UX
Control Panel Guide
The control panel is a compact operational surface. It tells you what TargetFrame is doing right now and offers a few decisive actions rather than a full graphics-options labyrinth.
Quick presets
Preset buttons offer a single intent change: 30, 45, 60, or 90 FPS. TargetFrame updates the target and reapplies the policy.
Apply policy
Useful after changing settings or for manual reassertion during tuning. It re-applies the current policy without forcing a new benchmark.
Re-run benchmark
Forces a new benchmark pass and refreshes the setup summary. This is mainly for QA and content tuning.
Notes and recent events
Setup notes explain static policy choices. Recent events show the live adaptation history that led to the current posture.
Core Logic
Policy Engine
TargetFrame is not a static preset pack. It is a policy engine that starts from a safe baseline, validates the machine, then moves quality within a bounded runtime ladder to protect the requested frame target.
Benchmark first, not guesswork first
The initial run uses Unreal's benchmark facilities and a hardware snapshot to choose a starting posture that matches the machine instead of assuming desktop-high by default.
Hysteresis
Runtime quality shifts use thresholds and cooldown behavior so the game does not oscillate between two states every few seconds.
Policy over raw cvars
Buyers do not want to babysit a large list of rendering variables. The plugin groups those variables into understandable policy decisions with setup notes and event logs.
Designed for shipping QA
The value is not just changing settings. The value is being able to explain the resulting behavior to designers, QA, and support.
Startup pass:
1. Detect vendor, VRAM budget, benchmark scores, and project capabilities.
2. Select target profile, safety caps, and a preferred supported upscaler.
3. Apply quality, HWRT, Nanite, upscaler, triangle-culling, and UI posture.
4. Monitor live FPS and adjust supported upscaler quality, culling, or render cost within bounded steps.
5. Emit telemetry so every change has an audit trail.
Rendering Controls
Rendering Systems Managed by TargetFrame
The plugin coordinates several subsystems together. That coordination is the product. Each subsystem alone is just another exposed engine setting.
Scalability Baseline
Sets the initial quality level based on benchmark results and developer defaults, then treats that baseline as the top of a bounded adaptation ladder.
Direct Upscaler Integration
When the project exposes runtime cvars for supported vendor plugins, TargetFrame can choose DLSS or FSR posture directly and fall back safely when those controls are unavailable.
Dynamic Resolution
Adjusts render scale when the project supports it, and can stand down when a vendor upscaler is active and configured to own scene scaling.
Nanite Runtime Policy
Uses Nanite edge and raster budget controls to soften geometry cost before resorting to harsher overall quality cuts.
Triangle-Aware Culling
Optional literal culling for heavy static-mesh and instanced-static-mesh components uses triangle counts to apply bounded distance limits and restores original values when the policy is disabled.
Upscaler-Safe UI
Preserves UI legibility by keeping the secondary game viewport percentage separated from the main scene posture during dynamic resolution, TSR, or supported DLSS/FSR workflows.
Vendor and VRAM Awareness
Builds policy notes and guardrails around the actual hardware budget instead of pretending every GPU class behaves the same.
HWRT Guardrails
Clamps hardware ray tracing when the memory budget or posture indicates it is more likely to destabilize frame time than improve shipping quality.
Illustration: Layered Response
Illustration: UI Separation
Illustration: Hardware Budget
Diagnostics
Telemetry, Probes, and Debug Visibility
TargetFrame needs to be legible to developers. A system that changes rendering posture without evidence becomes a support burden instead of a feature.
Recent events list
The runtime widget surfaces recent decisions in player-facing language, making it obvious whether the system reduced quality, recovered, or held steady.
CSV and log telemetry
Each policy change should be mirrored into logs or CSV output so QA can correlate a visual report with an exact machine state.
Runtime probe values
Explicit live logging for active upscaler mode and quality, triangle-culling scale and managed component count, Nanite budget, texture pool, UI viewport percentage, dynamic resolution state, and HWRT clamp prevents silent drift.
HUD diagnostics
The in-game debug HUD is the fastest sanity check during tuning. It should remain visually clean enough to use during capture and QA runs.
| Signal | Why it matters | Where to inspect it |
|---|---|---|
| Target FPS and live FPS | Confirms whether the adaptation logic is acting on a real deficit or merely reacting to transient noise. | Control panel, debug HUD, logs |
| Nanite edge / raster budget | Shows whether geometry cost is being trimmed before broader quality changes. | Runtime probe and HUD |
| Upscaler mode / quality | Shows whether direct DLSS or FSR integration is active, or whether the plugin stayed on TSR or native fallback. | Runtime probe, setup notes, debug HUD |
| Triangle cull scale / managed count | Confirms whether literal component culling is active and how aggressively heavy geometry is being trimmed. | Runtime probe, setup notes, debug HUD |
| UI viewport percentage | Validates the crisp-UI promise while render scale moves independently. | Runtime probe and setup notes |
| HWRT posture | Explains whether ray-tracing-heavy features are being clamped for safety. | Setup summary, logs |
Practical Tuning
Tuning Guide for Real Projects
Good defaults make the demo look competent. Tuning for a real game is where the plugin becomes commercially credible.
1. Tune against content, not template geometry
Use your heaviest playable scene, not the sample map, to calibrate thresholds. The benchmark is only part of the picture; actual content pressure still matters.
2. Decide the visual sacrifice order
Pick the order that matches your game's identity. Some games can lose edge density early. Others should preserve scene sharpness and trade other quality first.
3. Validate across a hardware matrix
Test NVIDIA, AMD, Intel, lower-VRAM machines, packaged builds, and multiple upscaler setups. A paid plugin needs evidence, not intuition.
Shipping checklist
- Package the game and retest the policy outside the editor.
- Capture before-and-after benchmarks for the listing page.
- Write project-specific setup notes for any required render settings.
- Confirm optional vendor-upscaler cvars exist in the packaged runtime before enabling direct integration.
- Confirm the UI composition path remains crisp with your HUD stack.
Common tuning levers
- Target FPS defaults by platform or SKU.
- Vendor upscaler preference and tier-based quality mapping.
- Triangle-count thresholds and cull-distance scale floor.
- Low-VRAM pool caps and safety factors.
- Nanite edge / raster step sizes and cooldowns.
- Dynamic resolution bounds and aggressiveness.
Support posture
- Include a diagnostic screenshot guide.
- Tells you which logs to attach.
- Expose a one-click "re-run benchmark" action.
- Document project prerequisites clearly.
Support
Troubleshooting
Some issues can be diagnosed in two minutes.
| Symptom | Likely cause | Recommended check |
|---|---|---|
| Onboarding does not appear | The completion flag was already saved on this machine. | Inspect GameUserSettings.ini for the TargetFrame.UserExperience section or clear the stored flag. |
| Widget layout looks wrong at runtime | Viewport scaling, authored asset changes, or an unexpected font mismatch. | Open the UMG asset, validate anchors and wrapping, then confirm runtime font normalization still runs. |
| UI becomes blurry when render scale drops | Secondary viewport percentage is not being held at the intended value for the project. | Check setup notes, runtime probe logs, and any project-level UI rendering overrides. |
| Performance still tanks on a low-VRAM GPU | The content exceeds the assumed pool or a feature remains too expensive for the title. | Verify texture pool caps, review HWRT posture, and tune the scene-specific fallback order. |
| DLSS or FSR never activates | The project runtime does not expose the vendor cvars, the feature is disabled in settings, or the current GPU falls back to TSR/native posture. | Check the capability summary, runtime probe logs, and TargetFrame settings before assuming the integration is broken. |
| Distant heavy meshes disappear too early | Triangle-aware culling thresholds or distance scales are too aggressive for the content. | Raise the triangle threshold, raise the distance floor, or disable the optional triangle-culling policy and compare captures. |
| Frequent quality bouncing | Thresholds or cooldowns are too aggressive for the content's frame-time variance. | Increase hysteresis windows and review event logs over a longer play segment. |
Questions
FAQ
The short answers below are written for buyers evaluating whether TargetFrame is a serious workflow tool or just a convenience wrapper.
Does it replace a graphics settings menu?
No. It complements one. TargetFrame is a runtime decision layer that can sit behind a user-facing settings menu and make those choices safer on real hardware.
Is this only for Lumen or Nanite?
No. Those are headline systems, but the real value is coordinating multiple rendering cost centers under one understandable policy.
Can it be used in packaged builds?
That is the intended target. Runtime validation should always be repeated in packaged builds before shipping or marketplace promotion.
Does it directly control DLSS and FSR now?
Yes, when the project exposes the relevant runtime cvars. The integration is capability-scanned and optional, so unsupported projects fall back to TSR or native posture instead of breaking the rest of the policy layer.
Why emphasize telemetry so much?
Because automatic adaptation without observability is difficult to trust. Telemetry is what turns the system into an engineering tool instead of a black box.
Can the sample UI be replaced?
Yes. The included sample experience is meant to accelerate adoption and illustrate best practices, not lock teams into one aesthetic.
Is triangle-aware culling a renderer hack?
No. The current implementation is an opt-in runtime distance-culling layer for heavy static-mesh components. It is literal culling, but it is designed to be reversible and content-tuned rather than a deep engine modification.
What makes this commercially different from a settings widget?
The differentiator is policy plus explanation: hardware-aware recommendations, runtime guardrails, optional vendor-upscaler and triangle-culling layers, crisp UI posture, and diagnostics that tell you what the system changed.
Links
Resources
Thank you for choosing the TargetFrame UE5.5+ plugin! Some useful links below.