techartnomad

[LINK] 일본 히스토리아 블로그 UE 아카이브

jplee — Fri, 29 May 2026 05:05:58 +0900

뭐 이건 번역 하기에는 무리가 있고 짧게 짧게 포스팅 된 내용도 많더군요.

2023년 이후 고객사의 신작이 언리얼엔진 5.7 로 시작하게 되어서요. 다른 고객사도 언리얼엔진 5로 개발했었지만 5.6 부터 인터페이스도 약간씩 바뀌고 어딘가 또 제가 모르는 피처들이 분명 있겠죠. 그래서 이래 저래 또 살펴보고 있습니다. 초기 단계라서 엔진 커스터마이징 진행은 하지 않고 순정으로 작업 중입니다. POC 단계 후에 버티컬 슬라이스로 가면 아마도 엔진 소스코드 버전으로 넘어가야 하겠지만요.

UE4・ニュース・イベント｜ゲーム企画・開発のヒストリア

ヒストリアのブログページ。最新のイベント・ぷちコン情報や製品情報、初心者でもわかるUE4のテクニカル情報、ゲーム開発の裏側などをご紹介しています。

historia.co.jp

Youtube Player Widget

jplee — Fri, 29 May 2026 04:19:05 +0900

고객사 사무실을 거닐다보면 아티스트분드께서 작업 하면서 유투브영상을 틀어놓고 창을 작게 해서 보조모니터에 띄워놓곤 하더군요. Always On Top 기능과 검색 및 로그인 그리고 시청까지 제공하는 위젯으로 만들어봤습니다. 영상을 보면서 일하는 스타일이 아닌 저로서는 이해가 잘 안됬지만 와이프 역시 3D 아티스트로 십수년 경력이 있는데 물어 보니까 백색노이즈 처럼 집중력이 올라가는 경우가 있다고 합니다. 자기도 그런다고.... 그래서 아무튼 만들었습니다.
다운로드 링크: https://mazeline.tech/freeapps/youtube-player-widget/

YouTube Player Widget | 무료앱 | Mazeline

YouTube 영상을 데스크톱 위젯으로 띄워 작업 중에도 항상 보면서 들을 수 있는 앱입니다. 항상 위 고정, 크기 조절을 지원합니다.

mazeline.tech

인스톨러 다운받고 설치 하시면 됩니다. 이후 업데이트는 자동감지 되니까 업데이트 하라고 뜨면 해 주세요.

Movie2GIF 변환기. 깃허브 공유

jplee — Fri, 29 May 2026 00:53:50 +0900

티스토리에 영상파일 업로드 서비스가 사라져가지고....당황스러웠는데 뭐 그래서 AI 시켜서 간단한 Movie2GIF 변환기를 만들었습니다.

깃허브

GitHub - mazelines/movie2gif: 티스트로에 영상 업로드 사라져서..... gif 로 변환하는 간단한 툴 만듬.

티스트로에 영상 업로드 사라져서..... gif 로 변환하는 간단한 툴 만듬. Contribute to mazelines/movie2gif development by creating an account on GitHub.

github.com

이런 간단한 유틸리티는 아젠틱 코딩으로 간단히 만들어 쓸 수 있는 시대가 됬네요.

약간 사족입니다만...게임개발에도 일부 AI 를 도입해서 쓰고 있는데요 협업을 하면 할 수록 팀원과의 대화보다 AI 와의 대화에 매몰된다는 단점이 많아서 몇일 전에도 인디게임개발팀 파트너들과 심도 있는 토론을 했습니다. 특히나 팀원들이 모두 리모트로 협업할때 더 심각하더라고요.

AI 코딩을 최소화 하고 가능하면 직접 코딩을 하고 난재들 위주로 AI 에게 도움을 받아서 개발하거나 테스팅 분야쪽에서 AI 를 활용 하는 식의 보조도구로서 AI 사용 가이드를 잡아야 한다는 점에 이견이 없더라고요.

아무튼... 만든 차에 공유 해 봅니다. 용량이 작지 않은 이유는 ffmpeg 이나 디펜던시를 슬림화 하고 실행파일에 다 넣어서 그렇습니다. ( 따로 디펜던시 설치 과정이 없도록 했어요 )

종료 시 고아 프로세스 남는 부분 정리.

YOUTUBE 에서 Transcript 추출 및 mp3 변환 툴|로컬AI추가|깃허브

jplee — Fri, 29 May 2026 00:19:00 +0900

와이프가 만들어 달래서... 간단히 AI 사용해서 만들었습니다. 이렇게 단일 툴은 AI 로 만들기가 참 쉽긴 하네요. 약간 복잡한 게임을 개발 할 때 협업 하면서 AI 를 사용하는것과는 달리 하네스던 뭐던 큰 문제가 없긴 합니다.
https://drive.google.com/file/d/1BuxFj2t1iakIXBwMozocRlJrfrZjA5fd/view?usp=sharing

YouTubeTranscriptExtractor.exe

drive.google.com

깃허브 저장소

mazelines/YOUTUBE-SCRIPT-EXTRACT

GitHub - mazelines/YOUTUBE-SCRIPT-EXTRACT

Contribute to mazelines/YOUTUBE-SCRIPT-EXTRACT development by creating an account on GitHub.

github.com

트랜스크립트 추출 쪽은 노션에 정리 할 수 있도록 타임테이블을 제거 했고 문장 단위 마침표 처리가 되도록 했습니다.
음원 추출쪽은 aria2c 1.37 을 사용해서 멀티코넥트 처리 해서 1시간 짜리 음원 추출 시간을 좀 더 개선 했구요.
특별한 설정 없이 사용하도록 로컬 AI 모델 젬마 4 를 붙혔습니다. NVIDIA 와 인텔 그리고 AMD 지피유 모두에서 연산하도록 Vulkan GGLM 을 사용했어요. 요약 켄버스는 마크다운 프리뷰 렌더러 아니면 HTML 렌더러로 바꿔야겠어요.

뭐 일단 와이프는 만족하고 쓰고 있네요.

문장 구분 자막 추출 결과

[번역][UE5] MotionMatching에서 MotionBrick으로

jplee — Thu, 28 May 2026 23:44:12 +0900

역자의 말: 오랜 시간 렌더링과 최적화만 봐왔던 탓에 모션매칭이나 테크애니쪽으로는 아는게 별로 없는것 같습니다. 콘솔게임 개발도 많이 활성화 되가고 있고 최근에 붉은사막 플레이 영상들만 봐도 확실히 콘솔이나 AAA 급에서 눈에 띄는 것은 모션처리와 행동트리 + 상태기계 등이 중요한 것 같습니다. 그래서 이쪽으로도 좀 저도 공부 할 겸 해서 번역글 공유 해 봅니다.

저자: Asuka.W ( 테크니컬 애니메이터 )

MotionBricks에 대해 이야기할 때, 우리는 무엇을 이야기하는가

얼마 전 NVIDIA의 새로운 애니메이션 기술인 MotionBricks를 보고, 첫 반응은 '경이로움'이었습니다. 이는 현재 게임 애니메이션 시스템, 특히 로코모션(locomotion) 시스템의 장기적인 딜레마에 대해 다시 생각하게 만들었습니다.

글을 시작하기 전에, 언리얼 엔진 5(UE5)에서 테스트해 본 mujoco 버전의 MotionBrick 영상을 먼저 첨부합니다.

「UE5」MotionBrick의 UE5 초기 시도, 어떤 애니메이션 블루프린트도 필요 없음_bilibili

1. 상태 머신(State Machine)의 딜레마

우리 모두 알고 있듯이, 유한 상태 머신(FSM)으로 애니메이션 시스템을 구축할 때 초기에는 매우 효율적입니다. 빠른 검증, 상태 분리, 애니메이션 연결 등은 FSM의 강점입니다.

하지만 프로젝트가 진행됨에 따라, 상태 머신은 점차 유지보수 비용이 극도로 높은 시스템으로 변해갑니다. 새로운 상태, 트랜지션, 예외 상황, 인터럽트, 오버레이, 우선순위 등이 추가되면서 그래프는 갈수록 복잡해집니다. 이 문제의 본질은 "상태 머신이 좋지 않다"는 것이 아니라, 우리가 유한한 열거(enum) 방식으로 거의 무한하게 연속적인 운동 공간을 커버하려 한다는 데 있습니다.

그래서 후반부로 갈수록 상태 머신은 복잡해지고, 유지보수가 어려워지며, 결과물이 항상 안정적이지도 않게 됩니다. 검증 단계에는 아주 적합하지만, 시스템이 대량의 정식 콘텐츠를 감당하기 시작하면 누구나 건드리기 싫어하는 복잡한 거미줄이 되기 쉽습니다.

여기서 하나의 의문이 생깁니다. 이상적인 캐릭터 애니메이션 시스템이 과연 이렇게까지 복잡해야 할까요? 아니면, 수동 예외 처리에 의존하는 것을 최소화하고 안정적이며 일관성 있고 재사용 가능한 시스템이 되어야 할까요?

2. Motion Matching의 한계

모션 매칭(Motion Matching)은 상태 머신의 딜레마에 대한 중요한 개선책입니다.

GASP를 예로 들면, 그 애니메이션 블루프린트에는 전통적인 복잡한 상태 머신과 같은 숨막히는 구조가 없습니다. 많은 복잡성이 모션 캡처 데이터, PoseSearchDatabase, PoseSearchSchema 및 쿼리 로직으로 이전되었습니다. 이는 보다 데이터 지향적인 애니메이션 시스템입니다.

하지만 MM에 한계가 없는 것은 아닙니다.

MM의 본질은 여전히 유한한 데이터베이스 내에서 현재의 자세, 미래의 궤적, 속도, 방향, 태그, 비용(cost) 가중치 등의 조건을 바탕으로 가장 적합한 기존 애니메이션 프레임을 찾는 것입니다. 이는 새로운 동작을 "생성"하는 것이 아니라, 기존 데이터에서 현재 요구에 가장 가까운 결과를 "선택"하는 것입니다.

이는 데이터베이스의 커버리지가 부족하거나, 스키마 표현이 충분하지 않거나, 비용 가중치가 현재 컨텍스트에 맞지 않을 때 여전히 문제가 발생한다는 것을 의미합니다.

로코모션에서 매우 흔한 예를 들어보겠습니다. 축 기반 이동 시스템을 만들고 walk / run / sprint 세 가지 보행 패턴과 45도, 90도, 135도, 180도 회전 애니메이션을 준비했다고 합시다. 디버깅 시, 같은 회전 각도라도 바깥쪽 발이 디딤발일 때는 아주 자연스럽지만, 안쪽 발이 디딤발이 될 때는 튀는 현상, 발 꼬임, 원치 않는 프레임 선택이 발생하거나 아예 원하는 결과를 재생하지 못하는 경우를 쉽게 발견할 수 있습니다.

최근 화제가 된 게임 《붉은 사막》을 예로 들어보겠습니다. 자체 개발 엔진이라는 점 외에도 이는 완벽한 예시를 보여줍니다. 세 가지 보행 패턴, 축 기반 MM 환경에서 어떤 모습을 보여주는지 살펴보죠.

먼저 바깥쪽 발을 디딤발로 삼아 90도 회전하는 애니메이션입니다.

애니메이션이 매끄럽고 자연스러운 것을 볼 수 있습니다.

빨간색 상자는 회전 시의 디딤발, 파란색 화살표는 박차고 나가는 발입니다.

그렇다면 안쪽 발로 90도 회전을 할 때는 어떨까요?

이제 디딤발과 박차고 나가는 발이 같은 발이 되었습니다.

눈에 띄게 튀거나 발이 꼬이는 현상을 볼 수 있습니다.

이것은 제가 예전에 상용 게임에서 겪었던 거의 똑같은 문제가 구체적으로 나타난 것입니다. 당시 저는 Transition이라는 스키마의 파라미터를 어떤 상황에서든 봐줄 만한 수준으로 맞추려 했으나, 결국 파라미터 조절에 엄청난 시간만 낭비하고 좋은 결과를 얻지 못했습니다.

이것은 단순히 파라미터 하나를 조절한다고 반드시 해결할 수 있는 문제가 아닙니다. "좌회전 90도"라는 것은 단일 상태가 아니며, 현재의 보행 패턴, 속도, 가속도, 몸의 방향, 발의 위상(phase), 디딤발, 현재 포즈(pose), 미래 궤적 등 일련의 컨텍스트를 포함하기 때문입니다. MM의 경우, 이 모든 정보가 결국 쿼리 스키마와 비용(cost) 안에 압축되어야 합니다.

물론, MM은 이런 문제들을 완화할 수 있는 많은 방법을 제공합니다. 더 풍부한 데이터, 더 세밀한 특징(feature), 더 나은 발 접촉/위상 특징, 태그(tags), 다중 데이터베이스, chooser, 모션 워핑(motion warping), inertialization 등입니다.

하지만 이러한 해결책들의 대가는 시스템의 복잡성이 다시 데이터 구성, 파라미터 튜닝, 규칙 유지보수 및 엣지 케이스 처리로 되돌아간다는 것입니다.

그래서 저는 MM의 한계가 "MM이 좋지 않다"가 아니라, 상태 머신 시대의 그래프 복잡성을 데이터베이스 커버리지와 쿼리 파라미터 튜닝의 복잡성으로 치환한 것이라고 생각합니다.

이는 여전히 현재로서 매우 신뢰할 수 있고, 제어 가능하며, 디버깅하기 쉬운 솔루션이지만, 로코모션의 종착지는 아닙니다.

3. 로코모션은 왜 이렇게 어려운가

로코모션은 가장 기초적인 것처럼 보이지만, 사실 잘 만들기 가장 어려운 부분 중 하나입니다.

입력에 반응하면서도 신체 움직임의 자연스러움을 유지해야 하고, 민첩해야 하지만 튀지 않아야 하며, 플레이어의 제어에 부합하면서도 발의 위상, 몸의 관성, 무게 중심의 이동, 그리고 운동의 리듬과 맞아떨어져야 하기 때문입니다.

캐릭터를 더 생동감 있게 만드는 핵심은 더 풍부하고 연속적인 움직임의 변화에 있습니다. 기본 이동으로 분해해 보면, 이는 더 섬세한 보행 패턴의 변화, 위상의 변화, 속도의 변화, 방향의 변화, 그리고 신체 협응의 변화입니다.

전통적인 애니메이션 시스템은 주로 상태와 규칙을 통해 이러한 변화를 묘사합니다. 반면 MM은 데이터베이스와 특징(feature) 쿼리를 통해 이를 묘사합니다. 이 둘은 사실 같은 질문에 답하려 하고 있습니다.

"현재 이 캐릭터는, 이 운동 컨텍스트에서 다음 프레임에 어떤 모습이어야 하는가?"

차이점이라면, 상태 머신은 수동적인 열거를 통해 답하고, MM은 데이터 쿼리를 통해 답한다는 것뿐입니다.

그리고 신경망 기반 모션 시스템(neural motion system)은 또 다른 형태의 답을 시도하기 시작했습니다. 방대한 데이터에서 운동 법칙을 학습한 뒤, 제어 조건에 따라 결과를 생성하는 것입니다.

4. PFNN에서 DeepPhase까지: 운동 표상 학습하기

Neural animation은 갑자기 나타난 것이 아닙니다.

PFNN은 매우 중요한 기점입니다. 그 의의는 일찍이 로코모션을 "상태 전환"에서 "조건부 생성"의 영역으로 밀어붙였다는 점입니다. 미래 궤적, 속도, 보행 패턴, 지형 등의 제어 신호를 입력하면, 네트워크가 다음 자세를 예측합니다.

이는 neural animation이 단순한 오프라인 생성 도구가 아니라 실시간 캐릭터 제어에도 서비스될 수 있음을 보여줍니다.

하지만 PFNN은 여전히 '위상(phase)'이라는 매우 중요한 수동 설계 개념에 의존합니다.

위상은 중요합니다. 왜냐하면 로코모션은 본질적으로 주기성을 띠기 때문입니다. 걷기, 뛰기, 돌기, 멈추기는 고립된 동작이 아니라, 신체 리듬과 발 위상의 연속적인 변화의 결과입니다.

문제는 전통적인 위상이 대개 인위적으로 정의된다는 것입니다. 단순한 걷기와 뛰기 정도라면 괜찮지만, 움직임이 복잡해지고 특히 다양한 보행 패턴, 방향 변화, 스타일 변화, 비주기적 동작이 더해지면 단일 위상만으로는 전체 운동 상태를 묘사하기 어려워집니다.

DeepPhase의 의의가 바로 여기에 있습니다.

그것은 단순히 "우리가 MM을 대체하겠다"고 말하는 것이 아니라, 로코모션의 많은 핵심 변수들이 수동으로 열거하기에 적합하지 않다는 것을 설명합니다. 보행 위상, 리듬, 신체 협응 관계는 본질적으로 연속적이고 다채널(multi-channel)입니다. 수동으로 고정된 위상을 설계하는 것보다, 데이터에서 쿼리, 매칭 및 생성에 더 적합한 위상 매니폴드(phase manifold)를 학습하는 것이 낫습니다.

이 맥락은 매우 중요합니다.

애니메이션 시스템의 진화가 단순히 FSM에서 MM으로, 혹은 MM에서 neural로 넘어가는 것이 아니라, 인공적인 규칙에서 점차 학습 기반의 표상(representation)으로 나아가고 있음을 보여주기 때문입니다.

5. Control Operators: 제어 인터페이스의 변화

주목할 만한 또 다른 방향은 Control Operators, 혹은 좀 더 넓은 의미에서의 구조화된 제어 인터페이스입니다.

기저(bottom-level)가 MM이든 neural motion system이든, 상위 레벨에서는 사실 동일한 질문에 답해야 합니다. "캐릭터에게 무엇을 시킬 것인가?"를 어떻게 표현할 것인가?

전통적인 상태 머신에서 이 의도는 보통 상태(state)와 조건(condition)으로 분해됩니다.

MM에서 이 의도는 보통 trajectory, tags, query features, cost로 변환됩니다.

Neural system에서 이 의도는 tensor, keyframes, latent condition, 또는 policy input이 될 수 있습니다.

Control Operators나 Smart Primitives의 가치는 그것들이 애니메이션을 직접 생성하는 데 있는 것이 아니라, 목표, 제약 조건, 스타일, 상호작용 의도를 구조화된 제어 신호로 변환한다는 점에 있습니다.

예를 들어:

캐릭터가 어디로 이동해야 하는가.

어느 방향을 바라봐야 하는가.

어떤 속도를 유지해야 하는가.

어떤 스타일을 사용해야 하는가.

어떤 물체와 상호작용해야 하는가.

어느 손이나 발이 어느 목표 지점에 도달해야 하는가.

이 목표가 강한 제약(hard constraint)인가 부드러운 유도(soft guide)인가.

MM의 관점에서 볼 때, 이러한 제어 정보는 trajectory, tags, query weights 또는 추가적인 특징으로 컴파일될 수 있습니다.

Neural motion system의 관점에서는 생성 과정에 조건부 입력으로 직접 참여할 수 있습니다.

따라서 Control Operators는 통일된 제어 언어의 계층에 더 가깝습니다. 그것은 MM의 핵심 알고리즘도, neural의 완벽한 정답도 아니지만, MM과 neural이 공유하는 상위 인터페이스로 아주 적합합니다.

제가 Control Operators와 MotionBricks의 Smart Primitives 사이에 깊은 연관성이 있다고 느끼는 이유가 바로 이것입니다. 진정한 트렌드는 단순히 "애니메이션 노드를 교체하는 것"이 아니라, 제어 의도가 점차 구조화되고, 데이터화되며, 조합 가능해지는 것에 있습니다.

6. 쿼리 생성 vs 잠재 생성(Latent Generation)

이 점이 바로 MotionBricks가 제 흥미를 끄는 이유입니다.

전통적인 Motion Matching은 "쿼리 생성(Query Generation)"에 더 가깝습니다:

시스템이 데이터베이스에서 현재 요구사항에 가장 가까운 애니메이션 클립을 찾습니다.

MotionBricks는 "잠재 공간 생성(Latent Space Generation)"에 더 가깝습니다:

시스템이 대규모 모션 데이터로부터 연속적인 운동 표현을 먼저 학습한 후, 컨텍스트, 목표 키프레임 및 제어 조건에 따라 다음 움직임을 생성합니다.

거칠게 비유하자면 다음과 같습니다:

Motion Matching은 도서관에서 가장 적합한 페이지를 찾는 것과 같습니다.

MotionBricks는 수많은 책을 읽은 뒤 현재의 요구에 맞게 새로운 내용을 써 내려가는 것과 같습니다.

물론, 이 비유를 MotionBricks가 무에서 유를 창조한다고 오해해서는 안 됩니다. 이 역시 대규모 모션 데이터에 의존합니다. 진짜 차이는 MM은 런타임에 데이터베이스를 조회하는 반면, MotionBricks는 훈련을 통해 운동 규칙을 잠재 모델(latent model)에 압축해 두고 런타임에 제약 조건에 맞춰 생성한다는 점입니다.

이는 한 가지 핵심적인 변화를 가져옵니다. 시스템이 더 이상 "이미 존재하는 특정 프레임"만을 선택해야 하는 것이 아니라, 연속적인 공간에서 현재의 컨텍스트에 더 부합하는 움직임을 생성할 기회를 얻게 된다는 것입니다.

MotionBricks 논문의 벤치마크에 따르면, in-betweening 작업에서 15,000 FPS, 2ms 지연 속도를 달성했으며, target reaching success 등의 지표에서도 여러 생성형 베이스라인(baseline)을 눈에 띄게 능가했습니다. 이 결과를 "MotionBricks가 이미 Motion Matching을 전면적으로 대체했다"고 단순 해석해서는 안 됩니다. 벤치마크 환경과 실제 프로덕션 환경은 다르기 때문입니다. 하지만 적어도 과거에 우리가 neural animation에 대해 가졌던 핵심적인 우려, 즉 실시간성(real-time latency) 문제가 뚜렷하게 약화되고 있음을 보여줍니다.

7. MotionBricks의 세 가지 역할

MotionBricks는 크게 세 가지 핵심 부분으로 나눌 수 있습니다.

첫째는 Tokenizer입니다.

복잡한 스켈레톤 애니메이션을 더 컴팩트한 잠재 토큰(latent token)으로 압축합니다. 원본 스켈레톤 데이터는 차원이 너무 높아 직접 처리하는 데 큰 비용이 듭니다. 압축된 토큰은 모델이 학습하고 생성하기에 더 적합합니다.

둘째는 Pose Module입니다.

이 토큰들 이면에 있는 운동 법칙을 학습합니다. 단순히 각 프레임을 기억하는 것이 아니라, 다양한 컨텍스트, 목표, 제약 조건 하에서 합리적인 움직임이 어떻게 진화해야 하는지를 배웁니다.

셋째는 Decoder입니다.

잠재 토큰과 제어 조건을 다시 구체적인 스켈레톤 자세로 복원하여 연속적인 애니메이션을 생성합니다.

Motion Matching이 "데이터베이스에서 한 구간을 선택하는 것"이라면, MotionBricks는 "운동 분포(motion distribution)에서 한 구간을 생성하는 것"에 더 가깝습니다.

이것이 바로 전통적인 MM과의 가장 본질적인 차이점입니다.

8. 기술 진화의 맥락

이러한 여러 기술의 갈래를 한데 모아보면 대략 다음과 같이 이해할 수 있습니다:

기술	핵심 사상	해결한 문제	여전히 남은 문제
FSM	상태와 전환의 수동 열거	빠른 검증, 명확한 로직	상태 폭발, 유지보수의 어려움
Motion Matching	데이터베이스에서 최적 프레임 조회	상태 그래프의 복잡도 감소, 자연스러운 결과	데이터 커버리지 및 쿼리/비용 파라미터 튜닝에 의존
PFNN	궤적, 보행 패턴, 지형 등의 조건에 따른 동작 예측	neural locomotion의 실시간 제어 가능성 입증	표현력 및 확장성의 한계
DeepPhase	데이터에서 연속적인 위상(phase) 표현 학습	위상, 리듬, 매칭 및 생성 표현의 개선	표상 계층에 치우쳐 있어 완전한 프로덕션 시스템이 아님
Control Operators	제어 의도의 구조화	상위 레벨 제어 언어의 통일	구체적인 백엔드 실행 시스템 필요
MotionBricks	잠재 생성 모델 + smart primitives	대규모 생성, 제약, 상호작용의 통합	툴체인, 디버깅, 훈련 및 프로덕션 검증 등 성숙도 문제

따라서 이 기술 진화는 단순히 "누가 누구를 대체하느냐"의 문제가 아닙니다.

FSM은 사라지지 않았습니다.

MM 역시 당장 사라지지 않을 것입니다.

PFNN, DeepPhase, Control Operators, MotionBricks는 각기 다른 측면에서 애니메이션 시스템의 변화를 주도하고 있는 것에 가깝습니다.

진정한 트렌드는, 운동 시스템이 갈수록 데이터화되고, 연속화되며, 조건화된다는 것입니다.

상태 머신은 수동 열거입니다.

MM은 데이터 조회입니다.

PFNN은 조건 예측입니다.

DeepPhase는 운동 표상의 학습입니다.

Control Operators는 구조화된 제어 의도입니다.

MotionBricks는 대규모 잠재 운동 공간에서 제약 조건에 따라 움직임을 생성하는 것입니다.

이들은 모두 '캐릭터 애니메이션'이라는 거대한 동일한 문제의 각기 다른 부분들을 해결하고 있습니다.

9. MotionBricks의 의의

제가 생각하는 MotionBricks의 진정한 중요성은 "또 하나의 신경망 애니메이션 솔루션이 나왔다"는 점에 그치지 않고, 과거에 흩어져 있던 몇 가지 문제들을 하나로 통합하려 한다는 데 있습니다:

기본 이동

스타일 전환

목표 지점 도달

사물과의 상호작용

키프레임 제약

런타임 경로 재계획

이전에는 이를 완성하기 위해 상태 머신, 애니메이션 블루프린트, Motion Matching, Motion Warping, IK, 상호작용 포인트, 각종 규칙들이 함께 맞물려 작동해야 했습니다. 반면 MotionBricks는 하나의 통합된 neural backbone과 smart primitives를 사용해 이를 처리하고자 합니다.

이것이 제가 그 이름(MotionBricks)이 참 잘 지어졌다고 생각하는 이유이기도 합니다.

캐릭터의 기본 이동은 원래 벽돌(brick)처럼 안정적이어야 합니다. 언제나 복잡한 거미줄처럼 얽혀 있는 것이 아니라, 재사용 가능하고, 조합할 수 있으며, 대체 가능한 기반 모듈이어야 합니다.

물론, 이는 MotionBricks가 당장 기존의 모든 애니메이션 시스템을 대체할 수 있다는 의미는 아닙니다. 프로덕션 툴체인, 디버깅의 투명성, 훈련 비용, 데이터 준비, 리타기팅(retargeting), 기획자의 통제 가능성 등 여전히 많은 과제가 남아있습니다. 하지만 이 기술은 매우 명확한 방향을 제시합니다. 미래의 애니메이션 시스템의 복잡성은 "상태 그래프와 수동 파라미터 튜닝"에서 "데이터, 모델, 제어 인터페이스, 그리고 검증 도구" 쪽으로 이동할 가능성이 큽니다.

10. 결점 감추기(藏拙)의 시대는 끝날 것인가?

예전에 누군가 게임 개발의 비결 중 상당 부분은 "결점을 잘 감추는 것(藏拙)"에 있다고 말한 적이 있습니다. 저 역시 깊이 동의합니다.

많은 경우, 게임은 모든 것을 완벽하게 해내는 것이 아니라 어디를 드러내고 어디를 가려야 할지 아는 것입니다. 로코모션 역시 마찬가지입니다. 아주 기초적인 것처럼 보이지만 실제로 잘 구현하기란 매우 어렵습니다. 대부분의 플레이어는 "여기서 회전할 때 디딤발이 틀렸어"라고 명확히 지적하지 않습니다. 그저 캐릭터가 부자연스럽고, 부드럽지 못하며, 퀄리티가 낮다고 느낄 뿐입니다.

과거에 이러한 문제들이 오랫동안 근본적으로 해결되지 못했던 것은 개발자들이 이를 몰라서가 아니라, 해결 비용이 너무 높았기 때문입니다.

기본 이동을 잘 만들기 위해서는 애니메이터, 프로그래머, TA, 기획자가 끊임없이 디버깅해야 하고 엄청난 양의 엣지 케이스를 커버해야 합니다. 많은 프로젝트가 결국 이를 가리거나, 우회하거나, 어느 정도의 부자연스러움을 수용하는 쪽을 선택할 수밖에 없었습니다.

하지만 AI와 신경망 기반 모션 시스템의 등장은 이 상황을 바꿀지도 모릅니다.

기본 이동, 스타일 전환, 상호작용 트랜지션 같은 기저의 문제들이 더 안정적이고 자동화된다면, 개발자들은 진짜 차별화되는 요소들에 더 많은 에너지를 쏟을 수 있게 됩니다.

슈팅 게임이라면 애니메이션 TA가 총기 조작과 1인칭 표현에 더 집중할 수 있습니다.

액션 게임이라면 팀이 피격, 처형, 적의 반응, 전투 피드백에 더 몰두할 수 있습니다.

오픈 월드 게임이라면 수많은 로코모션 엣지 케이스에서 오는 유지보수 비용을 크게 줄일 수 있습니다.

그래서 저는 MotionBricks의 의의가 "MM은 죽었다"가 아니라고 생각합니다. 오히려 그것은 우리에게 기본 애니메이션 시스템이 마침내 장기간 결점을 감춰야 했던 복잡한 엔지니어링에서 벗어나, 훨씬 더 견고하고 재사용 가능하며 인프라에 가까운 무언가로 변모할 기회를 얻었음을 보여줍니다.

단기적으로는 MM이 여전히 가장 안정적이고, 통제 가능하며, 도입하기 쉬운 로코모션의 베이스라인이 될 것입니다.

중기적으로는 MM과 neural motion system이 오랫동안 공존할 가능성이 높습니다.

장기적으로 보았을 때 진정 중요한 것은 우리가 MM을 택하느냐 MotionBricks를 택하느냐가 아니라, 단일한 캐릭터 운동 시스템에 여러 백엔드가 서비스될 수 있도록 '통일된 제어 인터페이스'를 구축할 수 있느냐일 것입니다.

결점을 감추던 시대가 당장 끝나는 것은 아닐지도 모릅니다.

원문

https://zhuanlan.zhihu.com/p/2033641452836745984?share_code=T7B8tVt6gv0N&utm_psn=2041814874976695569

[DEVOPS] TEAMCITY Agent Monitor 입니다.

jplee — Thu, 28 May 2026 01:50:20 +0900

고객사 스튜디오 내 스크린에 띄울려고 만들었습니다.
빌드 된 버전을 공유 합니다.
https://drive.google.com/file/d/1C08mn-xswMhGyFtVzWtgUlyTwi9h1K0A/view?usp=sharing

TeamCity Monitor-1.0.0-setup.exe

drive.google.com

중국 게임회사는 거의 공통적으로 각 부서마다 이런 모니터링 툴을 사용합니다. 예로 들어 QA 팀 공간에 가면 QA 이슈 모니터링 스크린이 있습니다. 비즈니스 유닛에 가면 ROI 나 DAU 같은 뭐 그런 정보를 실시간으로 차팅 해 주고 분석 해서 보여주는 모니터링 스크린이 있구요.
엔진팀이나 클라팀에는 또 각 유닛에 맞는 모니터링 스크린을 대형 스크린에 띄우거나 벽에 55인치 모니터 여러대를 걸어놓곤 합니다.
2011년 광저우에 있는 중국 2대 텔레콤 회사 남방 IDC 센터 에 출장 갔을 때도 봤던 건데요. 게임회사가 아닌 IT 회사들도 비슷했습니다.
이 다음으로는 센트리 모니터링 툴을 만들어야겠네요.

창을 내리면 이렇게 트레이 위에 위젯으로 작게 보여줍니다.

[GITHUB] MARTINI/RTIN 유니티 구현 공유

jplee — Thu, 28 May 2026 00:21:56 +0900

유니티 6.4 에서 작업 했습니다.

저장소 라이센스는 MIT 라서 마음대로 변형 및 사용하셔도 됩니다.

원래 월드파티션 유니티 라는 솔루션 개발하고 있었는데 일부만 때어냈어요.

고객사 요청으로 유니티로 개발하던 MMO 프로젝트가 UE5 로 완전히 바뀌게 되었네요. ( 솔직히 좋네요. )

유니티 엔진으로 MMORPG 를 만드는건 고난의 길이고 저 혼자 렌더링과 툴 대부분을 다 커버 해야 했는데... 그래서 잠을 잘 못자는 환경에 놓여있었습니다. 그래도 중간 중간 포스팅 그니까 주로 번역글을 올리면서 근 1년을 보냈네요. 앞으로는 플러그인 구현등 제 아이디어 기반으로 만든것들에 대한 글도 좀 써 볼 생각입니다.

깃허브

Techartflowio/MARTINI-RTIN-UNITY

GitHub - Techartflowio/MARTINI-RTIN-UNITY

Contribute to Techartflowio/MARTINI-RTIN-UNITY development by creating an account on GitHub.

github.com

MARTINI/RTIN 에 관한 엮인 글은 아래...

MARTINI/RTIN 알고리즘 이해

역자의 말: 이 문서는 지형 렌더링 최적화를 위해 널리 사용되는 MARTINI 및 RTIN(Right-Triangulated Irregular Networks) 알고리즘의 핵심 원리를 다루고 있습니다. 이 알고리즘은 고해상도 하이트맵(Heightmap)

techartnomad.tistory.com

[번역][FAB] VBAO – Visibility Bitmask Ambient Occlusion

jplee — Wed, 27 May 2026 23:00:43 +0900

저자: troupfonel@gmail.com

개요

VBAO는 언리얼 엔진 5용 고성능 앰비언트 오클루전(Ambient Occlusion) 플러그인입니다. 이 플러그인은 기존 GTAO의 발전되고 현대화된 대안 역할을 하는 가시성 비트마스크(Visibility Bitmask) 알고리즘을 기반으로 합니다.

작동 원리

다음 연구 논문을 기반으로 합니다: https://arxiv.org/abs/2301.11376

어떤 지점이 가려져 있는지(occluded) 판단하기 위해 기존의 레이 마칭(ray marching)을 사용하는 대신, 가시성 비트마스크 알고리즘은 표면 위 반구(hemisphere)를 불연속적인 각도 섹터로 나눕니다. 주변 지오메트리를 샘플링하면서 특정 방향이 물체에 의해 막혀 있는지 여부를 나타내기 위해 비트마스크에 "비트(bits)"를 설정합니다.

이 비트마스크를 분석하여 알고리즘은 앰비언트 라이트가 얼마나 차단되었는지 빠르게 계산할 수 있습니다. 이 접근 방식은 기존 SSAO/GTAO 기법과 관련된 일반적인 시각적 아티팩트를 방지하고, 우수한 다중 레이어 오클루전을 제공하며, 매우 효율적인 시간적(temporal) 노이즈 감소를 가능하게 합니다. 그 결과 더 풍부하고 물리적으로 그럴싸한 셰이딩 효과를 얻을 수 있습니다.

시작하기

콘솔 명령어를 사용하여 기본 AO를 비활성화합니다: r.AmbientOcclusionLevels 0 r.Lumen.ScreenProbeGather.ShortRangeAO 0
플러그인 설정에서 VBAO 플러그인을 활성화합니다.
콘솔 명령어 r.VBAO.Enabled 1을 사용하여 효과가 켜져 있는지 확인합니다.

최상의 결과를 얻으려면 TAA 또는 TSR 안티앨리어싱을 사용하세요. r.AntiAliasingMethod 2 시간적 누적(Temporal accumulation)은 AO 노이즈를 줄이고 프레임 간에 효과를 안정화하는 데 도움이 됩니다. Temporal AA가 없으면 특히 낮은 퀄리티 설정에서 AO가 눈에 띄게 노이즈가 많아 보일 수 있습니다.

파라미터

아래는 플러그인에서 제공하는 주요 파라미터입니다.

퀄리티 (Quality)

r.VBAO.Quality

기본값: 2

앰비언트 오클루전의 전반적인 퀄리티 프리셋을 제어합니다. 값이 높을수록 더 많은 샘플을 채취하여 더 부드럽고 정확한 결과를 생성하지만 성능 비용이 증가합니다.

Quality: 1

성능 ≈ 0.4ms 1080p / RTX 2060

Quality: 2

성능 ≈ 0.6ms 1080p / RTX 2060

Quality: 3

성능 ≈ 0.8ms 1080p / RTX 2060

Quality: 4

성능 ≈ 1.6ms 1080p / RTX 2060

강도 (Intensity)

r.VBAO.Intensity

기본값: 0.5

앰비언트 오클루전의 전반적인 어둡기 효과를 곱합니다. 더 강하고 어두운 그림자를 원하면 이 값을 늘리고, 더 미묘하고 자연스러운 느낌을 원하면 값을 줄이세요.

Intensity: 0.5

Intensity: 1.5

반경 (Radius)

r.VBAO.Radius

기본값: 73.0

오클루전 샘플이 도달할 수 있는 최대 월드 공간 거리를 제어합니다. 반경이 크면 큰 구조물이 먼 표면에 오클루전을 드리울 수 있고, 반경이 작으면 좁은 모서리와 작은 디테일에 오클루전이 제한됩니다.

Radius: 10.0

Radius: 73.0

패스 트레이싱(Path Traced) AO와 일치하도록 최적화되었습니다. 이 값을 변경하면 물리적 정확도가 떨어질 수 있습니다.

두께 (Thickness)

r.VBAO.Thickness

기본값: 30.0

뒤쪽의 오클루전을 처리하기 위해 뎁스 버퍼에서 오브젝트의 가정된 두께를 나타냅니다. 얇은 벽이나 표면을 통해 앰비언트 오클루전이 잘못 "새는(leaking)" 현상이 발견되면 이 값을 조정하세요.

Thickness: 30.0

Thickness: 300.0

패스 트레이싱(Path Traced) AO와 일치하도록 최적화되었습니다. 이 값을 변경하면 물리적 정확도가 떨어질 수 있습니다.

멀티 바운스 (Multi Bounce)

r.VBAO.MultiBounce

기본값: 1

표면의 알베도(albedo)를 고려하여 틈새 내부의 빛 반사(bouncing)를 근사화합니다. 이는 오클루전 그림자가 부자연스럽게 검게 보이는 것을 방지하고 색상이 있는 환경과 유기적으로 섞이도록 돕습니다.

MultiBounce: 0

MultiBounce: 1

템포럴 지터 (Temporal Jitter)

r.VBAO.TemporalJitter

기본값: 1

프레임 전반에 걸쳐 템포럴 지터링을 활성화합니다. 엔진의 안티앨리어싱(TAA/TSR)과 결합할 경우, 많은 비용이 드는 공간 샘플(spatial samples) 수 없이도 노이즈를 크게 줄이고 오클루전 효과를 안정화합니다.

TemporalJitter: 0

TemporalJitter: 1

포그 감쇠 (Fog Attenuation)

r.VBAO.Fog

기본값: 0.0

이 명령어는 씬의 포그와 상호 작용할 때 앰비언트 오클루전이 페이드 아웃되는 방식을 제어합니다. 거리나 대기에 의해 가려질 때 음영 처리된 영역이 부자연스럽게 어둡거나 "단절되어" 보이지 않도록 합니다.

값 (Value)	모드 (Mode)	설명 (Description)
0	자동 (Auto)	플러그인이 현재 포그 설정에 따라 동적으로 AO의 균형을 맞춥니다.
>0	수동 (Manual)	직접적인 강도 승수 역할을 합니다. 이 값을 사용하여 시스템을 오버라이드하고 특정 예술적 룩을 위해 AO가 포그를 얼마나 뚫고 보여야 하는지 수동으로 조정할 수 있습니다.

Fog Attenuation: 0.0

Fog Attenuation: 1.0

출력 모드 (Output Mode)

r.VBAO.OutputMode

기본값: 0

오클루전 효과가 렌더링되고 씬에 통합되는 방식을 결정합니다.

값 (Value)	모드 (Mode)	설명 (Description)
0	커스텀 합성 (Custom Composite)	표준 엔진 파이프라인에서 완전히 분리되어 모든 곳에 AO를 적용합니다. 네이티브 UE5 AO 합성은 조명과 강하게 연결되어 있어 밝은 영역에서는 종종 페이드 아웃됩니다. 이 모드는 AO를 강력하고 눈에 띄게 유지합니다. 커스텀 컴포지터를 사용하기 때문에 가끔 아티팩트가 발생할 수 있습니다. 포그 감쇠(Fog Attenuation)와 같은 기능은 이를 관리하는 데 도움을 주기 위해 존재합니다.
1	네이티브 SSAO 버퍼 (Native SSAO Buffer)	엔진의 표준 ScreenSpaceAO 버퍼에 직접 기록합니다. 커스텀 합성 아티팩트를 완전히 피하고 AO가 표준 UE5 조명 규칙을 따르도록 하려면 이 모드를 사용하세요.

Output Mode: 0

Output Mode: 1

커스텀 컴포지터를 우회하면 포그 감쇠(Fog Attenuation), 멀티 바운스(Multi Bounce) 및 디버그 모드가 비활성화된다는 점에 유의하세요.

FAB

VBAO - Visibility Bitmask Ambient Occlusion

| DOCUMENTATION |VBAO is a modernized evolution of GTAO. It provides a massive upgrade in visual quality while maintaining equivalent performance to GTAO.The bitmask algorithm calculates actual object thickness at native resolution to deliver sharp contact

www.fab.com

원문

VBAO Docs | VBAO

ark-kra.gitbook.io

언리얼 포럼

ARK.KRA - VBAO - Visibility Bitmask Ambient Occlusion - Distribution / Product Discussion - Epic Developer Community Forums

ARK.KRA - VBAO - Visibility Bitmask Ambient Occlusion

| DOCUMENTATION | VBAO is a modernized and highly optimized evolution of GTAO, It provides a massive upgrade in visual quality without the usual performance drop. The standard Unreal Engine 5 GTAO takes about 3ms at 1080p, VBAO drops this cost to just 0.6m

forums.unrealengine.com

Shader Toy

https://www.shadertoy.com/view/3clGWB

OCIO 별 룩 비교 ( 올드 스쿨 )

jplee — Tue, 26 May 2026 19:00:43 +0900

2019년 쯤 사내 피피티 때문에 만든 이미지. 구글 포토에서 다른 사진 찾다가 앨범에서 찾은 이미지.

테크아트 부서가 분리되어 있었지만 주로 아트팀 서포트 비중이 많았던 때에는 이런 일도 참 많이 했던 기억이... 새록 새록 합니다.

MARTINI/RTIN 알고리즘 이해

jplee — Tue, 26 May 2026 16:48:04 +0900

MARTINI/RTIN 알고리즘 구조

역자의 말: 이 문서는 지형 렌더링 최적화를 위해 널리 사용되는 MARTINI 및 RTIN(Right-Triangulated Irregular Networks) 알고리즘의 핵심 원리를 다루고 있습니다. 이 알고리즘은 고해상도 하이트맵(Heightmap) 데이터를 기반으로 지형의 굴곡이 심한 곳은 작은 직각 삼각형으로 재귀적으로 분할하여 디테일을 살리고, 평탄한 곳은 큰 삼각형으로 유지하여 전체적인 폴리곤 수를 획기적으로 줄이는 동적 레벨 오브 디테일(LOD) 기법입니다. 실시간 그래픽스 및 모바일 환경에서 지형 렌더링 성능을 극대화하는 데 매우 유용한 방식이므로, 게임 엔진이나 렌더링 파이프라인에 적용하기 전 해당 알고리즘의 계층적 분할 구조를 직관적으로 이해하는 데 도움이 되길 바랍니다.

1. 시작하며: 왜 지형을 최적화해야 할까요?

먼저 2019년 중국 거인 네트워크에서 오픈월드 게임을 개발할 때 작업 했던 흔적들을 봅시다. 중국 회사들은 대부분 연말 실적 브리핑을 해야합니다. 그때 작성 했던 예전 PPT 문서의 일부입니다.

지형(Terrain)을 렌더링할 때 가장 무식하고(?) 단순한 방법은 모든 면을 똑같은 크기의 촘촘한 삼각형 덩어리(균일 그리드)로 만드는 것입니다. 하지만 이렇게 하면 아무것도 없는 밋밋한 평지에도 불필요하게 많은 폴리곤이 들어가게 됩니다. 반대로 폴리곤을 극단적으로 줄이려고 마음대로 점을 찍어서 연결하면, 지형의 품질은 좋겠지만 연산이 너무 느려지고 지형 덩어리끼리 이어붙일 때 틈새가 벌어지기 십상입니다.

2019년 당시에는 모바일 게임에서 터레인 자체를 사용하기에는 부담스러웠던 시절이기에 대부분의 회사들이 메시 터레인으로 변환 하여 사용해 왔습니다. 터레인의 픽셀애러를 10 이상으로 설정 할 경우 드로우콜 방어는 되지만 실루엣이 처참하게 뭉개져버리기 때문에 아트팀에서 인가 할 수 없는 상황이기도 했습니다.

이 두 가지 문제점을 완벽하게 해결해 주는 마법 같은 방법이 바로 RTIN(Right-Triangulated Irregular Network), 그리고 이를 더 쉽게 쓸 수 있게 만든 MARTINI 알고리즘입니다.

처음 적용을 했기 때문에 레퍼런스로 Polygon Cruncher SDK 를 참조 하여 유니티 플러그인인 Terrain2Mesh 를 수정했습니다. 이후 신동네트워크에서도 동일하게 작업 됬습니다.

2. 핵심 원리: '수직 에러'란 무엇일까?

이 알고리즘의 목표는 아주 단순합니다. "울퉁불퉁한 곳엔 폴리곤을 많이, 평평한 곳엔 폴리곤을 적게 쓰자!" 입니다.

그렇다면 컴퓨터는 어디가 울퉁불퉁한지 어떻게 알 수 있을까요? 여기서 '수직 에러(Vertical Error)'라는 개념이 등장합니다.

수직 에러의 개념

위 이미지를 보면 이해가 쉽습니다.

원래의 울퉁불퉁한 땅(초록색 선)을 크고 단순한 폴리곤(파란색 선)으로 덮었다고 상상해 보세요. 이때, 가짜 폴리곤과 실제 땅 높이의 차이를 '수직 에러'라고 부릅니다.

평지: 크고 단순한 폴리곤으로 덮어도 실제 땅과의 높이 차이가 거의 없습니다. (에러가 작음 → 큰 삼각형 유지)
절벽, 산맥: 큰 폴리곤으로 덮으면 실제 땅과의 높이 차이가 큽니다. (에러가 큼 → 더 작은 삼각형으로 쪼갬)

보충 설명: 삼각형은 어떻게 쪼개질까?

항상 직각 이등변 삼각형의 '가장 긴 변(빗변)'의 가운데를 쪼개는 방식으로 반씩 줄여나갑니다. 아래 이미지를 보시면 정사각형이 어떻게 잘게 쪼개져 나가는지 직관적으로 이해하실 수 있습니다.

RTIN 알고리즘의 격자 분할 과정 (Level 0 ~ Level 2)

3. 골치 아픈 '틈새(T-Junction)' 문제 해결

아티스트 분들이 지형 최적화(LOD) 툴을 쓰다 보면 가장 스트레스 받는 문제 중 하나가 바로 메쉬가 찢어지는 현상, 즉 'T-Junction'에 의한 크랙(Crack)입니다. 디테일이 높은 영역과 낮은 영역이 만나는 경계선에서 정점(Vertex)의 개수가 맞지 않아 빈 공간이 뻥 뚫려 보이는 현상이죠.

T-Junction과 RTIN 메쉬 비교

하지만 RTIN 알고리즘은 "무조건 가장 긴 변(빗변)의 가운데를 반으로 가른다"는 단순한 수학적 규칙을 가지고 있습니다. 이 규칙 덕분에, 옆에 있는 삼각형이 쪼개지든 말든 모서리가 딱 들어맞게 됩니다. 즉, 아티스트가 후처리로 경계선을 바느질하듯 꿰매거나 가려줄 필요 없이 태생적으로 틈새(Crack)가 생기지 않는 엄청난 장점을 가집니다.

4. 알고리즘은 어떻게 작동하나요? (2단계 과정)

프로그래머들이 이 알고리즘을 좋아하는 이유는 코드가 아주 깔끔하게 두 단계로 나뉘기 때문입니다.

지형 파악하기 (Phase 1): 처음 한 번만 맵 전체를 훑어보면서 "여기는 평지니까 에러 0, 여기는 절벽이니까 에러 100" 이런 식으로 에러 지도를 만듭니다.
카메라 거리에 맞춰 메쉬 뽑아내기 (Phase 2): 유저의 카메라가 산에 가까워지면 허용하는 에러 수치를 낮춰서 폴리곤을 잘게 쪼개고, 멀어지면 에러 수치를 높여서 큼직한 폴리곤으로 렌더링합니다. 이미 1단계에서 지도를 다 만들어 뒀기 때문에 2단계는 순식간에 끝납니다.

5. 아티스트와 테크니컬 아티스트(TA)가 알아두면 좋은 점

텍스처 해상도 맞추기: 이 알고리즘은 256, 512, 1024 같은 짝수 해상도보다, 끝자리가 1로 끝나는 해상도(257, 513, 1025)를 좋아합니다. 짝수로 떨어지면 반으로 계속 쪼개다 보면 픽셀이 어긋나기 때문입니다. 보통 엔진 내부에서 가장자리 1픽셀을 자동으로 늘려주지만, 개념을 알고 계시면 좋습니다.
모든 형태를 다 만들 순 없습니다: 이 방식은 위에서 아래로 내려다보는 높이 맵(Heightmap)을 기반으로 합니다. 따라서 튀어나온 절벽(Overhang)이나 동굴 안쪽 같은 형태는 이 알고리즘으로 처리할 수 없고, 별도의 일반 프랍 메쉬(Static Mesh)로 덧대어 주어야 합니다.

적용 결과 프리뷰

마무리

요약하자면 RTIN(MARTINI) 알고리즘은 지형의 굴곡에 따라 폴리곤을 똑똑하게 분배하고, 골치 아픈 틈새 찢어짐 현상을 원천 차단하며, 카메라 거리에 따른 최적화를 매우 빠르게 처리하는 훌륭한 기법입니다. 모바일이나 오픈월드 게임의 지형을 다룰 때 왜 이런 구조를 사용하는지 이해하신다면, 프로그래머 및 TA 분들과 소통하실 때 훨씬 큰 도움이 될 것입니다!

더 읽어 볼 것들.

MARTINI 인터랙티브 노트북: observablehq.com/@mourner/martin-real-time-rtin-terrain-mesh — 알고리즘의 시각화가 압권
레퍼런스 구현: github.com/mapbox/martini (JS), pymartini (Python/Cython), martini_rtin (Rust)
RTINI 시리즈: brodieg.com/2020/01/27/mesh-reduction-1/ — 알고리즘의 "왜"와 "어떻게"를 시각적으로 풀어낸 글