Installation

Requirements

Requirement	Value
Engine	Unreal Engine 5.7 or 5.8 — two separate editions, verified on 5.7.4 and 5.8.2
Platforms	Windows 64-bit (Win64)
Project type	Blueprint-only or C++
Compiler	Unreal’s supported Visual Studio C++ toolchain, to build the source-only package — including in a Blueprint-only project

Supported Unreal Engine versions

Edition	Status
Unreal Engine 5.7	Verified on 5.7.4 (changelist 51494982), Win64. Descriptor EngineVersion 5.7.0
Unreal Engine 5.8	Verified on 5.8.2 (changelist 56702186), Win64. Descriptor EngineVersion 5.8.0

The recorded checks for both editions cover BuildPlugin Editor, Game Development and Game Shipping builds, plus targeted automated physics tests in disposable buyer-style projects. They do not validate every renderer, hardware configuration or buyer project. Content assets are engine-specific: use the edition matching your engine and never mix the two.

Source-only packages

The 1.0.0 archives prepared for Fab contain the plugin descriptor, source code, content, resources and offline documentation — no precompiled binaries. A project that uses such an archive directly compiles the plugin itself, which requires Unreal’s supported Visual Studio C++ toolchain even when the project has no C++ of its own. Packaging a game that includes a native plugin can also require that toolchain. How a marketplace distribution is delivered is outside what these archives verify.

Keep the plugin explicitly enabled in your .uproject. The descriptor deliberately uses EnabledByDefault: false, so that a Blueprint-only project packages with the plugin’s native code correctly linked.

Required Epic plugins

The plugin descriptor enables these engine plugins:

Plugin	Scope	Why
GeometryCollectionPlugin	Editor	Creating and validating Geometry Collection assets during authoring
Fracture	Editor	Deterministic Voronoi fracture used by the authoring pipeline
Niagara	Editor and runtime	Optional built-in VFX presentation
ProceduralMeshComponent	Editor and runtime	Runtime glass shard meshes
EnhancedInput	Editor and runtime	Input of the bundled demo module
ControlRig	Editor and runtime	UE 5.7.4 edition only — enabled by its descriptor

If a project explicitly disabled one of these, re-enable it. Authoring will otherwise fail at the staging step. No Gameplay Ability System or external combat framework is required; the modules’ other engine dependencies are declared in their .Build.cs files.

Plugin installation

1. For a per-project install, copy the SoulsDestructionFramework folder from the edition matching your engine into your project’s Plugins/ directory, creating it if it does not exist.
2. Make sure the plugin’s modules can be compiled with Unreal’s supported Visual Studio C++ toolchain for your engine version: the archive ships source, not binaries.
3. When the plugin is available through Fab, install it from Library → Fab Library in the Epic Games Launcher for the engine version you target.

Enable the plugin

1. Open the project.
2. Edit → Plugins.
3. Search for Souls Destruction Framework.
4. Tick Enabled.
5. Restart the editor when prompted.

Project restart

A restart is required after enabling. The editor module loads at PostEngineInit, which is what registers the Souls Destruction context menu on Static Meshes and the authoring and batch tabs. If the context menu is missing, the editor was not restarted or the plugin failed to load — check Window → Output Log for load errors.

Content visibility

The plugin ships content: authoring presets, runtime profile templates, demo props and demo integration Blueprints. To see them in the Content Browser:

1. Open the Content Browser’s Settings menu.
2. Enable Show Plugin Content.

Plugin content then appears under the SoulsDestructionFramework root.

Plugin content

Path	Contents
/SoulsDestructionFramework/Authoring/Presets	The ten shipped authoring presets — the wood family (Wood, WoodenCrate, WoodenBarrel, WoodenFurniture, WoodenCoffin), Ceramic, Stone, Glass, GlassVessel and Generic
/SoulsDestructionFramework/Authoring/RuntimeTemplates	Matching runtime profile templates
/SoulsDestructionFramework/Demo/...	Demo props, generated setups, projectile profiles and integration Blueprints

Presets are data assets. Duplicate one into your own project content to customise it instead of editing the shipped asset, so an engine-level plugin update cannot overwrite your changes.

Blueprint-only projects

No C++ code of your own is required — but the source-only package still has to be compiled with the C++ toolchain, as described above. Everything gameplay code needs is exposed to Blueprint:

• USDFDestructibleComponent with Apply Destruction Damage;
• USDFDestructionProfile data assets;
• USDFDestructionSubsystem for radial destruction, budgets and diagnostics;
• the melee, collision and projectile hit sender components;
• the intact physics override, status and fall-damage diagnostics;
• all payload, result and request structures.

C++ projects

Add the runtime module to your build dependencies:

PublicDependencyModuleNames.AddRange(new string[]
{
    "Core",
    "CoreUObject",
    "Engine",
    "GameplayTags",
    "SoulsDestructionRuntime"
});

Then include the public headers you need:

#include "SDFDestructibleComponent.h"
#include "SDFDestructionTypes.h"
#include "SDFDestructionSubsystem.h"

Project settings

Two settings sections are registered under Project Settings → Plugins:

Section	Scope	Contents
Souls Destruction Framework	Game config	World budget limits: active Chaos representations, destruction events per frame, built-in audio and VFX events per frame
Souls Destruction Authoring	Editor config	Output folder policy, default output folder, asset name prefixes, triangle-count warning and automatic thresholds

Upgrades and version compatibility

• The authoring manifest schema is currently version 4. Setups generated by an earlier schema are detected as LegacyManifest drift and must be explicitly adopted before they can be regenerated. Nothing is migrated silently.
• Setups generated before intact physics existed keep their physics (Keep Existing) after an upgrade. Switching them to Simulated is an explicit step with the editor command SDF.MigrateToSimulatedPhysics — see Migrating older setups.
• Generated assets keep their object paths across regeneration, so upgrading a setup does not break level references.
• Read the changelog before upgrading across versions, and validate a representative setup before rerunning a batch across a whole library.

Uninstall considerations

Removing the plugin removes the runtime component and profile classes. Assets that reference them are affected:

• Blueprints derived from ASDFDestructibleActor or ASDFPhysicsDestructibleActor will fail to load;
• USDFDestructionProfile and authoring manifest data assets become unresolvable;
• generated Geometry Collections remain valid — they are standard engine assets.

Before uninstalling, decide whether you want to keep the generated Geometry Collections and rewire them to your own actors. Take a source-control snapshot first.