Assimp라는 걸 사용해서 FBX를 로드해 볼 것이다.
1. 오리엔테이션
1) Unitychan 에셋 안의 구성요소 중 Model은 무엇인가
유니티 3D 에셋을 받아서 보면 뭐가 뭔지 모르는 게 많이 들어가 있음을 볼 수 있다.
Animation, Material, Model, Texture, Shader 이런 것들이 머릿속에 정리가 잘 되지 않았었다.
오늘 알아볼 핵심은 Models라고 볼 수 있다.
지금까지 배운 내용들을 돌이켜 보면 에셋에 대해 알 수 있다.
Material은 Shader에 넘겨주고 싶은 인자값들을 모아서 관리하는 것이고,
Shader는 사실상 GPU가 뭔가를 그릴 때 GPU한테 명령을 내리기 위한 기술서 같은 거다.
Animation은 아직 안 해봤다.
오늘 배울 Model은 유니티에서 unitychan 에셋을 넣고 폴더에 들어가 살펴보면 fbx 포맷으로 되어 있는 것을 볼 수 있다. fbx 포맷만 있는 게 아니라 obj 등 여러 포맷들이 있다. 지금까지는 메쉬를 만들 때 코드로 큐브도 만들어 보고 스피어도 만들어 보고 했다. 그런 물체들을 만들어서 uv 매핑으로 텍스쳐를 입히고, 쉐이더를 작성하고 거기에 Material을 통해서 이런저런 정보들을 넘겨줬다. 이제는 뭔가 그럴싸한 물체를 만들게 될 텐데 큐브 같이 단순하지 않기 때문에 코드로만 만들 수 없을 것이다. 3D맥스 같은 툴을 이용해 캐릭터를 만들어서 추출하면 FBX라는 파일로 나오게 되는데 중요한 거는 이 아이가 포함하고 있는 정보가 무엇인가이다.
2) 3D 모델링 파일을 추출해서 얻은 FBX파일이 포함하고 있는 정보
오늘 fbx 파일을 로드해서 살펴볼 것인데 열어 보면 굉장히 복잡하다.
fbx파일 하나에 여러 가지 메쉬들로 이루어져 있는 걸 볼 수 있고, material 정보, lighting 정보, camera 정보 등 다양한 포맷의 정보가 들어가 있다.
어떤 모델을 나타내는 건데 왜 이렇게 잡동사니 정보가 많을까. vertex, index buffer정보만 들어가 있어서 Geometry 만 표현하면 되는 거 아닌가 왜 이렇게 복잡하게 되어 있는가 싶겠지만, 3D모델이 꼭 게임용이라는 보장이 있는 건 아니다. 다양한 용도로 활용되기 때문에 FBX 도 복잡한 것이고, 순수 게임용으로 만들어진 게 아닌 것이다
게임을 만들 때는 따로 light를 설치하기 때문에 보통은 조명 정보 같은 건 필요하지 않을 것이다. 필요한 내용들만 뽑아 먹어야 한다.
물체 같은 경우도 한번 배치하면 끝나는 경우가 있는 반면, 애니메이션이 들어가야 하는 경우도 있다. 스테틱 메시와 스켈레탈 메시로 구분하는데 고정된 상태면 스테틱 메시, 나중에 팔을 휘두르거나 애니가 들어가면 복잡한 얘기가 된다.
애니는 다음 주에 할 예정이다.
3) 2D와 다른 계층 구조를 가진 3D 모델로 애니메이션을 구현하는 방법
머리를 두리번거리며 브레스를 뿜는다면 2D에서는 스프라이트 여러 개 만들어서 틀어주면 됐는데 3D에서는 메시가 3각형으로 이루어진 집합이라 했다. 만약 고개를 살짝 돌리는 상태를 만들고 싶으면 고개를 돌린 메시를 만들어서 포즈를 30개 만들어서 저장해서 하나씩 틀어주면 되겠다 싶지만 2D와는 다른 점은 굉장히 많은 삼각형들로 이루어져 있다. 이 모든 정보들을 살짝 다르게 다른 메시로 만든다는 건 말이 안 된다. Cbuffer에 뭔가 꽂아 주는 것도 틀린 얘기는 아니지만 삼각형 개수가 어마무시하게 많기 때문에 매번 갱신하는 게 말이 안 된다. 기존에 2D방식으로는 애니메이션을 구현할 수 없다.
이렇게 설명하는 건 이어지는 이야기이기 때문이다.
결국 뼈대를 넣어서 모든 정보를 갱신하는 건 말이 안 되니 뼈대 방식으로 계층 구조를 만들어 준 다음에 어느 부분만 움직이게끔 수학적으로 계산해서 움직이는 게 핵심이다.
유니티짱의 Model도 유심히 보면 여러 계층 구조로 되어 있다.
부위별로 되어있다. 이걸 통해서 애니메이션을 돌려줄 것이다.
원본 메시 자체는 변하지 않고, 세부적으로 변하는 부분만 고쳐줘야 한다.
모든 부분들이 움직이는 건 아니기 때문에 특정 부분만 움직이게끔 우리가 뼈대라는 정보를 넣어서 움직인다가 핵심적인 내용이 된다.
리깅이랑 그런 거도 들어가지만 아직 좀 먼 얘기이다.
4) 계층구조의 모델 파일을 자료구조에 파싱하는 방법
오늘 해야 할 건
아직 애니를 적용할 게 아니라서 물체를 하나 짜리로 볼 것이긴 하다
그럼에도 불구하고 FBX포맷 상으로는 계층 구조로 들어가 있는 경우가 많기 때문에 파싱을 할 때부터 계층 구조를 생각해서 작업을 할 것이다.
계층 구조라는 건 자료구조로 표현하면 뭐라 할 수 있을까. 트리를 이용하는 게 직관성이 있을 것이다.
벡터를 이용하기엔 벅차고, 트리라는 건 하나의 노드를 기반으로 parent 노드가 있을 것이고, 여러 가지 자식들을 자신들의 자식들로, 벡터이건 뭔가로 집어넣어서 계층 구조로 표현할 수 있을 것이다.
자료구조 알고리즘 시간에 트리 실습을 해보면서 해봤었다.
트리를 기준으로 순회를 할 때 순서라는 게 보장이 되어 있지 않는데 재귀함수를 이용해 작업을 하면 트리를 순회하는데 궁합이 잘 맞는다. 루트를 기준으로 실행하는 함수를 만들어 준 다음에 자식들을 대상으로 똑같은 함수를 또 호출해 모든 것을 스캔해서 얻은 정보를 들고 있게 할 것이다.
5) 계층 구조 안 각 요소가 가진 Relative 좌표와 상위 좌표계와의 관계
unitychan의 계층구조에 있는 정보를 살펴보면 Transform의 SRT정보가 살짝살짝씩 달라지고 있다. 이 정보는 무엇을 의미하고 있는지 이해하는 게 필요하다. 간단하게 표현하면 계층구조이기 때문에 월드 좌표는 아니다. 자신의 직속상관을 기준으로 하는 자신의 좌표를 얘기했던 것이다. Relative 좌표라고 하자. 상대적인 좌표다.
자신을 기준으로 하는 좌표계에서 자신의 직속상관을 기준으로 하는 좌표계로 토스를 하고 싶으면
SRT로 행렬을 만들어서 곱하면 그게 World로 넘어가는 게 아니라 직속상관을 기준으로 하는 걸로 넘어가는 것이다.
직속상관이 아닌 월드 좌표계에서의 좌표를 구하고 싶으면 부모의 좌표계로 타고 타고 끝까지 올라가면 된다.
쉐이더 코드에서 Transform의 STR 정보를 받아서 뭔가를 해줘야 하는데 그럴 때 World로 넘어가는 건 부담이 될 것이다.
그래도 물체의 최상위 계층을 기준으로 한 좌표로 한번 변환을 해주고 시작을 해야 한다.
즉 물체의 Local을 기준으로 하는 좌표를 들고 시작을 할 것이고, 물체의 좌표를 쉐이더에 넘겨주면 일반 물체와 똑같이 WVP를 그대로 곱해주면 된다.
좌표계를 왔다 갔다 할 수 있어야 한다.
애니메이션을 틀 때는 거꾸로 특정 계층을 기준으로 했을 때 어떻게 얼마큼 바뀌느냐로 애니메이션 정보가 제공되기 때문에 항상 자신의 부모를 기준으로 하는 상대적인 좌표계와, 최상위 부모인 local을 기준으로 하는 좌표계와, World, View, Projection을 곱해서 World, View, Projection space 이런 식으로 여러 개의 좌표계를 왔다 갔다 할 수 있어야지만 애니메이션을 완벽하게 이해할 수 있게 되는 거다.
제대로 이해하는 사람이 거의 없다. 학원에서도 내용이 어렵다 보니 코드를 복붙 해 사용하기 때문에 나중에 코드를 봐도 내용을 간과하기 쉬운데 이게 핵심이다.
이걸 Transform 다룰 때 다뤄본 이유는 이런 계층 구조에 관련되어 넘어가는 것도 결국에는 Transform을 코드로 만들 때 그 부분이랑 별반 다를 바가 없다.
6) FBX 파일 사용 전략 : FBX 포멧의 파일을 Assimp라이브러리를 이용해 로드해서 메모리에 올려 놓고 커스텀 포맷으로 변환을 해서 사용할 예정
전략은
먼저 FBX포맷을 로드해야 하는데 FBX 로더나 여러 라이브러리들이 있다.
FBX로더는 FBX파일만 되지만 Assimp를 이용하게 되면 오브젝트 파일이나 다른 파일들도 받아줄 수 있는 조금 더 범용적인 라이브러리이기 때문에 그거를 사용하는 게 조금 더 낫다고 볼 수 있다.
1차 적으로 FBX파일을 로드해서 이미지 파일처럼 분석을 해야 한다.
그 부분을 Assimp 라이브러리를 통해서 해서
계층 구조에 있는 각 요소들을 수단과 방법을 가리지 않고 메모리에 일단 올려놓고 시작을 할 것이다.
그러면 메모리에 올라간 형태는 외부 라이브러리를 사용했으니 Assimp에서 지정한 형태의 무엇인가로 저장이 될 것이고, 그거를 다시 그대로 사용하거나 조금 더 가공해서 원하는 정보만 추출해서 그 정보를 가지고 작업을 하거나 여러 가지 선택지가 있다.
FBX를 Assimp로 그냥 로드를 하면 시간이 오래 걸린다.
학원 같은데서는 로드 한 다음에 우리만의 포맷으로 한 번 더 변환을 해서 그 변환된 파일 형태로 일단은 저장하는 식으로 작업을 많이 한다. 우리만의 포맷을 새로 만드는 거다.
그걸 저장하고 있다가 한 번 변환이 된 이후에는 우리가 이미 만들어진 우리만의 포맷만 로드해서 바로 실행을 하면 훨씬 더 로드하는 속도가 빠르다.
10초 정도 걸리는 걸 핵심 정보만 추출해서 저장했다가 로드하면 빨라지는 거다.
조명정보나 잡동사니들을 필요 없기 때문에 과하다 싶을 정도로 많기 때문에 이렇게 해주는 게 깔끔하다.
상용엔진을 만든다면 이런저런 메타 데이터가 있을 것이다.
이런 걸 최적화해서 만들 자신이 있는 건 아니기 때문에 한 단계 거치는 방법을 이용할 것이다.
여기까지가 오리엔테이션이다.
2. Assimp 라이브러리 가져오기
FBX 파일을 로드해 보기위해 일단 Assimp의 코드를 가져와서 빌드해 볼 것이다.
1) 이미 만들어 놓은 수업자료 프로젝트에서 가져오는 방법
sln파일이 있는 폴더\Libraries\Include에 Assimp 폴더를 복붙 한다.
sln파일이 있는 폴더\Libraries\Lib에서도 Assimp를 복붙 한다.
2) 인터넷에서 라이브러리 자체를 다운 받아 가져오는 방법
처음부터 만드는 입장이라면 이 라이브러리를 찾아서 넣어줘야 한다.
인터넷에서 Assimp와 관련된 부분들을 어떻게 하는지 찾아보면 Git으로 제공하는 경우가 많다.
압축파일을 받아서 그거를 설치하면 된다.
만약 sln 파일이 있다면 쉽게 할 수 있지만
없다면 CMake라는 프로그램을 받아가지고 한 번 더 변환을 해서 만들어 줘야 한다.
코드가 있는 소스의 위치를 선택하고, 결과물이 저장될 위치를 지정하고, Configure버튼을 눌러서
어떤 환경으로 할지 Visual Studio 17 2022, x64, Use default native compoiler를 지정하고 Finish를 누르고 기다려주면 변환 작업을 해줄 것이고, 다 끝나면 Generate버튼을 누르면 된다.
이런 식으로 찾아서 해주면 된다.
그러면 지정한 폴더에 sln 파일이 생기게 되고,
이제부터는 윈도 환경에서 작업하던 것과 똑같이 할 수 있게 된다.
sln 파일을 열어서 Debug와 Release모드로 각각 ALL_BUILD를 시작 프로젝트로 해서 실행을 하면 완료가 된다.
include\assimp 폴더를 살펴보면 코드가 있을 것이니 코드를 갖고 오고,
결과물 lib 파일도 어딘가에 있을 테니 경로를 찾아보고 갖고 와서 작업을 하면 된다.
dll보다 lib로 작업하는 게 편하다 그래야지만 빌드하는 순간 포함이 되어서 가지고 나갈 수 있기 때문이다.
3. 새 프로젝트를 생성하고 Assimp 라이브러리를 사용할 사전 작업 하기
이렇게 코드 파일과 라이브러리 파일을 가져왔으면 항상 하던 사전 작업을 하면 된다.
1) EnginePch.h에서 Assimp의 파일 경로와 라이브러리 경로를 추가해주기
Engine\99. Headers\EnginePch.h에 가서 경로를 추가해 준다.
// Libs 방로 위에다 Assimp 3 총사를 넣어준다.
// Assimp
#include <Assimp/Importer.hpp>
#include <Assimp/scene.h>
#include <Assimp/postprocess.h>
// libs 아래
#ifdef _DEBUG
#pragma comment(lib, "DirectXTex/DirectXTex_debug.lib")
#pragma comment(lib, "FX11/Effects11d.lib")
#pragma comment(lib, "Assimp/assimp-vc143-mtd.lib")
#else
#pragma comment(lib, "DirectXTex/DirectXTex.lib")
#pragma comment(lib, "FX11/Effects11.lib")
#pragma comment(lib, "Assimp/assimp-vc143-mt.lib")
#endif이렇게 lib를 사용하겠다고 해준다.
이렇게 할 수 있었던 건 Engine 프로젝트 만들 때 속성에서
C++의 General에서 Additional Include Directories에 Libraries\Include가 포함이 되어 있기 때문이다.
여기를 기준으로 추가적으로 헤더 3 총사를 찾아 줄 것이고,
Librarian의 General의 Additional Library Directories에서 Libraries\Lib를 포함시켰기 때문에 거기서 추가적인 부분만 Assimp/assimp-vc143-mtd.lib 이렇게 적어주면 되었다.
Engine을 빌드한다.
2) AssimpTool 프로젝트 생성하기
해야 할 것은 하나의 툴을 만들어서 그 툴에서 원하는 fbx파일을 로드한 다음에 그걸 메모리에 들고 있다가 툴을 이용해 명령을 하거나 설정을 하거나 여러 가지 환경에 의해서 원하는 형태의 파일로 변환하는 작업을 일단 만들어 줘야 되는데 걔는 사실 어디에 만들지가 애매하다.
Engine인지 Client인지 징검다리 역할을 하는 걸 Tool이라고 한다. 나중에 맵툴, 애니메이션툴, 이펙트 툴 등이 생기긴 한다. 새로운 프로젝트로 만들어 준다.
솔루션에서 새로운 프로젝트를 추가한다.
WindowsDesktopWizard를 선택한다(무엇을 선택해도 설정을 바꾸면 변경할 수 있다)
이름을 AssimpTool이라고 하고 Create를 하면
Application type은 Desktop application을 선택하고 Additional options는 Empty project를 선택하고
확인을 눌러준다.
Solution에 New Project folder를 추가해서 Tools라고 이름을 정하고
거기에 AssimpTool 프로젝트를 옮겨서 작업을 한다.
프로젝트를 만들어 줄 때 위치를 처음부터 sln파일이 있는 폴더에 만드는 게 아니라
새로운 폴더 Tools를 만든 다음에 물리적으로 AssimpTool 프로젝트 폴더를 이 Tools 산하에 넣었다면 나중에 라이브러리를 include 할 때 상대 경로 같은 걸로 해주는 작업이 꽤 있다.
Client에서도 ~Demo 시리즈들을 만들 때 상대 경로로
auto texture = RESOURCES->Load<Texture>(L"Veigar", L"..\\Resources\\Textures\\veigar.jpg");이렇게 작성한 경로들을 수정해야 한다.
그래서 그냥 같은 위치에다가 프로젝트를 만드는 게 좀 더 통용성 있게 만들 수 있기 때문에 그렇게 하는 걸 권장을 드리지만 언제든지 프로젝트의 위치는 다른 곳에 위치시켜도 무방하다.
3) AssimpTool 프로젝트의 Properties 세팅하기
나머지는 Client를 만들 때와 유사하게 만들면 된다.
Client의 속성을 참고해서
출력 디렉토리 $(SolutionDir)Binaries\
중간 디렉토리 $(SolutionDir)Intermediate\$(Configuration)\
C/C++의 추가 포함 디렉토리 설정 목록이 나오게 하기 위해
pch 클래스를 만들어서 Source Files 필터에 넣는다.
HeaderFiles와 ResourceFiles 필터는 삭제한다.
이제 속성을 보면 C/C++이 생겼다.
추가 포함 디렉토리 $(SolutionDir)Libraries\Include\;$(SolutionDir)Libraries\Include\Engine\;%(AdditionalIncludeDirectories)
링커의 General에서
추가 라이브러리 디렉토리 $(SolutionDir)Libraries\Lib\;%(AdditionalLibraryDirectories)
그리고 pch를 처음 했다고 하면
프로젝트의 속성에서
C/C++의 미리 컴파일된 헤더에서
미리 컴파일된 헤더 Use (/Yu)
미리 컴파일된 헤더 파일 pch.h
로 설정해 준다.
이렇게 사용하는 순간 모든 애들이 다 사용으로 바뀌는데
유일하게 pch.cpp라는 파일은 속성에서
미리 컴파일된 헤더 Create (/Yc)
이렇게 설정해 준다.
프로젝트를 생성할 때마다 해줘야 하는데 기억이 안 나면 그냥 다른 프로젝트를 보고 하면 된다.
이렇게 4가지를 설정하는 게 기본 상태라고 볼 수 있다.
빌드는 아직 main 함수가 없기 때문에 안된다.
4) 재사용할 코드 Client에서 가져오기
Client와 비슷한 느낌으로 만들고 싶지만 달라지는 부분은 Client처럼 사용하지만 툴을 기반으로 하는 것이기 때문에 Client에서 사용할 것들을 가져와서 사용하면 된다.
예를 들어 Main, CameraScript클래스를 활용할 것이라고 하면 복사해서 AssimpTool 프로젝트 폴더에 붙여 넣는다.,
그거를 솔루션 탐색기에서 AssimpTool프로젝트의 SourceFiles 필터에 넣는다.
Main.cpp 에서 Demo시리즈 헤더를 #include 하는 코드를 삭제한다.
//desc.app = make_shared<NormalMappingDemo>();
아직 Demo 클래스가 없으니 주석처리 한다.
AssimpTool프로젝트의 pch.h에 엔진을 로드하는 부분
#pragma once
#pragma comment(lib, "Engine/Engine.lib")
#include "Engine/EnginePch.h"
이 코드를 넣어준다.
빌드를 하면 빌드가 된다.
이런 식으로 하나씩 쌓아 올려 갈 것이다.
AssimpTool을 기반으로 쌓아 올려서 완성된 형태가 되면 Client에서 했던 것처럼 비슷한 부분들을 AssimpTool로 쌓아 올릴 것이다.
오늘 작업할 건 Assimp로드하는 부분들을 진행할 것이다.
5) Assimp::Imperter를 가져와서 로드하는 기능을 사용할 Convert클래스 생성하기
Assimp와 관련된 부분들을 사용할 수 있는지 궁금하다. 간단하게 만들어 본다.'
AssimpTool 프로젝트에서 Utils라는 필터를 추가한다. 여기에 Convert 하는 여러 가지 부분들을 넣어줄 것이다.
그리고 Main 필터를 추가한다.
CameraScript 클래스는 Utils에 넣어주고, Main, pch클래스는 Main 필터에 넣어준다.
SourceFiles 필터는 삭제한다.
Utils 필터에 Converter라는 클래스를 만든다. 핵심 작업인 Assimp를 갖고 와서 그 부분을 로드하는 그 기능을 할 얘를 만들어 줄 것이다.
Converter라는 애가 아직 뭐 할지는 모르겠지만 여기서 Assimp를 사용할 준비를 하게 될 것이다.
Assimp::Importer를 이용해서 뭐가 만들어 줄 수 있다.
Assimp를 Engine 코드에 넣어 줬기 때문에 그냥 편하게 사용할 수 있지만 경우에 따라서 엔진까지 가기 좀 뭐 한 애다라고 하면 그 부분들만 우리가 작업하고 있는 이 프로젝트에 추가하면 된다. 지금은 Engine에 넣어 둔 것을 사용한다.
#pragma once
class Converter
{
public:
Converter();
~Converter();
private:
shared_ptr<Assimp::Importer> _importer;
};
#include "pch.h"
#include "Converter.h"
Converter::Converter()
{
_importer = make_shared<Assimp::Importer>();
}
Converter::~Converter()
{
}
여기까지 별다른 문제가 없이 잘 빌드가 된다.
Assimp라이브러리를 활용할 준비가 끝났다.
만약 여기까지 오면서 설정이 틀어져서 헤더파일만 알고 실제 라이브러리 파일이 없거나 버전이 다르거나 뭔가가 잘못되었다고 하면 Link에러가 뜬다.
일단 여기서 빌드가 되어야 문제가 없는 상황이다.
이걸 이용해서 asset을 로드한 다음에 온갖 잡동사니를 하게 될 예정이다.
4. Resources 폴더 관리 기준 정하기
Resources 폴더를 어떻게 관리할 것인가를 생각해야 한다.
여러 가지 파일들이 들어가게 될 것인데 다 넣기에는 정신이 없기 때문에
어느 정도 구조를 정해서 만들어야 한다.
원본 파일을 저장할 폴더를 Assets라고 한다.
이 안에다 여러 가지 fbx파일을 넣을 것이고 그 경로를 전달해 줘서 Converter를 통해서 변환을 하게 되면
그 변환된 결과물들이 나올 폴더를 Models라고 한다.
Material 같은 경우는 따로 폴더를 빼줄 것인지 Textures 산하에 같이 넣어줄 것인지가 고민인데 선생님은 Texture는 Material과 같이 모아 두는 게 좋다고 생각한다고 한다. 왜냐하면 Material은 자신과 관련된 여러 수치들과 실제로 Material과 연결된 Texture파일들까지 같이 1+1으로 포함이 되어야 하는데 나중에 유니티처럼 엔진들 잘 만들게 되면 모든 그런 리소스들을 아이디로 관리를 해서 어디 위치해 있건 그 위치로 매핑을 하는 것을 구현하면 되겠지만 지금은 그렇게 하기 힘들기 때문이다. 만약 Texture에 House라는 에셋이 들어가게 된다면 Texure안에 House라는 폴더를 만들어서 그 안에 House와 관련된 Material과 관련된 Texture들을 몰빵 해서 관리하는 게 가장 깔끔하다고 볼 수 있다.
이렇게 규칙을 정해주는 게 중요한 이유는 툴을 이용해 Resources에 있는 내용을 정한 구조대로 이리저리 배치를 할 것이기 때문이기도 하고 나중에 가서라도 수동으로 뭔가를 해주고 싶다고 하면 지금 잡동사니들이 널브러져 있는데 구조를 정해서 규칙을 만들어야지만 편하게 관리가 된다.
이게 보통 학원에서 구현하는 형태라고 보면 된다.
이게 일단 기반이 되는 구조라고 보면 된다.
5. 맺음말
다음시간부터 해야 하는 건 Assimp를 활용하는 연습들을 해볼 것이다.
겁을 먹을 필요가 없다. 해야 할 것만 러프하게 머리에 떠올리면 문서를 찾아보거나 하나씩 하나씩 테스트를 해보면 혹은 샘플 코드를 따라 치면 그런 기능들은 이제 다 구현할 수 있을 것이다.
Assimp 안에 들어가서 코드를 보는 건 의미가 없다. 모든 부분을 하나씩 살펴보면 끝이 없다.
라이브러리를 다 분석해서 사용하는 건 언젠가는 한계가 있다. 그냥 받아들여야 한다.
다 이해하고 자신이 만들어야 한다면 컴파일러도 만들어야 하고, 컴파일러도 운영체제 위에서 돌아가는 거니 운영체제도 만들어야 하고, 운영체제도 하드웨어 기반으로 되어 있으니 칩도 만들어야 하고 끝도 없으니 포기하는 게 맞다.
앞으로 하나씩 추가하면서 과학자 느낌으로 어떻게 동작하는지 메모리에서 어떠한 정보를 들고 있는지 등을 살펴보며 진행할 것이다.
'DirectX' 카테고리의 다른 글
| 54. 모델_Bone, Mesh 로딩 (0) | 2024.02.23 |
|---|---|
| 53. 모델_Material 로딩 (0) | 2024.02.21 |
| 51. Light, Material_버그수정(카메라 좌표) (0) | 2024.02.17 |
| 50. Light, Material_Normal Mapping (0) | 2024.02.17 |
| 49. Light, Material_Material (0) | 2024.02.16 |
댓글