← lab3.studioAn Unreal Engine plugin by Lab³ Studio
BP Nativizer
Pick your hottest Blueprint functions, turn them into C++ you can actually read, and prove the two behave identically before anything ships.
BP Nativizer compiles a function's Blueprint bytecode into C++ and binds the native body onto the live function, so every existing Blueprint caller just starts running it. Your Blueprint stays the source of truth: anything the tool can't prove, it refuses out loud, and the moment you edit a nativized function it falls back to the VM until you regenerate.
Why use it
Blueprint is a great place to write gameplay logic and a terrible place to run the hottest two percent of it. The usual fix is rewriting those functions in C++ by hand. Here's how that actually compares:
For a sense of scale: on the project this was built for, nativizing the AI fast cycle saved a mean 0.93 ms (−29%) on the game-thread timer slice with 30 NPCs up. Measure your own functions with the built-in Measure command, in PIE, before and after - performance numbers transfer between projects less than anyone hopes.
Features
Note
Not everything nativizes, on purpose.
The emitter covers deliberately less than the whole Blueprint VM, and everything it refuses keeps running on the VM exactly as before. Before you buy into a workflow, run the sweep commandlet on your project - it tells you the exact split for your own content.
Getting Started
- Copy the BPNativizer folder into your project's Plugins folder.
- In the Unreal Editor, go to Edit > Plugins and enable BP Nativizer. There are no plugin dependencies.
- Restart the editor. For C++ projects, regenerate project files and rebuild.
- Open a Blueprint, select a function, and tick Nativize in the Details panel. The plugin generates the C++ into Plugins/NativizedFunctions (created on first use) and says build required.
- Close the editor, build, reopen. The log reports bound N generated function(s).
- Press Verify on the function before you trust it.
Good candidates
Anything called every frame for every agent: AI service ticks, interpolation updates, path evaluation, state scoring. That's where per-call VM overhead piles up. A function that runs once per interaction isn't worth the checkbox.
The generated code
One C++ file per function, sitting in your project, meant to be committed and reviewed like anything else you wrote. The header tells you which Blueprint it came from and under which hash; the body follows the bytecode statement for statement and keeps the Blueprint's own variable names, so it reads like the graph you built.
// GENERATED BY BPNativizer - DO NOT EDIT.
// Source function: /Game/Blueprints/AI/AC_AIRuntime.AC_AIRuntime_C::EvaluatePath
// Source hash: 0x4BDF211135D0B82C
// Bytecode: 1301 bytes, 51 statements
static void Body(UObject* Context, void* Parms)
{
...
L_isValidPath = true;
if (!(A_Reset)) { goto Lbl_12; }
L_CallFunc_Array_Length_ReturnValue_1 = (V_PathPoints).Num();
L_CallFunc_Greater_IntInt_ReturnValue =
UKismetMathLibrary::Greater_IntInt(L_CallFunc_Array_Length_ReturnValue_1, 0);
if (!(L_CallFunc_Greater_IntInt_ReturnValue)) { goto Lbl_33; }
...
}Member offsets and external signatures are resolved at bind time against the live types, never baked in - so a struct edit or a signature change refuses to bind instead of silently reading the wrong bytes. Each file also carries a call counter, which means "did my Blueprint caller actually reach native code" has a numeric answer instead of a hopeful one.
Headless Reference
Everything the UI does, one commandlet does unattended - the Details-panel checkbox with Verify / Measure / Regenerate, the toolbar dropdown, and the bpnativizer.* console family all drive the same code underneath, so nothing you script behaves differently from what you click.
UnrealEditor-Cmd.exe YourProject.uproject -run=BPNativizer -mode=verify -class=/Game/Path/BP_MyActor -function=MyFunction -iterations=100000 -unattended -nopause -nosplashWhat v1 refuses
You should be able to tell whether this fits your project before you buy it. These construct families refuse today; a function that uses one keeps running on the Blueprint VM and behaves exactly as it always did.
Loop macros - ForEachLoop, WhileLoop and friends - are supported, nested included: they lower to the same execution-flow stack the VM runs. For a sense of what the refusals leave: on the 353-Blueprint Lyra project the release gates run against, 211 of 308 function bodies - just over two thirds - nativize today.
Verification
This table is what the release gates actually verify - the right column is unverified, which is not the same as broken. None of it asks you to take our word for anything: the self-test suites (identity, dupreg) and the parity harness ship inside the plugin and run headless against your own functions, on your own machine.
Design
Nine decisions shape the plugin, and most of them exist because something was tried, measured, and found broken. Summaries below; the full record, failures included, ships with the plugin as DESIGN.md.
The emitter lowers what it can prove from the bytecode and refuses everything else by name, at generation. A refused function stays on the Blueprint VM and works exactly as before. The failure mode 'plausible-looking wrong C++' is designed out: an unknown opcode fails the decode, and no code is produced from a stream the decoder did not fully account for.
Generated code is derived output. The canonical source hash ties each generated body to the exact bytecode it was compiled from; editing the Blueprint breaks the match, the VM takes over at the next bind, and the status line says stale. Nothing you do in the Blueprint editor can be silently overridden by stale native code.
The hash covers opcodes, operands with pointers replaced by path names, jump targets as statement indices, the parameter and local layout, and every callee by path - with instrumentation dropped, FName-derived strings case-folded, and sizes excluded. The same function hashes identically in the editor, a commandlet, and a cooked build.
Blueprint struct member offsets are resolved at bind time from the live struct, never compiled into the generated code. Object literals are resolved by path and validate their assumed native ancestor. A struct edit or asset reparent fails the bind, and the VM keeps the function - silently reading wrong bytes is not an available outcome.
Randomized inputs run through both implementations; outputs are compared member by member and objects by content. The input pool keeps nulls, feeds interface implementers to functions that cast, and reports per-input branch coverage - because a green run that never took a branch proves nothing about it.
Bind moves the function's bytecode aside and installs the native body; Unbind restores it byte for byte. The editor unbinds around every package save, so 'native' can never be serialized into a .uasset. AutoBind 0 unbinds everything now, in both directions. ForceVM pins one function to the VM for this process without touching the manifest.
Every write goes through a file transaction with preflight, staging, atomic replace, and rollback - under a system-wide lock taken before the manifest is read. A commit journals its intent first, so a crash mid-write is recovered on the next run. The manifest is validated field by field and refused whole when malformed.
Delete Plugins/NativizedFunctions, or run bpnativizer.RemoveGenerated: every function returns to the VM and nothing else breaks. Remove fails closed - if the .uproject cannot be updated, nothing is copied and nothing is deleted.
The compatibility table on this page claims exactly what the release gates last proved, nothing wider. The gates are runnable: the self-test suites ship in the plugin, the sweep and parity harness run against your own content, and the README names what is NOT verified with the same prominence as what is.
Support
The README, CHANGELOG, and design record ship inside the plugin package. For everything else, use the channels below.