[YOUTUBE] Profiling with Pirates: Performance Plundered from a Real Game | Unreal Fest Chicago 2026

이 영상은 "프로파일링(Profiling)" 기법을 실제 게임 개발 과정에 적용하여 성능 문제를 진단하고 최적화하는 방법을 다루고 있습니다.

주요 내용:

1. 프로파일링의 필요성: 단순히 기능 구현을 넘어, 게임이 얼마나 효율적으로 작동하는지(성능)를 측정하는 것이 중요합니다.
2. 프로파일링 도구 및 방법론:
   • 언리얼 엔진(Unreal Engine)의 고급 트레이스 채널 활용: Stat, Trace, Counters 등 다양한 트레이스 채널을 활성화하여 시스템의 세부적인 작동 정보(프레임 속도, 메모리 사용량, 드로우 콜 수 등)를 수집합니다.
   • 로드 시간 추적 (Load Time Trace): 에셋 로딩 과정에서 병목 현상이 발생하는 지점을 정확히 파악하는 것이 중요합니다.
   • 에셋 로딩 인사이트 (Asset Loading Insights): 어떤 에셋들이, 어떤 순서로, 얼마나 많은 패키지를 로드하는지 시각적으로 분석합니다.
3. 실제 사례 분석 (게임: Corsair Cove):
   • 개발팀은 실제 인디 개발 게임인 'Corsair Cove'를 예시로 사용합니다.
   • 문제 발견: 메인 메뉴 로딩 시 12초가 순수하게 에셋 플러싱(Flushing Assets)에 소요되는 것을 확인했습니다.
   • 진단: 로딩 과정에서 너무 많은 에셋(메인 메뉴 컨테이너만 8,300개 패키지, 2.5GB)이 한 번에 로드되면서 병목 현상을 일으키고 있음을 데이터로 입증했습니다.
4. 결론: 개발 과정에서 추측에 의존하기보다, 전문적인 프로파일링 도구와 체계적인 방법론을 통해 '무엇이', '왜', '어떻게' 느린지를 과학적으로 분석하고 개선해야 합니다.

요약하자면, 이 영상은 언리얼 엔진 환경에서 실제 게임의 성능 병목 지점을 찾아내고 해결하는 전문적인 '성능 최적화 가이드'입니다.

자, 모두들. 자, 모두들. 자. 제가 놀랍고 인내심 강한 선장님을 소개해야겠어요. 선장 A입니다.
그리고 이쪽은 저, 부선장 아르벤입니다.
저희는 에픽게임즈의 기술 개발자 관계 팀입니다.
저희는 에픽 프로 지원 고객을 위한 높은 수준의 지원, 라이선스 관리를 합니다. 에픽 프로 지원 티켓에 답변하고, 임시 지원을 제공하며, 이런 프레젠테이션 같은 사전 예방적 콘텐츠를 제공합니다. 더 자세한 정보는 https: Unrealengine.com/support에서 확인하실 수 있습니다.
하지만 저희가 필요하지 않으셨으면 좋겠잖아요, 그렇죠? 그래서 저희가 이 발표를 하는 거예요. 그리고 이 프레젠테이션에서는 우리가 어떻게 프로파일링하는지에 대해 이야기할 거예요.
실제 개발 중인 게임에서 저희의 프로파일링 방법론을 보여드릴 거예요. 그래서 샘플 프로젝트는 아니에요. 이건 실제 게임의 실제 문제입니다. 그리고 작년에 스톡홀름에서 저희는 이 프로파일링 노르스 오스 오브 블러드에 대한 발표를 했었는데, 제가 알기로는 지금 공개되었어요. 그리고 그건 정말 많은 분들이 참석했어요.
제가 말씀드리건대요. 저기 QR 코드를 통해 확인하실 수 있어요.
그리고 오늘 저희가 프로파일링할 게임을 보여드리고 싶어요.
자, 여기 있어요.
우리의 생존이 위태롭습니다.
그리고 당신은 아무것도 없는 채로 좌초되었습니다.
익숙한 느낌이 드네요.
여기서 꿈이 시작됩니다, 친구.
질문은 당신이 어떻게 당신의 유산을 쌓아 올릴 것인가 하는 거예요.
작은 항구 도시부터 시작하겠지만, 곧 훨씬 더 커질 거예요.
당신의 해적 은신처를 건설하고, 관리하고, 지배하세요.
당신의 초라한 정착지를 번성하는 은신처로 만드세요.
원하는 곳 어디든 건설하고, 다른 사람들이 감히 할 수 없는 높이까지 도달하세요.
당신의 승무원들을 행복하게 유지하세요.
생산 라인을 설치하고 배를 잘 운영하세요.
충분한 자원이 있다면, 당신의 영향력을 확장할 수 있어요. 강력한 배를 만드세요.
저는 새 배가 필요해요. 일곱 바다를 건너.
기다리는 어떤 위험이나 보상에 맞서세요.
하지만 중요한 건 당신이 무엇을 건설하느냐가 아니라, 어떻게 이끌어 가느냐예요.
바다를 지배하고, 위대한 보물을 약탈하고, 전설이 될 것인가, 아니면 모든 것을 차지할 용기가 있을까요?

자, 친구들, 다시 한번 묻겠습니다. 당신의 유산을 어떻게 구축할 건가요?
맞습니다. 저희가 프로파일링을 할 겁니다.
오늘 저희가 프로파일링할 게임은 코스어 코브(Corsair Cove)라는 게임입니다. 저희 친구들인 림빅 엔터테인먼트(Limbic Entertainment)에서 개발했습니다. 저희가 살펴볼 수 있도록 게임을 제공해 주셔서 감사합니다. 저희 친구들인 후디드 호스(Hooded Horse)에서 퍼블리싱했습니다. 데모는 스팀 넥스트페스트 덕분에 지금 이용 가능하며 7월 31일에 출시됩니다. 이곳에서 이 게임을 만드는 독일의 친구들이 정말 기대됩니다. 이제 CPU 프로파일링에 대해 이야기할 제 동료 아리엔(Arien)에게 넘기겠습니다. 감사합니다, 선장님.
좋습니다, CPU 프로파일링에 대해 이야기해 봅시다.
제가 출시할 때, 오, 한쪽 눈으로 보기에는 정말 어렵네요.
코스어 코브를 프로파일링할 때 제가 사용한 실행 매개변수들입니다. 이 매개변수들은 이전 발표에서 사용했던 것과 동일한 실행 매개변수입니다. '목적을 가지고 프로파일링하기(Profiling with Purpose)'라는 발표가 있습니다. 이 QR 코드를 찍으면 바로 그곳으로 연결됩니다. 원하시면 지금 스캔하세요. 그렇지 않다면, 아예 art.games로 가시면 됩니다. 링크는 제 웹사이트 상단 근처에 있습니다. 간단히 요약하자면, 트레이스(Trace)는 채널만 설정합니다. 태스크(Tasks)는 어떤 작업에서 대기하고 있는지 볼 수 있는 라인을 제공합니다. 스테트 네임드 이벤트(Stat named events)는 저에게 좀 더 많은 정보를 제공합니다. 익스잇 커맨드(Exit commands)는 명령을 실행합니다. 저는 왼쪽 하단에 프레임 기록을 보여주는 유닛 그래프를 원합니다.
스테트 FPS(Stat FPS)는 단순히 FPS 수치만 볼 수 있게 해줍니다.
이제 AGC를 확인해 봅시다. 개발 빌드라서 추가적인 검증을 프로파일링하고 있습니다. 그래서 저는 그것들에 신경 쓰지 않습니다. 그래서 그것들을 끕니다. 가비지 컬렉션 중에 U 객체 카운트와 타이밍을 실제로 보고 싶기 때문에 로그 가비지 상세(log garbage verbose)를 켭니다. 그리고 인슈어(ensure)는 0 퍼센트로 설정합니다. 왜냐하면 인슈어는 범위를 가지지 않아서 골칫거리거든요. 그래서 '이게 뭐야?' 같은 거죠. '아, 인슈어구나.' 하지만 지난 발표 이후로 새로운 실행 매개변수가 있나요? 저는 코어 리밋(core limit)이 있습니다. 왜냐하면 제 업무용 컴퓨터는 128개의 하드웨어 스레드를 가진 64코어 스레퍼(Threadripper)라서, 안드로이드 5가 멀티스레딩에서 훨씬 좋아졌기 때문에, 현재 세대 콘솔이나 하드웨어의 대표성을 띠지 못하기 때문입니다. 그래서 코어 리밋 14는 현재 세대 콘솔이나 일반 소비자용 CPU에 훨씬 가까운 시나리오를 시뮬레이션합니다. 스팀 하드웨어 설문조사에 따르면, 소비자용 CPU의 절반이 6코어 이하입니다.

카운터 추적 채널도 켰습니다. 이건 제가 최근에 빠지게 된 기능입니다. 언리얼 인사이트에서 카운터를 활성화할 수 있게 해줍니다. 유용한 것들로는 플랫폼 메모리가 있습니다. 시스템 전체의 총 물리 메모리와 사용 가능한 물리 메모리를 보여줍니다. 프로세스별 사용 물리 메모리도 있습니다. 또한 프리미티브에서 U 프리미티브 컴포넌트 개수, 드로우 호출 수, GPU 어댑터 이름이 있는데, 이건 CPU가 호출한 후 GPU가 처리한 드로우 호출 수를 알려줍니다. 그리고 U 오브젝트 개수도 있는데, 이건 우리가 없어서 넣어야겠다고 생각한 건데, 정말 중요한 수치라고 생각합니다. 모든 것이 기본적으로 활성화되어야 한다고 생각합니다. 아무튼 지금은 카운터 채널에 있습니다. 제가 5.8에 추가했습니다. 코드 두 줄밖에 안 됩니다. 원하시면 여러분 것도 쉽게 가져갈 수 있습니다. 제가 발표할 때 계속 물리 관련 이야기를 하거든요. 예를 들어, 카오스 솔버 바디 개수 같은 것들이요. 비운동성, 동적, 비이동성, 하지만 개수는 그냥 총 개수입니다. 프레임마다 활성화된 물리 도형이 얼마나 많은지 보는 것이 정말 좋습니다. 또한 씬 라이트도 유용합니다. 이것도 말씀드리고 싶었는데, 통계 추적 도구가 있습니다. 언리얼에는 통계가 정말 많은데, 이 채널만 활성화하면 모든 통계를 언리얼 인사이트로 전송합니다. 특정 통계가 필요할 때 정말 좋습니다. 그렇지 않으면 그냥 오버헤드만 추가됩니다. 만약 이게 뭔지 모르거나 지금까지 필요했던 적이 없다면, 그냥 켜지 않는 게 낫습니다. 하지만 '오, 이제부터 이걸 켜야겠다'고 생각할 만한 유용한 것들로는 다이렉트 3D 사용 비디오 메모리가 있습니다. 이건 좋은 기능입니다. 사용 가능한 비디오 메모리, 총 비디오 메모리, 네비게이션 메모리가 있습니다. 그래서 저는 코스(Corsair)에서 100MB가 네비게이션에서 사용되고 있는 것을 발견했는데, 이건 네비게이션 자체가 없는 게임입니다.

아니요, 자체적으로 가지고 있습니다. 그래서, >> 나침반이 필요합니다.
이 채널을 켜서 발견한 좋은 점이었습니다. 그리고 런타임 그래픽 PS 또는 히치 카운트도 있습니다. 그래서 이걸 알고 나니, 한번 살펴보겠습니다. 게임을 실행했습니다. 무엇을 보았을까요? 게임 시작 부분에 집중하겠습니다. 음, 게임의 새 저장 지점까지 가는 데 약 23초가 걸립니다. 메인 메뉴 로딩과 첫 로딩을 포함한 시간입니다. 그리고 그중 12초가 순전히 에셋 플러싱에 사용된다는 것을 발견했습니다. 보통은 에셋 플러싱을 하지 말라고 항상 말하지만, 이 경우에는 괜찮습니다. 왜냐하면 메인 스레드가 플러싱으로 멈춰 있어도 틱하는 로딩 화면이 있기 때문에 비교적 부드럽게 보이기 때문입니다. 여전히 많은 에셋을 플러싱하고 있고, 저는 추측만 하지 않고 항상 무엇이, 왜, 어떻게 느린지 조사해야 한다고 생각합니다. 무엇이 느린지, 왜 느린지, 그리고 어떻게 고칠 수 있는지 기억하세요. 그래서 로드 시간 추적 채널을 켰습니다. 이건 여러분이 가장 좋아하는 추적 채널 중 하나가 될 겁니다. 적어도 저에게는요. 로딩 트랙 인사이트 타이밍 뷰를 활성화하고 에셋 로딩 탭을 활성화합니다. 그래서 인사이트에서 로딩 트랙이 어떻게 보이는지입니다. 음, 다른 에셋 로딩 트랙 버튼을 통해 켜거나 그냥 L 키를 누르면 켜집니다. 그리고 이건 CPU에서 현재 처리 중인 에셋을 보여줍니다. IO 스토어 또는 패킹 로딩은 고려하지 않습니다. 그건 보통 훨씬 빠릅니다. 그리고 저는 그게 별로 신경 쓰이지 않습니다. 저는 어떤 순서로 오고 CPU에서 처리되는지가 중요합니다. 왜냐하면 우리는 보통 거기서 추가적인 처리를 하기 때문입니다. 이게 더 중요한 부분입니다.
그리고 에셋 로딩 인사이트 탭입니다.

새 탭을 보시면 알 수 있듯이, 이 탭은 특정 시간 범위 동안 무엇이 로드되었는지 보여주는 여러 테이블을 제공합니다. 심지어 경로 그룹화를 추가하여 폴더별로 항목을 그룹화할 수도 있습니다. 예를 들어, 여기는 이벤트 집계 탭입니다. 패키지가 아니라 이벤트입니다. 각 패키지에는 요청이나 로드와 같은 많은 이벤트가 있습니다. 하지만 구조체에서 많은 이벤트가 발생하고 많은 구조체가 로드되고 있다는 것을 볼 수 있습니다. 그리고 이것은 메인 메뉴까지의 내용입니다. 그래서 요청 테이블도 확인해 보시는 것을 추천합니다. 이 테이블은 맵을 위한 것인지, 아니면 에셋을 수동으로 로드하는 것인지, 동기식인지 비동기식인지에 관계없이 모든 로드 요청을 표시합니다. 그리고 끌어온 모든 종속성을 포함하여 해당 로드 요청의 지속 시간과 패키지 수를 보여줄 것입니다. 코서스 코브의 경우, 메인 메뉴 컨테이너, 즉 메인 메뉴 맵이 8,300개의 패키지를 가져오는 것을 볼 수 있습니다.

2.5GB인가요?
네.
오, 세상에.
그리고 지속 시간이 5초나 걸리네요.
꽤 많은 에셋이네요.
다행히 추측할 필요가 없습니다. 그냥 볼 수 있습니다. 맵을 마우스 오른쪽 버튼으로 클릭하고 '맵 크기'를 클릭하면 모든 종속성이 표시되고 스크롤해서 볼 수 있습니다. 정말 좋지만, 저는 에디터에 접근할 수 없습니다. 개발 빌드를 막 받았기 때문에 제가 직접 방법을 찾아야 합니다. 그래서 게임에 존재하는 모든 객체를 나열했습니다.
나중에 어떻게 하는지 보여드릴게요. 음, 그리고 제가 찾은 메시지 중 하나를 가져와서 '객체 또는 obj 참조'를 호출했는데, 이는 가장 짧은 체인으로 정렬한 다음 이름과 전체 U 객체의 전체 경로로 설정합니다. 이것은 기본적으로 메모리에 객체를 유지하면서 모든 참조 체인을 작성합니다. 이것은 메모리 누수를 조사하는 데 실제로 매우 좋습니다. U 객체가 왜 수집되지 않는지 궁금할 때 이 명령을 실행하기만 하면 됩니다. 무언가가 참조하고 있기 때문에 정확히 왜 수집되지 않는지 보여줄 것입니다.
그리고 저희 게임에서는 메인 메뉴 컨테이너가 게임 모드 메인 메뉴를 참조하고, 게임 모드 메인 메뉴가 게임 상태 메뉴를 참조하고, 게임 상태 메뉴가 데이터 에셋 UI 전역을 참조하는 것을 볼 수 있습니다.
따라서 메인 메뉴는 기본적으로 이 전역 데이터 에셋으로 연결되어 많은 참조, 많은 정적 메시지를 가져옵니다. 그리고 보통 게임에서 이것을 보면 '참조 지옥'이라고 부릅니다. 기본적으로 게임의 거대한 부분을 로드하는 것입니다. 그래서 메인 메뉴 로딩의 경우, 메인 메뉴에 많은 에셋이 로드됩니다. 그리고 저는 이것들이 실제로 게임에 로드될 때까지 지연될 수 있다고 생각합니다.
총 로딩 시간은 같지만, 적어도 사용자는 메인 메뉴에 더 빨리 도달할 수 있습니다. 그곳에서 새 게임을 클릭하고 싶지 않고, 게임 로드 등을 하고 싶을 수도 있습니다. 그래서 어떤 에셋을 로드할지 더 잘 결정할 수 있습니다. 게임 상태에서 UI 전역을 참조하지 않음으로써 몇 초를 절약할 수도 있습니다. 하지만 한 가지 알아차린 것이 있습니다. 두 로딩 시간 범위를 모두 선택했습니다. 메인 메뉴 로딩과 새 저장 또는 게임 로딩입니다. 그리고 일부 에셋은 두 개의 행을 가지고 있어 두 번 로드되고 있음을 의미합니다.
사실, 많은 에셋이 그랬습니다. 그래서 무슨 일이 일어났는지 궁금했습니다. 그래서 제가 방금 보여드릴 명령을 사용하여 두 로딩 후의 모든 U 객체를 나열했습니다. 그래서 메인 메뉴는 총 11,000개의 패키지로 로드됩니다.
게임 레벨은 추가로 16,000개의 패키지로 로드되지만, 추가가 아닙니다. 그중 9,000개의 패키지가 두 번 로드되었습니다.

그래서 이게 발생하는 이유는 언리얼 엔진이 맵을 변경할 때 가비지 컬렉션을 실행하기 때문입니다. 이전 맵을 언로드하고, 가비지 컬렉션한 다음, 새 맵을 로드하고 이전 맵과 게임 상태가 다른 곳에서 참조하지 않으면 수집됩니다. 따라서 이런 일이 일어나지 않게 하려면 DA 전역 변수에 참조를 추가하거나, 아니면 아예 참조하지 않으면 됩니다. 저희의 경우 애셋이 로드되고 가비지 컬렉션되고 다시 로드되면서 기본적으로 몇 초 동안 중복 작업을 하는 데 시간을 낭비하고 있는 것입니다. 로그에서 더 자세한 가비지 컬렉션 타이밍 통계를 얻을 수 있는데, 'log garbage verbose insights'를 사용하면 훨씬 더 많은 정보를 얻을 수 있습니다. 'insights'에는 이런 모든 것이 표시되지만, 추가로 얻는 것은 스택 댓글입니다. 뷰 객체의 개수와 함께요. 또한 이 가비지 컬렉션이 약 200밀리초가 걸리는 것을 알아차리세요. 이것은 우리가 증분 방식이 아닌 전체 정리 가비지 컬렉션을 수행하기 때문입니다. 보통 레벨을 변경할 때 언리얼은 전체 정리를 수행하며, 시간 분할을 거의 하지 않습니다. 이것이 로그에서 보이는 모습입니다. 실제로 처음 몇 줄의 도달 가능성 분석은 보통 시간이 많이 걸리지만, 단지 0.4밀리초밖에 걸리지 않습니다. 왜냐하면 체인이 상당히 일찍 끝났기 때문입니다. 더 이상 UI 전역 변수를 참조하지 않기 때문에 탐색을 멈추는 것입니다. 그래서 꽤 빠릅니다. 하지만 파괴되는 객체가 많고, 객체가 정말 많이 파괴되고 있어서 비용이 많이 듭니다. 그래서 도달할 수 없는 객체를 해시 해제하는 데 88밀리초가 걸리는 것을 볼 수 있습니다. 왜냐하면 해시 테이블이 이 모든 참조를 유지하고 있기 때문입니다. 따라서 클래스 'Super'의 모든 객체를 빠르게 가져오는 것과 같은 작업을 할 수 있습니다. 그래서 이것을 정리해야 합니다. 또한 81,000개 객체를 정리하는 데 212밀리초가 걸리는데, 이는 단순히 다시 로드하기 위해 정리된 객체가 많기 때문입니다. 다행히 쉬운 수정입니다. 하지만 네, 객체들이 우리가 많이 가지고 있고 시간이 이렇게 오래 걸린다는 것을 알게 되었습니다. U 객체 개수를 어떻게 조사할 수 있을까요?
U 객체 개수는 가비지 컬렉션 시간에 직접적인 영향을 미칩니다. 보통 참조 분석, 도달 가능성 분석을 수행합니다. 그리고 얼마나 많은 새 객체가 게임에 있어야 하는지 궁금할 수 있습니다.
에픽은 예전에 어떤 숫자를 추천한 적이 있나요?

저는 하드 리밋이 있다고 생각합니다.
하드 리밋은 있지만, 이 숫자들로 가비지 컬렉터가 얼마나 오래 걸리는지 보면서 제가 추천을 드리고 싶었습니다. 그래서 만약 게임에 10만 개의 U 객체가 있다면 저는 만족합니다. 당신의 게임을 보고 10만 개의 객체를 보면, 저는 미소 짓거나 심지어 더 낮은 숫자를 줄 것입니다. 매우 감명받을 겁니다.
더 많다면, 음, 심지어 20만 개라도 저는 여전히 만족할 겁니다. 당신들이 무엇을 하고 있는지 알 것 같습니다. 정말 잘했어요. 네, 당신들은 언리얼 엔진의 마스터입니다. 만약 50만 개나 50만 개 이상, 어쩌면 30만 개에서 50만 개, 최대 70만 개 사이라면, 나쁘지 않고 끔찍하지는 않습니다.
어떤 게임들은 그냥 그렇게 많은 양을 가지고 있어야 합니다. 예를 들어 오래된 코드베이스 같은 경우요. 그냥, 오, 모든 것을 설정했는데 너무 많은 노력이 들 것 같다고요. 제가 고치라고 말하지는 않겠지만,
확인해 볼 수는 있겠지만, 아마 가장 큰 문제는 아닐 겁니다.
그리고 어쩌면 가비지 컬렉션이 실행될 때 분당 한 프레임이 떨어지는 정도일 수도 있고, 그러면 괜찮을 수도 있습니다. 하지만 100만 개의 객체는 좋지 않습니다. 너무 많습니다. 저는 그 얼굴을 할 것입니다. 만약 제가 당신으로부터 캡처를 받고 100만 개의 객체를 보면, "아니, 당신은 뭔가 잘못하고 있어요. 무언가 설정하는 방식이 정확하지 않아요."라고 말할 겁니다.
U 객체가 너무 높아요.
너무 높아요.

만약 그보다 더 높이, 2백만 개나 그 이상으로 가면 언리얼 엔진이 그냥 충돌합니다. U 오브젝트 테이블에 하드 제한이 있기 때문입니다. 2백만 개의 항목으로 초기화되고 우리가 채우는 것이고, 오브젝트를 생성하고 비우면 그 한계를 넘어서면 그냥 충돌합니다.
그것이 당신의 신호입니다.
네. 당신이 무언가 잘못하고 있다는 신호죠.
물론, 그것은 당신의 게임과 목표 하드웨어에 따라 다릅니다. 만약 당신이 이것을 온라인으로 보고 있고, "하지만 우리에겐 더 이상 GPS 컬렉터도 없는데요?" 같은 상황이라면, 알다시피 이건 제가 모르겠네요. 그냥 프로파일링을 해서 얼마나 걸리는지 보세요. 가비지 컬렉터가 한 프레임 전체를 차지하고 프레임 드롭이 발생한다면, 그건 너무 심합니다. 제가 어떤 스튜디오에서 "오, 2백만에 도달했어. 그냥 언리얼 소스 코드를 열어서 제한을 늘렸어"라는 말을 들었는데, 그러지 마세요. 다시 말하지만, 좋은 해결책이 아닙니다.
당신이 뭔가 잘못하고 있는 겁니다. 대신 U 오브젝트 수를 줄이세요. 어떻게 하나요? 게임에서 어떤 U 오브젝트가 사용되는지 어떻게 알 수 있나요?
음, 'object list' 또는 'obj list'라는 콘솔 명령어가 있습니다. 저는 이걸 정말 많이 사용해요. 여러분 모두가 사용해야 합니다. 정말 놀랍습니다. 기본적으로 크기별로 각 클래스의 오브젝트 개수를 보여줍니다.
하지만 지금은 크기는 신경 안 써요. 메모리를 조사하는 게 아니라 가비지 컬렉터 타이밍을 조사하고 있거든요. 그래서 저는 개수에 신경을 씁니다. 그래서 거기에 '-count' 정렬 매개변수를 추가할 수 있습니다.
개수별로 정렬합니다. 그러면 이런 게 나올 거예요. 그리고 조사하고 싶은 클래스가 생기면, 여기처럼 'overlay slots 132,000'을 볼 수 있습니다.
그것을 'object list class'에 넣으면 모든 오버레이 슬롯과 전체 오브젝트 이름을 보여줍니다.
그리고 만약 그것을 도구나 무언가에 넣고, 그것으로 멋진 작업을 하거나, 아니면 제가 모르겠네요, 자동화하고 싶다면, '-csv'를 추가할 수 있습니다. 그러면 쉼표로 구분된 값 목록으로 오브젝트를 출력해서 파싱하기 쉽습니다. 그리고 그게 제가 계속 말씀드리던 그 도구, 그 명령어예요. 모든 오브젝트를 보여주는 'object list -all'이요. 제가 이걸 만들는 동안, 저희 엔지니어 중 한 명이 언리얼 인사이트에 대해 "저기, 그거에 대한 새로운 게 있어요."라고 말했어요. 그래서 제가 "더 말해봐요."라고 했죠.
그가 "이 'object trace snapshot control'이라는 오브젝트가 있어요."라고 말했어요. 제가 발표에 넣은 건 그가 우연히 언급했기 때문이에요.
그가 우연히 언급했고, 그래서 오늘 아침에 5.8에서 출시하게 되었고, 그래서 모든 사람들이 이제 그 명령어를 사용할 수 있게 되었어요.
하지만 만약 그가 그냥 무심코 언급하지 않았다면, 저도 몰랐을 거예요. SL도 없었을 거예요. 어쨌든, 모든 오브젝트의 내부 스냅샷을 생성합니다. 저런 자체 탭이 있어요. 그리고 필터링하고, 정렬하고, 그룹화할 수 있어서 정말 멋져요. 저는 "이거 대단하다."라고 생각했어요. 하지만, 코스 코브는 5.8에서 만들어진 게 아니었어요. 그래서 저는 이 도구가 없었어요.
말했듯이, 오늘 출시된 5.8의 새로운 기능이에요. 음, 하지만 코스 코브의 U 오브젝트를 봅시다.
메인 메뉴에는 132,000개의 U 오브젝트가 있고, 새 저장 파일은, 이건 도시 건설 게임이나 코브 관리 게임 같은 거예요. 그래서 새 저장 파일이 300,000개인데, 여기는 빈 맵이에요. 이건 좀 너무 많네요.
제 얼굴이 좀 일그러지기 시작하는 지점에 도달했고, "나쁘진 않지만, 최고는 아니네."라고 생각했어요. 그리고 게임 후반 저장 파일은 761,000개였습니다.
이미 1백만 개 한계에 도달해서, "당신 뭔가 잘못하고 있어요. 우리가 이걸 조사해야 해요."라고 생각했죠. 그래서 오늘 조사할 거예요. 그래서 게임 후반 저장 파일의 모든 U 오브젝트들이요. 그래서 저는 'trace U objects' 명령어가 필요했어요. 그래서 그냥 코딩했어요.

실례합니다. 음, 기본적으로 같은 기능을 하는 간단한 웹페이지가 있습니다. 먼저 클래스별로 정렬한 다음 경로 같은 것을 표시합니다. 자세히 살펴보니 절반은 UI 객체입니다.
알겠습니다. 오버레이 슬롯은 132,000개, 오버레이는 69,000개, 이미지는 65,000개입니다. 무슨 말인지 아시겠죠. 저는 프로젝트에 접근할 수 없어서 이름만 보고 구조를 보려고 했는데, 모든 구조가 가능한 모든 UI 위젯과 버튼을 미리 할당한 것 같습니다. 음, 위젯 블루프린트 구조, 운송 위젯, 오버레이, 버튼 등 이 302개의 버튼이 104,000개의 오버레이를 사용합니다. 즉, 오버레이만으로도 게임 전체에 필요한 객체 수라고 할 수 있습니다. 오버레이에만 그렇게 많이 사용하고 있다는 거죠. 다행히 이제 알게 되었으니, 그들이 막 제작 중이라서 게임을 보내주면서 "프로파일링은 시작했나요?"라고 물어봤을 때, "아뇨, 안 했어요"라고 말할 수 있게 되었고, 저희가 이것을 도와주게 되어 그들이 정말 고마워했습니다. 그리고 제가 조언을 해줄 수 있었죠. "이건 사실 아주 간단하게 고칠 수 있어요. 하루 만에 할 수 있어요. 필요한 때에만 UI 객체를 생성하고, 가져와서 재사용하면 모든 것을 없앨 수 있을 거예요."
또한 후반 게임 저장 시 가비지 컬렉션도 살펴보았습니다. 가비지 컬렉션이 도달 가능성 분석 같은 과정에서 거의 30밀리초가 걸렸습니다. 하지만 그 2.1초 동안 여러 프레임에 걸쳐 시간 분할되어 있었습니다. 약 80만 개의 객체에 대한 가비지 컬렉션이 시간이 걸립니다. 도달 가능성 분석도 시간이 걸리고, 객체 파괴도 시간이 걸립니다. 그리고 로그의 맨 아래에 있는 'log garbage verbose' 명령을 보면 몇 개의 객체가 수집되었는지 볼 수 있다는 것을 알아차렸습니다.
그리고 매분마다 가비지 컬렉터가 파괴하는 데 시간을 쓰는 객체가 약 4만 개에 달합니다. 이는 초당 약 11개의 새 객체가 생성되었다가 버려진다는 의미입니다. 다시 말하지만, 이제 알았으니 아마 수정이 필요할 겁니다. UI 객체 목록을 나열해서 언제 생성하는지 보고, 추상화하거나 재사용하는 방식으로 바꿀 수 있을 겁니다. 그리고 파괴가 2초 이상에 걸쳐 프레임별로 시간 분할되어 있더라도, 여전히 프레임 예산에서 2밀리초를 차지하고 있습니다. 이는 게임 플레이에 사용할 수 있는 시간입니다.
좋습니다. 인사이트로 돌아가서, 제가 또 무엇을 발견했는지 말씀드리겠습니다. 로딩 화면을 보니, 플러싱 후에 로딩 화면이 더 있습니다. 그래서 사실 메인 메뉴와 후반 게임 저장에 들어가는 것을 합치면 총 43초가 걸립니다. 저는 SSD를 사용하는데, 요즘 게임들이 그렇게 오래 걸릴 필요가 없다는 걸 알았죠. 그 22초는 액터 초기화에만 사용되었습니다. 우리는 이미 첫 번째 과정은 제거할 수 있다는 것을 알고 있습니다. 참조가 필요 없기 때문입니다.
그리고 중복도 줄일 수 있고, 플러스트 비동기 로딩 시간도 많이 줄일 수 있지만, 액터 초기화에 22초가 걸리는 것은 좀 의심스럽습니다.
그래서 좀 더 깊이 파봤는데, 모든 액터가 물리 객체를 생성하고 있다는 것을 볼 수 있습니다. 그래서 물리 객체 생성에 10초가 걸립니다. 10.55초입니다. 타이머 뷰에서 볼 수 있습니다.
그리고 제가 말씀드린 새로운 카운터 채널을 사용하면, 매 프레임마다 실제로 58,632개의 물리 본체를 사용하고 있다는 것을 알려줍니다. 기본적으로 제가 만든 전체 캡처 동안 정적이었습니다. 그런데 이건 이상합니다. 저는 "잠깐, 도시 관리 게임에 거의 물리 엔진이 필요하지 않잖아. 공을 던지거나 튕기거나 하는 것도 없고, 캐릭터도 없는데."라고 생각했습니다.

어, 그래서 제가 다시 카오스 비주얼 디버거를 실행해 보기로 했습니다. 그리고 제가 가장 좋아하는 것요. 그리고 그걸 보여드리진 않을 거예요. 그냥 스크린샷 하나만 보여드릴 건데, 이게 꽤 자명하다고 생각해서요.
보시다시피 기본적으로 식물들, 모든 잎사귀에 물리 효과가 적용되어 있어요. 이전 발표인 '목적을 가지고 프로파일링하기'를 보시면, 실제로 똑같은 시나리오가 있었는데, 그들은 모든 것에 물리 효과를 켜 두지 않았어요.
언리얼 엔진의 기본 설정이에요. 죄송해요. 그냥 엔진을 사용하는 초보자들을 위해 작동하게 하고 싶었을 뿐이에요. 하지만 만약 어떤 것이 물리 효과가 필요 없다는 것을 깨닫는다면, 가서 그 물리 효과를 꺼야 해요. 그래서 다시 말하지만, 이제 우리가 이걸 찾았으니, 사실 아주 간단한 해결책이 있어요. 하루도 안 걸려요. 모든 스태틱 메시를 순회하며 복잡한 물리 효과와 단순한 물리 효과를 모두 제거하는 명령만 만들면 되고, 그 22초는 사라질 거예요.
저에게는 의무적인 과일 바구니도 있어요.

뭐라고 불렀어? 아니, 너 말고. 너 말고, 선장님.
좋아. 음, 저는 과일 바구니나 아니면 이런 상자 같은 걸 보면 정말 기분이 좋아져요. 대포알 상자 같은 거요. 음, 또 비난하는 건 아니에요. 모든 게임에서 이걸 보기 때문에, 이제는 그냥 밈(meme) 같아요. 정말 웃기다고 생각해요.
자, 저는 여기까지고요. 플리즈, 선장님, 가져가세요. 고마워요, 아리. 좋아요, 저 혼자서는 전체 과정을 할 수 없을 것 같아요. 그래서, 저는 기술 아티스트이다 보니 주로 GPU 프로파일링에 집중했어요. 그래서 제 프로파일링 설정을 한번 살펴봅시다. 음, 저희가 출시할 때, PC로 출시했기 때문에, 저는 모든 것을 윈도우 11에서 실행했어요. 테스트했던 다양한 하드웨어 구성이 있었어요. 쓰레드 리퍼 워크스테이션도 있었는데, 쓰레드 코어 제한에 대해 몰랐던 거예요. 이건 나중에 따로 챙겨둘게요. 제 작업용 노트북은 i7에 RTX 3070이 달려 있고, 개인용 컴퓨터는 좀 성능이 떨어져요. 아주 오래된 i7, 아주 오래된 3060이요. 음, 하지만 저는 보통 사람들에게 콘솔에서 프로파일링 하라고 말하곤 해요. 왜냐하면 일관된 하드웨어니까요. 제가 정말 원하는 건, 여러분이 프로파일링을 할 때 일관된 하드웨어에서 하라는 거예요. 그래야 여러분이, 아시다시피, 프로파일링을 왔다 갔다 할 때 일관된 기준선이 생기거든요. 그래서, 다양한 하드웨어 구성을 가질 수 있는 PC에서 프로파일링할 때 고려하거나 알아야 할 몇 가지 아이디어에 대해 이야기해 봅시다. 그래서, 음, 접근할 수 있는 몇 가지 방법이 있어요.
다시 말하지만, 이건 일관성에 관한 거예요. 모든 개발자가 동일한 하드웨어를 가지고 있을 수 있는데, 그게 더 어렵거나 비쌀 수도 있어요. 음, 저희 친구들인 리믹(Limic)에서 받은 제안 중 하나가 정말 좋았던 건, 스팀 덱이나 ROG 얼리 같은 휴대용 PC를 콘솔처럼 사용하는 것이었어요. 왜냐하면 그건 일관된 하드웨어 조각들이라는 걸 알기 때문이에요. 저는 또한 여러 가지 구성을 가지고 작업하는 개발자들에 대해서도 들었어요. 여기서 아이디어는, 만약 모든 개발자가 다른 하드웨어 구성을 가지고 있고 매일 게임을 프로파일링하거나 테스트한다면, CPU, GPU, 마더보드, RAM 등에 대해 훨씬 더 광범위한 커버리지를 갖게 된다는 거예요. 그래서, 고려할 수 있는 몇 가지 다른 옵션들이 있어요. 정말로, 그냥 회귀성 등을 테스트할 때는 일관성을 유지하는 것이 중요해요. 그래서, 저는 몇 가지 다른 시나리오를 가지고 있었어요. 매우 후반부의 저장된 게임 파일이 있었어요.
그래서, 많은 것이 일어나고 있었어요. 음, 저는 빌딩 UI를 가지고 만져보고 있었는데, 그게 새로 추가된, 테스트해야 할 다른 모드였거든요.
그리고 저는 일시 정지 및 재개 테스트를 했어요. 왜냐하면 이건 도시 건설 게임이잖아요. 위로 올라가서 게임을 일시 정지시키고, 많은 것을 짓고, 그리고 다시 실행하는 거죠. 이 게임이 플레이될 수 있는 모든 다른 방식들을 생각하는 것이 정말 중요해요.

그리고 저는 항상 몇 가지 다른 설정을 가지고 테스트합니다. R.RHI에 GPU 캡처 옵션 1을 설정했습니다. 정말 멋집니다. GPU용 통계 이름 이벤트 같은 것이라고 할 수 있습니다. 모든 것을 울트라 그래픽으로 실행했는데, 적어도 제 3060이 얼마나 잘 작동하는지 보고 싶었기 때문입니다. 그런 다음 TSR로 전환하고 화면 비율을 75%로 설정했는데, TSR이 업스케일링에 정말 좋다고 생각하기 때문입니다. 더 적고 더 높은 품질의 픽셀에 집중할 수 있습니다. 오늘 오후에 더 많이 이야기하겠습니다. 제가 사용한 소프트웨어는 winpix였는데, pix의 윈도우 버전입니다. pix로 무언가를 프로파일링하려고 할 때는 명령줄 인수에 -ash attach pix를 추가해야 한다는 점을 명심하세요. 그렇지 않으면 감지되지 않습니다. 또한 Unreal Insights를 사용하여 GPU 프로파일링을 수행했습니다. 이것은 나중에 이야기하겠습니다. 그래서 winpix는 정말 멋진데, PC 게임에 대해 심층적인 GPU 캡처 및 분석을 할 수 있다는 의미입니다. 그런데 문제가 있습니다. 예를 들어, 제가 개인용 컴퓨터에서 GPU 캡처를 수행하고 그것을 워크스테이션으로 가져가서 분석하려고 하면, 완전히 다른 그래픽 카드를 사용하고 있기 때문에 타이밍 등이 같지 않다는 큰 경고를 받습니다. 현재 제가 사용할 수 있는 다른 것은 5.6에서 출시된 이 새로운 GPU 프로파일러 2입니다. 이것이 기본적으로 의미하는 바는 R.hetgPU RH I set GPU capture options one으로 실행할 때 Unreal Insights에서 개별 드로우 콜과 그것들이 걸린 시간을 볼 수 있다는 것입니다. Unreal Insights에서 개별 드로우 콜을 볼 수 있습니다. 지형의 지형 재질이 렌더링되는 데 걸린 시간을 보려면 GPU 캡처를 분석할 필요가 없습니다. 그렇죠? 그래서 이 게임에서 발견한 주요 문제는 나나이트 빈의 수, 지형 베이스 패스, 그리고 많은 비나나이트 그림자 비용이었습니다. 그래서 여기 있는 이것도 보았습니다. 저기요? 맞습니다. 중앙에. 이건 간격입니다. 간격인 것은 알지만, HZB와 베이스 패스 사이에 이게 무슨 역할을 하는 건가요? 정말 이상합니다. 전에 본 적이 없습니다. 자, 그것에 대해 이야기해 봅시다. GPU 시간이 아니었기 때문에 stat GPU에서는 발생하고 있는 것을 볼 수 없었습니다. Pix에서도 볼 수 없었습니다. 단지 Pix가 GPU로 설정된 모든 이벤트를 재생하고 있었기 때문입니다. 만약 stat unit graph와 같은 것으로 실행했다면 드로우 스레드 시간에서 볼 수 있었는데, 정말 흥미로웠지만 제 워크스테이션에서 매우 특수한 상황에서만 재현할 수 있었습니다. 개인용 컴퓨터에서 나타날 가능성이 더 높았습니다. 정말 이상했습니다. 그리고 GPU 프로파일러 2.0에서 정말 멋진 점은 GPU가 작동했을 때와 작동하지 않았을 때 Unreal Insights에서 볼 수 있다는 것입니다. 그래서 GPU가 여기서 아무 작업도 하지 않았습니다. 다시 말하지만, 정말 정말 이상합니다. 그러니 어딘가에 있어야 합니다. Unreal Insights에 있고 모든 스레드를 아래로 스크롤하다가 아, 여기 있다. 가려짐 콜 파이프. 문제는 가려짐입니다. 다행히 해결했습니다. 잠깐, 아니요. 아니요, GPUbound_waiting for GPU occlusion queries cgpu track이라고 되어 있습니다. 그래서 이것은 실제 가려짐 문제가 아닙니다. 이것은 단지 렌더 스레드가 다른 일이 일어나기를 기다리며 작업을 수행하고 있는 것입니다. 하지만 GPU에서 발생하는 일이 아니라는 것을 압니다. 왜냐하면 가려짐 쿼리를 비활성화하면 드로우 시간이 떨어지지만 GPU 시간은 증가하기 때문입니다. 단지 그 간격을 옮긴 것뿐입니다. 다시 말하지만, 이것은 정말 이상했습니다. 그래서 고려해야 할 한 가지는 AI의 핵심 제한 사항이 포함된 5.4의 맥락에서 렌더 스레드를 병렬화했다는 것입니다. 따라서 렌더링을 위한 프레임을 설정하는 모든 작업을 수행하는 스레드가 하나 있었고, 그것을 여러 워커 스레드로 옮겼습니다. 5.5에서는 RHI 변환에서도 같은 일을 하여 작업을 여러 다른 워커 스레드에 분산시켰고, 워커 스레드는 코어가 필요합니다.

그래서 R을, 그러면 RHI 번역을 살펴봅니다. RHI는 렌더 스레드에서 받은 명령들을 여기 있고, 이것을 GPU로 보내기 위해 우리가 해야 할 것이 이것이라고 번역합니다. 그렇죠? 그리고 작업 스레드에서 일어나는 모든 것들을 볼 수 있습니다. 이것은 GPU 시간이 아닙니다. 이것은 RHI 스레드입니다. 우리가 렌더링할 것들을 준비하고 있는 것입니다. 그리고 여기 있는 모든 셰이딩 빈들을 보세요. 제가 전부 볼 수 있습니다. 그리고 이것은 언리얼 인사이트에 이 정보를 기록하는 데 시간이 좀 걸리는 것 같습니다. 그래서 조금 되돌아가서 RHI가 GPU 캡처 옵션을 활성화했다고 말했습니다. 이것은 GPU를 위한 일종의 이름 붙은 이벤트와 같습니다. 정보가 많을수록 오버헤드가 크다는 것이죠. 문제가 해결되었습니다. 단지 제가 첨부된 픽스를 활성화한 언리얼 인사이트를 보고 있었기 때문에 RHI 스레드에 추가적인 오버헤드가 많았던 것입니다. 그래서 그것이 문제입니다. 아니요, 여전히 문제가 있습니다. 왜냐하면 번역되어야 하는 모든 셰이딩 빈들이 있기 때문에 그 문제는 발생합니다. 실제로 다른 몇몇 프로젝트에서도 이런 일이 있었습니다. 셰이딩 빈이 너무 많아서 GPU 스레드에 작은 거품이 생기게 합니다. 그래서 우리는 이것에 대해 무언가를 해야 합니다. 그래서 나나이트 래스터 및 셰이딩 빈에 대한 아주 간단한 복습입니다. 이것들은 나나이트 버전의 드로우 콜입니다. 기본적으로 고유한 지오메트리는 아니지만, 올바른 버튼을 클릭하고 있습니다. 모든 머티리얼은 씬에 존재해야 셰이딩 빈이 필요합니다. 따라서 모든 머티리얼 인스턴스 상수, 모든 머티리얼 인스턴스 동적 등이 최소 3마이크로초가 걸립니다. 그리고 우리는 빈 컴팩션을 위해 일부 작업을 수행했지만, 여전히 신중해야 합니다. 왜냐하면 번들링이 모든 것을 해결하지 못하기 때문입니다. 활성 셰이딩 빈이 6,000개라면 여전히 약간의 문제입니다. 그래서 언리얼 인사이트로 들어가서 약 2,100개의 래스터 빈과 4,000개의 셰이딩 빈이 있었고, 이는 너무 많은 편입니다. 저는 래스터 빈은 50개, 셰이딩 빈은 약 1,000개 정도였으면 좋겠습니다. 이것을 줄이려면 무엇을 할 수 있을까요? 음, 제가 여러분 모두가 염두에 두어야 할 한 가지는 머티리얼 레이어가 나이아가라 모듈처럼 사용되어서는 안 된다는 것입니다. 이것들은 포토샵 레이어가 아닙니다. 저는 여러분이 고정된 머티리얼 토폴로지를 가지고 있어서 머티리얼 인스턴스를 재사용할 수 있기를 훨씬 더 선호합니다. 그리고 커스텀 프리미티브 데이터, 머티리얼 파라미터 컬렉션, 인스턴스별 커스텀 데이터와 같은 것을 사용하여 머티리얼 인스턴스를 재사용할 수 있습니다. 그리고 5.8의 실험적인 기능인 나나이트 바인드리스 셰이더에 대해 정말 기대가 됩니다. 그리고 셰이더를 줄이는 것에 대해 더 알고 싶다면, 시스템적 셰이더 감소에 대한 오늘 4시 30분 제이슨과 존의 강연을 꼭 확인해 보세요. 그들이 포트나이트의 셰이더를 68%나 줄였습니다. 정말 멋진 강연이었습니다. 그리고 이 셰이딩 빈들은 실제로 그들의 군중으로부터 온 것이었습니다.

음, 그들은 그것을 BNM 설정이라고 불렀습니다. 그리고 애니메이션 상태를 업데이트하고 캐릭터를 움직이는 등의 작업을 위해 많은 머티리얼 인스턴스 다이내믹을 사용했습니다. 음, 그리고 그들은 자신들만의 방식으로 이 문제를 해결했습니다. 만약 에픽한 방식으로 해결하는 방법을 배우고 싶다면, 먼저 3시에 재러드가 열는 '객체 지향 프로그래밍을 잊기', 'ECS와 매스 엔티티를 사용한 데이터 지향 게임 디자인'에 관한 강연을 들으셔야 합니다. 이것은 언리얼 엔진에서 확장 가능한 메타휴먼 군중을 구축하는 방법에 대한 헨리의 강연의 전제 조건입니다. 저는 오늘 4시 30분에 있을 이 강연이 정말 기대됩니다. 제가 둘러보다가 발견한 다음 문제는 지형 머티리얼이었습니다. 베이스 패스에서 지형 머티리얼에 많은 시간이 소요되는 것을 볼 수 있었는데, 이는 우리가 지형을 내려다보는 데 많은 시간을 보내기 때문에 이해할 만합니다. 그리고 지형 머티리얼 인스턴스 상수_96 같은 것이 많이 있다는 것을 알 수 있습니다. 그리고 제가 머티리얼 인스턴스 상수가 나나이트 셰이딩 빈에 기여하는 것이라고 말했었죠, 맞죠? 하지만 지형 머티리얼은 좀 다릅니다. 할당된 모든 다른 레이어 가중치와 함께 컴포넌트별로 컴파일되기 때문입니다.
어쩔 수 있는 건 많지 않지만, 런타임 가상 텍스처를 사용하여 지형 머티리얼을 설정했는지 확인하는 것을 추천합니다. 지형 머티리얼에서 샘플링한 후에는 최소한의 작업을 수행하세요. 왜냐하면 그것은 큰 것이기 때문입니다. 많은 픽셀을 차지합니다. 물론 렌더링하는 데 시간이 걸릴 것입니다. 그리고 GPU에서 제가 마지막으로 알아차린 것은 비(非)나나이트 그림자였습니다. 매우 크지만 매우 작은 것들이 많이 있었습니다. 그래서 만약 픽스에서 버텍스 셰이더 출력을 본다면, 이것은 비(非)나나이트이기 때문에, 저기 오른쪽 아래에 하나가 있고, 왼쪽 상단 작은 곳에 하나가 있는 것을 볼 수 있습니다. 이것은 단지 두 개의 매우 멀리 떨어진 것을 가진 인스턴스 스태틱 메시 같은 것입니다. 경계가 정말 크기 때문에 렌더링하는 데 시간이 좀 더 걸릴 것입니다. 비(非)나나이트 그림자에서 제가 알아차린 또 다른 것은 NS 갈매기 페른 하나 인스턴스, NS 앵무새 파울리 같은 것들이었습니다. 음, 그래서 그것에 대해서는 나중에 다시 다루겠지만, 정말로 비(非)나나이트 그림자, 특히 가상 그림자 맵을 사용하는 경우, 나나이트를 사용하고 있다면 나나이트여야 합니다. 왜냐하면 그것이 나나이트와 관련된 고정 비용을 상각하는 데 도움이 되기 때문에 루멘과 가상 그림자 맵 성능에 더 좋습니다.
어, 뭐야, 폴리? 아, 앵무새 질문으로 돌아가기를 원했군요, 맞죠? 그래서 우리는 NS 앵무새, NS 상어, NS 갈매기 같은 많은 단일 인스턴스 파티클을 보았습니다. 음, 그래서 이것은 마치 나이아가라로 살아있는 세계의 생물을 만들고 있는 것 같은 느낌을 줄 수 있습니다, 맞죠? 그래서 그것을 처리하는 방법을 알아내려면, 내일 오전 9시에 필립의 강연을 들으러 가야 합니다.

나이아가라로 살아있는 세계의 생명체를 만듭니다. 포트나이트에서 이 모든 것을 어떻게 했는지에 대한 정말 훌륭한 강연이었습니다. 정말 기대됩니다. 아, 그건 정말 좋은 질문이네요, 폴리. 제가 또 뭘 발견했죠? 맞아요. 아리가 아까 언급했던 사용자 인터페이스를 봤습니다. 건물과 관련된 모든 버튼에 2,800개의 액터 컴포넌트 틱이 있었습니다. 맞죠? 그래서 리브 위젯 컴포넌트가 있었습니다. 위젯 컴포넌트가 여기저기 있었습니다. 약 2,800개가 틱하고 있었고, 모든 틱마다 우리가 알다시피 실행하는 데 시간이 좀 걸립니다. 그래서 우리는 무언가를 해야 합니다. 그래서, 위젯 컴포넌트는 업데이트되거나 변경될 때마다 다시 그려져야 합니다. 그것들은 UI를 위한 드로우 머티리얼 같은 것이어서, 많은 오버레이가 거기서 나왔습니다. 저는 비디오 게임에서 이런 것을 매우 자주 봅니다. 예를 들어 데미지 숫자 표시기 같은 것들로, "5 데미지", "10 데미지", "100 데미지", "치명타" 같은 것들이요. 위젯 컴포넌트는 그것에 그다지 좋지 않습니다. 특히 화면에 많이 표시되는 경우 더욱 그렇습니다. 왜냐하면 그들은 모두 개별 컴포넌트이기 때문이죠. 그래서 저는 위젯 컴포넌트를 트릭으로 사용한다고 말하고 싶습니다. 그리고 대신 나이아가라와 나이아가라 데이터 채널을 사용하여 이러한 경우 중 일부를 해결할 수 있습니다. 하지만 다시 말하지만, 이것은 프로젝트에 따라 크게 달라질 것입니다. 단지 이것이 많은 의미가 있었고 또한 몇 가지 문제를 일으킨 것임을 알려드리고 싶었습니다. 제 동료가 여러분에게 강조하고 싶었던 또 다른 것은 위젯 컴포넌트의 자동 틱 모드 기본값입니다. 만약 위젯 컴포넌트를 많이 사용하려고 한다면, 이 기능을 켜보는 것이 좋을지도 모릅니다. 꽤 유용할 수 있습니다. UI 성능과 관련하여 본 것은 이러한 제약 캔버스가 많았다는 것입니다. 이것들은 캔버스 패널이죠? 그리고 우리 모두는 UE4에서 U 사용자 위젯을 만들 때마다 루트에 캔버스 패널로 시작했다는 것을 기억합니다. 그리고 우리 모두는 그것이 위젯을 만드는 올바른 방법이라고 생각했습니다. 하지만 그렇지 않습니다. 왜냐하면 각각의 것이 모든 변환으로 레이아웃되고 업데이트되어야 하기 때문입니다. 그리고 그것은 많은 시간이 걸립니다. 그리고 저는 UI 성능에 대해 많은 시간을 할애하지 않겠습니다. 왜냐하면 제 동료 코디 앨버트가 목요일 오전 9시에 UI 성능 및 무효화 디버깅에 대해 이야기할 것이기 때문입니다. 정말 죄송합니다. 목요일 오전 9시는 너무 빡빡합니다. 싸움을 선택하세요. 그래서 저도 시작 시간을 살펴보고 있었습니다. 왜냐하면 매번 세션에 들어가기까지 40초에서 2분이 걸렸기 때문입니다. 그리고 그것은 제가 반복할 수 있는 능력을 줄입니다. 그래서, 위젯 컴포넌트에 대해 말하자면, 모두 초기화하는 데 3.6초가 걸렸습니다. 오디가 이미 물리 상태에 대해 이야기했으니 그 점은 너무 자세히 설명하지 않겠습니다. 그리고 또한 70,000마리의 상어가 있다는 것을 알아차렸습니다. 상어가 정말 많네요. 그래서 그것은... 정말 많았습니다. 그래서, 성능과 관련된 다른 강연을 찾고 계신다면, 제가 알고 있듯이, 오늘 점심 식사 후에 저는 이 방으로 돌아와서 초당 60프레임으로 프로젝트를 시작하고 그 상태를 유지하는 방법에 대해 이야기할 것입니다. 그리고 그 다음에는 AI에 대해 이 방에서 강연이 있습니다. 네, 프레임 라이브 프레임 타이밍, 동기화, 지연 시간, 프레임 페이싱 및 언리얼의 입력 지연에 관한 것입니다. 저는 그것에서 많은 것을 배웠습니다. 그리고 목요일에는 제 동료 카밀이 프로젝트 상태, 중요한 기술 지표에 대해 이야기할 것입니다. 따라서 프로젝트를 개발하는 동안 염두에 둘 사항들입니다. 그리고 라이엇 게임즈의 동료들이 2x KO를 위해 수행한 최적화에 대해 이야기할 것입니다. 그리고 카오스를 최적화하는 것에 대해 궁금하다면, 그것에 대한 강연도 있습니다. 그래서, 정말 멋지네요. 제 생각에는 그것으로 충분한 것 같습니다.

마무리하기 전에, 네, 여러분과 셀카를 찍고 싶어요. 부탁해요. 아, 객실 기술자님, 실내등 좀 켜주시겠어요? 실내등 켜고 셀카 찍을 거예요. 제가 카운트다운 할게요. 3, 2, 1. 그리고 여러분 모두 '시카고에서 안녕!'을 아주 크고 신나게 외쳐주세요. 손 흔드는 거 많이, 입 크게 벌리는 거 많이 보여주세요. 신나게 해요. 보여줘요. 준비됐어요? 저기 계셔야 해요. 오, 네. 자, 모두 준비됐나요? 3, 2, 1. 시카고에서 안녕! 굉장해요. 굉장해요. 스스로 박수 한번 쳐주세요. 수고했어요, 팀. 잠깐만, 잠깐만, 잠깐만. 폴리가 할 말이 있어요. 폴리가 할 말이 있어요. 뭐라고요? 폴리. 폴리 프로필. 요호 요호 요호 요호. 할리우드 프로필. 정말 그렇네요. 우리가 찾는 황금은 코인이나 보석이에요. 언리얼의 도구를 통해 더 빠른 게임이에요. 프레임 속도가 떨어질 때가 즐거워요. 찾을 만한 보물이 될 거예요. 프레임 전체에 위협을 가할 거예요. 게임을 느리게 하는 걸 사냥할 거예요. 이름으로 핫스팟을 추적할 거예요. 폴리와 함께하는 프로파일링. 요호 요호 요호 요호 프로파일. 정말 그렇네요. 감사합니다. 남은 시간 잘 보내세요.