월세 500 호기심 천국

11주차: 마무리 - 후기

원펀치 쓰리 갓냥이 — Thu, 7 Mar 2024 21:28:19 +0900

유니티에 관해 궁금한 것은 많았고,

굳이 그것들을 알아야 할 필요는 없었다.

Quaternion이나 Unity Render Pipeline에 대해서는 얕은 정도의 지식만 알고 있어도

평소 하던대로 소규모 인디 게임 개발 정도의 작업은 할 수 있을 터였다.

하지만 가뜩이나 궁금한게 생기면 온종일 나무위키를 타고 타고 들어가 파헤쳐보는 성격에,

그냥 지나치기에는 아쉬운 것들이 너무 많았다.

이에 티스토리 연재를 명분 삼아 이것저것 공부를 시작했다.

월세 500 호기심 천국.

블로그 명을 보고 작성자가 비싼 집에 살고 있다고 자랑을 하는 것일까?

생각할 수도 있겠지만,

블로그 한 줄 설명을 보면 이해가 더 쉬울 것이다.

마음 속 깊숙히 품어놓기만 했던 궁금한 것들을 파헤쳐나가며

지식의 천국에 도달하고 싶다면,

그에 걸맞는 꾸준한 노동을 치루어야 한다는,

비유적인 의미의 월세 500이였다.

(애초에 이런 집에 살고 있을리도 없고...)

그 말에 맞게, 지난 10주는 꽤나 바빴다.

사실 어쩌다 한 편 글을 작성하는건 그렇게 큰 부담이 아닐지라도,

매주마다 다른 주제의 글을 꾸준히 작성하는건 상당한 부담으로 다가왔다.

그럼에도 결국은 1주차부터 10주차까지, 어케저케 해냈다.

몇 개의 주제는 학과 수업 때 배웠던 부분들이 조금씩 응용되어있는 것도 있었다.

몇 개는 기존 자료를 쉽게 찾아볼 수 없어 구글을 싹 다 뒤져봐야하는 것도 있었다.

그래도 모두 유니티에 관한 짜잘한 지식들임에는 변함이 없었다.

지금 당장은 쓰이는 상황이 없더라도, 분명 언젠가는 내게 도움이 될 것이다.

처음 목표했던 것들을 채우고나니 참 뿌듯해지는 것 같다.

지금껏 월세 500은 성실히 납부해왔다.

그렇다면 이제 나는 지식의 천국에 도달 수 있을까?

글쎄...

그곳에서 월세만 꾸준히 낸다고 편하게 먹고 살 수는 없을 것이다.

각종 세금, 식비, 수도세, 전기세도 필요할 테니.

그러므로 이제는 다른 공부를 하러 가야 한다.

그럼,

내 맘대로 쓰는 Unity 심층분석 析深層分,

연재 끝!!!

잘가요 동지들... 취업한 미래에서, 씨유어게인

10주차: 철가방 채로 배달온 Unity 빌드 파일. 난 단무지 시킨 적 없는데, 왜 있지?

원펀치 쓰리 갓냥이 — Fri, 1 Mar 2024 01:30:12 +0900

유니티로 게임을 개발하고 빌드하면,

.exe 파일과 함께 꼭 보이는 파일들이 있다.

(windows용 빌드 기준)

2개의 영문 모를 폴더명과, 의문의 .exe, .dll 파일.

모바일 .apk 파일처럼 실행에 필요한 .exe 파일 하나만 깔끔하게 나오면 참 좋을 텐데...

왜 저런 파일들이 항상 같이 붙어나오는 걸까?

순서대로 하나하나 자세히 알아볼 필요가 있다.

어차피 꼭 딸려나오는거, 안에 뭐가 들었는지 알고 먹는게 더 맛있지 않겠는가?

게임명_Data 폴더

그래도 다른 파일들에 비해 이름이 정직한 편이다.

대충 게임에 필요한 데이터들이 들어있겠지...

하는 생각으로 폴더를 열어보면?

뭐가 또 이렇게 많은걸까...

Managed, Plugins, Resources...

수많은 폴더와 파일들이 그 안에 숨어있었다.

이것도 또 차례대로 열어봐야겠는걸.

Managed 폴더

Managed 폴더 안에는 유니티 실행 코드를 컴파일한 여러 코드들이 dll의 형태로 저장되어있다.

Cinemachine, UnityEngine, UnityEngine.UI 등 우리가 스크립트 상에서

using문을 통해 불러와 사용하는 코드들도 있어서 반가웠다.

Plugins 폴더

Plugins 폴더 내부에는 몇 개의 폴더가 더 있었고,

타고 타고 끝까지 들어가봐도 막 엄청난 것들이 있다거나 하지는 않았다.

유니티 외부에서 제공되는 플러그인들이 담겨있는 폴더라고 한다.

내 게임의 경우 스팀 출시를 위해 관련 플러그인을 사용했기 때문에

해당 폴더에 steam_api64.dll이 포함되어 있었다.

Resources 폴더

Resources 폴더에 있는 것들.

유니티의 기본 기능들이 들어가있다.

Texture, Material, Font, Mesh, MonoBehaviour등 필수적인 요소의 경우 unity default resources에,

Shader와 같은 선택적인 요소의 경우 unity_builtin_extra에 따로 담겨있다고 한다.

기타 파일들

app.info

.info라는 생소한 확장자의 파일이다.

하지만 메모장으로 열어보면 게임의 이름, 제작사명이 들어있는 것을 알 수 있다.

globalgamemanagers

서로 비슷한 이름으로

globalgamemanagers,

globalgamemanagers.assets,

globalgamemanagers.assets.resS

세 종류가 있으며, 각각의 역할 역시 다르다.

globalgamemanagers

- 유니티 프로젝트 내 대부분의 설정들이 다 담겨있다.

- PlayerSettings, GraphicsSettings, BuildSettings, Physics2DSettings 등.

globalgamemanagers.assets

- 위의 것과 이름이 비슷해 헷갈릴 수 있지만, 역할이 엄연히 다르다.

- Shader와 MonoScript(스크립트의 이름, 클래스명, 네임스페이스 등)에 대한 정보를 담고 있다.

globalgamemanagers.assets.resS

- globalgamemanagers.assets에서 상대적으로 용량이 큰
이미지, 음성, 동영상 등을 외부에서 불러올 때 사용된다.

level0, level1, level2, ... , levelN

프로젝트마다 존재하는 level 파일의 개수가 다르며,

각 파일별로 자신의 번호에 대응되는 씬의 정보를 담는다.

level0의 경우 Scene[0], level1의 경우 Scene[1]과 같은 식이다.

당연히 level 파일은 씬의 개수만큼 존재한다.

resources.assets, resources.assets.resS

각 씬에 묶여있는 리소스들이 아닌,

게임의 런타임 시점에서 자유롭게 로딩되는 리소스들을 담고 있다.

유니티 에디터 상에서 Resources 폴더 안에 넣어두는 에셋들을 생각하면 될 것 같다.

때문에 런타임 로딩 특성상 게임 내에서 사용되지 않는 파일들도 포함되어 있을 수 있다.

.resS의 경우 아까와 마찬가지로 상대적으로 용량이 큰 이미지, 음성, 동영상 등을 불러올 때 사용된다.

sharedassetsN.assets, sharedassetsN.assets.resS

게임 내 실질적인 에셋들이 전부 담겨있는 핵심 파일이다.

levelN에 등장하는 에셋들이 각 번호에 맞는 sharedassetsN.assets에 저장된다.

때문에 _Data 폴더 내의 파일들 중 용량이 가장 크며,

특히 상대적으로 용량이 큰 이미지, 음성, 동영상 등이 담아내는 .resS의 경우

작성자가 빌드한 게임 기준 1GB가 넘게 나왔다.

평소 즐겨 하던 게임의 클라이언트를 뜯어보고 싶은 유저라면

사실상 가장 먼저 뜯어봐야 할 파일이다.

이로써 양이 제일 많은 게임명_Data 폴더를 전부 뜯어보았다.

다음은 MonoBleedingEdge 폴더이다.

MonoBleedingEdge

음... 열어봐도 사실 별게 없다.

더 들어가보아도 .dll 파일만 몇 개 있을 뿐이고,

(프로그램을 실행시키기 위한 C#, MonoDevelop 라이브러리)

하위 경로인 etc로 들어갈 경우 유니티가 사용하는

mono 가상머신 관련 파일들이 담겨있는 mono 폴더를 볼 수 있다.

UnityCrashHandler64.exe

게임 실행 파일과 같은 확장자인 .exe 파일이다.

유니티 게임을 한 번이라도 직접 실행해본 사람들은

호기심에라도 몇 번 눌러봤지만, 실행은 잘 되지 않았을, 그런 파일이다.

그도 당연할 것이, 이 파일은 애초에 직접 창을 열어서 실행시키는 그런 파일이 아니다.

이 파일은 Unity 내부에서 충돌이 나거나 문제가 생겼을 때

개발자가 문제를 식별하고 수정하기 위해 사용하는,

크래시 핸들러 실행 파일이다.

의외지만, 이 파일을 삭제하더라도 게임의 실행에 전혀 영향을 끼치지 않는다.

오히려 어떤 경우에는 플레이 중인 게임에서 버그가 발생했는데,

이 크래시 핸들러 파일을 삭제하고 문제가 사라졌다는 사람도 있는 것 같다.

어찌됐든 이를 통해 알 수 있는 것은,

게임 유저 입장에서는 크게 중요한 파일이 아니라는 것이다.

UnityPlayer.dll

이미 .dll 파일은 앞에서도 많이 나오긴 했지만,

이제 와서라도 더 정확한 의미를 알아보자면 Dynamic Link Library라는 뜻이다.

여러 프로그램에서 동시에 사용할 수 있는 코드와 데이터를 포함하는 파일의 유형이다.

모두가 흔히 쓰는, 말 그대로 두루두루 자주 쓰이는 코드들을 .dll 형식으로 배포하면,

우리는 해당 .dll을 불러온 뒤 함수를 호출하여 그 기능들을 편하게 사용할 수 있는 것이다.

우리가 Unity C# Script를 작성할 때 UnityEngine, UnityEngine.UI 등을 using문을 통해 가져오는 것도

유용한 함수와 클래스들이 UnityEngine.dll, UnityEngine.UI.dll의 형태로 저장되어있기 때문이다.

그 중 이 UnityPlayer.dll의 경우 유니티에 있어서 가장 핵심이라고 볼 수 있겠다.

유니티 공식 문서에는 이 파일이 유니티의 native 엔진 코드를 모두 포함한다고 설명한다.

때문에 해당 파일이 없으면 게임 자체가 실행이 되지 않고,

구글에 조금만 검색해봐도 이 파일이 없어 게임이 실행되지 않는다며

문제를 해결해달라는 글이 꽤 많이 올라와있음을 알 수 있다.

유니티의 빌드 파일 구조를 조금만 알고 있는 사람이라면,

아무데서나 굴러다니는 UnityPlayer.dll 파일 하나를 복사해다가

문제되는 게임 실행 파일 옆에 붙여넣어 문제를 바로 해결했을 것이다.

나중에 나한테도 그런 일이 생기면 멋지게 써먹어봐야지.

마무리

이렇게 해서 철가방 채 배달온 Unity 게임 빌드 파일 5형제를 모두 뜯어보았다.

게임 실행에 있어서 정말 필수적인 젓가락 같은 녀석들도 있었고,

있으나 마나한 양파 춘장 같은 녀석도 있었다.

생양파가 있든말든 결국 유저한테는 실행만 잘 되면 장땡인걸

사실 짜장면을 요리하는 사람이나, 짜장면을 먹는 사람이나,

왜 같이 나오는 단무지의 색이 항상 노란색인지,

왜 군만두는 꼭 주름 잡힌 초승달 모양이어야 하는지

꼭 알아야 할 필요는 없다.

그냥 다른 중국집에서도 다 기성품으로 주고,

우리도 그렇게 먹는게 보통 맛있기 때문이다.

하지만 글 도입부에서 말했듯,

알고 먹는 것과 모르고 먹는 것에는 차이가 있다.

혹여나 식당만의 차별화된 단무지가 필요하다는 생각이 들 때

이전에 배워두었던 레시피를 응용해 직접 담가서 대접할 수도 있는거고,

군만두도 직접 만들어 이윤을 더 노려볼 수도 있는 것이다.

그게 또 색다른 맛으로 대박이 날 수도 있는거고.

짜장면을 요리하는 사람이나, 그것을 먹는 사람이나,

오직 알고 있는 자만이 이것들을 누릴 수 있다.

지금껏 약 10주 가량의 기간 동안 열심히 유니티를 파헤쳐 온 것이,

어쩌면 그 단무지와 군만두를 알아가는 과정일 수도 있겠다.

그렇게 드디어, 이 기나긴 여정에도 마침표를 찍을 때가 온 것 같다.

초기 기획해두었던 목표 주제들도 모두 작성 완료했고,

다음 주에는 후기글을 작성해볼 예정이다.

내일은 짜장면 시켜먹어야지.

그럼, 이번 주도 끝!

9주차: 내 과자 포장지 누가 버렸어? - meta data 파일 (.meta) 파헤치기

원펀치 쓰리 갓냥이 — Sat, 24 Feb 2024 01:50:43 +0900

유니티 프로젝트 창에서만 보던 에셋들을 파일 탐색기를 통해 열어보면 원본 파일들과 함께,

열리지 않는 .meta 확장자의 파일들이 한 짝씩 세트로 있는 것을 알 수 있다.

모두 원본 파일의 이름을 그대로 담고 있고 맨 마지막에만 확장자로 .meta를 붙였을 뿐이다.

용량은 평균 3KB로 솜털만큼이나 가볍다.

쉐도우 파트너인가?

이 에셋의 그림자 같은 녀석들의 정체는 뭐고,

대체 왜 존재하는 걸까?

.meta 파일 열어보기

본격적으로 궁금증을 해결하기 전에,

먼저 찍어먹어보는 방법이 있다.

일단 파일 탐색기로 열어보려 하면, 열리지 않는다.

(정확히는 확장자에 맞는 응용프로그램을 수동으로 선택해야 한다)

여는 방법을 따로 구글링해서 찾아볼 수도 있겠지만,

우선은 언제나 그렇듯 깃허브를 들어간다.

깃허브는 대부분의 파일들을 그에 맞는 형식으로 열어주는 다재다능한 친구이기에,

녀석을 믿고 2-2.jpg.meta를 조심스럽게 열어주면...?

fileFormatVersion: 2
guid: 8069e5455909aaa4d9733841896b1318
TextureImporter:
  internalIDToNameTable: []
  externalObjects: {}
  serializedVersion: 12
  mipmaps:
    mipMapMode: 0
    enableMipMap: 0
    sRGBTexture: 1
    linearTexture: 0
    fadeOut: 0
    borderMipMap: 0
    mipMapsPreserveCoverage: 0
    alphaTestReferenceValue: 0.5
    mipMapFadeDistanceStart: 1
    mipMapFadeDistanceEnd: 3
  bumpmap:
    convertToNormalMap: 0
    externalNormalMap: 0
    heightScale: 0.25
    normalMapFilter: 0
  isReadable: 0
  streamingMipmaps: 0
  streamingMipmapsPriority: 0
  vTOnly: 0
  ignoreMasterTextureLimit: 0
  grayScaleToAlpha: 0
  generateCubemap: 6
  cubemapConvolution: 0
  seamlessCubemap: 0
  textureFormat: 1
  maxTextureSize: 2048
  textureSettings:
    serializedVersion: 2
    filterMode: 1
    aniso: 1
    mipBias: 0
    wrapU: 1
    wrapV: 1
    wrapW: 1
//
//
//
//후략

어... 홀리...

이게 뭘까.

생각보다 더 대단한 녀석이 나와버렸다.

(위 복사본에서는 뒷부분을 생략했지만 실제로는 123줄짜리 텍스트 파일이었다)

앞에서는 고작 3KB라고 하긴 했지만,

텍스트 파일 기준 3KB면 충분히 많은 양이라는 것을 잊고 있었다.

텍스트 내용이 생각보다 자세하기도 했고, 양도 적지 않은 만큼

무언가 확실한 역할을 맡고 있다는 것 쯤은 이제 알겠다.

그러니 이제 그 역할을 알아보자.

.meta 파일의 역할

.meta 파일을 열자마자 바로 두 번째 줄에서 익숙한 내용을 볼 수 있었다.

fileFormatVersion: 2
guid: 8069e5455909aaa4d9733841896b1318
.
.
.

바로 저번 주 .unity 씬 파일을 열면서 발견한 guid이다.

호... 그게 이 녀석이란 말이지?

유니티 내의 모든 에셋들은 전부 각각의 .meta 파일을 가지고 있었고,

그것들마다 저마다의 고유한 ID 번호를 소유하고 있었다.

저번 주에 열어보았던 .unity 파일 속 guid를 예시로 들면,

--- !u!4 &12438314 stripped
Transform:
  m_CorrespondingSourceObject: {fileID: 4808409092926342, guid: 70704ddec6bf2c543b7008ab52a9006d,
    type: 3}
  m_PrefabInstance: {fileID: 12438313}
  m_PrefabAsset: {fileID: 0}

어떤 오브젝트의 Transform을 설명하면서,

해당 Transform을 담고 있는 오브젝트의 ID인 fileID,

그리고 이에 대응되는 아이템인 guid 번호를 기재한 것이다.

그러면 자연스레 70704ddec6bf2c543b7008ab52a9006d의 guid를 담고 있는 .meta 파일에 대응되는 에셋을 사용하겠다는 의미가 된다.

그렇다면 2-2.jpg.meta의 guid, 그 이후의 내용들도 한 번 살펴보자.

TextureImporter:
  internalIDToNameTable: []
  externalObjects: {}
  serializedVersion: 12
  mipmaps:
    mipMapMode: 0
    enableMipMap: 0
    sRGBTexture: 1
    linearTexture: 0
    fadeOut: 0
    borderMipMap: 0
    mipMapsPreserveCoverage: 0
    alphaTestReferenceValue: 0.5
    mipMapFadeDistanceStart: 1
    mipMapFadeDistanceEnd: 3
  bumpmap:
    convertToNormalMap: 0
    externalNormalMap: 0
    heightScale: 0.25
    normalMapFilter: 0

TextureImporter... 밉맵... 범프맵...

무언가 익숙한 용어들이다.

그것은 바로!!

유니티 인스펙터 창에서 에셋을 열람할 경우

옵션으로 볼 수 있었던 내용들이다.

mipmap의 경우 sRGBTexture, fadeout, bordermipmap, mipmapPreserveCoverage 등

이름까지도 일치하는 옵션들을 확인할 수 있다.

즉 .meta 파일은 에셋 각각의 세부 옵션들까지도 기록하고 있는 것이다.

우리가 유니티 상에서 이미지 파일의 해상도를 절반으로 낮춘다고 해서

원본 이미지의 해상도가 실제로 조정되지는 않는다.

원본은 기존 품질의 해상도를 유지하고, 유니티에서 적용될때만 더 낮은 해상도가 적용될 뿐이다.

때문에 이러한 옵션 정보를 .jpg 원본이 아닌 다른 곳 어디엔가 저장할 것이라고 예상 정도는 할 수 있었겠지만,

이렇게 간단한 방법으로 저장이 되어있을 것이라고는 생각하지 못했다...

.meta 파일 덕분에, 우리는 A 이미지의 파일명이 A-1로 바뀌어도

씬 전체에 참조되어있는 A 이미지는 그대로 유지된다.

어차피 유니티는 파일명이 아닌 각 에셋의 고유한 ID인 guid를 통해 에셋을 참조하기 때문이다.

(단, 유니티 프로젝트 창에서 파일명을 변경해야 한다.

유니티 외부에서 변경할 경우, (ex 파일 탐색기)

A 이미지가 사라지고 A-1 이미지가 들어온 것으로 인식하므로 아예 새로운 .meta 파일이 생성된다.)

반대로, 기존 A 이미지에 파일명만 같고 내용은 완전히 다른 새로운 A 이미지가 덮어 씌워져도,

A 이미지가 가지고 있던 옵션은 그대로 유지된다.

해상도, pixel per unit, pivot 등 전부 말이다.

.meta의 의미

통상적으로 메타(meta)는 자기 자신을 재귀적으로 가리킬 때 사용되는 말이다.

때문에 보통 메타 데이터라 하면 데이터에 대한 데이터를 말한다.

이미지라는 데이터가 있고, 그 이미지를 설명하는 데이터가 메타 데이터가 되는 것이다.

별 것 아닌 것 같아보이지만, 이는 데이터를 구조화하는 데에 큰 도움을 준다.

우리가 누군가에게 유니티 프로젝트 파일을 넘겨줄 때 .meta 파일을 제외하고 넘겨준다면,

넘겨받은 사람이 프로젝트를 열었을 때 그 안은 난장판이 되어있을 것이다.

넘겨받은 유니티를 처음 실행할 때 모든 .meta 파일들이 새롭게 일괄 생성될 것이고,

다시 guid가 랜덤하게 재배치 될 것이기 때문이다.

에셋의 옵션은 초기화될 것이고, 오브젝트 참조는 전부 꼬일 것이다.

때문에 유니티 파일을 공유할 때는 꼭 반드시 .meta 파일을 함께 공유해야 한다.

우리에게 데이터가 중요한 만큼,

이를 효율적으로 관리하기 위한 데이터에 대한 데이터 역시 중요하다.

분명 우리가 맛있게 먹고 즐기는 것은 과자의 포장지가 아닌 과자의 내용물이지만,

과자의 이름, 회사, 원산지, 유통기한, 알레르기 유의사항 등의 정보를 계속 활용하기 위해서는 포장지 박스를 버려서는 안된다.

포장지를 다 뜯어둔 채 그릇에 쌓아둔 과자 더미를 가리키며

외국인 친구에게 맛동산 한 조각만 갖다달라고 하면,

어떤 과자가 맛동산인지 알아내고 바로 갖다줄 수 있는 친구가 얼마나 있을까?

과자가 유통기한이 지났는지 안지났는지는 어떻게 구분할 수 있을까?

정보에 대한 정보가 필요하다.

에셋이라는 과자를 개별 포장하고 있는 과자 박스. 이것이 유니티의 .meta 파일이다.

사진을 보며 문득 든 생각은...

후레쉬베리가 먹고 싶어졌다.

촉촉한 초코칩은 엄청 달기 때문에,

이왕이면 후레쉬베리를 먼저 먹고 그 다음에 촉촉한 초코칩을 먹는 편이 좋을 것 같다.

유니티 .meta 파일과 후레쉬베리,

오늘 내용은 꽤 보람찼던 것 같다.

그럼 이번 주도 끝!

8주차: 야물(YAML)딱진 그 녀석의 은밀한 속마음 - Unity Scene 파일 (.unity)

원펀치 쓰리 갓냥이 — Wed, 14 Feb 2024 05:06:38 +0900

지금까지는 주로 유니티 내의 코드들이 작동되는 원리를 뜯어보았었다.

오일러각과 쿼터니온, 유니티 생명 주기, 코루틴 등등...

이제는 유니티의 씬 자체가 저장되는 방식,

.unity 파일에 대해서 알아볼 차례다.

사실 지금까지는 유니티를 조금 공부해봤다 싶으면 조금씩은 도전을 해봤을 만한 부분의 주제들이었다면,

이제부터는 정말 말 그대로 심층분석, 말을 좀 다르게 해보자면 아무도 관심이 없었을 만한 주제이다.

연재 시리즈가 후반으로 향해가면서 점점 취지에 맞는 것들이 등장하는 것이다.

.unity란?

유니티의 씬(Scene)이 통째로 저장돼있는 파일을 나타내는 확장자명이다.

이 씬이 전부 다 저장된다고?

그렇다면 씬 내에 게임의 정보가 전부 다 들어있는 만큼, 용량 역시도 무지막지할까?

게임 자체가 여러 개의 씬이 모여 하나의 빌드로 구성되는 방식인데,

빌드가 500MB고 씬이 5개면 개당 평균 100MB는 되지 않겠냐는 것이다.

몰론 유니티, 혹은 동영상 편집 툴을 조금이라도 써본 사람이라면 알겠지만, 답은 NO다.

빌드가 GB 단위의 큼직한 규모의 게임이더라도,

정말로 필요한 정보만 주소와 ID 형식으로 최소화하여 저장하기 때문에,

씬 파일은 보통 몇십MB 언저리를 넘지 않는다.

어떻게 이런 용량 절약이 가능한걸까?

그 답은 .unity 파일이 쓰여지는 방식에 있다.

Scene 파일 내 데이터의 직렬화, YAML

%YAML 1.1
%TAG !u! tag:unity3d.com,2011:
--- !u!29 &1
OcclusionCullingSettings:
  m_ObjectHideFlags: 0
  serializedVersion: 2
  m_OcclusionBakeSettings:
    smallestOccluder: 5
    smallestHole: 0.25
    backfaceThreshold: 100
  m_SceneGUID: 00000000000000000000000000000000
  m_OcclusionCullingData: {fileID: 0}
--- !u!104 &2
RenderSettings:
  m_ObjectHideFlags: 0
  serializedVersion: 9
  m_Fog: 0
  m_FogColor: {r: 0.5, g: 0.5, b: 0.5, a: 1}
  m_FogMode: 3
  m_FogDensity: 0.01
  m_LinearFogStart: 0
  m_LinearFogEnd: 300
  m_AmbientSkyColor: {r: 0.212, g: 0.227, b: 0.259, a: 1}
  m_AmbientEquatorColor: {r: 0.114, g: 0.125, b: 0.133, a: 1}
  m_AmbientGroundColor: {r: 0.047, g: 0.043, b: 0.035, a: 1}
  m_AmbientIntensity: 1
  m_AmbientMode: 0
  m_SubtractiveShadowColor: {r: 0.42, g: 0.478, b: 0.627, a: 1}
  m_SkyboxMaterial: {fileID: 2100000, guid: 9a819b815e161b64e8c78164c1902994, type: 2}
  m_HaloStrength: 0.5
  m_FlareStrength: 1
  m_FlareFadeSpeed: 3
  m_HaloTexture: {fileID: 0}
  m_SpotCookie: {fileID: 10001, guid: 0000000000000000e000000000000000, type: 0}
  m_DefaultReflectionMode: 0
  m_DefaultReflectionResolution: 128
  m_ReflectionBounces: 1
  m_ReflectionIntensity: 1
  m_CustomReflection: {fileID: 0}
  m_Sun: {fileID: 0}
  m_UseRadianceAmbientProbe: 0

.unity 파일을 파일 탐색기를 통해 열람할 경우 자동으로 Unity Editor로 이동되지만,

GitHub를 통해 열람할 경우 위 형식의 YAML 코드로 이루어져있음을 확인할 수 있다.

YAML은 특정 데이터를 기록하고 전달하는 데에 목적을 둔 언어이며,

json처럼 사람이 읽을 수 있을 정도로 직관적인 형태로 씬 전체를 직렬화한다.

그럼 위의 코드를 한줄한줄 뜯어보자.

%YAML 1.1
%TAG !u! tag:unity3d.com,2011:

모든 .unity YAML 파일에 있어야 하는 코드이다.

코드의 맨 앞줄에 이 두 줄을 기재함으로써 우리가 사용할 YAML이 1.1 버전이고,

보통의 YAML과 다소 차이가 있는 Unity 맞춤형 YAML을 사용할 것임을 명시한다.

--- !u!1 &1947408731
GameObject:
  m_ObjectHideFlags: 0
  m_CorrespondingSourceObject: {fileID: 0}
  m_PrefabInstance: {fileID: 0}
  m_PrefabAsset: {fileID: 0}
  serializedVersion: 6
  m_Component:
  - component: {fileID: 1947408733}
  - component: {fileID: 1947408732}
  m_Layer: 0
  m_Name: CubeController
  m_TagString: Untagged
  m_Icon: {fileID: 0}
  m_NavMeshLayer: 0
  m_StaticEditorFlags: 0
  m_IsActive: 1

--- 은 파일 내의 오브젝트를 하나 소개하겠다는 뜻이며,

이후는 공백 한 칸 이후 !u! + 숫자A + & + 숫자B 구조이다.

숫자A는 해당 오브젝트의 클래스를 나타내며,

다음의 사전에 정해진 구분을 따른다.

ID	클래스
0	오브젝트
1	GameObject
2	Component
3	LevelGameManager
4	Transform
5	TimeManager
6	GlobalGameManager
8	Behaviour
9	GameManager
.....	.....
2058629511	VisualEffectResource
2059678085	VisualEffectObject
2083052967	VisualEffect
2083778819	LocalizationAsset
2089858483	ScriptedImporter

이어서 & 뒤에 오는 숫자B의 경우 각 파일 내의 고유한 ID인 fileID가 할당된다.

--- !u!1 &1947408731

즉 위의 경우 소개하려는 오브젝트는 GameObject이며,

해당 파일의 fileID는 1947408731인 것이다.

GameObject:
  m_ObjectHideFlags: 0
  m_CorrespondingSourceObject: {fileID: 0}
  m_PrefabInstance: {fileID: 0}
  m_PrefabAsset: {fileID: 0}
  serializedVersion: 6
  m_Component:
  - component: {fileID: 1947408733}
  - component: {fileID: 1947408732}
  m_Layer: 0
  m_Name: CubeController
  m_TagString: Untagged
  m_Icon: {fileID: 0}
  m_NavMeshLayer: 0
  m_StaticEditorFlags: 0
  m_IsActive: 1

그 이후로는 해당 GameObject의 프로퍼티들이 나열되어있다.

m_ObjectHideFlags처럼 UnityC#의 GameObject 스크립트 내에 실제로 존재하는 프로퍼티들도 있었고,

스크립트 상에서는 존재하지 않는 것도 있었다.

GameObject의 부모 클래스인 Object 내에 존재하는 hideFlags, name

GameObject 클래스 내에 존재하는 layer, tag, active 등

  m_Component:
  - component: {fileID: 1947408733}
  - component: {fileID: 1947408732}

또한 해당 GameObject는 1947408733과 1947408732 두 개를 Component로 가진다는 코드가 같이 적혀있었는데,

해당 fileID를 토대로 이들을 추적해보면...

--- !u!114 &1947408732
MonoBehaviour:
  m_ObjectHideFlags: 0
  .....

--- !u!4 &1947408733
Transform:
  m_ObjectHideFlags: 0
  .....

GameObject가 가지고 있는 MonoBehaviour 클래스와 Transform 클래스를 말한 것이었음을 알 수 있었고,

두 클래스 모두 각자의 데이터 역시도 포함하고 있었다.

--- !u!4 &1947408733
Transform:
  m_ObjectHideFlags: 0
  m_CorrespondingSourceObject: {fileID: 0}
  m_PrefabInstance: {fileID: 0}
  m_PrefabAsset: {fileID: 0}
  m_GameObject: {fileID: 1947408731}
  m_LocalRotation: {x: 0, y: 0, z: 0, w: 1}
  m_LocalPosition: {x: 0, y: 0.5, z: 0}
  m_LocalScale: {x: 1, y: 1, z: 1}
  m_ConstrainProportionsScale: 0
  m_Children: []
  m_Father: {fileID: 0}
  m_RootOrder: 7
  m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}

특히 1947408732의 fileID를 가진 Transform의 경우 위의 표에서 정리되어있던 대로 4라는 클래스 ID를 가졌으며,

localRotation, localPosition, localScale 등 우리에게 이미 익숙한 변수들도 보였다.

물론 xyzw의 실제 벡터 정보들도 모두 포함되어있었다.

worldRotatiln, worldPosition 등이 없는 이유는

부모의 Transform 정보와 자신의 local한 정보를 통해서 역으로 충분히 계산해서 나타낼 수 있기도 하고,

애초에 에디터의 인스펙터 창만 봐도 local한 좌표를 기준으로 관리되고 있어서 그런 것도 있는 것 같다.

추가로 m_GameObject의 경우 해당 Transform을 담고 있는 GameObject의 fileID인 1947408731가 입력되어 있었다.

--- !u!4 &12438314 stripped
Transform:
  m_CorrespondingSourceObject: {fileID: 4808409092926342, guid: 70704ddec6bf2c543b7008ab52a9006d,
    type: 3}
  m_PrefabInstance: {fileID: 12438313}
  m_PrefabAsset: {fileID: 0}

YAML 파일을 이곳저곳 훑다보면 guid라는 녀석도 가끔 보였다.

guid는 fileID와는 달리 에셋이 Unity Editor에 처음 잡히자마자 할당되는 고유의 번호라고 한다.

우리가 유니티 에셋 폴더에 리소스를 드래그 앤 드롭하면 약간의 로딩과 함께 .meta 파일이 생성되는데,

그 과정에서 자동으로 할당되는 것 같다.

어쩌면... 다음 주에 다루게 될 .meta 파일과 연관이 있을 수도 있겠다.

이 녀석은 조금 더 두고봐야겠는걸...

실제로 열어본 .unity 후기

막상 열어보니 구성 자체는 간단했다.

씬 내의 모든 오브젝트가 --- !u!*classID* &*fileID* 식으로 소개되고

그 안의 프로퍼티값들이 세세히 나열되는 방식이었다.

문제는, 이 '모든 오브젝트'의 양이 방대했다.

말 그대로 씬 내의 모든 것들이 기재되어있어야 했기에,

잠깐 1~2주 짤막하게 개발 중인 토이 프로젝트였음에도

메인 씬의 YAML 코드는 11,000자를 육박했다.

본격적인 프로젝트의 .unity 파일은 얼마나 내용이 길련지...

아... 따로 압축은 안하는 건가?

하긴 어차피 용량도 별로 안 큰 텍스트 파일이니 압축해봤자일 것 같기도 하고.

오히려 YAML의 사용 목적에 맞게 가독성을 더 살리고자 압축을 하지 않았을 수도 있다.

씬 내에 100MB짜리 비디오 파일이 포함된다고 해서,

.unity 파일에도 100MB짜리 영상을 넣어 저장하는 것보다는 이미 훨씬 효율적이지 않은가.

호오...

씬의 저장은... 이런 식으로 이루어지는구나.

참으로 기묘하도다.

그럼 이번 주도 끝!

7주차: 남들보다 더 갓생 사는 Coroutine의 충격적인 정체

원펀치 쓰리 갓냥이 — Thu, 8 Feb 2024 13:42:47 +0900

보통 컴퓨터는 한 번에 하나의 일만 수행하는 일이 거의 없다.

티스토리에 글을 쓸 수 있도록 크롬창을 띄우고, 백그라운드에서 유튜브로 노래를 틀어주고,

카톡이 오면 사용자가 바로 볼 수 있도록 바로 알림을 띄워준다.

저 어디 안쪽에서는 백신 프로그램의 자동 검사도 돌아가고 있다.

짧은 시간 안에 많은 일이 주어지고 그것들을 동시에 수행해내야 하는 것은

비단 컴퓨터 운영체제만이 아닐 것이다.

우리가 개발하는 게임, 응용 프로그램들 역시 이것들을 해내야 한다.

하지만 어떻게?

우리가 유니티에게 'A랑 B 코드를 동시에 실행해줘!'

명령한다고 해서 말처럼 그게 바로 되는 건 아니다.

우선, 떠올릴 수 있는 가장 간단한 방법은

앞서 6주차에서 다뤘던 유니티의 Life Cycle 중 Update()를 활용하는 것이다.

MonoBehaviour를 포함한 모든 클래스에는 Update()가 기본적으로 주어지고,

이 함수는 코드가 작성된 순서대로, 직렬적으로 실행된다.

그리고 Update() 안의 모든 코드들은, 모두 한 프레임 안에서 동시에 실행될 것을 보장받는다.

즉, 동시에 실행하고 싶은 모든 내용들을 하나의 Update()안에 넣으면 된다.

한 프레임 안에서 일어나고 있는 수많은 일들

그렇다면 이걸로 해결된걸까?

아래의 상황을 보자.

people은 일정 시간(3초)마다 Eat() 함수를 통해 밥을 먹어야 한다.

쿨타임 변수와 Time.deltaTime을 활용해 people에게 꾸준히 밥을 먹일 수 있다.

코드 상에는 문제가 없다.

    float eatMaxCoolTime = 3;
    float eatCurCoolTime = 0;

    void Update()
    {
        if (eatCurCoolTime < 0)
        {
            people.Eat();
            eatCurCoolTime = eatMaxCoolTime;
        }
        eatCurCoolTime -= Time.deltaTime;
    }

그리고 사람이 다섯 명으로 늘었다. 다행히 우리에게는 반복문이 있기 때문에, 이 정도는 아직 할만하다.

    float eatMaxCoolTime = 3;
    float[] eatCurCoolTimes = new float[5];

    void Update()
    {
        for (int i = 0; i < people.Length; i++)
        {
            if (eatCurCoolTimes[i] < 0)
            {
                people[i].Eat();
                eatCurCoolTimes[i] = eatMaxCoolTime;
            }
            eatCurCoolTime[i] -= Time.deltaTime;
        }
    }

사람이 밥만 먹고 살지는 않는다. 먹고, 마시고, 놀고, 공부하고, 자는 과정을 추가한다.

반복문의 사용에도 한계가 있다.

    float eatMaxCoolTime = 3;
    float[] eatCurCoolTimes = new float[5];
    float drinkMaxCoolTime = 2;
    float[] drinkCurCoolTimes = new float[5];
    float playMaxCoolTime = 5;
    float[] playCurCoolTimes = new float[5];
    float studyMaxCoolTime = 1;
    float[] studyCurCoolTimes = new float[5];
    float sleepMaxCoolTime = 10;
    float[] sleepCurCoolTimes = new float[5];

    void Update()
    {
        for (int i = 0; i < people.Length; i++)
        {
            if (eatCurCoolTimes[i] < 0)
            {
                people[i].Eat();
                eatCurCoolTimes[i] = eatMaxCoolTime;
            }
            if (drinkCurCoolTimes[i] < 0)
            {
                people[i].Drink();
                drinkCurCoolTimes[i] = drinkMaxCoolTime;
            }
            if (playCurCoolTimes[i] < 0)
            {
                people[i].Play();
                playCurCoolTimes[i] = playMaxCoolTime;
            }
            if (studyCurCoolTimes[i] < 0)
            {
                people[i].Study();
                studyCurCoolTimes[i] = studyMaxCoolTime;
            }
            if (sleepCurCoolTimes[i] < 0)
            {
                people[i].Sleep();
                sleepCurCoolTimes[i] = sleepMaxCoolTime;
            }
        }
        eatCurCoolTime[i] -= Time.deltaTime;
        drinkCurCoolTimes[i] -= Time.deltaTime;
        playCurCoolTimes[i] -= Time.deltaTime;
        studyCurCoolTimes[i] -= Time.deltaTime;
        sleepCurCoolTimes[i] -= Time.deltaTime;
    }

게다가 사람은 밥을 한 프레임이 지나가는 시간 안에 절대 다 먹을 수 없다.

밥 한 술 떠야하고, 메추리알 장조림 하나 집어야 하고, 목 메이니까 가슴 콩콩 두드려야 하고...

연근 조림 한 번 쓱 보고, 다시 메추리알로 시선 돌리고...

밥 한 공기 다 먹는데에 최소 5초는 걸린다.

또 하루 일과가 밥 먹는거 하나만 있는 것도 아니고...

밥 먹는 데에 걸리는 시간(실제 함수 실행 시간)이랑

이것까지 다 고려해보면...

    Debug.Log("박명수: 안해 이쒸");

한 Update() 안에 담겨야 하는 내용이 많아질수록,

그리고 그 작업들 간의 연관성이 줄어들수록,

코드가 눈에 띄게 복잡해지고 가독성 역시 떨어짐을 알 수 있다.

그렇다면 클래스의 개수를 늘리고, 여러 개의 Update()로 나눠 작성하면 일이 해결될까?

가독성은 개선되겠지만,

Unity는 Update() 뿐만 아니라 모든 코드를 하나의 단일 스레드로만 실행한다.

그러기에 발생하는 문제가 하나 더 있다.

    for (int i = 0; i < people.Length; i++)
    {
        if (eatCurCoolTimes[i] < 0)
        {
            people[i].Eat();
            eatCurCoolTimes[i] = eatMaxCoolTime;
        }
    }

사람 한 명이 밥을 먹게 되기까지 쿨타임이 10초, (= eatMaxCoolTime이 10초)

방금 전 상황처럼 밥 한 그릇을 다 먹는 데에 소요되는 시간이 5초라고 해보자. (= Eat()의 실행시간)

반복문을 돌며 people[0]과 people[1]이 쿨타임 10초를 다 채웠고 둘 모두 식사할 준비가 되어있음에도,

people[0]이 5초 동안 밥을 다 먹기 전까지는 (즉, people[0]의 Eat() 작업이 끝나기 전까지는)

people[1]은 밥을 먹을 수 없다.

유니티는 모든 소스 코드를 하나의 스레드로 실행하기 때문에
people[0]의 Eat() 함수로 들어가 return을 만나기 전까지는 그 다음 코드를 실행할 수 없고,

유니티는 5초간 Eat() 외의 다른 작업은 하나도 수행하지 못하며,

Update() 역시 5초간 종료될 수 없기에

그동안 프레임 자체가 정지될 것이다. (= 극심한 오버헤드)

나름 반복문과 쿨타임, Time.deltaTime을 통해 이들의 일정을 병렬적으로 해결했다고 생각했지만,

전혀 아니었던 것이다.

여러 개의 클래스를 통해 여러 개의 Update()를 만든다 해도 마찬가지이다.

클래스 A의 Update()를 모두 수행하기 전까지 클래스 B의 Update()는 실행되지 않는다.

때문에 우리는, 코루틴을 사용해야 한다.

코루틴이란?

- "나무위키"

기존의 함수는 일단 한 번 호출하면 return을 만나거나 코드가 끝나지 않는 한 종료될 수 없었다.

우리의 경우는 보통 함수 실행시간 자체가 길지 않기 때문에 크게 걱정할 일이 없지만,

로딩, 입출력, 인터넷 연결과 같이 작업에 긴 시간이 소요되는 코드들이 일반 함수에 들어있을 경우

유니티 생명 주기를 딜레이시키는 주요 원인이 된다.

반면 코루틴은 작업의 중단이 자유롭다.

실행하던 작업을 잠시 멈추고, 자신을 호출했던 코드로 돌아가 그 뒤를 마저 수행할 수 있다.

단일 스레드만을 사용하는 유니티 특성상

코드 실행의 물리적인 병렬성을 구현할 수는 없지만,

코루틴을 통해 논리적인 병행성을 확보할 수 있는 것이다.

밥 한 술 뜨고 굴비 한 번 보고, 다시 밥 한 술 뜨고 굴비 한 번 보는 통칭 <밥캔굴캔>이 가능해진다

이는 꽤나 큰 이점이 되는데,

위에서 언급한 입출력, 인터넷 연결 등

외부적인 요인으로 시간 지연이 예상되는 작업은 요청만 해둔 채

코루틴을 중지하고 원래 수행 중이던 코드로 돌아가면 많은 시간을 절약할 수 있다.

운영체제에서 배웠던 스케쥴링의 중요성이 생각나기도 하고...

위에서 사람 다섯 명의 일과를 코루틴을 사용해 나타내면

아래와 같이 더욱 깔끔하게 표현할 수 있다.

    Coroutine[] eatingCor = new Coroutine[5];
    Coroutine[] drinkingCor = new Coroutine[5];
    Coroutine[] playingCor = new Coroutine[5];
    Coroutine[] studyingCor = new Coroutine[5];
    Coroutine[] sleepingCor = new Coroutine[5];

    void Update()
    {
        for (int i = 0; i < people.Length; i++)
        {
            if (eatingCor[i] == null)
                eatingCor[i] = StartCoroutine(Eat(i, 5, 3));

            if (drinkingCor[i] == null)
                drinkingCor[i] = StartCoroutine(Drink(i, 2, 2));

            if (playingCor[i] == null)
                playingCor[i] = StartCoroutine(Play(i, 5, 7));

            if (studyingCor[i] == null)
                studyingCor[i] = StartCoroutine(Study(i, 1, 1));

            if (sleepingCor[i] == null)
                sleepingCor[i] = StartCoroutine(Sleep(i, 10, 10));
        }
    }

    IEnumerator Eat(int peopleIdx, float spendTime, float coolTime)
    {
        yield return new WaitForSeconds(spendTime);
        yield return StartCoroutine(WaitForCooltime(coolTime));
        eatingCor[peopleIdx] = null;
    }

    IEnumerator Drink(int peopleIdx, float spendTime, float coolTime) { ... }

    IEnumerator Play(int peopleIdx, float spendTime, float coolTime) { ... }

    IEnumerator Study(int peopleIdx, float spendTime, float coolTime) { ... }

    IEnumerator Sleep(int peopleIdx, float spendTime, float coolTime) { ... }

    IEnumerator WaitForCooltime(float coolTime)
    {
        yield return new WaitForSeconds(coolTime);
    }

코루틴의 핵심, yield

사실 저번 주차 Life Cycle에서도 살짝 얼굴을 비췄던 녀석이다.
도로 위 표지판에도 간간히 보이는 yield는, 코루틴에서도 비슷한 의미로 사용된다

보통 yield + return + @ 세트로 묶여 사용되며,

해당 문구에 도달하면 스레드는 코루틴 실행을 중지하여 다른 작업으로 관심을 돌린다.

코루틴이 다른 곳에 잠깐 동안 작업을 양보하는 개념인 것이다.

@값에 따라 코루틴이 호출자에게 양보하는 양상이 달라지며.

Update()와 싱크를 맞추고 싶을 경우 yield return + null,

FixedUpdate()와 싱크를 맞추고 싶을 경우 null 대신 WaitForFixedUpdate()를 붙여 사용할 수 있고,

WaitForSeconds(float) or WaitForSecondsRealtime(float)을 통해 일정 시간 만큼 코루틴을 중단시킬 수 있다. (WaitForSecondsRealtime은 timescale의 영향을 받지 않음)

또한 WaitWhile과 WaitUntil등으로 조건부 대기를 걸 수도 있다.

심지어 yield return StartCoroutine(코루틴명())을 통해 새로운 코루틴을 호출하고,

호출한 코루틴의 작업이 종료되기 전까지 지금의 코루틴을 중지시킬 수 있다.

이에 더해 yield + return + @가 아닌 yield break로 코루틴을 즉시 종료할 수 있다.

코루틴의 실행과 중지

코루틴은 일반 함수와는 실행 방식이 조금 다르다.

구현 부분에서도 차이가 있다.

    void Start()
    {
        ThisIsFunc();
        Coroutine cor = StartCoroutine(ThisIsCor());
    }

    void ThisIsFunc()
    {
        Debug.Log("This is Function");
        return;
    }

    IEnumerator ThisIsCor()
    {
        Debug.Log("This is Coroutine");
        yield break;
    }

함수를 구현할 때는 함수 이름 앞에 return값의 자료형이 들어간다.

반면 코루틴 이름 앞에는 자료형 대신 열거자 인터페이스라는 의미의 IEnumerator가 들어간다.

함수는 반드시 자료형에 맞는 return을 내놓아야 하지만(void 함수 제외),

코루틴은 기존의 return을 요구하지 않는 대신 yield return + @, 혹은 yield break가 반드시 있어야 한다.

호출할 때 역시도 함수는 함수명과 인자를 적어 호출하는 반면,

코루틴은 StartCoroutine 안에 코루틴명과 인자를 적고,

필요에 따라 Coroutine 변수에 실행 중인 코루틴을 담아 둔 다음

StopCoroutine을 통해 해당 코루틴을 중단시킬 수 있다.

천천히 함께 가는 코루틴

코루틴은 모든 작업을 한 프레임에 모두 끝내버리는 일반 함수와는 다르다.

시간차를 두고 천천히 진행하는 특성 덕분에 코드의 실행을 의도적으로 지연시키고,

오버헤드의 우려가 있는 작업을 여러 번에 나누어 처리할 수 있다.

또한 코루틴은 혼자만 앞서 나가지 않는다.

코루틴이 몇 개가 호출되든, Update()나 FixedUpdate(), 혹은 다른 코루틴들과 함께 발맞춰

그들과 병행하며 작업을 수행한다.

이런 식의 지연과 병행 작업이 필요한 상황이 아니라면 보통의 함수를 이용하는 편이 더 간단하고 편할 수 있겠다.

하지만 코루틴을 온전히 이해하고 목적에 맞게, 적재적소에 활용할 수 있다면,

그 잠재력은 무궁무진해질 것이다.

마치 리그 오브 레전드, 할로우나이트, 얼불춤, 오목, 영상 편집,

스타크래프트, 모의고사 풀이와 유니티 코딩을

앉은 자리에서 컴퓨터 한 대로 모두 해내는,

Faker처럼.

00:51 초 보면 진짜 유니티임...ㅋㅋ

그럼 이번 주도 끝!!!

6주차: 매 프레임 나보다 갓생 사는 Unity의 Life Cycle

원펀치 쓰리 갓냥이 — Sun, 4 Feb 2024 20:42:38 +0900

Unity에서 개발자가 작성하는 대부분의 C# 스크립트는 MonoBehaviour 클래스를 상속받는다.

MonoBehaviour 클래스는 에디터 상에서 스크립트가 게임 오브젝트와 잘 연동될 수 있도록 프레임워크를 제공해주며,

모든 스크립트가 공통된 생명 주기(Life Cycle)를 따라

일정에 맞게 딱딱 실행될 수 있도록 관리해준다.

이제 FixedUpdate로 이동할 시간입니다 공주님

위 그림에서 C# 스크립트를 공주로, MonoBehaviour를 시종으로 비유를 든 것은

C# 스크립트가 딱히 기품 있거나 고귀해서가 아니다.

하루 일정이 ㅈㄴ 빡세기 때문이다.

숨 한 번 크게 들이키고 스크롤을 내려보자.

Unity 공식 문서에서 하달 받은 오늘 한 프레임의 일정입니다 공주님

위 순서도의 대부분이 무려 '한 프레임' 이내에 일어나는 것들이다.

Unity의 Life Cycle을 하나하나 파헤치며

공주님과 함께하는 오늘의 일상 VLOG,

겟 레디 윗 미(Get Ready With Me)를 시작해보자

ㅁ...뭣

1. Initialization

하루의 시작이다.

씬에서 오브젝트가 처음 생성될 때 한 번씩 호출되는 함수들이다.

Awake

Initialization 단계에서 맨 처음으로 호출된다.

뒤이어 나올 Start와 비슷하지만 Start보다도 먼저 호출된다는 특징을 가지고 있다.

때문에 Start보다도 선행으로 실행돼야 할 코드들이 있을 경우 (Find 라던가)

주로 Awake 문에서 실행한다.

OnEnable

씬에서 활성화돼있는 스크립트의 경우, Awake 이후 OnEnable을 호출한다.

처음 1회만 호출되는건 아니고, 스크립트가 활성화될 때마다 호출되기 때문에

그에 맞춰 새로이 활성화된 스크립트의 초기화 등 유동적인 용도로 활용할 수 있다.

Reset

에디터 모드에서만 호출되는 함수이다.

인스펙터 창에서 해당 스크립트를 Reset 했을 때 호출된다.

에디터 플레이 모드에서 스크립트를 조절하다가 초기값으로 복구하고 싶을 때 사용한다.

Start

첫 번째 Update가 호출되기 직전, 스크립트가 활성화돼있을 경우 호출된다.

Update와 함께 Unity에서 C# Script를 생성하면 기본적으로 기재되어 있는 함수이며,

그만큼 Unity 초심자부터 고인물들까지 범용적으로 폭 넓게 사용한다.

2. Physics, Input Events, Game Logic

바쁜 Unity 공주의 본격적인 일과 시간이다.

매 프레임 각 부처에서 올린 공문과 국민들이 올린 탄원서,

왕이 내린 왕가의 규율과 지침을 담은 문서를 읽고

학교에서 받은 가정통신문과 알림장을 확인,

이번 달 우유급식비는 제때 냈는지 검토한다.

투니버스에서 틀어주는 신비아파트와 또봇을 한 편씩 보고

적국에서 보내온 자객들에 맞서기 위한 호신술과 살인 기술을 연마한다.

그리고 밤 9시가 되면 양치하고 발닦고 칼같이 잠에 든다.

ㅋ

이러한 루틴은 매일매일 매 프레임마다 반복된다.

다음은 그 루틴들을 좀 더 자세하게 풀어놓은 것이다.

FixedUpdate

별다른 상호작용을 하지 않아도 일정한 시간 간격으로 호출되는 함수이다.

여기서 일정한 시간 간격이란 Time.fixedDeltaTime(기본값: 0.02)이며,

프레임이 아닌 고정된 시간 간격에 의존하기 때문에

각종 플랫폼의 성능 차이에서 오는 frameRate에 영향받지 않을 수 있다.

때문에 일정한 시간 간격으로 힘을 받아야 하는 물리 연산(특히 RigidBody쪽)들에

주로 사용된다.

OnTrigger(Enter, Stay, Exit)

Collider끼리의 충돌을 체크하는 단계이다.

단, 물리 연산을 하지 않는 충돌도 포함이며,

어느 한쪽 Collider의 isTrigger가 켜져있어야 한다.

OnCollision(Enter, Stay, Exit)

Collider끼리의 충돌을 체크하는 단계이다.

단, 물리 연산이 적용되는 충돌만을 말하며,

어느 한쪽 Collider도 isTrigger가 켜져있으면 안된다.

yield WaitForFixedUpdate

뒤에서도 계속 나올 yield 시리즈의 함수(정확히는 코루틴)들은

코루틴 그 자체에 특별한 기능이 있다기보다는,

특정 시점이 오기 전까지 잠들어 있다가

생명 주기 상에서 어떠한 과정이 끝났다라는 '플래그'를 발견하면

다시 깨어나는 역할을 한다.

나 좀 깨워줘

그 중 yield WaitForFixedUpdate는 생명 주기 중 Physics 단계가 끝났을 때 깨어나며,

코루틴 내의 while 반복문 말미에 yield return new WaitForFixedUpdate();를 한 줄 적어넣어

마치 while 반복문이 FixedUpdate와 같은 주기로 돌게끔 설계할 수 있다.

코루틴이 무엇인가?에 대해서는 바로 다음 주차인 '7주차: 코루틴'에서 살펴볼 예정이다.

OnMouse(Enter, Over, Exit, Down, Drag, Up)

플레이어의 마우스 클릭을 감지하는 단계이다.

각 함수들이 호출되는 시점은

해당 타겟 위에 마우스가 진입했을 경우 Enter,

타겟 위에 마우스가 올라와 있을 경우 Over,

타겟에서 마우스가 벗어났을 경우 Exit,

타겟에서 마우스 버튼이 눌렸을 경우 Down,

타겟에서 마우스 클릭이 유지되고 있을 경우 Drag,

타겟에서 눌렸던 마우스 버튼이 다시 떼졌을 경우 Up

이다.

Update

생명 주기의 함수들 중 Start와 함께 가장 유명한 친구이다.

해당 스크립트가 켜져있는 경우 매 프레임마다 확정적으로 호출하지만,

프레임 당 1회이기 때문에 프레임 간격이 들쭉날쭉한 저성능의 플랫폼의 경우

Update 함수의 호출 빈도가 심각하게 낮아지거나 불균형해지는 모습을 볼 수 있다.

때문에 Update 호출 시마다 연산 결과를 누적해야 하는 경우 연산값에

프레임과 프레임 사이의 시간 간격인 Time.deltaTime을 곱해줘야 한다는 이야기를

어디선가 많이 들어봤을 것이다.

yield null

yield WaitForFixedUpdate에서 언급했던 yield 시리즈이다.

yield null의 경우 모든 Update가 종료될 때까지 잠들어있다가 다시 깨어난다.

마찬가지로 While 반복문 말이에 yield return null;을 한 줄 넣어

Update와 같은 주기로 돌게끔 활용하는 방법이 있다.

yield WaitForSeconds

또 yield 시리즈.

숫자 하나를 인자로 받고 해당 숫자의 시간(초)만큼 활동을 멈춘 뒤,

시간이 지난 시점에서 Update문이 모두 종료되면 다시 깨어난다.

이제는 알람 맞추고 잠들어버린

yield WWW

또 또 yield 시리즈.

WWW 다운로드가 완료되기 전까지 잠들어 있는다.

코잇츠 또 잠들어버린 www

yield StartCoroutine

또 또 또 yield 시리즈

인자로 다른 코루틴을 받고, 해당 코루틴이 종료되기 전까지 잠들어 있는다.

해당 코루틴이 종료된 시점에서 다른 모든 Update가 종료될 때 다시 깨어난다.

쟤 끝나기 전까진 나 깨우지 말라고

LateUpdate

Game Logic 단계에서 가장 마지막으로 호출되는 함수이다.

온갖 종류의 Update문과 yield문의 연산이 종료되고

마지막으로 호출되는 찐막 Update이기 때문에

주로 여기에 Camera 관련 Logic을 넣어

더 매끄러운 화면을 보여준다.

이제 일할 시간이다

3. Scene, Gizmo, GUI Rendering

드디어 칼잠에 든 공주.

공주는 자신이 하루 겪었던 일을 토대로 꿈을 꾸기 시작한다.

머릿속 정리되어있지 않은 장면들이

감긴 눈 속에서 한 프레임씩 렌더링되고 그려지는 과정이다.

OnWillRenderObject

해당 오브젝트가 카메라에 보여지는 상황이고, UI가 아니라면

카메라 당 한 번씩 호출된다.

OnPreCull

씬이 카메라에 의해 컬링되기 직전에 호출된다.

컬링은 해당 오브젝트가 카메라에 표시될지, 표시되지 않을지 분별하는 작업이다.

OnBecameVisible/Invisible

컬링 작업을 거친 후 오브젝트가 카메라에 표시되는 것으로 판정됐을 때(Visible),

혹은 표시되지 않는 것으로 판정됐을 때(Invisible) 호출된다.

OnPreRender

씬이 화면에 본격적으로 렌더링되기 직전에 호출된다.

OnRenderObject

씬 내 모든 오브젝트들의 렌더링이 처리된 직후 호출된다.

OnPostRender

카메라의 모든 씬 렌더링이 종료된 후 호출된다.

OnRenderImage

씬의 모든 렌더링이 종료된 이후 포스트 프로세싱이 가능해진 시점에서 호출된다.

OnDrawGizmos

추가적으로 에디터 상의 화면에서 기즈모(격자)를 그려낼 필요가 있을 할 때 호출한다.

OnGUI

마지막으로 화면 상에서 UI에 해당하는 것들을 그릴 때 호출된다.

4. 기타

yield WaitForEndOfFrame

이름에서 알 수 있듯, 한 프레임이 종료될 때마다 호출된다.

특이한 점은 앞선 yield Wait 시리즈들과는 달리

화면 렌더링까지 전부 종료된 이후 화면에 나타내기 직전에 호출된다는 것이다.

OnApplicationPause

게임이 일시정지되었다는 사실을 감지한 이후 프레임의 OnApplicationPause 단계에서 호출된다.

정확히는 인자로 게임의 일시정지 여부를 bool 값으로 받고,

게임이 정상적으로 실행되고 있을 경우 false를,

무언가에 의해 멈췄을 경우 true를 반환한다.

이는 일시정지 기능을 자체적으로 제공하는 에디터에서는 물론,

빌드 버전에서도 게임 창이 다른 어플리케이션 화면들에 가려지는 등의 상황이 발생할 때 사용할 수 있다.

5. Decommissioning

바쁘게 살아온 일상,

한평생 나라를 위해 몸을 바쳐온 공주의 삶에도 끝이 찾아왔다.

매일매일 정해진 일과를 보내고 잠들기만을 반복했던 우리의 공주는

곧 영원히 잠에 들 준비를 한다.

OnApplicationQuit

에디터 기준으로 Playmode가 종료되었을 때,

빌드 버전으로 게임이 종료될 때 호출된다.

OnDisable

해당 스크립트, 혹은 해당 오브젝트가 비활성화되었을 때 호출된다.

Initialization 단계의 OnEnable과 반대격이지만 순서상 더 이후에 호출된다고 생각하면 된다.

OnDestroy

활성화돼있던 스크립트, 혹은 오브젝트가 파괴될 때 호출된다.

이렇게 해서 Unity Life Cycle의 시작과 끝을 알아보았다.

이 수많은 과정들이 고작 한 프레임 단위로 사이클을 돌고 있다니...

그것도 한두개가 아닌 스크립트와 오브젝트들에서.

이것이 참으로 갓생이 아닐 수가 없다.

대단하다 유니티!

그럼 이번 주도 끝~

5주차: 헐크 아저씨도 깜짝 놀란 Unity Render Pipeline이 작동하는 과정

원펀치 쓰리 갓냥이 — Sat, 27 Jan 2024 06:59:28 +0900

렌더링 중

컴퓨터는 사용자가 원하는 결과물을 내놓기 위해

짧은 시간 안에 수많은 연산과 상호작용을 한다.

그리고 자신이 연산해낸 것들을 사람에게 보여주기 위해

그것을 화면에 띄워내야 하는데,

이 과정 역시도 또 다른 연산들을 거쳐야 한다.

모니터는 컴퓨터가 원하는 대로 연필로 쓰고 지우개로 지워 내놓으면 그만인 도화지가 아니고,

가로 세로 정해진 개수의 픽셀들에 색을 칠해

표현된 그림을 매순간 갈아치워야 하는 애니메이션 플립 북이기 때문이다.

이 때문에 컴퓨터는 매 프레임마다 어떤 픽셀에 어떤 색을 채워 내보내야

이용자가 원하는 화면을 나타낼 수 있는지 계산해야 하고,

개발자는 그런 연산 과정을 효율적으로 잘 프로그래밍 해줘야 한다.

하지만 그렇다고 해서 모든 개발자들이

이런 과정들까지 세세하게 구현해야 할 필요는 없다.

이제 막 SpriteRenderer와 RawImage 배치를 만지작거리는 새싹 개발자들에게

해당 오브젝트들이 씬 화면에 보일 수 있도록 그 과정을 구현하게 하는 것은 좀 이상하지 않은가?

때문에 이런 과정들을 쉽게 구현할 수 있도록

순차적인 단계로 나누어 코드를 미리 작성하고,

누구나 사용할 수 있도록 모듈화된 라이브러리로 배포한 케이스가 있다.

예시로는 그래픽 라이브러리 중 인지도가 가장 높은 OpenGL, DirectX 등이 있다.

그렇다면 여기에서 위 그래픽 라이브러리들이 구현해낸 '순차적인 단계'란 무엇일까?

고화질의 2D, 혹은 3D 이미지들을 모니터에 그려내는 것은 CPU 혼자서 처리할 수 있는 일이 아니다.

CPU는 복잡한 연산도 단시간에 뚝딱 처리할 수 있는 뛰어난 성능을 가지고 있지만,

모니터에 방대한 양의 그래픽을 그려내는 것은 단일 속도만으로 커버해내기는 어렵기 때문이다.

하나의 일을 차근차근 처리하는 CPU와 단순한 일들을 병렬적으로 한 번에 처리하는 GPU

그래픽 연산은 계산 과정 자체는 단순하지만 그 양이 어마무시하게 많다.

그렇기에 복잡한 연산에 능하더라도 한 번에 많은 연산을 처리하지 못하는 CPU보다는,

간단한 연산만 가능하더라도 병렬적으로 한 번에 많은 연산을 처리할 수 있는 GPU(그래픽 카드)가 작업에 더 적합하다.

하지만 GPU가 그래픽 관련 모든 연산을 다 도맡아서 할 수는 없다.

GPU는 CPU가 하기엔 양이 많은 연산들을 가져가 대신 해주는 보조자의 역할일 뿐이므로.

때문에, CPU와 GPU의 분업이 중요할 것이다.

전체에서 누가 어떤 파트의 연산을 맡을 것인가?

연산 결과를 서로에게 어느 시점에, 어떤 방식으로 전달할 것인가?

또 어떤 단계의 연산들을 프로그래머가 직접 수정할 수 있도록 허용할 것인가?

이러한 일련의 과정을 미리 정해놓고 하나의 회로처럼 단계별로 설계한 것을 Rendering Pipeline이라고 한다.

그리고 OpenGL, DirectX, WebGL등의 유명 그래픽 라이브러리들은 전부 저마다의 Rendering Pipeline을 가지고 있다.

가장 유명한 OpenGL Rendering Pipeline

그렇다면 Unity는 과연 어떤 렌더 파이프라인을 사용할까?

Unity가 사용하는 파이프라인에는 크게 다음 세 가지가 있다.

Built-In Render Pipeline

Unity에 기본적으로 내장되어있는 파이프라인이다.

기본 아이템인 만큼 인터넷상에서 관련 정보를 찾아보기가 쉽고,

기존의 여느 타 기능들과 섞여도 잘 작동하는 보편성을 보장 받으며,

Asset Store에서 받아온 에셋들과도 호환성이 뛰어나다.

그곳에 있는 에셋들도 전부 기본 Pipeline의 사용을 염두에 두고 제작되었을 것이므로.

다만 여느 '내장 탑재'의 이름이 붙은 것들이 그러하듯,

코드의 수정이 불가능하고 사용할 수 있는 기능들이 제한적이다.

정확히 말하자면, 개발자가 코드를 직접 작성해 새로운 기능을 추가하고 싶어도 추가할 수가 없는 것이다.

Universal Render Pipeline (URP) (구 LWRP)

위의 기본 파이프라인에 비해 최적화 방면에서 더 좋은 모습을 보이는 파이프라인이다.

Lighting, Shading 등 다양한 부분에서 trade-off를 진행해,

제한된 성능의 플랫폼에서도 고사양 품질의 그래픽을 뽑아내는 것이

해당 파이프라인의 개발 목적이다.

또한 URP는 Scriptable Render Pipline(SRP)에 속한 파이프라인이기 때문에

코드 수정과 기능의 추가가 비교적 자유로워 높은 확장성을 가지고,

Shading면에서도 더 다채로운 모습을 보인다.

다만 SRP에 포함되는 만큼 코드의 수정이 많아질수록

Asset Store에 있는 에셋들과 호환이 되지 않을 가능성이 높아진다.

High Definition Render Pipeline (HDRP)

URP가 플랫폼의 성능 편차에 구애받지 않는 최적화를 추구했다면,

HDRP가 추구하는 것은 오로지 최상의 퀄리티이다.

고성능 PC, 콘솔 등 하이 엔드 급의 플랫폼들을 타겟으로 할 때 주로 사용되며,

Real-Time으로 최고 품질의 Lighting, Shading 등을 표현해내는데 용이하다.

마찬가지로 SRP에 속해있는 파이프라인으로, 코드 수정과 기능 추가가 자유롭다.

Unity 파이프라인의 종류들을 알아봤으니,

이제 실제로 그것들이 어떤 과정을 거쳐 화면에 그림을 그려내는지 알아볼 때가 되었다.

Built-In Render Pipeline의 Forward Rendering Path (가장 일반적인 렌더링 경로)

를 택했을 때의 경우를 기준으로 준비했다.

0. Pipeline Overview

Unity Built-In Render Pipeline Overview

1. Input Assembler (Vertex Specification)

그래픽 상에서 나타나는 모든 물체들은 폴리곤이라는

조그마한 삼각형들로 이루어져 있다.

곡면을 있는 그대로 계산해 묘사하기보다는

무수히 많은 평면으로 나누어 묘사하는 편이 더 효율적이고,

그러한 평면을 이루는 최소 조건이 세 개의 점, 즉 삼각형이기 때문.

때문에 이 폴리곤을 만들기 위해서는 각 폴리곤의 꼭짓점(= 정점)들이 3개씩 필요하다.

Input Assembler 단계에서 CPU가 GPU에게 정점들의 정보를 전달한다.

삼각형을 만들고 싶다면 삼각형의 꼭짓점 세 개를,

사각형을 만들고 싶다면 삼각형 두 개의 꼭짓점 여섯 개를 전달한다.

2. Vertex Shader

CPU에게서 전달받은 정점들의 좌표 정보를 있는 그대로 사용할 수는 없다.

지구라는 행성에 의자라는 모델링을 하나 추가한다고 할 때,

의자의 위치를 (209동 1305호, 안방, 컴퓨터 책상 앞)으로 계산할 수는 없지 않은가?

위도, 경도, 고도를 다 따져 범지구적인 스케일의 정확하고 범용성 있는 수치로 나타내야 한다.

이 과정을 Modeling Coordinates를 World Coordinates로 변환해주는

Model Transform (= Local Transform)이라고 한다.

위 그림과 같이 GPU가 공간 좌표계를 여러 단계 변환해주는 동시에,

개발자가 원한다면 Gouraud Shading이라 불리는

다소 원시적인 기법의 Lighting도 적용해줄 수 있는 단계이다.

Gouraud Shading: 정점 단위로 빛의 반사가 계산되는 만큼 반사광 모양이 어색하고 뾰족하게 표현된다. 옛날 3D 게임에서 자주 찾아볼 수 있다.

3. Tesselator

가까이 있는 물체는 멀리 있는 물체에 비해 폴리곤이 더 밀도있게 짜여질 필요가 있다.

폴리곤이 부족하다는 것은 곧 해상도가 떨어진다는 것이고,

가까이서 볼수록 티가 나는 것은 당연하기 때문이다.

얘는 폴리곤이 부족한게 아니라 초점이 안맞은 거긴 하지만

Tesselator라는 이름에서 알 수 있듯이

빈 공간에 타일을 채우듯 기존 모델의 정점을 쪼개어

폴리곤 사이 사이 빈 공간에 새로운 폴리곤들을 추가해

근거리에서는 더 높은 해상도를 얻을 수 있게끔 한다.

4. Geometry Shader

Tesselator에서 전달받은 새로운 정점들에 더해

기존 모델의 정점을 추가/삭제/수정할 수 있는 단계이다.

수정 단계가 끝나면 해당 정점들이 이루는 폴리곤을 추가로 생성한다.

5. Rasterizer

Rasterizer의 역할은 다양하다.

Unhinging Transformation을 통해 원근감을 부여하고,

기존 사각뿔 형태의 시야각을 직육면체 형태로 확장해 가까운 물체를 크게 키워 원근감을 부여한다.

정점과 정점 사이, 폴리곤 내부의 빈 공간들을 보간을 통해 픽셀로 채운다.

정육면체의 각 꼭짓점(정점)들을 서로 다른 색깔로 설정해두면, 보간으로 인해 폴리곤 내부에는 무지개빛 그라데이션의 픽셀들이 생성된다.

또한 카메라 시야에 들어오지 않는 픽셀들은 가차 없이 잘라낸다.

6. Depth Test

Rasterizer 이후 픽셀들을 바로 렌더링하게 되면

폴리곤들이 처리되는 순서가 실제로 카메라에 보이게 되는 순서와 무관하기 때문에

카메라 기준으로 더 뒤에 있는 폴리곤이

그 앞에 있는 폴리곤을 뚫고 나오거나, 역으로 가리는 상황이 발생할 수 있다.

폴리곤 처리 순서 차이로 큐브의 아랫면이 사라진 것처럼 보인다.

때문에 Depth Test에서 각 픽셀들의 깊이값(카메라로부터의 거리, Z값)을 계산/결정하고

Z-Buffer에 저장하는 과정을 거친다.

알고리즘 특성상 Z-Buffer에 저장된 결과값은 각 폴리곤의 처리 순서와 무관하게 항상 같다.

7. Stencil Test

Depth Test가 픽셀에 의해 가려지는 다른 픽셀, 물체의 뒷면 등이

화면에 나타나지 않도록 Z-Buffer에 값들을 저장해두는 역할을 했다면,

Stencil Test는 픽셀의 깊이(거리)와 무관하게

어떤 부분을 보이게 하고, 어떤 부분을 안보이게 할지를 개발자가 직접 설정하는 단계이다.

마찬가지로 Stencil Buffer에 픽셀의 렌더링 유무 정보를 넣는다.

선택적으로 렌더링 되지 않을 곳을 정해주는 기능이기 때문에,

그림자, 거울, 외곽선 표현 등 다양한 곳에서 사용된다.

8. Fragment Shader (= Pixel Shader)

렌더링의 꽃이라고 할 수 있는 Fragment Shader이다.

폴리곤의 픽셀들에 색을 칠하고,

Height Map, Bump Map, Normal Map 등 다양한 기법의 Texture를 적용한 뒤,

정점들과 폴리곤의 법선 벡터를 이용해 각종 Lighting 효과를 입힌다.

사람의 눈으로 보았을 때 화려하다고 느껴지는 부분의 최소 70% 이상이 구현되는 곳이며,

컴퓨터 그래픽 기술의 발전이 가장 크게 체감되는 단계이다.

9. Output Merger

Fragment Shader 이후 화면에 나타나기 전에 거치는,

사실상 렌더링에서의 마지막 단계이다.

Depth Test/Stencil Test에서 얻어낸 Z-Buffer/Stencil Buffer를 이용해

어떤 픽셀을 나타내고 어떤 픽셀을 숨길지 계산하며,

색과 색이 섞일 때의 Blending 기법을 적용하고, (예: Alpha Blending)

픽셀과 픽셀의 경계를 흐릿하게 해주는 Anti-Aliasing를 통해 계단 현상을 방지하는 등

모니터에 보이기 전 최종 마무리 단계를 거친다.

10. Post Processing

Post Processing은 1~9의 렌더링 단계를 거치고 난 뒤

필요에 따라 한 번 더 렌더링 과정을 더하는 작업이다.

블러 효과, 렌즈 효과 (빛 번짐), 화면 왜곡, 흑백/색조 변환 등

앞의 과정들에 더하여 비주얼적으로 한 층 더 발전한 결과물들을 얻어낼 수 있다.

이렇게 하여

Unity Render Pipeline의 일반적인 작동 과정을 살펴보았다.
라고 써놓기는 했지만, 사실 OpenGL이니 DirectX이니 대부분 것들의 Pipeline이

이와 비슷한 과정을 취하고 있을 것이다.

필자도 찾아보면서 그렇게 느끼기도 했고.

우리가 게임, 영화, 혹은 애니메이션에서 별 생각 없이 봤던 장면들이

실제로는 이렇게 까다로운 과정을 거쳐 화면에 나타난 거였다니...

원래도 알고는 있었지만 파면 팔수록 세상 일 돌아가는거 진짜 복잡하구나 하는 생각이 들었다.

그럼 이번 주도 끝!!!

4주차: EulerAngle아, Quaternion아, 둘이 싸우지 말고 사이좋게 지내야 한다~ (2/2)

원펀치 쓰리 갓냥이 — Thu, 18 Jan 2024 04:39:07 +0900

사실 물체의 회전을 표현하는 방식에 오일러 각만 존재하는 것은 아니다.

기존의 3개의 실수로 구성되어있던 오일러 각과 달리

1개의 실수, 3개의 허수 부분으로 구성된 사원수(Quaternion)라는

새로운 수 체계로 3차원 회전을 표현할 수 있다.

실수만으로는 전부 나타낼 수 없는 부분을 허수의 힘을 빌려 나타낸다는 점에서

복소수와 사원수가 다소 비슷해 보일 수 있으나,

몇 가지 공통점과 차이점이 있다.

공통점은 위 수식에서도 볼 수 있듯이 새로운 허수 단위를 사용한다는 것이다.

복소수의 경우 i, 사원수의 경우 i, j, k를 활용하며,

두 경우의 허수들 모두 제곱할 경우 -1이 된다는 특징이 있다.

위 식만을 볼 경우

i, j, k의 제곱값이 같다면, 그럼 결국 모두 다 같은 값인 것 아닌가?

할 수 있겠지만, 사원수의 경우 다음 한 가지 규칙이 추가된다.

때문에 만일 i = j = k을 만족할 경우 i³ = -1이 성립됨으로 인해

i² = j² = k² = -1의 공식이 깨져버리기 때문에

i, j, k는 모두 다른 허수 값임을 알 수 있다.

쉽게 이해하자면 다음과 같다.

실수 xy 좌표계(그림1)에 z 단위를 추가해 xyz 좌표계(그림2)를 만든 것처럼,

허수 i 복소수 체계(그림3)에 jk 단위를 더해 허수 ijk 사원수 체계(그림4)가 만들어진 것.

xy 좌표계에서 x와 y가 아예 다른 단위인 것처럼,

i, j, k 역시 서로 아예 다른 단위인 것이다.

어째서 시작부터 i, j, k가 서로 다른 단위임을 이토록 강조하는 것일까?

아예 다르다라는 것은 독립적이라는 의미고,

그것은 곧 서로에 대해서 종속적이지 않다는 것이기 때문이다.

회전축이 서로 종속되어있기에 문제가 발생했던 그 무언가

4차원 좌표로 회전을 표현? 어떻게?

3차원 물체의 회전을 4차원 좌표로 표현한다는 것은 조금 낯설어보일 수도 있겠다.

하지만 이는 이미 기존의 2차원 좌표계에서도 이미 잘 쓰이고 있었다.

위 복소수 평면에 원을 그리고,

원 위에서 임의의 점 P를 회전시킨다고 해보자.

점 P가 초기에 R축 위 1 지점에 있다고 할 때,

점을 반시계 방향으로 90도 회전시키고 싶다면 P의 좌표에 i를 곱하면 된다.

점 P에 i를 곱해 90도 회전시키면

1에서 i로, i에서 -1로, -1에서 -i로, 그리고 다시 1로 돌아오는 것을 확인할 수 있다.

이처럼 회전을 복소수 좌표계로 나타내면

물체의 회전을 곱셈으로 나타낼 수 있다는 큰 메리트가 생기게 된다.

위의 복소수 평면에서의 경우

회전축은 평면에서 수직으로 뚫려 나오는 방향으로 1개, 좌표 단위는 I, R로 2개였다.

그렇다면 회전축이 3개 필요한 3차원 회전의 경우 몇 개의 좌표 단위가 필요할까?

삼원수를 활용해 3개의 단위만으로 표현해보려는 시도도 있었지만,

결론부터 말하자면 4개이다.

3개의 회전축을 필요로 했던 오일러 각이 3개의 단위를 사용하고

하나의 회전축이 잠겨버렸던 것에서 짐작할 수 있었듯이,

회전축이 1개인 복소수 평면에서는 필요한 단위가 2개였던 것처럼,

우리가 직접 통제 가능한 단위의 개수는 회전축의 수보다 최소 1개 이상은 더 많아야 했다.

그리고 마침 1개의 실수 부분과 3개의 허수 부분, 총 4개의 단위를 사용하는 사원수는 이 조건을 충족했다.

이제 3차원 물체의 회전에 사원수(Quaternion)을 적용하기 위한 준비는 끝났다.

다시 돌아와, 쌩쇼를 하며 회전하는 보일러의 불판을 본 쿼터니온느는 어떤 번뜩이는 아이디어를 떠올렸다

쿼터니온느는 새로운 모델의 불판을 제안했다.

기존의 x y z에 더불어 w라는 새로운 단위를 탑재한,

언젠간 자신이 재학 중인 4차원 좌표계 공학과의 졸업 작품으로 만들어보고자 구상했던,

~~자신의 이름을 딴~~ 쿼터니언 불판이었다.

보일러가 만들었던 기존의 불판은 x y z 순서대로 세 번의 회전을 거쳐

마지막 최종 회전의 모습을 보여줬다면,

쿼터니언 불판은 x y z에 원하는 회전축의 벡터의 정보를 담고,

w에 회전각 정보를 넣어 그만큼 회전시켰다.

단 한 번의 회전으로 모든 작업이 끝났기 때문에

회전 순서에 따라 결과가 달라질 일도 없었고,

회전축의 방향이 제한되어있지 않고

회전축 벡터를 원하는 대로 지정할 수 있었기 때문에

이전과 달리 공간상으로 최단거리를 따라 이동하게끔 회전을 유도할 수 있었다.

때문에 이전처럼 회전 과정에서 보간의 오류를 야기하지도 않았다.

회전축이 잠길 일도 없었기 때문에 짐벌락 현상 역시 찾아볼 수 없었다.

머쓱

쿼터니언 회전의 한계

제한된 180˚ 이상의 회전

물론 장점만 있는 것은 아니었다.

쿼터니언 불판은 180˚이상의 회전을 한 번에 나타낼 수 없었다.

위에서 말했듯 공간상으로 최단거리를 따라 이동하게끔 되어있었기 때문에,

사전에 180 + α만큼 회전하도록 의도하고 설계했다면,

실제로 실행시켜보면 더 짧은 거리인 180 - α만큼 반대 방향으로 회전하는 것이었다.

물론 이는 보간 과정에서의 모호성을 없애기 위해서는 감당해야 할 수 밖에 없는 현상으로,

만약 180˚ 이상의 회전을 표현하고 싶은 경우

한 번의 회전이 아닌 두 번 이상의 회전으로 나누어 표현하거나,

반드시 거쳐야 하는 중간 지점을 설정해두면 해결될 일이었다.

직관적이지 못한 표기법

보일러가 만든 불판과 비교되는 가장 큰 단점이라면 단점인 부분이었다.

오일러 각으로 나타낸 (45, 0, 60), (30, 90, 0) 등의 회전각들을 보면

짐벌락이 발생하지 않는 선에서는

직관적으로 회전 이후의 모습을 예상하기 쉬웠다.

세 개의 축과 세 번의 회전이라는 오일러 각의 작동 원리가

우리 머릿속에서도 재현되기 쉬울 정도로 쉽고 직관적이었기 때문이다.

반면 쿼터니언 회전의 (10, 50, 30, 60)를 보고

회전이 적용된 이후의 고기 모습을 쉽게 예상할 수 있는 학생은 없었다.

고기가 원하는 각도까지 도달할 수 있도록 하려면 얼마만큼 회전시켜야 하는지

쿼터니언으로 나타낼 수 있는 학생도 얼마 되지 않았다.

이렇듯 더 좋은 결과의 회전을 만들어낼 수 있고 연산 횟수가 적어 컴퓨터와 불판에게는 친근했어도,

정작 불판을 만지는 학생들에게는 그렇게 쉽게 가까이 다가갈 수는 없는 표현 방식이였다.

기술적으로는 뛰어났지만 사회성은 조금 부족했던 쿼터니온느

그럼에도...

그럼에도 보일러와 쿼터니온느는 힘을 합쳐 새로운 모델의 불판을 제작해내기로 했다.

다만 둘은 어느 한 명의 의견만을 반영해 단점을 그대로 안고 가지 않고,

둘 모두의 방법을 응용, 서로의 단점을 보완해 최고의 불판이 나오도록 협업했다.

뚝딱뚝딱

학생들이 직접 불판의 조종값을 입력하고 현재의 회전값을 확인하는 데에는

직관성이 뛰어난 보일러의 불판(Euler Angle)을 응용했다.

반면 목표한 회전값까지 기계가 계산해서 자동으로 회전시켜 주는 데에는

회전축과 각도의 제약이 없어 회전이 자유로운 쿼터니온느의 불판(Quaternion)을 응용했다.

3차원 좌표계 공학과 학생과 4차원 좌표계 공학과 학생의

이런 민족 대통합과도 같은 훈훈한 일화는 세대를 타고 전해져 내려와

현대로도 이어져 Unity 시스템에도 그대로 담겨 차용되고 있다.

Unity 인스펙터 창의 Transform → Rotation란의 Vector3 회전값은 오일러 각을 사용한다.

C# 스크립트 상에서 물체의 현재 회전값을 확인하고 싶을 때도 Transform.eulerAngle에 접근해 알아낸다.

하지만 우리가 물체를 직접 회전시키거나 회전값을 수정하고 싶을 때에는 Quaternion.Euler(x, y, z)를 사용한다.

(x, y, z)에 우리가 원하는 물체의 오일러 각을 넣으면,

컴퓨터가 그것에 대응되는 알맞은 쿼터니언으로 변환하고 회전에 사용한다는 것이다.

이후 고기를 맛있게 구워먹었다.

이렇게 싸울듯 말듯 투닥투닥 다투던 보일러와 쿼터니온느는

어느 순간 자신들의 감정이 깊어져 가는 것을 확인했고

대학을 졸업한 후 결혼에 성공적으로 골인했다.

끝.

끼야아아아악

뭐요.

3주차: EulerAngle아, Quaternion아, 둘이 싸우지 말고 사이좋게 지내야 한다~ (1/2)

원펀치 쓰리 갓냥이 — Sat, 13 Jan 2024 19:50:03 +0900

아주 먼 옛날, 세상에 스마트폰과 챗GPT가 보급되지 않았던 시절,

마법이라는 이름으로 수학과 과학이라는 신비로운 학문을 연구하던 시대가 있었다.

그리고 여기, 영국의 명문 제빵 마법 학교인 호그로와상에 두 에이스 학생,

보일러 드리프트와 쿼터니온느 그라인더가 있다.

보일러는 불속성 마법 융합대학 소속의 3차원 좌표계 공학과 학생이었고,

쿼터니온느는 같은 융합대학 소속의 과만 다른 4차원 좌표계 공학과 학생으로 둘은 친하게 지내는 편이었다.

그러던 어느 날, 호그로와상 불속성 마법 융합대학의 MT가 열렸다.

MT에 참석한 학생들은 각 학과들끼리 모여 바비큐 파티를 가지려 했으나,

얇고 넓은 사이즈의 바비큐 고기에 비해

좁고 강한 세기의 숯불로 학생들의 파티는 난항을 겪었다.

고기를 골고루 굽고 싶었으나 고기의 중심부만 가열되는 것이었다.

이에 3차원 좌표계 공학과의 에이스 보일러 학생은 다음과 같은 방식으로 고기를 굽기 시작했다.

보일러의 동기들은 이 현란한 불판의 움직임을 보며

바비큐 고기의 모든 부분을 골고루 구울 수 있는 최고의 방식이라고 극찬했다.

그러나 이 방식을 옆 테이블에 지켜본

4차원 좌표계 공학과의 에이스 쿼터니온느는 화들짝 놀랐다.

아니 저런 식으로 구우면, 불판을 원하는 대로 회전시킬 수 없을 텐데?

과연 고기를 제대로 구울 수나 있을까?

똑똑한 쿼터니온느가 우려했던 위 불판에서의 문제점은,

바로 3차원 회전에서 발생할 수 있는 짐벌락 현상이었다.

이에 3차원 좌표계 공학과 학생들과 4차원 좌표계 공학과 학생들은

위 문제에 관련된 심도 깊은 토론을 하기 위해

즉시 모든 바비큐 파티를 중단하고 테이블을 한데 모아 긴급 회의를 시작했다.

오일러 각

오일러 각은 3차원 공간에 놓인 물체의 회전 상태를 세 번의 축회전으로 나타내는 각도 표현 방식이다.

예를 들어 오일러 각이 (45, 60, 20)인 물체는

X축 회전으로 45도, Y축 회전으로 60도, Z축 회전으로 20도 회전한 결과물이라고 볼 수 있다.

이 회전 방식의 독특한 점은

물체가 회전할 시, 자신을 제외한 다른 회전축들 역시 같이 회전할 수 있다는 것이다.

예를 들어 X축 회전 시 Y, Z축이,

Y축 회전 시 Z축이 같이 회전할 가능성이 생긴다.

이러한 회전축들 사이의 독립적이지 않은 종속적인 관계가,

이어서 나오게 될 오일러 각의 여러 한계들을 유발하는 결정적 원인이 된다.

오일러 각의 한계

1. 회전 순서에 따라 달라지는 결과

하나의 회전축이 자신을 제외한 다른 축들에게도 영향을 주는 묘한 특성 때문에,

물체를 회전시키는 순서에 따라 아예 다른 결과물이 나오게 된다.

아주 같은 케이스는 아니지만 비슷한 케이스를 조금 보도록 하자.

학생 A와 B는 학교 운동장에서 보물지도를 발견했다.

보물지도에는 다음 세 문장이 적혀있었다.

같은 보물지도를 발견한 학생 A와 B였지만, 기억한 내용은 달랐다.

학생 A는 지도에 적힌 순서대로(1→2→3) 길을 맞게 찾아갔고,

학생 B는 거리와 방향은 정확히 기억했지만 순서를 헷갈려(1→3→2) 도착한 곳이 달라지게 되었다.

A 학생( 1→2→3 )과 B 학생(1→3→2)의 이동 경로 차이

A와 B 모두 1, 2, 3 문장을 합쳐

총합 오른쪽으로 여섯 보, 왼쪽으로 이 보 이동한 것은 똑같은데,

어째서 도착한 곳이 달라진 걸까?

이는 이동하기 위해 서 있던 곳에서 오른쪽/왼쪽을 바라보는 행위가,

그 다음 순서의 오른쪽/왼쪽의 기준을 바꾸었기 때문이다.

오일러 각에서의 회전 역시 마찬가지다.

축끼리의 회전이 독립적이지 못하고 종속적이기 때문에,

X축의 회전은 다음 회전에 쓰일 Y, Z축의 형태에 영향을 끼치고,

다음 회전의 모양이 달라지게 된다.

당연하게도 Y, Z축의 회전 역시 마찬가지이다.

위에서 언급한 (45, 60, 20) 오일러각의 경우도

X를 45도 회전, Y를 60도 회전, Z를 20도 회전하는 경우와

X를 45도 회전, Z를 20도 회전, Y를 60도 회전하는 경우의 회전 결과가 다르게 나타나는 것이다.

때문에 실제로 오일러각을 나타내는 방법에는 다음 12가지가 있다.

XYZ, ZXY, ZXZ, XYX, YXY, YZY,

ZYZ, ZXZ, XZY, YXZ, YZX, ZYX

(α, β, γ)의 각도가 주어지고 위 12가지 방법에 따라

XYZ의 경우 X를 α만큼, Y를 β만큼, Z를 γ만큼,

ZXY의 경우 Z를 α만큼, X를 β만큼, Y를 γ만큼

순서에 따른 차이를 발생시키지 않기 위해

미리 약속된 순서대로 주어진 각도를 회전시키는 방식이다.

이렇게 어떻게든 해결책이 마련이 되기는 했지만,

회전 순서에 따라 결과가 달라질 수 있다는 점은

여전히 회전을 표현하는 방식에 있어서 크나큰 단점이다.

어후 3차원 애들이란 ㅉㅉ

2. 보간의 문제

학술적인 연구도 중요하지만 결국 배고픔 앞에 장사가 없다는 것을 알아차린 호그로와상 불속성 마법 융합대학 학생들은,

결국 회의를 중단하고 다시 바비큐 파티를 재개했다.

회의를 통해 별 다른 대안을 찾지 못했기 때문에 학생들은 보일러의 불판을 계속 사용했고,

이는 쿼터니온느의 심술을 돋구기에 충분했다.

쿼터니온느에게 있어서 배고픔보다도 더 거부감이 드는 것은

3차원 좌표계 공학과 학생들의 멍청함과 안일함이기 때문이었다.

군침을 흘리며 기다리는 학생들을 보다못한 쿼터니온느는 결국 불판을 담당하는 보일러에게 요청했다.

쿼터니온느의 속셈을 몰랐던 보일러는 그대로 불판을 회전시켜 주었다.

그리고 고기가 익기를 조금 기다린 뒤,

쿼터니온느는 우매한 3차원 좌표계 공학과 학생들에게 결정적인 한 방을 날렸다.

보일러는 쿼터니온느의 요청대로 불판을 회전시켜 주었다.

그리고 이윽고 보여지는 광경에,

3차원 좌표계 공학과 학생들은 충격과 공포에 빠져 그대로 그 자리에 얼어붙어버렸다.

수직 위 방향(-90, 90, -90)을 가리키고 있던 고기는

직관적인 일직선 궤적이 아닌

알 수 없는 이상한 궤적을 그리며 원위치(0, 0, 0)로 돌아오는 것이었다.

끼야아아아악

이 현상의 원인을 이해하기 위해 알고 있어야 하는 오일러 각의 또 하나의 특징은

(α, β, γ) 각에서 α, β, γ은 모두 -180°와 180° 사이의 각을 가진다는 것이다. (or -π ~ π)

여기서 -180°와 180°는 같은 크기의 각이고,

180°에서 1°를 더한 181°의 경우 -179°와 완전히 같다.

각도는 결국 회전이고,

한 바퀴를 회전하든 두 바퀴를 회전하든

회전한 바퀴수가 각도에 표현되어야 할 이유는 없기 때문에

360°를 주기로 -180°과 180° 사이를 반복하게 되는 것이다.

여기서 문제가 생긴다.

아까와 마찬가지로 보물지도 문제이다.

학생 A와 B는 학교 운동장에서 보물지도를 찾았다.

보물지도에는 다음 세 문장이 적혀있었다.

같은 보물지도를 발견했지만, 학생 A와 B의 해석은 달랐다.

학생 A는 단순히 (-120 + 60) / 2 = -30임을 인식해 -30° 지점으로 달려가 열심히 땅을 파기 시작했다.

반면 학생 B는 -120° = 240°임을 이용, (240 + 60) / 2 = 150임을 인식해 150° 지점으로 달려가 열심히 땅을 파기 시작했다.

A: (-120 + 60) / 2 = -30 ------------------------------------------------------------ B: (240 + 60) / 2 = 150

결국 두 지점 모두 나름의 정답이었고,

이러한 중간값의 모호성은 컴퓨터로 하여금 우리가 의도하지 않은 계산값을 내놓게 한다.

컴퓨터를 이용해 게임 혹은 영화의 애니메이션을 제작할 때,

우리는 위치와 각도의 보간값을 많이 사용한다.

보간값은 임의의 두 지점 사이의 중간값, 혹은 사전에 정해둔 비율의 사잇값으로,

대상의 더 매끄러운 움직임을 구현하기 사용된다.

예시를 들자면 주인공이 검을 휘두르는 모션을 제작하기 위해

검을 위로 치켜드는 프레임에서 팔의 각도를 0°,

검을 아래로 내리친 이후의 프레임에서 팔의 각도를 90°로 설정하고

그 사이의 프레임을 0°와 90°사이의 수없이 많은 보간값들로 채워

검을 든 팔이 부드럽게 내려가는 모습을 연출하는 것이다.

하지만 이 계산을 컴퓨터에게 맡기게 된다면 문제가 발생할 수 있다.

개발자는 0° → 10° → 45° → 80° → 90°의 각도 변화를 의도했겠지만,

컴퓨터는 0° → -10° → -135° → 100°(-260°) → 90°(-270°)로 팔이 반대방향으로 돌 수도 있는 것이다.

오일러 각에서 45°와 -135° 모두 0°와 90°의 중간값이기 때문.

아까 보일러가 고기 굽던 불판을 다시 생각해보자.

위 불판이 이상한 궤적을 그리며 원위치로 돌아온 이유는 계산이 잘못돼서가 아니라,

(-90, 90, -90)에서 (0, 0, 0)으로 이동할 때

공간상으로 가까운 지름길 좌표들을 거치는 것이 아닌,

오일러 각으로 나타내었을 때 수치적으로 정직하게 가까운 좌표인

(-90, 90, -90) → (-45, 45, -45) → (0, 0, 0)

를 거쳐 이동했기 때문이다.

10°와 363° 중 1°에 더 가까운 것은 무엇일까?

수치상으로 보았을 때는 10°이다. 1°에서 9°만큼만 더 이동하면 되기 때문이다.

하지만 실제 공간상으로 나타내어 보았을 때는 1°에서 무려 362°나 더 가야 하는 363°가 더 가까운 곳에 있다.

또한 우리가 직접 보고 생각하는 1°와 363°의 중간값과 ((1 + 3) / 2 = 2°)

컴퓨터가 생각하는 1°와 363°의 중간값은 다르다. ((1 + 363) / 2 = 182 = -178°)

이러한 모호성, 그리고 각도의 수치상의 크기가 공간상에서의 크기와 일치하지 않는 특성은

회전 계산에 있어서 오일러 각의 크나큰 맹점이다.

그니까 고기 그만 구워라 보일러

3. 짐벌락

바비큐 장에 잠시 혼란이 찾아왔지만, 학생들은 이내

'회전 과정에서 약간의 궤도 이탈이 일어나는 것 정도는 고기가 구워지는데 문제가 되지 않는다.'

라고 판단, 불판을 계속해서 보일러에게 맡기고 고기를 굽기 시작했다.

쿼터니온느는 이 상황이 정말로 마음에 들지 않았다.

그녀 내면의 심술 뚜껑이 날아가 버릴 정도로 속이 매우 매우 끓고 있었다.

보일러가 모두에게 주목받는 것도, 바비큐 파티의 영웅이 되는 것도,

모두 그저 끔찍한 상황이라고 생각했다.

쿼터니온느는 보일러에게 다시 은근슬쩍 다가가 요청했다.

보일러는 쿼터니온느의 행동을 이해하지 못했다.

분명 어제까지만 해도 친한 친구였는데,

어째서 갑자기 나를 계속해서 함정에 빠트리고 난처하게 만드는 거지?

내가 무엇을 잘못한 거지?

하지만 보일러는 학생들에게 맛있는 고기를 먹이고 싶었다.

(90, 0, 0)로 불판을 회전시키면 실제로 고기의 윗부분이 밑으로 내려가게 되기 때문에,

쿼터니온느의 말에 일리가 있다 생각하고 불판을 회전시켰다.

고기의 윗부분이 맛있게 구워지는 동안,

쿼터니온느는 다음 말을 내뱉어버렸다.

이제 제발 그만...

이 일에 충격을 받은 보일러는 그야말로 펑펑 울었다.

세상이 자신을 억까한다는 생각이 들었고

계속해서 자신을 괴롭히는 쿼터니온느가 원망스러워졌다.

고기의 모든 면을 자유자재로 구워야 할 수 있는 불판이,

3차원 회전임에도 불구하고 회전축이 3개에서 2개로 줄어드는 일은

자기 자신이 보기에도 도저히 용납할 수 없었다.

보일러는 세상이 미웠다.

보일러와 쿼터니온느 사이의 신경전을 그저 웃기다며 구경만 하고 있는 학생들도 미웠다.

보일러는 몽둥이를 들고와 자신이 만들었던 불판을 마구 부수기로 마음 먹었다.

불판이라면 고기의 모든 면을 잘 구워내야 하는 것을,

제대로 회전도 못하면 그걸 어따 쓰농!

이라면서.

보일러가 몽둥이를 들어올리려는 찰나,

쿼터니온느가 그 앞을 가로막아섰다.

보일러가 들고있는 몽둥이를 뺏어 저 멀리 던졌고,

찌질하게 그만 좀 울으라고 휴지를 앞에 툭 내놨다.

보일러는 그런 쿼터니온느의 행동을 도무지 이해할 수 없었다.

얜 대체 왜 이러는 걸까.

모두의 주목 속에서 보일러의 울음이 그치려는 찰나,

쿼터니온느가 그 원리를 차분히 설명했다.

짐벌락은 아까 보간의 문제 부분에서 보았던 고기 불판의 기이한 움직임에서 추가로 이어진다.

불판이 (-90, 90, -90)에서 (0, 0, 0)로 바로 회전할 수 없었던 이유는

보간의 문제를 이용해서도 설명할 수 있지만,

다음 예시에서와 같이 컴퓨터 모델로 직접 구현하여 실행해보면

불판이 잘 회전을 하다가 어느 순간

불판을 회전시켜 줄 수 있는 회전축이 하나가 사라진다는 것을 알 수 있다.

가장 바깥쪽 회전과 가장 안쪽 회전이 '아예 같은 회전'이 되어버렸다

서로 다른 회전축에 수직인 두 개의 평면이 아예 포개어지는 상황이 발생하고,

물체의 현재 상태를 기준으로 X, Y, Z축 방향 모든 곳으로 회전할 수 있었던 불판이,

어느 순간 하나의 회전 방향을 잃게 된 것이다.

이런 식으로 특정 조건에서 하나의 회전축 자유도를 잃게 되는 현상을 짐벌락이라고 하며,

이는 3차원 공간의 회전에서 오일러 각이 제대로 쓰일 수 없는 가장 큰 이유가 된다.

세 가지 회전축을 사용하는 오일러 각은

회전 순서에 따라 결과값이 달라지는 모순이 있으며,

두 각도 사이의 보간값이 항상 정확하지는 않다는 모호성이 있고,

심지어 특정 조건을 만족시킬 경우 하나의 회전축이 아예 사라지는 문제가 있다.

그렇다면 3차원 공간에서 물체의 회전을 온전히 표현할 수 있는 방법은 아예 없는 것일까?

만약 있다면, 대체 어떤 방법을 사용해야 할까?

그저 학생들과 함께 골고루 익힌 고기가 먹고 싶어

직접 기지를 발휘해 불판을 만들고 맛있게 고기를 구워보려 하는 보일러를,

굳이 못 굽게 막고 딴지 걸고 지독하게 괴롭히는 쿼터니온느는,

대체 무슨 꿍꿍이인걸까?

이는 다음 주,

EulerAngle아, Quaternion아, 둘이 싸우지 말고 사이좋게 지내야 한다~ (2/2)

에서 이어서 다루어보겠다.

생각지도 못하게 양이 많아져 2부작이 되었다...

2주차: 의외로 세상 잡다한 Transform에 대한 모든 것

원펀치 쓰리 갓냥이 — Sun, 7 Jan 2024 21:34:22 +0900

이번 주는 Unity 개발을 하다보면 무조건 알 수밖에 없는 Transform에 대한 것이다.

Transform은 Scene 화면 내의 사실상 모든 오브젝트에 포함되어있는 필수 컴포넌트로(Canvas, UI 제외),

흔히들 오브젝트의 위치, 회전각, 크기 등의 정보들이 담겨져 있는 것으로 알고 있으며,

Hierarchy 창에서의 오브젝트 부모 자식 관계도 Transfrom에서 관리된다.

필수 컴포넌트인 만큼 우리가 자주 접하고 사용하지만,

의외로 우리는 이 친구에 대해서 아는 것이 많이 없다.

나를 포함, 대다수의 입문 개발자들은 보통

위치, 회전, 크기, 오브젝트 부모 자식의 상속이라는 Transform의 큼직한 역할만 알고 있지,

구체적으로 어떤 세부 기능들이 있는지는 잘 모르는 경우가 많기 때문이다.

반에서 항상 반장을 도맡아 하고, 주변에서 친하게 안 지내본 친구가 없다는 엄청난 인싸 녀석이

정작 의외로 그 녀석이 어디에서 사는지, 평소에 속으로 무슨 생각을 하고 다니는지는 아무도 모르는,

비밀에 숨겨진 그런 인싸 친구랄까?

오늘은 그런 불쌍한 친구와 속을 터놓고 이야기해보고자,

Transform에 담겨있는 자세한 내용들을 Position, Rotation, Scale, Parent,

이렇게 네 가지 분류로 나누어 알아볼 예정이다.

자세한 이야기를 시작하기에 앞서,

Transform 클래스는 사실 Object 클래스를 상속한 Component 클래스를 상속하고 있다.

Transform 클래스가 Component 클래스를 상속

그리고 Component 클래스가 Object 클래스를 상속 / 여기서 Object는 System.Object가 아닌 UnityEngine.Object

때문에 Transform 클래스는 Component 클래스, Object 클래스가 가지고 있는 속성들을 모두 공통적으로 가지고 있으며,

이것들에 대한 설명은 본 게시물에서 따로 다루지 않을 생각이다.

Transform 고유의 속성들만으로도 충분히 양이 많다.

친구랑 제대로 대화 해보기도 전에 아빠랑 할아버지가 누군지까지 알아버렸다

Transform의 속성 중 너무 유명한 녀석들은

회색 글씨로 그냥 짧게만 설명하고 바로 넘어갈 것이다.

1. Position

1) public Vector3 forward, right, up

파란색이 forward, 빨간색이 right, 초록색이 up

이미 잘 알려진 녀석이다.

오브젝트를 기준으로 세 가지 방향축을 나타내는 3차원 벡터이다.

2) public Vector3 position, localPosition

마찬가지로 이미 유명하다.

position은 오브젝트의 world 상에서의 좌표를 나타내는 3차원 벡터,

localPosition은 부모(0, 0, 0)를 기준으로 했을 때의 상대적인 좌표를 나타내는 3차원 벡터이다.

3) public Matrix4x4 localToWorldMatrix, worldToLocalMatrix

localPostion(로컬 좌표계)을 position(월드 좌표계)으로,

position(월드 좌표계)을 localPosition(로컬 좌표계)으로 변환하는 데에 사용되는 4차원 변환행렬이다.

localToWorldMatrix 행렬을 localPosition 앞에,

혹은 worldToLocalMatrix 행렬을 position 앞에 곱하여 좌표계가 변환된 결과를 얻어낼 수 있다.

왜 월드 좌표계와 로컬 좌표계를 오가는데 4차원 행렬을 곱하느냐? 한다면...

사실 단순 좌표계 변환 뿐만 아니라 위치, 회전, 크기 조정 모두 4차원 행렬의 곱으로 표현할 수 있고,

실제로도 Transform의 작동 원리 또한 그러하기 때문이다.

(tx, ty, tz)만큼 위치 이동 변환

θ각만큼 z축 회전 변환

(sx, sy, sz)만큼 확대/축소 변환

이렇게 해서 좌표계 변환 또한 행렬의 곱으로 나타낼 수 있다. 좌표계 변환 역시 위치 이동, 회전, 확대/축소의 연속일 것이므로.

Vector3 lPosition = transform.localPosition;
Vector3 wPosition1 = transform.position;
Vector3 wPosition2 = transform.localToWorldMatrix
       			* new Vector4(lPosition.x, lPosition.y, lPosition.z, 1);

//is wPosition1 equivalent to wPosition2? << yes

그리하여 좌표계 변환을 할 때 위 식에서 가운데에 곱해주는 변환행렬 역할을 하는 것이

localToWorldMatrix, worldToLocalMatrix 인 것이다.

곱해주기만 하면 원하는 좌표계에서의 좌표가 출력될 수 있게끔

이동, 회전 등의 연산들이 미리 적용되어 있는

변환행렬계의 밀키트라 볼 수 있겠다.

Transform 내에서 미리 계산하여 넘겨주는 것이기 때문에 당연히 읽기 전용이고,

수정이 불가능하다.

4) TransformDirection, InverseTransformDirection
TransformPoint, InverseTransformPoint
TransformVector, InverseTransformVector

바로 위에서 설명했던 4차원 변환행렬 친구들과 비슷한 녀석들이다.

다만 아까 그 친구는 4차원 변환행렬을 제공하는 것에서 그쳤다면,

이 녀석들은 변환까지 직접 해주는 함수들이다.

각각

local에서의 direction(forward, up, right)을 world에서의 direction으로,

local에서의 point를 world에서의 point로,

local에서의 vector를 world에서의 vector로

변환해준다.

예)

Vector3 wForward = transform.TransformDirection(Vector3.forward);

Inverse가 붙었을 경우 전과는 반대로 world에서 local로 변환해준다.

5) Translate

유명한 녀석이다.

transform의 position 좌표를 이동시켜주는 함수이며,

transform.position += new Vector3(speed * Time.deltaTime, 0, 0);

과 함께 가장 많이 쓰이는 오브젝트 이동 수단이다.

예)

transform.translate(Vector3.forward * speed * TIme.deltaTime);

2. Rotation

1) public Vector3 eulerAngles, localEulerAngles

오브젝트의 회전각을 오일러각(Vector3)의 형태로 표현한다.

local이 붙은 경우 world에서의 회전각이 아닌 부모 좌표계에서의 회전각을 나타낸다.

2) public Quaternion rotation, localRotation

오브젝트의 회전각을 쿼터니온(Quaternion)의 형태로 표현한다.

local이 붙은 경우 world에서의 회전각이 아닌 부모 좌표계에서의 회전각을 나타낸다.

왜 회전각을 굳이 오일러각과 쿼터니온으로 구분해서 표현할까...?

에 대해서는 3주차(Quaternion)에서 알아볼 예정이다.

3) LookAt

transform.LookAt(장난감.transform);

오브젝트의 forward 벡터가 특정 방향을 가리키도록 자동으로 회전시켜주는 함수이다.

여기에서 특정 방향이라 함은 LookAt 함수에 인자로 전달받은 Transform을 바라보는 방향이다.

허나 3차원 좌표계일 경우 단순히 바라보기만 한다면 문제가 조금 생길 수 있다.

오브젝트가 말 그대로 목표 Transform을 '바라보기만 하면' 되는 것이기 떄문에

내가 원하지 않는 각도로 오브젝트가 갸우뚱하면서 바라보는 상황이 생길 수 있다.

3명의 박진영은 모두 당신을 잘 '바라보고' 있기 때문에 LookAt 함수는 잘 적용되고 있다. 다만 내가 저런 각도를 원하지 않을 뿐.

때문에 LookAt 함수의 인자로 바라볼 대상 Transform에다가

윗벡터 Vector3를 하나 더 넣어주면 이런 문제를 해결할 수 있다.

transform.LookAt(target, Vector3.up);

오브젝트가 취할 수 있는 여러 각도 중 Transform 방향을 바라보는 각도는 무수히 많으나,

그 동시에 제3의 윗벡터가 오브젝트의 머리 위로 오게끔 하는 각도는 단 하나로 결정되기 때문에

이것으로 원하는 모습의 회전을 만들어낼 수 있는 것이다.

이제 각도는 괜찮은데 걍 사진이 문제

4) Rotate

흔히 아는 오브젝트를 회전시키는 함수이다.

현재 회전각에서 상대적인 수치만큼 회전시키고 싶다면

인자로 오일러각 Vector3를,

아예 절대적인 각도를 대입하고 싶다면

인자로 오일러각 Vector3와 함께 Space.World를 넣는다.

5) RotateAround

Rotate는 항상 오브젝트의 중심을 기준으로 회전하는 반면,

RotateAround는 회전의 중심이 되는 점 좌표 (Vector3), 회전축 벡터 (Vector3), 회전각 (float)

세 가지를 인자로 넘겨주면

원하는 중심축을 기준으로, 원하는 각도만큼 오브젝트를 회전시킬 수 있다.

3. Scale

1) public Vector3 localScale

흔히 쓰이는 transform의 크기 속성이다. 다만 parent 오브젝트에 대한 상대적인 크기라는 특징이 있다.

2) public Vector3 lossyScale

world 좌표계를 기준으로 하는, 오브젝트의 절대적인 크기이다.

lossyScale은 읽기 전용이기 때문에 우리가 직접적으로 수정할 수 없다는 특징이 있지만,

parent를 null로 설정해놓고 localScale을 원하는 크기만큼 조정한 다음,

다시 원래의 parent를 설정하는 식으로 lossyScale을 간접적으로 수정하는 방법이 있다.

4. Parent

1) public Transform root, parent

이름에서 알 수 있듯이, 해당 transform이 속한 오브젝트의 상위 오브젝트 transform을 저장해놓는 곳이다.

transform.parent를 통해 자신의 부모 오브젝트의 transform을,

transform.root을 통해 최상위 계층의 부모 오브젝트를 얻을 수 있다.

root의 경우 자신 위의 오브젝트가 존재하지 않으면 자기 자신을 반환하기 때문에 null이 나올 수 없다.

public void SetParent(Transform parent)를 통해 자신의 부모를 바꿀 수도 있다.

2) public int childCount

자신이 가지고 있는 child의 수를 반환한다.

비활성화돼있는 child 역시 카운팅에 포함되며,

모든 자식 오브젝트를 순회해야 할 일이 있을 때 유용하게 쓰인다.

3) Find, GetChild

자신이 가지고 있는 child 중 원하는 child를 얻어야 할 때 쓰인다.

Find의 경우에는 오브젝트의 이름(string)을 인자로 받으며,

GetChild는 찾고자 하는 child가 몇 번째 child인지 그 index(int)를 인자로 받는다.

4) DetachChildren

자신이 가지고 있는 모든 child를 부모 자식 관계를 끊고 unparent 시킨다.

진짜 무서운 함수다.

5) GetSiblingIndex, SetSiblingIndex

부모의 child 중 자신이 몇 번째인지 정보를 얻거나,

몇 번째 child가 되겠다고 변경한다.

즉 child간의 순서를 얻고 수정하는 속성이다.

오늘 서열 정리 좀 해야 쓰것다

6) SetAsFirstSibling, SetAsLastSibling

형제(Sibling) 중 첫 번째, 혹은 마지막 child로 순서를 변경한다.

etc.

public bool hasChanged

Transform에 있는 속성 중 내게 가장 생소한 속성이었다.

position, rotation, scale 등 Transform의 속성 중 하나라도 변한 것이 있다면 true를 반환한다.

다만 우리의 기대와는 달리 우리가 따로 Transform의 내용들을 수정한 적이 없어도

항상 매 프레임 true를 반환한다고 한다.

그 이유는 Transform의 속성 중 hasTransform이라는 녀석이 있는데,

이 녀석이 매 프레임마다 true로 변경되고, 프레임이 끝날 때쯤 fasle로 변경된 뒤 프레임이 종료되기 때문에

hasTransform의 변경 사실을 감지하고 hasChanged가 항상 true를 반환한다는 것이다.

때문에 false인 모습의 hasChanged를 보고 싶다면 개발자가 따로 타이밍을 정해

hasTransform 녀석과 원만한 합의를 봐야할 것이다.

아니면 직접 hasTransform = false로 값을 대입하던가.

이렇게 해서 Transform 안에 있는 속성들에 대해

자주 쓸 일 있는, 혹은 거의 써볼 일 없는 것들까지 전부 다 알아보았다.

Transform 정도면 간단한 기능 몇 개 있는 만만한 녀석일 거라 생각했는데...
양이 너무 많았다.

이 바닥 겸손해야 한다.

다음 주에 다시 돌아오겠다...