TargetFrame FAQ

TargetFrame is a runtime performance governor for Unreal Engine projects. It benchmarks the machine, classifies hardware, applies vendor and VRAM guardrails, watches runtime FPS, and makes controlled adjustments when the game drifts away from the selected frame target.

It is meant to sit between Unreal's rendering controls and a real shipped PC build, so your project has a consistent policy instead of scattered fallback logic.

No. A sample player-facing control panel is included, but the main product is the runtime policy system behind it.

A normal settings menu exposes options. TargetFrame decides what should happen on the player's machine, records why it made that decision, and can continue defending the target frame budget while play continues.

TargetFrame is designed for indie and small-to-mid Unreal teams shipping on PC without a dedicated rendering engineer owning runtime performance policy.

It is a good fit for UE5 projects using expensive modern rendering paths such as Lumen, Nanite, TSR, DLSS, FSR, XeSS, Virtual Shadow Maps, high-density instancing, or heavy dynamic scenes.

It is not the right tool if you only need a prettier settings screen, if your team already has a custom runtime performance policy stack, or if your project is mobile-first.

It is also not a substitute for profiling, content optimization, sensible scalability groups, or platform-specific QA.

No. TargetFrame provides a safer runtime fallback policy. It does not rewrite assets, fix expensive materials, redesign levels, or guarantee a particular frame rate on every hardware configuration.

Use it as a shipping guardrail, not as permission to skip optimization passes.

UE5 exposes many rendering knobs, but shipped games need a policy for when and how to use them. TargetFrame helps with first-launch defaults, low-VRAM safeguards, vendor-aware upscaler posture, Nanite and Virtual Shadow Map pressure, crisp UI under scene scaling, runtime recovery, and explainable telemetry.

The sample project includes the TargetFrame plugin, conservative default configuration, a showcase map, a simpler test map, a debug HUD, a player controller with QA hooks, the editor-side Beginner Wizard, and a UMG-backed TargetFrame experience widget.

The showcase map is useful for demos. The simpler test map is better when you want to isolate setup and tuning behavior or test the first-run beginner flow.

The fire-and-forget shipping capsule is the low-friction runtime mode. It can probe project capabilities, choose target FPS by hardware tier, apply a safe posture, and lock after stabilization so the game stops visibly changing quality once it settles.

If performance later drops far enough, it can unlock and intervene again.

1. Copy the `TargetFrame` plugin folder into your project's `Plugins` directory.
2. Enable the plugin in the editor or in your `.uproject` file.
3. Restart the editor so Unreal can compile or load the plugin.
4. Open Project Settings > Plugins > TargetFrame and review the Simple Mode defaults.

Open Project Settings > Plugins > TargetFrame. The first category is Simple Mode, with common setup choices for target FPS, quality bias, first-launch benchmark, runtime adaptation, low-VRAM and integrated-GPU protection, crisp UI handling, stability locking, telemetry, and opt-in vendor upscaler or triangle culling support.

Set Settings Mode to Advanced Mode when you want the full detailed surface. The advanced settings are grouped by bootstrap behavior, fire-and-forget shipping, runtime governor, CPU governor, quality steps, resolution, vendor and memory policy, feature guards, upscaler integration, Nanite policy, triangle culling, upscaler-safe UI, telemetry, and diagnostics.

For the simplest runtime path, call RunTargetFrameSetupWizard, shown in Blueprint as Run TargetFrame Setup Wizard, from a safe startup point such as your Game Instance or first gameplay map flow. That one node runs the beginner-facing automatic setup path.

If you build your own UI, CheckThisProject, shown in Blueprint as Check This Project, is still available for explicit readiness checks. The included TargetFrame experience widget now refreshes its readiness card automatically while it is open.

Use GetTargetFrameStatus and GetTargetFrameSetupSummary when you want to show the recommendation, setup notes, or recent decisions in your own UI.

If you want manual control, use StartTargetFrame, SetTargetFrameTargetFPS, and ApplyTargetFramePolicy.

The beginner flow is now project-aware. In the editor-side wizard, Run Beginner Flow stays on your current map for real project work, but it can switch from the showcase to the sample test map when you want the packaged first-run sample path.

In the live widget, Use recommended setup applies the recommendation and then pauses on a short confirmation state with Keep this setup, Show settings, and Start over.

The control panel also updates Setup readiness automatically while it is open, so the included beginner flow no longer depends on a manual project-check button for normal use.

• RunTargetFrameSetupWizard (Run TargetFrame Setup Wizard in Blueprint)
• CheckThisProject (Check This Project in Blueprint)
• StartTargetFrame
• StartTargetFrameFireAndForget
• SetTargetFrameTargetFPS
• ApplyTargetFramePolicy
• GetTargetFrameStatus
• GetTargetFrameSetupSummary
• GetTargetFrameProjectCapabilities
• PauseTargetFrameGovernor and ResumeTargetFrameGovernor
• ResetTargetFrameToDefaults
• HasCompletedTargetFrameOnboarding and SetTargetFrameOnboardingCompleted

Yes. TargetFrame is implemented as a runtime subsystem and a Blueprint library. In C++, get the subsystem from the Game Instance and call the same policy methods directly.

Typical usage is to start the policy during a loading flow, choose a target FPS, then query status or subscribe to policy change events for your own UI.

No. The included UTargetFrameUserExperienceWidget and sample UMG widget are optional. They provide onboarding, intent-first FPS presets, benchmark rerun, setup notes, automatic readiness feedback, runtime notes, recent policy events, and the post-setup confirmation step.

You can build your own menu using GetTargetFrameStatus, GetTargetFrameSetupSummary, GetTargetFrameProjectCapabilities, and the policy changed delegate.

Run it during a loading screen, first-launch setup, or another moment where a short synchronous hitch is acceptable. The default work scale is conservative, but Unreal's hardware benchmark can still pause the game briefly.

You can disable automatic benchmark startup and trigger it only when your UX is ready.

Yes. The onboarding completion flag is stored in GameUserSettings.ini under the TargetFrame user experience section. The Blueprint library exposes functions to read or set that state.

In the included widget, players can skip the first-run prompt, keep the recommended setup after it is applied, open settings instead, or start over from the confirmation step.

In Simple Mode, use Target FPS to choose automatic hardware-tier targets or a fixed 30, 45, 60, 90, or 120 FPS target for every machine. The automatic defaults are 45 FPS for entry tier, 60 FPS for mainstream tier, and 90 FPS for performance tier.

In the included widget, the beginner-facing quick choices are labeled by intent first: Lowest load, Most stable, Balanced, and High refresh, with FPS shown secondarily.

In Advanced Mode, the same behavior is controlled by the default target, fire-and-forget target selection, and the tier-specific target FPS settings.

TargetFrame reads platform name, RHI name, GPU brand, GPU vendor, logical core count, system memory, integrated GPU state, ray tracing support, dedicated video memory, shared memory, total graphics memory, texture pool size, streaming memory, and available streaming memory where Unreal exposes those values.

After warmup, TargetFrame evaluates smoothed FPS at a configurable interval. If performance stays below the allowed deficit for enough samples, it reduces cost. If there is enough recovery headroom for enough samples, it restores quality in a controlled order.

The system prefers lower-impact adjustments before harsher cuts. Depending on configuration and project capabilities, it can adjust processor-heavy detail, image-scaling quality, far-distance detail, geometry precision, overall visual quality, and 3D scene scale.

The exact ladder depends on which features are enabled and which runtime controls exist in the current project.

TargetFrame can detect processor-bound pressure by comparing total frame cost and graphics frame time. When processor-bound, it steps down processor-heavy groups such as foliage and view distance first, avoiding unnecessary loss of graphics image quality.

Frames longer than the configured hitch threshold are excluded from the smoothed FPS average. The default threshold is 0.1 seconds. This prevents loading spikes and transient hitches from immediately triggering quality reductions.

Not in the automatic setup path when stabilization lock is enabled. After enough stable evaluations, TargetFrame can pause visible changes. If a severe sustained deficit appears later, it can unlock and intervene again.

Yes. Use PauseTargetFrameGovernor and ResumeTargetFrameGovernor from Blueprint, or call the subsystem methods from C++. This is useful during cinematics, benchmark-only flows, settings screens, or sequences where visual stability is more important than automatic adjustment.

It can. bClampFrameRateToTarget is available in Runtime Governor settings. When enabled, TargetFrame sets t.MaxFPS to the selected target when applying policy or changing the target FPS.

Yes, when the project exposes the expected Nanite console variables. TargetFrame can set Nanite maximum pixels per edge, adjust the primary raster time budget, relax or restore edge precision at runtime, and disable Nanite tessellation in low-VRAM or Intel-specific cases if configured.

It can apply guardrails. TargetFrame checks ray tracing capability, GPU score, VRAM thresholds, and Intel policy settings before allowing hardware ray tracing posture. It is designed to prevent expensive features from staying enabled on machines that are not good candidates.

When low-VRAM mode is active and VSM management is enabled, TargetFrame can reduce r.Shadow.Virtual.MaxPhysicalPages. The default low-VRAM cap is 1024 pages.

TargetFrame can work with vendor upscaler controls when direct upscaler integration is enabled and the relevant project/plugin console variables exist. It can prefer DLSS on NVIDIA, XeSS on Intel, FSR on AMD and Intel, and TSR when vendor upscalers are not available.

It does not bundle vendor upscaler plugins. Your project still needs the relevant upscaler integration installed and functioning.

Vendor upscaler plugins and console variables vary by project setup. Keeping direct integration opt-in avoids changing upscaler state in projects that have their own rules or do not expose the expected controls.

TargetFrame uses the secondary screen-percentage path for the game viewport. The intended posture is to let the 3D scene scale when needed while keeping UI at a clearer presentation percentage, usually 100 percent.

Projects with custom viewport stacks should validate this path in their own UI and capture setup.

It can. Dynamic resolution has its own settings for enabling, minimum percentage, maximum percentage, and frame budget behavior. TargetFrame can also prefer dynamic resolution on Intel hardware or disable it when a vendor upscaler is active, depending on configuration.

TargetFrame can identify expensive static mesh components by triangle count and manage their cull distance policy. This is optional and disabled by default because content teams often want direct control over culling behavior.

Yes, when vendor and VRAM policy is enabled. TargetFrame can limit the texture pool to a fraction of available VRAM while respecting a minimum pool size. The default fraction is 0.72, with a minimum of 768 MB.

For most projects, start with the Simple Mode settings:

• SettingsMode
• SimpleTargetMode
• SimpleQualityBias
• bSimpleRunBenchmarkOnFirstLaunch
• bSimpleEnableRuntimeAdaptation
• bSimpleProtectLowVRAMAndIntegratedGPUs
• bSimpleKeepMenusAndHUDSharp

When SettingsMode is Advanced Mode, review the detailed policy settings:

• DefaultTargetFPS
• bEnableFireAndForgetShipping
• bAutoRunHardwareBenchmarkOnInitialize
• bEnableRuntimeGovernor
• LowVRAMThresholdGB and MainstreamVRAMThresholdGB
• MinResolutionScale and MaxResolutionScale
• bEnableDirectUpscalerIntegration
• bEnableUpscalerSafeUI
• bEnableCsvTelemetry and bLogRuntimeProbe

Capability probing checks whether the current project/runtime exposes the controls TargetFrame wants to use, such as Nanite budgeting cvars, upscaler cvars, dynamic resolution cvars, GameUserSettings, secondary screen percentage, and hardware ray tracing controls.

If a control is missing, the shipping capsule can skip it instead of assuming every project has the same rendering stack.

Yes. Most systems are independently configurable. You can disable the runtime governor, direct upscaler integration, Nanite policy, triangle culling, dynamic resolution, CSV telemetry, runtime probes, hardware ray tracing clamp, and other policy groups.

Start with the defaults, then test representative machines. The default low-VRAM threshold is 8 GB, and the mainstream threshold is 12 GB. Projects with very heavy textures, high-resolution shadows, large open worlds, or aggressive Nanite usage may need more conservative thresholds.

Only after reviewing your content. Triangle-aware culling can be useful in heavy scenes, but culling is visually sensitive. Validate the managed component set, distance ranges, and scale floor before shipping it broadly.

Use ResetTargetFrameToDefaults from Blueprint or the subsystem reset method from C++. It clears runtime overrides, resets status, restores managed triangle-cull states, and re-probes capabilities.

Yes, if your project exposes those controls. TargetFrame can live behind your own graphics menu. The important design choice is deciding when player intent should pause, override, or reapply the runtime policy.

TargetFrame can emit CSV telemetry snapshots and keeps a recent in-memory event log. Runtime probe logs can include FPS, target FPS, quality level, resolution scale, dynamic resolution posture, active upscaler, upscaler quality, triangle culling state, Nanite budget, texture pool, secondary screen percentage, and hardware ray tracing posture.

Automatic rendering changes are hard to trust when they are invisible. Telemetry and recent events make the system explainable for QA, support, and your own tuning passes.

The default telemetry snapshot interval is 1 second. You can raise or lower TelemetrySnapshotIntervalSeconds in the Telemetry settings.

Recent events are short policy-action messages kept in memory. They help a debug HUD or control panel show the last few decisions, such as lowering resolution scale, relaxing Nanite precision, selecting an upscaler posture, or entering low-VRAM mode.

The setup summary explains startup policy decisions: target FPS, hardware tier, upscaler posture, UI posture, low-VRAM state, Nanite state, and capability notes. It is meant for onboarding panels, debug UIs, and QA reports.

Yes. Use GetTargetFrameStatus, GetTargetFrameSetupSummary, GetTargetFrameProjectCapabilities, recent event data, and the policy changed delegate to feed your own HUD, menu, or QA overlay.

Yes. Review bEnableCsvTelemetry, bLogRuntimeProbe, bLogAdjustments, TelemetrySnapshotIntervalSeconds, and MaxRecentEvents. Some teams keep lightweight recent events in shipping for support visibility and disable verbose logging.

This FAQ is written for the current TargetFrame UE5 plugin state in this project, which now targets Unreal Engine 5.7 and includes the newer beginner-flow and readiness-card updates documented in the manual and changelog.

The plugin descriptor currently targets the UE 5.7 project state and allows Win64. Win64 remains the documented packaging target in this sample project.

The runtime plugin descriptor is set to CanContainContent: false. The sample project contains maps, widgets, and demo content around the plugin, but the packaged plugin itself is code, configuration, and resources.

The module depends on core Unreal runtime systems such as Core, CoreUObject, Engine, DeveloperSettings, plus private dependencies including Projects, RHI, Slate, SlateCore, and UMG.

No. TargetFrame can interact with those controls when your project exposes them, but it does not ship vendor upscaler plugins. Install and configure those vendor plugins separately.

Yes, that is the point of project capability probing. TargetFrame can detect missing control surfaces and skip those paths instead of failing or applying settings that do nothing.

Yes. TargetFrame is intended for shipping games, and the current project state targets UE 5.7 on Win64. You should still package your own game project and run runtime QA with your project settings, startup flow, and target content.

Yes. The plugin package includes the C++ source and build rules. That helps teams inspect behavior, debug integration, and tune the policy surface.

Yes. Unreal's hardware benchmark is synchronous enough that you should run it during a loading screen, setup flow, or safe transition. Disable automatic benchmark startup if you need precise control over when it happens.

• Make sure direct upscaler integration is enabled.
• Confirm the vendor upscaler plugin is installed and working in your project.
• Check the capability summary for detected DLSS, FSR, FSR2, FSR3, or XeSS cvars.
• Check whether dynamic resolution is configured to disable itself when a vendor upscaler is active.

Confirm bEnableUpscalerSafeUI, bOnlySeparateUIWhenUpscaling, and SecondaryScreenPercentageForUI. Then validate whether your project uses a custom viewport, render target, or post-process path that bypasses the standard secondary screen-percentage behavior.

• Check bEnableRuntimeGovernor.
• Check whether the warmup period is still active.
• Check whether policy is locked after stabilization.
• Check whether the current deficit exceeds AllowedDeficitFPS for enough consecutive samples.
• Check project capability notes for missing control surfaces.

Start with EvaluationIntervalSeconds, AllowedDeficitFPS, RecoveryHeadroomFPS, ConsecutiveLowSamplesRequired, ConsecutiveHighSamplesRequired, and HitchThresholdSeconds. For visual changes, review resolution scale step size, Nanite step size, upscaler quality limits, and triangle culling scale.

Review StableEvaluationsBeforeLock and SevereDeficitFPSBeforeUnlock. If the lock happens too early, require more stable evaluations or lower the unlock threshold so the policy resumes sooner during sustained deficits.

Tune LowVRAMThresholdGB, MainstreamVRAMThresholdGB, texture pool fraction, Virtual Shadow Map page cap, and max quality or resolution caps for low-VRAM mode. Use representative project content rather than empty maps.

Check whether the machine supports ray tracing, then review bClampHardwareRayTracingToCapability, MinGPUScoreForHardwareRayTracing, MinVRAMGBForHardwareRayTracing, and bDisableHardwareRayTracingOnIntel.

That usually means the expected cvar or runtime object was not found. Confirm the feature is enabled in your project, any required plugin is loaded, and the cvar name matches the integration version you are using.

Include engine version, TargetFrame version, platform, GPU, VRAM, whether the GPU is integrated or discrete, relevant TargetFrame settings, setup summary, recent events, runtime probe logs, and a short description of what you expected TargetFrame to do.

Use the Fab listing: TargetFrame on Fab.

Join the Discord server: https://discord.gg/nqYQ5mtmHb.

• Unreal Engine version and TargetFrame version.
• GPU model, VRAM amount, CPU, RAM, and target FPS.
• Whether fire-and-forget mode is enabled.
• Setup summary and recent events.
• Runtime probe logs around the problem.
• Any custom viewport, upscaler, dynamic resolution, or graphics menu logic.

Test first launch, benchmark timing, each hardware tier target, low-VRAM mode, Intel policy, NVIDIA policy, AMD policy, upscaler availability, UI clarity under scene scaling, shipping capsule lock and unlock, pause/resume behavior, and your own graphics menu interaction.

Avoid claims like guaranteed frame rate, automatic optimization for every project, perfect image quality on any hardware, or zero tuning required. Use factual phrasing: runtime policy layer, project-aware compatible mode, safe defaults, controlled fallback order, and reduced need to hand-build fallback logic.