Validation and regeneration

Regeneration is the operation most likely to destroy a day of work in a naive tool: it rewrites assets other assets already reference. SDF treats it as a protected operation with an explicit ownership model.

The authoring manifest

USDFDestructionAuthoringManifest is an editor-only data asset published alongside every generated setup. Its schema is currently version 4. It stores:

• the source Static Mesh path and its source signature;
• the interior material and the authoring preset;
• the preset family and fracture density;
• the paths of the generated Geometry Collection, destruction profile and destructible Actor;
• every input needed to reproduce the setup — random seed, fragment counts, minimum fragment size, grout, island splitting, the full noise parameter set, collision sample spacing, fragile profile intent, and whether the interior material or the advanced fracture values were overridden;
• the wood choices: WoodLengthCuts (-1 = the preset’s own rule) and PieceCollisionShape;
• the physics policy: whether it was recorded, the PhysicsMode, the Generate Simulation Collision if Needed choice, and the path of the setup-owned simulation mesh copy when one exists;
• ownership fingerprints;
• the directory of the most recent regeneration backup.

Fingerprints

FSDFAssetFingerprint records three things per asset: the object path, the package-file MD5 hash and the package-file size. Fingerprints are captured after packages are durably saved, which makes them evidence of what was on disk when SDF last owned the setup.

Fingerprints are stored for the source mesh, the preset, the interior material, the Geometry Collection, the destruction profile, the optional Blueprint and the optional simulation mesh copy.

Drift detection

Validate Destructible loads the manifest, recaptures fingerprints and reports every difference as an FSDFSetupDriftEntry with a kind, a severity, the affected asset, an explanation and a suggested action.

Drift kind	Meaning
LegacyManifest	The manifest predates the current ownership schema
SourceChanged	The source Static Mesh package changed since generation
PresetChanged	The authoring preset changed
InteriorMaterialChanged	The interior material changed
GeometryCollectionChanged	The generated Geometry Collection was modified
RuntimeProfileChanged	The generated destruction profile was modified
DestructibleActorChanged	The generated Blueprint was modified
OutputMissing	A managed output no longer exists
ReferenceMismatch	A managed reference no longer points where the manifest expects
UnsavedChanges	An involved asset has unsaved editor changes

The resulting FSDFDestructionSetupValidationReport states separately whether the setup is valid, whether drift exists, whether manual output changes were detected, whether regeneration is allowed, and whether a second consent is required.

Source changed

The usual case: the artist reimported the mesh. Regeneration will rebuild the fracture from the new geometry.

Preset or interior material changed

The look of the fracture changes, but no gameplay data does. Regenerate to bring the setup back in line with the preset.

Generated output changed

Someone edited the Geometry Collection, the profile or the Blueprint by hand. That is treated as manual output changes and requires a second, separate confirmation before those edits are replaced.

Unsaved changes

Unsaved editor changes to the source, preset, profile or Blueprint block regeneration entirely. In-memory work is never overwritten. Save or discard first.

Explicit confirmation

FSDFRegenerationRequest carries two booleans, and the service refuses to act without them:

Field	Requirement
bExplicitlyConfirmed	Must be true. Opening the window or running validation is never treated as consent.
bExplicitlyReplaceManualOutputChanges	Must also be true when validation detected saved manual edits to a managed output.

Physics policy and simulation copies

A Simulated setup whose source mesh cannot simulate as it stands owns a mesh copy, SM_SDF_<Name>_Sim, with generated simple collision. Regeneration treats that copy like any other managed output:

• the copy is rebuilt in place when the source mesh changed — same asset, same references — and left untouched when it did not; copies never accumulate;
• the source mesh is never modified, whether it lives in your project, in the engine or in another plugin;
• the recorded physics mode is restored, so an explicit Static choice survives regeneration;
• a manifest written before the physics policy existed keeps the physics of its published profile, including a value you set by hand. Regeneration never converts it to Simulated;
• when a Simulated setup’s source can no longer simulate (its simple collision was removed, or it now uses Use Complex As Simple) and the setup owns no copy to rebuild, regeneration refuses with SDF-REGEN-013 and modifies nothing.

The same collision refusals as generation apply: SDF-AUTH-PHYS-001 when the copy option is off, SDF-AUTH-PHYS-002 when the collision could not be generated.

Changing the choices: Modify Destructible

Regeneration reproduces the recorded choices. To change them — preset, density, cuts, collision shape, fragility, health — use Modify Destructible: it records the new choices in the manifest and rebuilds through this same protected path.

Migrating older setups to Simulated

Older setups keep their behaviour until you migrate them explicitly with the editor console command SDF.MigrateToSimulatedPhysics [VerifyOnly] [Root=/Game/Path] [Exit]. It targets SDF-managed manifests under Root, keeps existing drift and custom settings, leaves composite glass Static, and never rewrites a level or a Blueprint’s class. Run it with VerifyOnly first. Full details: Migrating older setups.

Legacy manifests

Setups generated before the current schema version are reported as LegacyManifest and are not migrated silently. UpgradeLegacyManifestOwnership explicitly trusts the current outputs as the ownership baseline, and only runs with a manifest, a preset and explicit confirmation. Ambiguous ownership is refused rather than guessed — issue codes SDF-REGEN-ADOPT-001 through SDF-REGEN-ADOPT-003.

Regeneration sequence

Validate -> review drift
    ↓
Explicit confirmation (+ second consent if manual edits exist)
    ↓
Stage new outputs transiently
    ↓
Validate staged outputs
    ↓
Back up existing packages
    ↓
Replace in place (object paths preserved)
    ↓
Save
    ↓
Re-stamp ownership -> revalidate

If replacement, save, ownership stamping or final validation fails, SDF restores both the in-memory managed state and the durable package files.

Backups and rollback

Before replacing managed outputs, exact package backups are written to:

Saved/SoulsDestructionFramework/RegenerationBackups/<timestamp_GUID>/

The backup covers the Geometry Collection, the runtime profile, the optional Blueprint and the manifest. The manifest keeps the path of the most recent backup directory.

FScopedTransaction and Modify() integrate with editor undo for the current session; the durable package backups remain the authoritative recovery mechanism after a save or a restart.

Preserved object paths

Regeneration replaces asset contents while keeping their object paths. Levels, Blueprints and data assets referencing the generated Geometry Collection, profile or Actor keep working.

Blueprint graphs and user metadata are preserved: the Blueprint asset is retained and only the SDF-managed CDO links — the intact source mesh and the runtime profile — are maintained.

Missing outputs

A missing managed destination is diagnosed conservatively and blocks in-place regeneration. Restore or redirect the asset first, so replacement can preserve external references. Generating a fresh setup instead would produce new paths and silently break the references you still have.