Sentry - Uneal Engine 4.27 integration

준비 사항

⚠️ 프로젝트가 C++ 클래스를 빌드할 수 있는 상태여야 합니다.

(가이드 문서 내용) Currently, this method is available only for C++ UE projects. Blueprint projects can be converted to a C++ one by adding an empty class using the editor.
→ 현재 이 메서드는 C++ UE 프로젝트에서만 사용할 수 있습니다. 블루프린트 프로젝트는 에디터를 사용하여 빈 클래스를 추가하여 C++ 프로젝트로 변환할 수 있습니다.

C++ 클래스 빌드를 위해서는 Visual Studio 설치가 필요합니다.
관련 구성요소를 설치해야하는데 설치해야하는 것은 다음과 같습니다.

  • .Net 데스크톱 개발, C++를 사용한 데스크톱 개발, 유니버설 Windows 플랫폼 개발

설치, 설정 방법

https://docs.sentry.io/platforms/unreal/
https://github.com/getsentry/sentry-unreal

설치 방법은 간단합니다.

  1. Github에서 Sentry-unreal 소스를 받는다.
    1. 4.27 버전 엔진의 경우 0.5.0 버전을 받아야함.
    2. 5.0 이상 엔진의 경우 최신 버전을 사용할 수 있음 (현재는 0.7.0)
  2. 받은 소스를 프로젝트 폴더/Plugins 폴더 하위에 옮긴다.
  3. 프로젝트를 실행한다.
    1. 프로젝트 실행시 플러그인을 빌드하겠냐는 팝업이 실행되면 빌드한다
  4. 이후 문서 가이드를 참고하여 설정한다
    1. https://docs.sentry.io/platforms/unreal/#configure

설정 상세

  • Project Settings > 프로젝트-패키징 > 패키징 > 크래시 리포터 포함에 체크해줍니다.
  • Project Settings > Plugins > Sentry 에서 DSN 값을 설정해줍니다.
    • 가이드 문서에서 Text 블록에 있는 텍스트를 클릭하면 현재 생성해둔 프로젝트들의 DSN 값을 골라서 볼 수 있습니다.
  • DSN 설정 후 하단에 있는 Crash Reporter Endpoint도 설정해줍니다.
    • 크래시 리포터를 통해 크래시 덤프 업로드하는 곳을 설정해주는 것입니다.

DSN, Crash Reporter Endpoint URL은 Sentry 웹페이지에서 프로젝트 > 프로젝트 설정 > SDK SETUP - Client Keys(DSN)에 있습니다

설정 후 크래시 테스트

저는 크래시 테스트를 위해 기본 프로젝트 생성 후 아래와 같이 진행했습니다.

  1. 기본 프로젝트 생성
  2. 파일 > 새로운 C++ 클래스 추가 > Game Mode Base 선택 > Game Mode 클래스(ex. MyGameModeBase class) 추가
  3. MyGameModeBase에 콘솔 명령어 함수 작성
  4. 에디터에서 월드 세팅 > Game Mode > 게임 모드 오버라이드에서 MyGameModeBase 설정
  5. 컴파일 후 프로젝트 패키지하여 프로그램 실행 테스트

코드

크래시 센트리 업로드 확인

프로젝트 패키지로 만들어진 바이너리 실행 후 크래시를 발생시킵니다.
저는 크래시 발생시키는 명령어 이름을 crashMe로 지어두었고 콘솔 명령어로 실행하면 아래와 같이 크래시 리포터가 뜨게됩니다.

크래시 리포터

“Send and Close”로 크래시 정보를 보내면 센트리에서 크래시 정보를 볼 수 있게됩니다.

Sentry-이슈 대시보드
Sentry-이슈 상세

마무리

이번 포스트에서는 간단히 센트리-언리얼 엔진 설정을 다뤄봤는데 글은 간단했지만..
실제로 크래시를 일으키기 위해 어떻게 해야할지 여러가지 난관이 있었네요.
(언리얼 엔진 에디터에서 처음 빌드해보고 Visual Studio로 연결하는 것도 처음이다보니 좀 걸렸습니다. 😅)
다음 포스트에는 다른 크래시 분석 툴을 설정해보고 포스트 남겨보겠습니다. 감사합니다. 🙏

설치중 에러 참고

ERROR: Could not find NetFxSDK install dir; this will prevent SwarmInterface from installing. Install a version of .NET Framework SDK at 4.6.0 or higher.

  • Visual Studio에서 빌드에 필요한 컴포넌트가 설치되어 있지 않아 발생하는 문제.
  • .Net 데스크톱 개발, C++를 사용한 데스크톱 개발, 유니버설 Windows 플랫폼 개발 설치

Plugin build fail

  • 플러그인이 소스코드만 포함되어있는 상태라면 Visual Studio 설치가 필요합니다.
  • Visual Studio를 설치해주세요.

인풋랙(Input Lag)? 그게 뭔데?

인풋랙(Input lag)?

참고 이미지: BenQ 인풋랙

https://en.wikipedia.org/wiki/Input_lag

인풋랙은 말 그대로 인풋(마우스, 키보드 등) → 연산장치(컴퓨터) → 디스플레이(모니터)까지 사용자의 인풋에 따른 디스플레이까지의 지연을 의미합니다.
인풋랙이라고 부르긴하지만 시스템 지연 시간으로 볼 수 있어요.

이번 포스트에서는 게임에서 주로 느끼는 인풋랙에 대해서만 다뤄보겠습니다.
(주로 인풋랙에 민감하게 반응하는 영역이 게임이기 때문에)

중간에 인풋랙을 찾다가 디스플레이 랙(Display Lag)으로 잘못 빠졌었는데 Latency(지연 시간, 응답 속도) 측면에서 완전히 분리할 수는 없지만 인풋랙과는 다른 영역이었네요.
디스플레이 랙 = 디스플레이 장치(예: 모니터, TV)에서 입력 신호를 받아 처리하여 화면에 표시되는 시간
참고: https://en.wikipedia.org/wiki/Display_lag

인풋랙 깊게 살펴보기

엔비디아에서 좋은 글, 좋은 영상이 있어서 들고왔습니다.
(엔비디아 Reflex에 대한 소개가 있긴하지만요 😅)

게임에서 인풋랙은 많은 요소들이 영향을 준다고 볼 수 있습니다. 적당히 풀어서 정리해볼게요.

  • 주변기기 지연 - 인풋 기기의 폴링 레이트(Polling Rate)에 맞춰 컴퓨터에서 신호 처리가 되는데 그 처리에서 지연 시간이 있습니다. (USB 신호 처리, CPU 처리 등)
  • PC 지연 - 입력을 받고 PC에서 처리되는 동안 발생하는 지연
    • CPU - 게임 내에서 일어나는 애니메이션, 물리 엔진 연산 등에 사용되는 시간
    • Render Queue - CPU 연산 뒤 렌더링을 위해 렌더링 명령들을 Queue에 적재하고 대기하는 시간
    • GPU - Render Queue에 있는 명령들을 렌더링하는 시간
  • 디스플레이 지연 - PC로 부터 받은 신호들을 보이도록 처리하는 시간

우리가 게임에서 말하는 인풋랙은 이렇게 크게 3가지 지연 시간을 합해서 계산해볼 수 있습니다.
물론 네트워크를 이용한 멀티플레이 게임의 경우, 네트워크 레이턴시도 포함해서 봐야하지만 그건 PC 지연에 포함한다고 가정하고 넘어가겠습니다

게임과 인풋랙

주로 인풋랙에 영향을 많이 받는 게임은 FPS(Shooter), 격투 게임, 리듬 게임이 작은 지연에도 큰 영향을 받는 게임 장르로 볼 수 있습니다.

  • FPS, Shooter: 인풋랙에 따라 상대방을 조준, 사격하는데에 있어서 인풋랙의 영향을 받습니다.
    • 추가로 네트워크 레이턴시도 추가되어 흔히 이야기하는 핑(ping) 차이가 발생하기도 합니다
    • 핑이 높으면 피커스 어드벤티지(Peeker’s advantage) 현상이 더 크게 발생할 수 있습니다
  • 격투 게임: 인풋랙에 따라 콤보를 넣을 수 있느냐, 상대의 공격을 인식해서 방어, 회피할 수 있냐가 달라지기에 크게 영향을 받는다고 볼 수 있습니다.
    • 한 사례로 콘솔 기기와 PC 설정 환경 차이로 인해 인풋렉의 차이가 발생해서 PC로 대회를 열 수 밖에 없었다는 사례도 있었네요. (스트리트파이터5 참고 사례, 참고 사례 링크2)
  • 리듬 게임: 인풋랙에 따라 노트를 정확하게 맞출 수 있냐 없냐가 달라지니 크게 영향을 받는다고 볼 수 있습니다.
    • 게임이 얼마나 세세하게 판정하냐에 따라 영향도는 달라질 수는 있지만 게임 자체 이슈, 모니터, 컨트롤러의 지연 요소에 따라 인풋랙이 크게 발생할 수 있습니다

인풋랙 측정 방법

퀘이사존: 모니터 인풋랙은 무엇이고, 어떻게 측정할까? https://quasarzone.com/bbs/qn_report/views/113059

상세한 내용은 퀘이사존에서 자세히 설명해주고 있어서 위 글을 참고해보시면 좋을 것 같습니다.

요약해보면 마우스 입력 → 화면 반응까지 시간을 LDAT(Latency Display Analysis Tool)이라는 장치를 이용해서 측정합니다.
LDAT이 없을때는 화면 반응을 카메라를 이용해서 촬영, 측정했다고 하네요. 🤩

인풋랙 개선 방법

엔비디아 글에서 여러가지 인풋랙 개선 방법들이 있어 간단히 남겨보겠습니다.

https://www.nvidia.com/en-us/geforce/guides/system-latency-optimization-guide/

  1. Turn on NVIDIA Reflex (게임 설정): 게임에서 Reflex 기능 On
  2. Turn on Ultra Low Latency Mode (엔비디아 설정): Low Latency를 Ultra로 설정
  3. Turn on Exclusive Fullscreen (게임 설정): 게임에서 “전체화면” 설정
  4. Turn off VSYNC (엔비디아 설정): Vsync 기능 off
  5. Turn on “Game Mode” in Windows(OS 설정)
  6. 설정 > 게임 > 게임 모드 >게임모드 On 설정
  7. Overclocking (PC 하드웨어 설정): CPU, GPU, Ram 오버클럭
  8. Consider Faster Hardware: 하드웨어 업그레이드 😂
  9. Reduce settings (게임 설정):
  10. 하위 옵션으로 반응성을 올려라
  11. Enable your maximum refresh rate: 디스플레이의 주사율을 최대로 설정
  12. Turn on G-SYNC Esports mode (엔비디아 설정)
  13. Turn on some overdrive: 모니터에서 오버드라이드 모드 설정

마무리

요렇게 인풋랙에 대해서 짧게 알아보았는데요. 정리해보고나니 일상적으로 게임에서 이야기하는 인풋랙은 시스템 레이턴시(시스템 지연 시간) 정도로 볼 수 있을 것 같습니다.

인풋랙은 워낙 많은 요소들이 영향을 주는 것이다 보니 하나만으로는 개선이 어렵고 이것저것 다 최적화해야하는 느낌이네요.

개인의 입장에서는 하드웨어 업그레이드, 게임 설정으로 개선할 수 있고
게임 입장에서는 게임 최적화, 하드웨어 기능 호환 등을 지원하는 것이 개선 방법이 될 수 있겠습니다.

참고

(Game Dev Study) DirectX, Vulkan 정리

Low level Graphics API (저수준 그래픽스 API)

DirectX, Vulkan을 소개하기에 앞서 저수준 그래픽스 API는 뭔지 알아봐야겠죠?

https://en.wikipedia.org/wiki/List_of_3D_graphics_libraries

위키에서는 3D 그래픽스 라이브러리로 이야기하고 있지만 그래픽스 API로 이해하고 보시면될 것 같습니다.
말 그대로 컴퓨터에서 3D를 볼 수 있게하는 그래픽스 엔진, 라이브러리로 이해하시면 편하겠네요.

이런 API를 통해서 언리얼 엔진이나 각종 게임 엔진에서 오브젝트들을 렌더링하고 그래픽 결과물들을 보여주고 있습니다.

DirectX, Vulkan 소개

DirectX

https://ko.wikipedia.org/wiki/DirectX

마이크로소프트에서 만든 주로 게임 개발에 널리 쓰이고 있는 API입니다. (멀티미디어를 위한 API)
DirectX에는 2D, 3D 등 그래픽 렌더링을 위한 API가 포함되어있습니다.

DirectX는 마이크로소프트 플랫폼(Windows, Xbox)에서 동작하는 그래픽스 API로 많은 게임에서 사용되는 API입니다.
현재 최신 버전은 12버전으로 Dx12, D3D12로 많이 부르기도합니다.

관련 자료들은 마이크로소프트 페이지에서도 확인하실 수 있으니 참고해보세요!

Vulkan

https://ko.wikipedia.org/wiki/%EB%B2%8C%EC%BB%A8_(API)

Vulkan은 크로스 플랫폼 3D 그래픽스 API입니다. 모바일, 리눅스, 마이크로소프트 플랫폼 등에 사용될 수 있다는 뜻이죠.
크로노스 그룹에서 OpenGL의 차세대 버전으로 준비하다가 Vulkan이라는 이름으로 릴리스되었습니다.

OpenGL처럼 게임이나 미디어 처럼 고성능 실시간 3D 그래픽스 앱을
모든 플랫폼에서 고성능으로 CPU를 적게 사용하도록 개발하는 것을 목표로 만들어진 API입니다.

영상에서는 기존 OpenGL 보다 Vulkan이 CPU 코어 활용성이 좋고 에너지를 덜 쓰는 것을 비교해서 보여주고 있네요.

DirectX 11, DirectX 12, Vulkan 뭘 써서 개발해야할까?

요즘 게임 개발을 하는데 바로 저수준 그래픽 API를 사용해서 개발하는 경우는 별로 없을겁니다.
언리얼 엔진이나 유니티 등 상용 엔진들을 사용해서 게임 컨텐츠를 개발하고 있죠.

컨텐츠 개발 이후 최적화에 있어서 어떤 것을 중점으로 최적화를 할지, 어떤 플랫폼에 런칭을 할지에 따라 위 질문에 있는 모든 것을 사용해야할 수도 있습니다.
Dx11이 Dx12 보다 버전이 낮지만 현재 개발된 환경에 따라 11 버전을 사용해야할 수도 있겠죠.
API에 맞게 최적화도 필요한 것이 있어 각 개발 환경에 맞춰 개발해야한다 정도로 이야기할 수 있을 것 같습니다. (너무 정론이네요 😂)

DirectX vs Vulkan?

2개의 API를 확인해보았으니 비교를 안해볼 수 없죠! 사실 Youtube에서 2개의 API를 치면 많이 나오는 것이 비교내용입니다.
게이머 입장에서는 그래픽 품질은 좋고 FPS가 잘나오면 최고이니까요. 게임 개발 엔진들에서도 각 API를 사용하여 개발할 수 있도록 지원하고 있기도하구요.

영상만 보았을 때는 Dx11은 Dx12, Vulkan에 비해 안좋은 버전으로 보이지만 사실 버전에 맞춰 게임 코드도 최적화가 필요하기에 버전만 12로 올리기는 어렵습니다.

다른 블로그 글이나 아티클들을 보면 두 API를 비교한 것은 대부분 성능상의 비교가 대부분인데요.
이건 사실 하드웨어 + 게임(앱) 마다 천차만별이라서 뭐가 더 좋고 나쁘다를 판별하기는 어렵다고 생각합니다.

마무리

사실 2개의 API를 비교하고 차이점을 정리하기에는 어려움이 있네요.

각각 그래픽을 렌더링하기 위해 다른 동작을 사용하고 있는 것도 있고 기본 개념이 같은 것들도 있었습니다.

이번 포스팅을 위해 공부를 얕고 짧게했지만 누가 우위에 있냐는 크게 중요하지 않은 것으로 결론을 내렸습니다.

아마 다음에는 하나하나 조금 더 깊게 공부할만한 주제로 찾아올 수 있지 않을까 싶네요.

다음에는 게임 개발에 필요한 그래픽스에 대해 조금이나마 더 알 수 있는 지식으로 찾아오겠습니다. 감사합니다. 😈

언리얼 엔진 5 얼리 액세스 출시

언리얼 엔진 5 소식

https://www.unrealengine.com/ko/blog/unreal-engine-5-is-now-available-in-early-access

지난 5월 26일에 언리얼 엔진 5가 얼리 액세스로 출시되었다는 소식이 있었습니다.
얼리 액세스 전에 나왔던 영상에서도 많은 기대를 모았는데 어떤 기능들이 공개된 대로 동작할지 기대가됩니다.

지난 5월 13일에 공유된 영상

얼리 액세스 릴리스와 함께 공유된 영상

⭐️ 영상에서 리스트 버튼을 눌러보시면 언리얼 엔진 5의 기능 리스트를 볼 수 있습니다.

언리얼 엔진 5 신기능 소개

나나이트(Nanite)

  • 가상화된 마이크로폴리곤 지오메트리 시스템 (Virtualized MicroPolygon Geometry System)
  • 노멀 맵에 디테일을 베이크하거나 LOD를 직접 제작하는 것처럼 오래 걸리고 반복적인 작업을 생략함

루멘(Lumen)

  • 완전한 다이나믹 글로벌 일루미네이션 솔루션 (Fully dynamic global illumination solution)
  • 이를 통해 직사광, 지오메트리의 변화에 간접광이 실시간으로 반응하는 사실적인 다이나믹 씬을 제작할 수 있음
  • 라이트 맵 UV를 제작하거나 라이트 맵 굽기를 기다리거나 리플렉션 캡쳐를 배치하지 않아도 됨

월드 파티션 시스템(World Partition System)

  • 자동으로 월드를 그리드로 나누고, 필요에 따라 필수적인 셀을 스트리밍하는 기능

액터당 한개의 파일 시스템 - 협업을 원활히 할 수 있게 액터를 파일 단위로 하는 기능

데이터 레이어

  • 레이어로 특정 조건, 상태에 따라 월드에 다른 베리에이션을 동일한 공간에 존재하는 레이어로 제작할 수 있음

애니메이션

  • 컨트롤 릭(Control Rig) - Rig을 제작하고 다수 캐릭터에 공유, 포즈 취할 수 있도록 함
  • 포즈 브라우저(Pose browser) - 포즈를 애셋화하거나 적용함
  • 풀 바디 IK 솔버(Full body IK Solver) - 쉽게 동작 구현 도움
  • 모션 워핑(Motion Warping) - 캐릭터 루트 모션을 다수의 타깃에 정렬되도록 동적으로 조정 가능

메타사운드(MetaSounds)

  • 사운드 소스의 오디오 DSP 그래프 생성에 대한 완전한 제어를 제공

향상된 에디터 UI 및 워크플로우

  • 콘텐츠 브라우저 고정 기능, 에디터 탭을 축소할 수 있는 기능
  • 디테일 패널에서 자주 사용하는 프로퍼티를 빠르게 액세스할 수 있는 새로운 즐겨찾기 시스템
  • 월드에 액터를 손쉽게 배치하게 해주는 메인 툴바의 새로운 생성 버튼, 새로운 프로젝트 생성을 위해 보다 쉽고 간소화된 워크플로도 제공

언리얼 엔진 5 보러가기

언리얼 엔진 5는 에픽게임즈 런처를 통해 실행해볼 수 있습니다.

튜토리얼도 있으니 한번 보고 해봐야겠어요. 😸

https://www.unrealengine.com/ko/onlinelearning-courses/ue5-early-access-quickstart

소개는 여기까지 하겠습니다. 자세한 내용은 원문을 참고해주세요!

우리에게 1ms의 의미란 (FPS vs Frame time)

Intro

이 글은 최적화 관점에서 FPS(Frame Per Second) 대신 Frame time(1ms)을 어떤 의미로 어떻게 볼 수 있는지에 대해 간단히 이야기해봅니다.

FPS? Frame time?

FPS는 다들 많이 들어보았을 것 같습니다. 말 그대로 Frame Per Second, 프레임 당 초(시간)을 의미하며 Frame rate(프레임률)이라고도 말합니다.

위키 참고: https://ko.wikipedia.org/wiki/프레임_레이트

1초 동안 보여주는 화면(프레임)의 수

예를 들면, FPS 60 == 1초당 60 프레임을 그린다고 볼 수 있겠습니다.

**Frame time(프레임 시간)**은 FPS에 비해서 생소할 수 있지만 간단히 말하면 화면(프레임)이 그려지는데 걸리는 시간입니다. (한 프레임을 그리는데 사용할 수 있는 버퍼 시간으로도 볼 수 있습니다.)

FPS와 동일하게 예를 들면, frame time 16ms == 화면 1개 그리는데 16ms 소요된다고 볼 수 있습니다.
FPS와 Frame time을 엮어서 보면 아래와 같겠죠

FPSFrame timeFrame time(ms)
201/2050ms
301/3033.33ms
601/6016.67ms
1001/10010ms
1441/1446.9ms

이렇게 보니 FPS와 Frame time이 연관이 있는 것은 알았습니다. 최적화 관점에서 이 두 값을 어떤 의미로 볼 수 있을까요?

최적화 후 1ms 차이

게임을 개발하면서 FPS가 안정적일 수 있도록, 더 높은 FPS로 플레이할 수 있도록 최적화를 하는데요. 이 때 최적화 결과 Frame time이 1ms 줄었을 때 FPS 변화는 어떻게될까요?

FPS와 Frame time 관계를 보았을 때 60 FPS 기준으로 Frame time은 16.67ms 였는데요.

Frame time이 16.67ms → 15.57ms가 될 경우, 60 FPS → 63.8 FPS. 약 3.8 FPS 상승합니다.

더 높은 FPS에서는 어떨까요? 10ms → 9ms가 되면 100 FPS → 111.11 FPS. 약 11.11 FPS 상승합니다.

최적화 후에는 FPS를 보는 것 보다 Frame time을 보는게 더 명확하다

60 FPS 고정인 상태 또는 게임에서의 부하(stress), 여러가지 하드웨어 환경에 따라 측정 결과가 다를 수 있긴합니다.

다만 최적화 후 개선된 항목(function 또는 Operation)이 얼마나 게임 환경(성능)에 영향을 주었는지를 Frame time 변화를 통해서 조금 더 명확하게 볼 수 있습니다.

물론 FPS 보다는 바로 이해가 가지 않을 수는 있지만 다른 요소에 영향을 받지 않는 수치로 볼 수 있는 것이죠.

Fin

일반인(?)의 시선으로 Frame time을 최적화 관점에서 정리를 해보았습니다.

항상 최적화 이후에 1ms, 0.5ms 개선했다는 내용이 큰 개선인가? 하는 의문이 있었고 그런 참에 계산해보고 정리해보면서 개선의 크기와 영향도를 알게되어서 즐거운 공부였네요.

틀린 내용이 있다면 편하게 댓글 남겨주세요.
고맙습니다. :)

참고 영상

https://www.youtube.com/watch?v=GpYyjb5mz48