Skip to main content

GPU Deformation Subsystem

The GPU Deformation Subsystem (UDeformableGpuDeformationSubsystem) collects deformation commands from GPU-backed components in the same game world. It schedules their work centrally instead of making every component submit each impact independently.

Setup​

No additional actor, Blueprint node or manually placed subsystem is required. Select GPU on the DMC and complete the normal mesh setup. Unreal creates the world subsystem for supported gameplay worlds. The retained CPU backend keeps its separate processing workflow.

From Impact to Visible Deformation​

  1. The DMC evaluates an incoming hit using its collision, strength and registration settings. Existing hit restrictions still apply.
  2. It prepares the deformation command, including local hit location, direction, radius, section damage, resistance and other deformation parameters.
  3. The subsystem queues commands and selects work for submission. Work not selected by the current command budget remains queued.
  4. Selected commands are grouped by their owning GPU render component and submitted as batches.
  5. The renderer dispatches compute work for the relevant mesh buffers and prepared LODs, then renders the updated positions and vertex damage colors.

Commands preserve their order within each component, which matters because repeated damage is stateful. Central collection does not make hit order interchangeable.

Batching and Buffer Ownership​

Every deformable component still owns its visual mesh and render state. Attachments remain separate components with their own transforms, materials and damage.

Central submission is not one universal dispatch

The subsystem can collect multiple vehicles into the same submission flow, but the renderer still issues separate compute work for their mesh buffers. It does not merge every vehicle, section or material into one mesh. Material drawing and compute dispatching are separate operations.

This reduces per-hit submission overhead and avoids using CPU ProceduralMesh rebuilds as the GPU deformation solution. It does not remove normal rendering costs, shader work, buffer updates or CPU hit preparation.

Scheduling and Pending Work​

The command budget controls how much queued work is selected for a submission step. It is not a guaranteed millisecond limit: commands with different meshes, LOD counts and hit workloads can have different costs. Scheduling may spread work over frames rather than making every queued dent visible immediately.

If a component's scene proxy is temporarily unavailable, its unsubmitted commands can be retried ahead of later work. Reset and component teardown also remove obsolete queued work for that component; old commands must not be treated as new damage after a reset. GPU mode does not silently switch to CPU deformation.

Use Advanced Damage Debugging to distinguish accepted hits, initialization retries, pending scheduler work and render-thread submissions. A submitted command is not proof that the GPU has completed it. Persistent pending work or retry warnings require investigating initialization and assigned mesh data.

Replication Is a Separate Responsibility​

The subsystem schedules local GPU processing. It is not a replicated world-wide hit store and does not replace actor relevancy or Component Replicates.

Damage snapshots, delta history and relevancy recovery belong to the deformation component's networking workflow. Network recovery budgeting and local GPU command scheduling are different stages; either can affect when recovered damage becomes visible.

Performance Checks​

Compare the same vehicles, prepared LODs, hit inputs, materials and camera. Verify actual deformation and scratch output before accepting an FPS result. Include frame-time spikes and queue latency, not only average FPS. See Performance Profiling.

Last updated on