언리얼의 오브젝트 관리 언리얼 엔진의 경우 C++ 기반이지만 GC가 존재하며 UObject의 형태로 생성된 객체들의 생명주기를 관리한다. 더 나아가 말하자면 언리얼은 스스로 UObject의 메모리를 할당하고 해제하는 것을 권장하지 않는다. 언리얼에서 손수 래핑한 함수를 거쳐 객체를 생성하고 소멸... 시키는 것처럼 보이게 하면서 GC에게 넘기도록 유도한다. 액터의 경우 그 액터를 소유한 레벨을 치우지 않는 이상 Destroy 함수를 통해 명시적 소멸 예약을 걸어두지 않는 한 살아 있다. 액터가 아닌 UObject는 까딱하면 GC가 데려가버린다. 이를 막기 위해 UPROPERTY() 매크로를 이용하여 '지금 참조중이다'라는 걸 일러두고 시작하는 일이 잦지만, UPROPERTY()는 하드 레퍼런스를 걸어두는..

티라미수(안드로이드 13)로 갈아타야만 하는 때가 다가왔다. 더 있지만 주요 라인업 위주로 적어봤다. 요구되는 타겟 SDK 버전 변경(23.08.31) 대상 API 수준의 기한을 더 명확히 하기 위해 매년 8월 31일로 날짜가 통일된다. 신규 등록 앱 / 기존 앱의 업데이트 버전 기존 앱 타겟 SDK Version 33(Android 13) 31(Android 12) 미준수 시 등록 불가 타겟 버전보다 최신 버전의 Android OS를 사용하는 기기의 사용자에게 더이상 구글 플레이에서 앱이 제공되지 않음 안드로이드 13을 타겟팅하는 앱의 동작 변경 사항 구글 플레이의 광고 ID를 사용하는 앱의 경우 이제 매니페스트에서 AD_ID 권한을 선언해야만 한다는 문단이 제일 눈에 띈다. 요구되는 결제 라이브러리 ..

UE5에서 안드로이드 앱을 대상으로 인사이트를 돌리는 건 UE4때와 큰 차이는 없다. UE4CommandLine.txt가 UECommandLine.txt로 바뀐 정도의 미세한 차이다. 예나 지금이나 PC 프로세스 캡처보다 모바일이 약간 더 번거로운 절차를 거칠 뿐이다. 인사이트를 통한 안드로이드 앱 프로파일링 A to Z 우선 인사이트 모듈 빌드, adb, 기기 디버그 허용 등의 기본적인 세팅은 되어 있다는 전제하에서 시작한다. adb reverse tcp:1980 tcp:1980 인사이트는 tcp 포트 1980를 수신하기 때문에 우선 adb revese 명령으로 포트를 돌려준다. UECommandLine.txt 파일을 준비한다. -tracehsot=[로컬 아이피 주소] -trace=[추적할 채널 목록]..

마침내! 임포스터 베이커가 UE5부터 정식 플러그인으로 합류했다. 게다가 UE5.1의 릴리즈 노트에 의하면 나나이트에 임포스터 빌드 옵션이 추가되었다는 언급(r.Nanite.Builder.Imposters)이 있었다. 우선 이번 글에선 기존 임포스터에 대해 알고 있던 것들과 임포스터 베이커의 사용법에 대해서 남겨두고자 한다. 임포스터 한줄 요약하자면, 물체가 항상 카메라를 바라보게 하는 빌보드 기법의 파생 기술이다. 단순한 판때기를 프랍처럼 보이게 하는 일종의 트릭이라고 할 수 있다. 이를 활용하면 버텍스 수를 효과적으로 절약할 수 있기 때문에 최적화에 있어 굉장히 든든한 친구다. 물론 어디까지나 트릭에 불과하기에 한계가 존재한다. 멀리서 볼 땐 그럴싸하지만 가까이서 보면 대놓고 우글우글 티가 나기 때문..

이전글 [UE4/UE5] Replication Graph 그리드 공간화 노드 리플리케이션 그래프에서 기본적으로 제공하는 노드 중 GridSpatialization2D라는 네이밍의 글로벌 노드가 있다. 간결하게 쓰면 구역을 임의로 나누고 내가 서 있는 구역에 속한 액터들만 수집한다는 개념이다. 월드를 그리드 셀이라는 하위 노드로 분할하여 각 셀 안에 조건에 맞는 액터들을 담고, 플레이어는 자신이 현재 위치한 셀 내의 액터 리스트만 노드에서 수집하게 된다. 물론 각 셀의 크기나 그리드의 시작점은 직접 세팅해줄 수 있다. 그리드의 바운드를 설정할 수도 있는데 바운드를 설정할 경우 바운드 밖의 액터는 가장 가까운 셀에 고정된다. 처음부터 모든 셀이 초기화되는 건 아니고, 현재 셀이 생성되어 있지 않은 위치에 액..

※ UE5.2.1 기준으로 최신화된 글 기존 동기화 과정 기본적인 언리얼 데디케이티드 서버 구조 기반의 리플리케이트는 대략 이런 형식이다. 여기서 중요한 포인트는 '매 틱 같은 과정을 반복한다는 것'이다. 소규모 레벨, 적은 플레이 인원에서는 전혀 문제가 되지 않는다. 이 경우 '리플리케이트 고려 대상 리스트' 속에 들어 있는 객체는 (보이지 않는 액터까지 포함해서) 끽해봤자 몇십 개 가량이고, 2개의 커넥션을 대상으로 매번 루프를 돌아봤자 서버 입장에서 그렇게 큰 부하가 발생하지 않을 뿐더러 고려 대상 안에 있는 객체들은 어차피 높은 확률로 리플리케이트된다. 하지만 이 경우는? 어림잡아 계산해도 어마어마한 연산이 나온다. 심지어 부하를 감수하고 열심히 돌려봤자 최종적으로 걸러진 한 커넥션 당 리플리케이..