엔진 Destructible 대신 조각 메시로 파괴 오브젝트 처리하기

엔진 Destructible과 커스텀 시스템#

APEX Destruction과 Chaos Destruction은 구현이 다르지만 큰 흐름은 비슷하다. 원본 메시를 에디터에서 미리 분할해 파괴 전용 자산을 만든다. UE4는 Destructible Mesh, UE5는 Geometry Collection이다. 조각들은 이 자산과 전용 컴포넌트 하나에 묶여 배치되고, 어떤 조각이 언제 떨어질지는 물리 엔진의 파괴 모듈이 정한다.

Chaos Destruction의 경우 Geometry Collection을 처음에 하나의 강체 클러스터로 시뮬레이션한다. 조각 사이에는 연결 그래프와 strain 값이 있고, 충돌이나 Physics Field가 연결 한계를 넘는 충격량을 가하면 연결이 끊어진다. APEX Destruction은 컴포넌트에 가한 피해가 자산에 설정한 피해 한계를 넘으면 조각을 분리한다.

커스텀 시스템은 이 역할을 게임 코드로 가져왔다.

엔진 방식은 분할과 분리 판단을 엔진에 맡기는 대신, 문제가 생기면 원인이 엔진 모듈 안에 있을 수 있다. 커스텀 시스템은 필요한 기능만 두고, 조각이 생기고 움직이고 사라지는 시점을 모두 게임 코드에서 정한다.

조각 데이터#

조각은 Blender에서 원본 메시를 미리 잘라 만든 StaticMesh다. 조각마다 다음 정보를 둔다.

1
USTRUCT()
2
struct FFragmentData
3
{
4
  GENERATED_BODY()
5

6
  UPROPERTY(EditAnywhere)
7
  TSoftObjectPtr<UStaticMesh> Mesh;
8

9
  // 부분 파괴에서 이 체력이 0이 되면 조각이 떨어져 나간다.
10
  UPROPERTY(EditAnywhere)
11
  float MaxHealth = 20.f;
12

13
  // 피해와 충격을 받지 않고 제자리에 남는 조각
14
  UPROPERTY(EditAnywhere)
15
  bool bIgnoreDamage = false;
16

17
  // 부분 파괴에서는 움직이지 않고 완전 파괴 때만 시뮬레이션하는 조각
18
  UPROPERTY(EditAnywhere)
19
  bool bSimulateOnlyOnFullDestruction = true;
20

21
  UPROPERTY(EditAnywhere)
22
  float MassScale = 1.f;
23
};

조각 메시는 소프트 레퍼런스로 두고, 액터가 월드에 들어오면 높은 우선순위로 비동기 로드한다. 파괴되는 순간에는 메시가 이미 메모리에 있다.

완전 파괴#

부분 파괴를 켜지 않은 오브젝트는 체력이 다 닳았을 때 한 번에 부서진다. 이런 오브젝트는 파괴 전에 조각 컴포넌트를 만들지 않는다. 월드에 있는 동안은 원본 UStaticMeshComponent 하나다.

체력이 0이 되면 그때 조각 데이터로 UStaticMeshComponent를 만들어 붙이고, 원본 메시의 표시와 충돌을 끈다. 이후 조각에 물리 시뮬레이션을 켜고 조각 전체의 바운드 중심에서 방사형 충격을 준다.

1
void UFragmentDestructionComponent::DestructAll()
2
{
3
  if (bDestructed)
4
  {
5
    return;
6
  }
7
  bDestructed = true;
8

9
  for (UFragmentMeshComponent* Fragment : Fragments)
10
  {
11
    Fragment->SetMobility(EComponentMobility::Movable);
12
    Fragment->SetVisibility(true);
13
    Fragment->SetCollisionEnabled(ECollisionEnabled::QueryAndPhysics);
14
    // 캐릭터는 조각에 막히지 않는다.
15
    Fragment->SetCollisionResponseToChannel(ECC_Pawn, ECR_Ignore);
16
    Fragment->SetCullDistance(FragmentCullDistance);
17

18
    if (!Fragment->IgnoresDamage())
19
    {
20
      Fragment->SetSimulatePhysics(true);
21
      Fragment->AddRadialImpulse(ImpulseOrigin, ImpulseRadius, ImpulseStrength, RIF_Linear);
22
    }
23
  }
24
}

캐릭터는 조각과 충돌하지 않는다. 오브젝트에 따라 조각끼리의 충돌도 끌 수 있고, 조각의 컬링 거리도 따로 지정할 수 있다.

조각은 기본 10초 동안 남는다. 그 뒤 서버가 모든 클라이언트에 조각 삭제를 멀티캐스트하고, 복제되는 파괴 상태 값을 켠다. 그 뒤에 이 오브젝트를 처음 받는 클라이언트는 이 값만 보고 원본 메시를 숨기며, 조각은 만들지 않는다.

조각 컴포넌트는 복제되지 않는다. 서버는 파괴 시점과 충격 위치만 알리고, 각 클라이언트가 자기 조각을 따로 시뮬레이션한다.

부분 파괴#

맞은 부분만 떨어져 나가야 하는 오브젝트는 부분 파괴를 켠다. 이 경우에는 메시를 로드한 직후 조각 컴포넌트를 미리 만들고 원본 메시를 숨긴다. 조각은 Static 모빌리티에 물리 시뮬레이션이 꺼진 상태로 시작한다.

서버가 피해를 받으면 맞은 위치와 법선, 피해량을 멀티캐스트한다. 각 머신은 그 위치에서 ECC_Destructible 채널로 구 트레이스를 한 번 하고, 걸린 조각 중 이 오브젝트의 조각에만 피해를 나눈다.

1
void UFragmentDestructionComponent::DestructPartially(const FVector& HitPoint, const FVector& HitNormal, float Damage)
2
{
3
  TArray<FHitResult> Hits;
4
  SweepFragments(HitPoint, HitNormal, PartialRadius, Hits);
5

6
  for (const FHitResult& Hit : Hits)
7
  {
8
    auto* Fragment = Cast<UFragmentMeshComponent>(Hit.GetComponent());
9
    if (Fragment == nullptr || Hit.GetActor() != GetOwner())
10
    {
11
      continue;
12
    }
13

14
    // 맞은 지점에서 멀수록 피해가 선형으로 줄어든다.
15
    const float Falloff = 1.f - FVector::Dist(Hit.ImpactPoint, HitPoint) / PartialRadius;
16
    const float FragmentDamage = Damage * Falloff;
17
    Fragment->ApplyDamage(FragmentDamage);
18

19
    // 체력이 0이 된 조각만 떨어져 나간다.
20
    if (Fragment->CanDetach())
21
    {
22
      Fragment->SetMobility(EComponentMobility::Movable);
23
      Fragment->SetSimulatePhysics(true);
24

25
      const float Strength = FMath::Min(FragmentDamage * DamageToImpulse, MaxPartialImpulse);
26
      Fragment->AddRadialImpulse(ImpulseOrigin, ImpulseRadius, Strength, RIF_Constant);
27
    }
28
  }
29
}

CanDetach()는 피해를 무시하는 조각, 완전 파괴 때만 움직이는 조각, 체력이 남은 조각을 걸러 낸다. 충격의 세기는 피해량에 비례하되 상한을 둔다. 조각 컴포넌트는 AddImpulse()도 재정의해서, 속도가 기준(기본 초속 26m) 이상인 조각에는 그 경로로 들어오는 충격을 더하지 않는다.

연출 전용 파편#

플레이어가 지은 건물과 차량, 부서지는 아이템은 같은 조각 컴포넌트를 연출 전용 경로로 쓴다. 이 경로는 클라이언트에서만 동작한다.

• 건물이 무너지거나 아이템이 부서졌다는 이벤트를 받거나 차량이 파괴되면, 클라이언트가 로컬에서 복제되지 않는 파편 액터를 스폰한다.
• 파편 액터가 조각 컴포넌트를 만들고 바로 완전 파괴를 실행한다.
• Dedicated Server와 렌더링 디테일이 낮음인 클라이언트에서는 파편을 만들지 않는다.
• 조각 메시를 미리 비동기 로드해 두고, 파괴 시점까지 로드가 끝나지 않았으면 설정에 따라 동기 로드하거나 연출을 건너뛴다.
• 건물과 문은 HP가 70% 이하로 떨어지면 서버가 클라이언트들에 조각 메시 로드를 알려, 무너지기 전에 로드를 시작한다.

파편이 남는 시간은 게임 상황을 보고 정한다.

1
float ACosmeticDebrisActor::GetLifeSpanFor(const FOptimizeStatus& Status, float DefaultLifeSpan) const
2
{
3
  // 프레임이 크게 떨어졌거나 웨이브 규모가 크면 파편을 만들지 않는다.
4
  if (Status.FPS <= 15 || IsLargeWave(Status))
5
  {
6
    return 0.f;
7
  }
8

9
  return DefaultLifeSpan;
10
}

결과가 0이면 조각을 만들지 않고 파편 액터를 바로 제거한다. 그렇지 않으면 기본 10초의 수명을 두고 조각을 만든다.

재현 환경에서 측정하기#

교체할 때는 시각 효과와 성능이 APEX와 거의 같을 거라고 보고 안정성을 기준으로 판단했다. 이 판단을 수치로 확인하려고 당시 환경을 별도 실험 프로젝트에 재현했다. UE 4.27(PhysX)에는 커스텀 방식과 교체 전 구성인 교체형 APEX를, 이전 후 엔진인 UE 5.3(Chaos)에는 커스텀 방식과 Chaos Geometry Collection을 같은 조각과 같은 충격 조건으로 구현했다. 회사의 코드와 에셋은 쓸 수 없어서 조각 생성기와 각 방식을 새로 만들고, 재질은 엔진의 Starter Content만 썼다. 크래시 빈도는 재현할 수 없어 측정 대상에서 뺐다.

겉모습#

같은 엔진에서 커스텀 방식(왼쪽)과 교체형 APEX(오른쪽)로 같은 장면을 부쉈다. 조각이 같아서 깨지는 모양과 흩어지는 범위는 거의 같다. APEX는 피해를 준 다음 프레임에도 청크가 아직 Dynamic이 아니라서 충격을 2프레임 뒤에 줬고, 그만큼 조각 위치는 조금씩 다르다.

UE 5.3에서도 커스텀 방식과 Chaos Geometry Collection의 깨지는 모양은 비슷했다.

부하 시험: 한꺼번에 부술 때#

웨이브 중 폭발처럼 여러 오브젝트가 한 프레임에 부서지는 경우를 보려고 동시에 부수는 수를 늘렸다. N개를 한 프레임에 부쉈을 때 0.5초 안의 가장 긴 프레임이다.

N	UE4 Custom	UE4 ApexSwap	UE5 Custom	UE5 ChaosSwap
1	2.67ms	3.68ms	4.50ms	4.46ms
10	13.69ms	5.79ms	22.50ms	7.30ms
50	67.82ms	15.75ms	106.34ms	24.46ms
100	138.12ms	31.83ms	191.23ms	43.67ms

동시에 부수는 수가 늘수록 커스텀의 스파이크가 교체형보다 빠르게 커졌다. 100개에서는 UE4 138ms, UE5 191ms였고(교체형 32ms, 44ms), 조각을 64개로 늘린 세트에서는 차이가 더 벌어졌다. 이 구간이 개선할 지점이었다.

100개 동시 파괴를 Unreal Insights로 따로 기록해 파괴 프레임을 나눠 봤다. 트레이스 실행은 위 표의 수치와 별도다.

엔진	방식	파괴 처리	렌더 씬 추가 (FScene_AddPrimitive)
UE 4.27	Custom	107.9ms	2,400회, 23.4ms
UE 4.27	ApexSwap	18.3ms	100회, 0.8ms
UE 5.3	Custom	142.7ms	2,400회, 33.7ms
UE 5.3	ChaosSwap	12.2ms	100회, 0.3ms

UE4 트레이스의 GameThread를 같은 시간 폭으로 잘라 위에 커스텀 방식, 아래에 교체형 APEX를 놓았다. ① 커스텀의 Bench_DestructAll은 107.9ms, ② 교체형은 18.3ms다. 그 뒤로는 커스텀의 바로 다음 프레임이 49.1ms, 교체형에서 충격을 주는 2프레임 뒤의 프레임이 34.7ms다.

같은 구간에서 Bench_DestructAll 아래의 호출이다. ① 커스텀은 Bench_CustomDestruct가 100회 불렸고 자체 시간이 84.2ms다. ② 그 안의 FScene_AddPrimitive는 2,400회, 23.4ms다. ③ 교체형의 FScene_AddPrimitive는 100회, 836.7µs다.

교체형은 오브젝트 하나에 컴포넌트 하나를 만들고 조각은 그 안에서 처리한다. 커스텀은 조각마다 UStaticMeshComponent를 만들어 등록하므로 100개 × 24조각 = 2,400개의 컴포넌트가 한 프레임에 생긴다. UE5에서는 물리 씬에 바디를 넣는 FChaosScene::AddActorsToScene_AssumesLocked도 2,400회(7.9ms) 불렸다. UE4 트레이스에는 ①의 자체 시간을 나눈 스코프가 없어 그 내역은 확인하지 못했다.

NOTD는 이런 상황에 대비해 연출 전용 파편에 프레임이 15fps 이하로 떨어지거나 웨이브가 크면 조각을 만들지 않는 조건을 두었다. 측정으로 비용이 어디서 나오는지 확인했으니, 조각을 생략하지 않고 비용을 여러 프레임에 나누는 방법을 시험했다.

프레임당 조각 예산 두기#

스파이크의 원인이 한 프레임에 몰리는 컴포넌트 생성이라면, 생성을 여러 프레임에 나누면 된다. 개선안에서는 한 프레임에 만들 수 있는 조각 컴포넌트 수에 예산을 두고(24조각 오브젝트 10개분인 240개), 예산을 넘는 파괴 요청은 줄을 세워 다음 프레임에 처리했다. 오브젝트 하나는 언제나 한 프레임에 통째로 부서지고, 차례를 기다리는 동안에는 통짜 메시가 그대로 보인다.

1
bool UFragmentBudgetSubsystem::TrySpend(int32 Cost)
2
{
3
  // 조각이 예산보다 많은 오브젝트도 부서져야 하므로, 이번 프레임에 아직 만든 조각이 없으면 허용한다.
4
  if (SpentThisFrame == 0 || SpentThisFrame + Cost <= BudgetPerFrame)
5
  {
6
    SpentThisFrame += Cost;
7
    return true;
8
  }
9
  return false;
10
}
11

12
void UFragmentBudgetSubsystem::RequestDestruct(AFragmentDestructible* Object, const FVector& ImpactPoint)
13
{
14
  // 앞선 요청이 기다리는 중이면 순서를 지키려고 뒤에 선다.
15
  if (Pending.Num() == 0 && TrySpend(Object->GetFragmentCount()))
16
  {
17
    Object->BreakNow(ImpactPoint);
18
    return;
19
  }
20
  Pending.Add({ Object, ImpactPoint });
21
}
22

23
void UFragmentBudgetSubsystem::Tick(float DeltaTime)
24
{
25
  int32 Processed = 0;
26
  for (; Processed < Pending.Num(); ++Processed)
27
  {
28
    AFragmentDestructible* Object = Pending[Processed].Object.Get();
29
    if (Object == nullptr)
30
    {
31
      continue;
32
    }
33
    if (!TrySpend(Object->GetFragmentCount()))
34
    {
35
      break;
36
    }
37
    Object->BreakNow(Pending[Processed].ImpactPoint);
38
  }
39
  Pending.RemoveAt(0, Processed);
40
  SpentThisFrame = 0;
41
}

100개 동시 파괴의 스파이크가 UE4에서 138ms에서 25ms로(82% 감소), UE5에서 191ms에서 37ms로(80% 감소) 내려가 교체형보다 낮아졌다. 조각 64개 세트의 50개 동시 파괴도 UE4에서 192.78ms에서 28.11ms가 됐다. 100개가 다 부서지기까지는 10프레임이 걸리고(이 측정의 실제 경과 시간은 UE4 약 0.19초, UE5 약 0.28초), 그동안 차례를 기다리는 오브젝트는 통짜 메시로 서 있다. 10개 이하는 예산 안이라 모두 같은 프레임에 부서진다.

남은 비용과 측정 범위#

예산은 파괴 순간의 비용을 나눈다. 조각이 움직이는 동안의 비용은 조각마다 컴포넌트와 강체를 갱신하는 데서 나오는 것으로 보이며, 100개 동시 파괴에서 UE4 평균 11.29ms로 교체형(2.66ms)보다 높다. 더 줄이려면 멈춘 조각을 Instanced Static Mesh로 옮기는 식으로 조각별 컴포넌트 수 자체를 줄여야 한다.

측정 범위는 다음과 같다.

• 네트워크, 오목 메시, Nanite, 비동기 물리는 다루지 않았다.
• 교체형은 같은 액터에 컴포넌트를 만들었다. NOTD는 별도 액터를 스폰했을 수 있다.
• NOTD의 APEX 에셋이 남아 있지 않아 원래 Destructible Mesh 설정값은 알 수 없다.
• 측정 PC 한 대의 결과다.

참고 자료#

• Destruction Overview in Unreal Engine
• Creating a Destructible Object in Unreal Engine 4 & Blender - Kids With Sticks