나에유의 개발이에유

Depth 양은 알 수가 없어

NAEU — Sat, 25 Apr 2026 16:26:14 +0900

ref. 아하렌 양은 알 수가 없어

한 3일동안 있었던 버그를 잡은 짧은 회고록입니다
렌더링 과정에서 depth test가 이루어지지 않아 그리는 순서대로 위에 그려지는 현상이 있었습니다

우선 view 혹은 projection의 matrix가 제대로 넘어가지지 않나 둘의 depth값을 확인해봤습니다

depth색은 정상적으로 적용되었습니다(멀수록 어둡게)
이때 알아낸 것은 현재 vector에 MeshRenderer를 담고 순차대로 draw를 진행하는데, 이 순차대고 먼저 그려진다는 사실입니다
따라서 depth test 자체가 이루어지지 않고 있다는 것을 의심했습니다

하지만 DepthStencilBuffer 생성도 통과하였고
DepthStencilState도 정상적으로 생성되었습니다
여기서 잠시 막히게 되었지만 결국 원인을 발견하였습니다

DXGI_SWAP_CHAIN_DESC scd;
ZeroMemory(&scd, sizeof(scd));

scd.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM; //버퍼 설정 중 색상 설정
scd.SampleDesc.Count = 4;
scd.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT; //스왑체인 사용 방식
scd.BufferCount = 1; //백 버퍼 갯수
scd.OutputWindow = hwnd;
scd.Windowed = TRUE; //창모드

D3D11_TEXTURE2D_DESC depthTexDesc{};
depthTexDesc.Width = 800;
depthTexDesc.Height = 800;
depthTexDesc.MipLevels = 1;
depthTexDesc.ArraySize = 1;
depthTexDesc.Format = DXGI_FORMAT_D24_UNORM_S8_UINT;
depthTexDesc.SampleDesc.Count = 1;
depthTexDesc.SampleDesc.Quality = 0;
depthTexDesc.Usage = D3D11_USAGE_DEFAULT;
depthTexDesc.BindFlags = D3D11_BIND_DEPTH_STENCIL;

다음은 swapchain을 위한 desc와 depth stencil을 위한 desc입니다
문제는 SampleDesc.Count에 있었습니다

Sample이란 픽셀의 색을 지정할때 부드럽게 하기 위한 방법입니다
픽셀 하나에 대해 N개의 점을 찍어 도형이 해당 점 위를 덮는지 여부를 파악하고, 모든 점들의 평균값을 구하여 해당 픽셀에 적용합니다

그럼 위에서의 정확한 문제는 swapchain과 depthstencil의 count값이 다른것이 였습니다
렌더 파이프라인을 보면 Rasterizer 후에 샘플별로 Pixel Shader를 실행하여 N개의 픽셀값을 구합니다
이후 OutputMerge단계에서 RenderTarget(swapchain)[n]과 depthbuffer[n]을 1:1 비교합니다
기존 픽셀의 depth와 새 depth를 비교하고 새 depth가 더 작다면 rendertarget[n]을 덮어씌우는거죠

하지만 저 갯수가 다르다면 바인딩 자체를 무효화 처리합니다
따라서 갯수의 주체는 RenderTarget입니다

참고로 D3D11_DSV_DIMENSION_TEXTURE2DMS <- 뒤에 MS(multi-sample)이 붙은걸로 view를 만들어야합니다

더 나아가보자면 이렇게 갯수를 일일히 동기화하는 것은 관리가 복잡해질 수 있습니다

따라서 TAA나 FXAA같은 방법을 사용한다고 하네요
-> post-processing 방식

어떤 변수값이 어떻게 사용되는지 무지한채로 완성에만 급급하여 개발을 하던게 이렇게 돌아오네요

특히 로우레벨/api를 다룰 떄는 항상 유의하며 학습해야겠습니다

Let's Groove - TCP와 UDP

NAEU — Sat, 7 Mar 2026 12:52:27 +0900

https://megayuchi.com/2025/10/07/tcp-vs-udp-latency-차이/

제가 자주 보는 분의 글들을 읽다가 적어봅니다 흔히 속도는 UDP, 안정성은 TCP라고 머리에 박혀있습니다 다만 글의 내용을 보면 오히려 TCP가 빠른 결과가 나왔습니다 전제를 살펴보도록 하죠

이미 연결되어 있다
재전송이 일어나지 않는다

TCP의 연결은 3-way handshake로 진행됩니다

Clinet -> Server 연결 요첨

Server -> Client 연결 확인 + 연결 요청

Client -> Server 연결 확인

반면 UDP는 연결이랄게 따로 없습니다

그냥 존재하는지도 모르는 어딘가에게 계속 데이터를 보내는 거죠

그래서 TCP는 연결 처리 과정이 존재합니만 전제는 이미 연결되어 있기에 이는 무시하도록 하죠

다음은 재전송입니다

재전송은 주로 패킷이 손실되었을 때 진행됩니다

TCP의 경우 데이터를 수신 확인인 ACK가 돌아오지 않았기에 다시 전송합니다 반

면 UDP는 손실됐는지도 모르기에 다시 처리할 과정이 존재하지 않습니다 따라 재전송이 발생한다면 TCP에서는 처리하는 일이 더 생기기에 늦어진다지만, 이것도 전제에서는 빠졌습니다

그럼 남은게 뭘까요?

헤더의 크기가 우선 떠오릅니다 TCP는 데이터의 상태같이 자세한 정보들을 더 기록해야하기에 패킷에서 크기를 더 차지합니다 하지만 그 차이는 현대 하드웨어 기준으로 무시될 수준이기에 실질적 레이턴시의 차이가 미미해지죠

그래서 결론은 TCP가 모든면에서 더 좋다? 라고 하기엔 사실 전제가 좀 사기인 면이 있죠

실시간 게임 네트워킹을 기준으로 최초 연결 시간은 어느정도 감수할 수 있지만, 손실에 대해 재전송하지 않으면 어떤 일들이 발생할지 모릅니다

특히 TCP는 순서가 꽤 중요한 프로토콜이기 때문에 더욱 무시될 수는 없죠

데이터가 방대해져 4개로 쪼개서 보낸다고 할때, 1. 통과 2. 손실이 발생하면 다음 3과 4는 블로킹 되어 HOL Blocking이 발생하게 되니까요

따라서 실제로 TCP만을 사용하기엔 무리가 있지만 글의 내용은 UDP는 빠름! TCP는 느림!이라는 단순한 사고를 경계하자는 취지인 것 같네요

추가로 몇개를 더 찾아봤는데 UDP기반으로 중요한 데이터만 재전송 가능하게 만든 방식도 있다고 합니다

Spider-Man: Into the Spider-Verse - 멀티스레딩

NAEU — Wed, 7 Jan 2026 22:08:45 +0900

오늘은 멀티스레딩에 대해 알아보자

좀 더 정확히 표현하자면 C++에서 어떻게 다루는지 알아보자

대충 알겠지만 멀티스레딩은 싱글스레딩만 해오던 나에게 굉장히 어려웠다

그렇기에 개념을 잡는 시간이 걸렸으며 사실 다 잡힌건 아닌 것 같다

따라서 앞으로도 개념정리는 계속 바뀌겠지만 현재까지 이해한 것을 바탕으로 써보겠다

std::thread

대입 연산자를 이용하여 함수를 실행하기 전까지는 빈 포인터 상태처럼 남아있다

void Work()
{
	std::this_thread::sleep_for(std::chrono::seconds(1));
}

int main()
{
	std::thread t = std::thread(Work);
	t.join();
}

스레드는 생성과 동시에 실행된다

그리고 이런 스레드에 대해 관리하는 방법은 2가지가 있다

join();

현재 스레드를 지정한 스레드가 끝나기전까지 재운다

그리고 유의할 점은 스레드가 끝난다고해서 std::thread가 죽진 않는다

detach();

“분리한다”라는 이 함수는 현재 스레드에서 실행 중인 스레드를 분리함으로서 독립적으로 수행 할 수 있게한다

void Independent()
{
	std::cout << "Start Independent Work" << std::endl;
	std::this_thread::sleep_for(std::chrono::seconds(5));
	std::cout << "End Independent Work" << std::endl;
}

void Caller()
{
	std::cout << "Start Call Work" << std::endl;
	std::thread t = std::thread(Independent);
	std::this_thread::sleep_for(std::chrono::seconds(2));
	std::cout << "End Call Work" << std::endl;
}

int main()
{
	std::thread t = std::thread(Caller);
	std::this_thread::sleep_for(std::chrono::seconds(10));
}

이 코드를 실행하게 되면 문제가 생긴다

바로 “End Independent Work”가 출력되지 않는다는 것인데, 그 이유는 std::thread는 기본적으로 스코프에 의해 생명이 관리되기 때문이다

그렇기에 5초가 지나 출력되기전에 2초가 지나버려 스레드 자체가 사라진다는 의미!

따라서 우리가 원하는 방향으로 실행하려면

void Independent()
{
	std::cout << "Start Independent Work" << std::endl;
	std::this_thread::sleep_for(std::chrono::seconds(5));
	std::cout << "End Independent Work" << std::endl;
}

void Caller()
{
	std::cout << "Start Call Work" << std::endl;
	std::thread t = std::thread(Independent);
	t.detach();
	std::this_thread::sleep_for(std::chrono::seconds(2));
	std::cout << "End Call Work" << std::endl;
}

int main()
{
	std::thread t = std::thread(Caller);
	std::this_thread::sleep_for(std::chrono::seconds(10));
}

다음과 같이 작성하면 된다

std::mutex

mutex는 일종의 간이영역이라고 생각하면 된다

mutex를 lock 상태로 만들어 범위 내, 혹은 스코프 내의 변수들을 보호한다

뭐로부터 보호하냐? 바로 다른 스레드들로부터이다

애초에 ‘멀티’스레드이기 때문에 다른 스레드들이 평행세계마냥 동시에 같이 돌아간다

그렇기에 같은 변수에 접근하려고 할 때 중첩이 된다거나 누락이 된다거나하는 문제들이 발생하기도 한다

그렇기에 이 변수를 수정할때 다른 스레드들은 건들지 못하도록 잠시 보호막, 이 스레드만 수정할 수 있는 권한을 부여하는 것이다

그럼 lock은 어떻게 하는지 알아보도록하자

std::lock_guard

std::mutex m;
{
    std::lock_guard<std::mutex> lock(m);
    sharedData++;
}

lock_guard는 가장 간단한 보호기로 mutex를 스코프 기준으로 보호한다

범위: 생성~스코프 끝날때까지

std::unique_lock

std::mutex m;
std::unique_lock<std::mutex> lock(m);
sharedData++;
lock.unlock(); 
// 다시 lock 가능
lock.lock();

좀 더 고급기능이 있는 보호기다

우선 스코프와 상관없이 해제 후 다시 lock이 가능하다

그리고 가장 중요한 이유로는 후술 할 std::condition_variable과 연동이 가능하다

std::condition_variable

이 친구는 잠든 스레드를 깨워서 자신의 mutex 권한이 있는지 확인해보라고 하나의 스레드 혹은 모든 스레드에게 전달할 수 있다

cv.wait(lock, [] {
    return !jobQueue.empty();
});

이 상태의 코드가 실행될 때 jobQueue에 요소가 있다면 그대로 실행되지만 요소가 없다면 잠들게 된다

cv.wait(lock, bool condition);

위에서는 람다식으로 표현했지만 그냥 bool 조건 검사이다

그 후 다시 한번 조건에 부합되는지 확인하기 위해서는 “조건이 변경되어서 참일 수도 있으니 한번 확인해봐라” 라고 알림을 보낼 수 있다

cv.notify_one(); //무작위 하나만 검사 요청
cv.notify_all(); //cv로 wait하는 모든 스레드에 검사 요청

만약 검사를 진행했더니 조건이 참이라면, 해당 wait 아래에 있는 코드들을 mutex 권한을 가진채로 실행한다

현재 스레드풀을 만들며 감을 잡아가고 있지만 앞으로 어떤 곳에 어떻게 쓰일지, 얼마나 더 어려워질지는 두고봐야할 것이다

우선은 사용하는 방법을 알았다는 것에 감사하자

Little Mo' Betta - 구조체 데이터 최적화하기

NAEU — Sat, 13 Dec 2025 12:32:19 +0900

struct Bonfire {
    bool bIsSleeping; 
    int nMemberCount; 
    bool bIsHappy; 
    bool bCanJoinNow; 
};

다음 구조체의 크기는 몇일까?
우리가 알고 있는 지식으로는 bool이 1바이트, int는 4바이트이다
따라서 bool x3 + int x1로 7바이트라고 생각할 수 있다
그렇다면 돌려보자

int main() {
	Bonfire fire;
	std::cout << "Size of Bonfire: " << sizeof(fire) << std::endl;
	return 0;
}

이게 왠걸
거의 2배인 12바이트가 할당되어버렸다
왜 그럴까?
첫번째로는 애초에 7바이트라는 사이즈만 할당할 수 없다
CPU에서는 값을 읽을때 4바이트로 정렬되어있다면 값을 한번에 읽을 수 있다
그렇기 때문에 컴파일러는 ABI(Application Binary Interface)라고 하는 규약을 따라 4바이트씩 데이터를 정렬한다
따라서 모든 데이터들은 1-4-8-16... 기준으로 할당된다
자 그럼 7이 안 나오는건 이해가 됐다
그럼 8이 나와야지 왜 12가 나오는걸까?
그 이유는 값을 정렬할때 패딩(padding)이라는 것이 들어가기 때문이다
만약 저 구조체의 메모리 레이아웃을 그려본다고 하자

cpp b: bool, i: int [b][ ][ ][ ] / [ ][ ][ ][ ] / [ ][ ][ ][ ]

우선 bIsSleeping에 해당하는 1바이트 bool을 삽입하였다
이 제 뭐 하 지 ?
다음으로는 4바이트 int를 삽입해야하는데 b 바로 다음에 넣게된다면 정렬 규칙이 깨져버리게 된다
따라서 컴파일러는 3바이트의 패딩값을 b다음에 먼저 삽입한다
그리고 그 후에 4바이트 int를 넣는다

b: bool, i: int, p: padding [b][p][p][p] / [i][i][i][i] / [ ][ ][ ][ ]

벌써 8바이트나 먹었다
이제 bool이 2개 남았다
먼저 삽입해보자

b: bool, i: int, p: padding [b][p][p][p] / [i][i][i][i] / [b][ ][ ][ ]

이제 1바이트 bool을 하나 더 삽입해야하지만
남은 크기를 보니 3바이트라는 무려 3배나 더 되는 크기가 남아있다
따라서 컴파일러는 b바로 다음에 bool을 하나 삽입한다

b: bool, i: int, p: padding [b][p][p][p] / [i][i][i][i] / [b][b][ ][ ]

그리고 구조체 자체의 변수가 더 없기 때문에 이 또한 4바이트씩 맞춰줘야한다
고로, 마지막에 패딩을 넣는다

b: bool, i: int, p: padding [b][p][p][p] / [i][i][i][i] / [b][b][p][p]

이렇게 완성된구조체의 메모리 레이아웃은 총 12바이트를 할당받고 있다
vs에서도 확인해보자

근데 이 메모리 구조를 보고있자니
내 안에서 치밀어오르는 이 화를 감출 수가 없다
아니 내가 쓰는건 7바이트 뿐인데
총 공간은 12바이트나 먹고 있다
무려 5바이트나 놀고 있는 것이다
고작 5바이트라고 생각할 수 있지만
이러한 객체가 굉장히 많아진다면
전체 용량에 약 41%를 낭비하고 있는거다
따라서 우리는 아주 살짝의 터치로 이를 보완할 수 있다

struct Bonfire { 
	int nMemberCount; 
    bool bIsSleeping;
    bool bIsHappy; 
    bool bCanJoinNow; 
    };

끝이다
bool을 한곳으로 모아두면 메모리 레이아웃은

이렇게 바뀌게 된다
총 크기 8바이트에 놀고 있는 용량도 1바이트밖에 안된다
이렇게 단순히 변수의 순서만으로도 최적화에 도움이 될 수 있다

Fight Club - Rule of 0/3/5

NAEU — Sat, 13 Dec 2025 11:25:29 +0900

C++을 공부하다 보면
Rule of 5, Rule of 3, Rule of 0라는 뭔 규칙을 의미하는건가 싶은 것을 볼 수 있다
오늘은 이 Rule of 0/3/5 에 대해 알아보자

사실 Rule of 3와 5은 동일하다
정확히하자면 기존의 Rule of 3에서 C++11 이후부턴 2가지의 규칙이 추가되어 5가 된것이다
이 이야기는 살짝 미뤄두고 Rule of 0부터 확인해보겠다

Rule of 0
핵심만 읊자면 클래스가 직접 메모리,파일,핸들 등을 관리하지 않게 설계하라는 의미이다
아니 그럼 데이터들을 어떻게 관리하냐? -> RAII를 사용하면 된다
RAII는 Resource acquisition is initialization의 약자로, "자원 획득은 초기화"라는 의미이다
RAII는 자원은 해당 객체가 살아있을 때만 보유되는 것을 보장하는 규칙이다
따라서 객체 누수가 없다면 그 안에 있는 자원 누수도 없어지니 자원 관리가 간편해진다
쉬운 예시로는 std::vector가 있다
std::vector는 내부적으로 Heap에 메모리를 할당하는 동적 할당을 사용한다
그렇기에 사용이 완료된 후에는 할당한 메모리를 해제해주어야하는데, std::vector는 이를 소멸자에서 처리하게 두어 사용자가 std::vector를 사용할때 굳이 신경쓰지 않아도 되게끔 만들었다
이게 Rule of 0의 좋은 예시이다
가장 안전하고, 버그가 좋고, 유지보수 비용이 낮다
Rule of 3
그렇다면 클래스가 리소스를 직접 관리할때는 어떤 것들이 필요할까?
해당 클래스 혹은 타입에 대해서 무조건
복사 생성자
복사 대입 연산자
소멸자
이 3개를 정의해야한다라고 말하는 것이 이 Rule of 3이다
class Data {
public:
Data(size_t size): m_data(new int[size]), m_size(size) {}

private:
int* m_data;
size_t m_size;
};

기본적인 데이터가 이렇게 존재할때 우선 이 데이터가 사라질때 만들어둔 m_data를 메모리에서 해제시켜주어야한다
class Data {
public:
Data(size_t size): m_data(new int[size]), m_size(size) {}

//소멸자
~Data() {
delete[] m_data;
}

private:
int* m_data;
size_t m_size;
};

그리고 나선
Data newData(existData);
Data newData = existData;
방식으로 값을 복사해서 사용하고 싶다면
class Data {
public:
Data(size_t size): m_data(new int[size]), m_size(size) {}

//복사 생성자
Data(const Data& other): m_data(new int[other.m_size]), m_size(other.m_size) {
std::copy(other.m_data, other.m_data + m_size, m_data);
}

//복사 대입 연산자
Data& operator=(const Data& other) {
if (this != &other) {
delete[] m_data;
m_size = other.m_size;
m_data = new int[m_size];
std::copy(other.m_data, other.m_data + m_size, m_data);
}
return *this;
}

//소멸자
~Data() {
delete[] m_data;
}

public:
int* m_data;
size_t m_size;
};

뭐 둘의 차이라고 한다면 복사 생성은 데이터를 처음 생성할때 기존의 있는 데이터 값을 복사해서 생성한다는 것이고,
복사 대입 연산자는 이미 있는 데이터의 값을 다른 데이터로 바꾸고 싶을때 복사해서 사용한다는 차이가 있다
이렇게 3개의 규칙을 알아봤는데 C++11 이후부턴 드디어 그 녀석이 생겨났다
Rule of 5
std::move();
포인터가 C++ 뉴비들의 첫 벽이라면 얘는 뉴비 분쇄기다
이동 시멘틱에 대해선 추후에 자세히 다루기로 하고 우선 나머지 2개의 규칙을 알아보자
이동 생성자
이동 대입 연산자
move라는 이동이 추가되면서 더 이상 비효율적인 복사 대신에 전체를 욺겨버릴 수 있는 효율적인 방법이 생겨났다
class Data {
public:
Data(size_t size): m_data(new int[size]), m_size(size) {}

//이동 생성자
Data(Data&& other): m_data(new int[other.m_size]), m_size(other.m_size) {
other.m_data = nullptr;
other.m_size = 0;
}

//이동 대입 연산자
Data& operator=(Data&& other) {
if (this != &other) {
delete[] m_data;
m_size = other.m_size;
m_data = new int[m_size];
std::copy(other.m_data, other.m_data + m_size, m_data);

  other.m_data = nullptr;
  other.m_size = 0;
  }

return *this;
}

//소멸자
~Data() {
delete[] m_data;
}

public:
int* m_data;
size_t m_size;
};

복사와 큰 차이점을 짚는다면 변수를 받아올 때 &&(Rvalue 참조 선언자)로 받아온다는 것과
other.m_data = nullptr;
other.m_size = 0;
로 기존에 있던 값들을 리셋한다는 것이다

앞으로 데이터를 정의할때 이 5가지를 꼭 기억해보자

Nameless - 좋은 이름을 짓는 방법

NAEU — Sat, 6 Dec 2025 10:23:12 +0900

언어별 예약어를 사용하지 말것 ex) int, float, for etc
컴파일러 예약어도 사용하지 말것 ex) __언더바2개, _Muck언더바후대문자
모두가 알고있는 약어만 사용할 것
같은 내용을 반복하지 말것

void saveEmployee(const Employee employee);
보다는
void save(const Employee employee);

프로퍼티도 이름의 일부로서 사용
bool bIsNotPlayer 처럼 논리형에 부정문 사용하지 않기 => bIsPlayer
귀찮더라도 임시변수에 이름 지정 ex) for문의 i, iterator의 it, templete의 T
어떻게 구현했지는지 생각하지 않기

pair<Player, int> GetPlayerLevelPairInt(const std::string name);
보다는
pair<Player, int> GetPlayerLevel(const std::string name);

위의 상황에서 "같은 내용 반복하지 말라"는 의미로 GetLevel로 함수명을 지정하면 안되냐 생각될 수도 있지만 리턴값이 아닌 프로퍼티에 한정하기 때문에 다름

pair<Player, int> GetLevel(const Player player);

라면 괜찮음

Still Alive - RAII에 대하여

NAEU — Mon, 21 Jul 2025 16:44:56 +0900

"Resource Acquisition Is Initialization"
번역하자면,
"객체와 자원의 라이프 사이클을 일치시킨다"
의 의미를 가지고 있는 원칙이다

이 원칙의 핵심은 프로그래머가 직접 자원을 관리하는 것이 아닌, 생성, 파괴 및 관리의 모든 것을 객체가 하도록 만드는 것이다

왜 그래야하지?

이유는 간단하다.

프로젝트가 커지고 여러 데이터들이 생명주기를 직접 관리해야한다면 인간인 이상 놓치는 부분이 생기기 때문이다
또한 놓치지 않더라도 이 데이터를 누가 참조하는 지에 대한 것도 불명확하기에 이를 방지하고자 지향해야한다

class Player
{
   public:
      Player()
      {
         m_inventory = new Inventory;
      }
      ~Player();
      {
         delete m_inventory;
         m_inventory = nullptr;
      }
   private:
      Inventory* m_inventory;
}

그렇다면 위의 코드는 RAII를 준수하였을까?
내부 변수로 Inventory를 동적할당하여 사용하고, Player가 삭제될 때도 함께 delete하였으니 준수했다고 볼 수 있다

하지만 모던 C++에서는 이를 스마트 포인터를 이용하여 관리하는 것을 권장한다

여기엔 몇가지 이유가 있는데

예외 안전성: 생성 도중 예외가 발생하더라도 메모리 누수를 방지
대입 연산자/복사 생성자 등에서의 안정성: Rule of Five 대응
자원 관리의 명시성과 추론 용이성: 코드의 의도가 명확해짐
정도이다

포인트는 개발자가 관리에 대한 책임을 갖지 않으면 그냥 잊어먹어도 괜찮다는 원칙이다

따라서 모던 C++에서는 스마트 포인터를 활용하여 RAII를 자동화하고 안전성을 높이는 방식이 바람직하다

OpenGL 공부하기 #4 - 행렬과 변환

NAEU — Mon, 14 Jul 2025 23:13:44 +0900

1. glm 라이브러리 기본

GLM (OpenGL Mathematics)은 GLSL과 유사한 문법을 사용하는 수학 라이브러리

#include <glm/glm.hpp>
#include <glm/gtc/matrix_transform.hpp>

2. Transformations의 종류

Translation (이동)

glm::mat4 model = glm::mat4(1.0f);
model = glm::translate(model, glm::vec3(x, y, z));

객체를 x, y, z 방향으로 이동시킴
보통 model 행렬에서 사용

Scaling (크기 조절)

model = glm::scale(model, glm::vec3(sx, sy, sz));

비율로 객체를 확대/축소
균일 스케일: glm::vec3(s, s, s)

Rotation (회전)

model = glm::rotate(model, glm::radians(angle), glm::vec3(ax, ay, az));

angle: 회전 각도 (라디안 단위)
vec3: 회전축

예) Z축 회전:

glm::rotate(model, glm::radians(180.0f), glm::vec3(0.0f, 0.0f, 1.0f));

3. Model Matrix (모델 행렬)

Local Space → World Space

로컬 좌표를 월드 좌표로 변환
객체 개별 위치, 회전, 스케일 등을 반영
순서: 크기 → 회전 → 위치

glm::mat4 model = glm::mat4(1.0f); 
model = glm::scale(model, glm::vec3(scale, scale, scale));
model = glm::rotate(model, glm::radians(angle), glm::vec3(0, 0, 1)); 
model = glm::translate(model, glm::vec3(x, y, z));

쉐이더에 전달하는 방법:

glm::mat4 mvp = projection * view * model;
glUniformMatrix4fv(mvpLocation, 1, GL_FALSE, glm::value_ptr(mvp));

4. View Matrix (뷰 행렬)

World Space → View (Camera) Space

카메라 위치/시점 기준으로 좌표를 변환
glm::lookAt() 함수를 자주 사용

glm::mat4 view = glm::lookAt( 
	glm::vec3(0.0f, 0.0f, 3.0f), // Camera position 
	glm::vec3(0.0f, 0.0f, 0.0f), // Target 
	glm::vec3(0.0f, 1.0f, 0.0f) // Up 
);

5. Projection Matrix (투영 행렬)

View Space → Clip Space

원근 투영: 원근감 있는 장면 표현

glm::mat4 projection = glm::perspective(glm::radians(45.0f), aspect, 0.1f, 100.0f);

직교 투영: 일정한 비율 유지

glm::mat4 projection = glm::ortho(left, right, bottom, top, near, far);

6. Clip Space (클립 공간)

-w ~ +w 사이로 정점 위치가 재조정됨.

MVP = projection * view * model 을 적용한 후의 결과는 Clip Space에 있음.
GPU는 이 공간에서 Clipping (잘라냄) 을 수행함. 즉, 화면 밖의 좌표를 제거함.
이 시점에서는 정점 좌표는 vec4(x, y, z, w) 형태임.

gl_Position = projection * view * model * vec4(vertexPos, 1.0);

7. NDC (Normalized Device Coordinates)

Clip Space → NDC (나눗셈 처리)

GPU가 자동으로 gl_Position.xyz / gl_Position.w 를 해줌
결과는 각 축의 값이 -1.0 ~ 1.0 사이로 정규화됨
(X: 왼쪽 -1, 오른쪽 1 / Y: 아래 -1, 위 1 / Z: near -1, far 1 or 0~1)

8. Viewport Transform → Screen Space

NDC → Screen Space

glViewport(x, y, width, height) 설정값 기준으로 변환
-1 ~ 1 범위의 NDC가 → 실제 화면 픽셀 좌표로 매핑됨

glViewport(0, 0, screenWidth, screenHeight);

NDC (0, 0) → 화면의 정중앙
NDC (1, 1) → 화면 오른쪽 위 모서리
NDC (-1, -1) → 화면 왼쪽 아래 모서리

전체 수식 정리

glm::mat4 mvp = projection * view * model; 
gl_Position = mvp * vec4(vertex, 1.0f);

파이프라인 흐름:

[Local Space] → model → [World Space] → view → [View (Camera) Space] → projection → [Clip Space] → perspective divide → [NDC] → viewport transform → [Screen Space]

OpenGL 개발하기 - Sierpinski Triangle

NAEU — Mon, 14 Jul 2025 22:23:05 +0900

재귀함수를 이용해 시에르핀스키 삼각형을 그리는 코드

원래 효율적으로 그리기 위해서는 재귀함수에 glDrawElements를 하지 않고 vector타입을 이용해 vertices에 정점을 더해가며 재귀가 마친 후에 VBO에 한번에 넣는 방식이다

하지만 그려보는 것이 목적이었기에 단순한 방식을 채택했다

#include <iostream>
#include <glad/glad.h>
#include <GLFW/glfw3.h>

#include <glm/glm.hpp>
#include <glm/gtc/matrix_transform.hpp>
#include <glm/gtc/type_ptr.hpp>

#include "Shader.h"
#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"


float vertices[] = {
// positions          // colors           // texture coords
1.0f,  1.0f, 0.0f,   1.0f, 0.0f, 0.0f,   1.0f,  1.0f,   // top right
0.0f, -1.0f, 0.0f,   0.0f, 1.0f, 0.0f,   0.5f,  0.0f,   // bottom center
   -1.0f,  1.0f, 0.0f,   0.0f, 0.0f, 1.0f,   0.0f,  1.0f,   // top left
};

unsigned int indices[] = { 
0, 1, 2
};

const int level = 5;
void recursive_triangle(unsigned int transformLoc, const glm::vec2& top, const glm::vec2& right, const glm::vec2& left, int depth) {
	if (depth > level) return;

	//draw
	glm::mat4 trans = glm::mat4(1.0f); // 단위 행렬 1로 초기화 (대각선으로만 1인것)
	trans = glm::translate(trans, glm::vec3(top.x, (top.y - right.y) / 4 + right.y, 0.0f)); // 위치
	float scale = pow(0.5f, depth);
	trans = glm::scale(trans, glm::vec3(scale, scale, 1.0f)); // 크기
	glUniformMatrix4fv(transformLoc, 1, GL_FALSE, glm::value_ptr(trans));

	glDrawElements(GL_TRIANGLES, 3, GL_UNSIGNED_INT, 0);
	depth++;

	glm::vec2 topRight = (top + right) * 0.5f;
	glm::vec2 bottom = (right + left) * 0.5f;
	glm::vec2 topLeft = (left + top) * 0.5f;

	recursive_triangle(transformLoc, top, topRight, topLeft, depth); //top
	recursive_triangle(transformLoc, topRight, right, bottom, depth); //right
	recursive_triangle(transformLoc, topLeft, bottom, left, depth); //left
}

void processInput(GLFWwindow* window)
{
	if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS)
	{
	glfwSetWindowShouldClose(window, true);
	}
}

int main()
{
	glfwInit();
	glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
	glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
	glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

	GLFWwindow* m_window = glfwCreateWindow(800, 800, "title", NULL, NULL);
	if (m_window == NULL)
	{
		std::cout << "Fail to create window" << std::endl;
		glfwTerminate();
		return -1;
	}

	glfwMakeContextCurrent(m_window);

	if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress))
	{
		std::cout << "Fail to initialize GLAD" << std::endl;
		return -1;
		}

	glViewport(0, 0, 800, 400 * sqrt(3));

	// 쉐이더
	Shader testShader("TestVertexShader.vert", "TestFragmentShader.frag");

	// VAO
	unsigned int VAO;
	glGenVertexArrays(1, &VAO);

	// VBO
	unsigned int VBO; // Vertex Buffer Object
	glGenBuffers(1, &VBO); // 버퍼 id 생성

	glBindVertexArray(VAO);
	glBindBuffer(GL_ARRAY_BUFFER, VBO); // VBO를 GL_ARRAY_BUFFER에 바인딩. GL_ARRAY_BUFFER 관련 작업은 VBO에 적용
	glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW); //VBO에 vertices 값을 복사해 넣음

	// VAO
    glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 8 * sizeof(float), (void*)0);
	glEnableVertexAttribArray(0); // location 0값
	glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 8 * sizeof(float), (void*)(3 * sizeof(float)));
	glEnableVertexAttribArray(1); // location 1값
	glVertexAttribPointer(2, 2, GL_FLOAT, GL_FALSE, 8 * sizeof(float), (void*)(6 * sizeof(float)));
	glEnableVertexAttribArray(2); // location 2값


	// EBO
	unsigned int EBO;
	glGenBuffers(1, &EBO);

	glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, EBO);
	glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);


	unsigned int texture1, texture2;
	glGenTextures(1, &texture1);
	glBindTexture(GL_TEXTURE_2D, texture1);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_BORDER); // set texture wrapping to GL_REPEAT (default wrapping method)
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_BORDER);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
	int width, height, nrChannels;
	stbi_set_flip_vertically_on_load(true); // tell stb_image.h to flip loaded texture's on the y-axis.
	
    unsigned char* data = stbi_load("Textures/pepe.png", &width, &height, &nrChannels, 0);
	if (data)
	{
		glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
		glGenerateMipmap(GL_TEXTURE_2D);
	}
	else
	{
		std::cout << "Failed to load texture" << std::endl;
	}
	stbi_image_free(data);

	testShader.use(); // don't forget to activate/use the shader before setting uniforms!
	// 한 프래그먼트에는 0~15까지 16개의 택스처를 동시에 사용 가능함
	testShader.setInt("texture1", 0);

	while (!glfwWindowShouldClose(m_window))
	{
		// input
		processInput(m_window);

		// render
		glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
		glClear(GL_COLOR_BUFFER_BIT);

		glActiveTexture(GL_TEXTURE0);
		glBindTexture(GL_TEXTURE_2D, texture1);
		testShader.use();

		unsigned int transformId = glGetUniformLocation(testShader.ID, "transform");
		recursive_triangle(transformId, glm::vec2(0.0f, 1.0f), glm::vec2(1.0f, -1.0f), glm::vec2(-1.0f, -1.0f), 1);


		// check and call event and swap
		glfwPollEvents();
		glfwSwapBuffers(m_window);
	}
	glDeleteVertexArrays(1, &VAO);
	glDeleteBuffers(1, &VBO);
	glDeleteBuffers(1, &EBO);
	glfwTerminate();

	return 0;
}

OpenGL 공부하기 #3 - VAO, VBO, EBO

NAEU — Sat, 5 Jul 2025 00:41:28 +0900

VAO (Vertex Array Object)

정점의 속성 구조를 저장하는 객체임

버텍스를 어떻게 해석할지 정의함 ex. 첫 3개 float은 xyz, 4번째부터 3개 flaot은 색상값 등
glGenVertexArrays()로 생성함
glBindVertexArray()로 바인딩 후 설정 저장 및 사용 가능
여러 VAO 생성하여 각각 다른 설정 가능

VBO (Vertex Buffer Object)

실제 정점 데이터를 GPU에 저장함
glGenBuffers()로 생성함
glBindBuffer(GL_ARRAY_BUFFER, id)로 바인딩함
glBufferData()로 버텍스 데이터 전송함 (데이터 복사 후 삽입)
GL_STATIC_DRAW → 자주 바뀌지 않는 데이터에 사용함

float vertices[] = {
    x, y, z, r, g, b
};

EBO (Element Buffer Object)

정점 인덱스를 통해 중복 없이 재사용 가능함
glGenBuffers() → EBO 생성함
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo)로 바인딩함
glDrawElements() 호출 시 사용함
예제에서는 glDrawArrays() 사용 중 → EBO 사용 안함

unsigned int indices[] = { 
    0, 1, 2,  
    3, 4, 5
};

glVertexAttribPointer() - VAO

버텍스 구조를 OpenGL에 설명함
ex) location 0 → 위치, location 1 → 색상
stride, offset으로 분리된 구조 처리 가능함
설정 후 glEnableVertexAttribArray()로 활성화함

glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void)0); // 위치
glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void)(3*sizeof(float))); // 색상

Shader (가볍게)

vertex shader → 정점 위치 처리함
fragment shader → 픽셀 색상 결정함
glCreateShader(), glShaderSource(), glCompileShader()로 생성 가능
glAttachShader(), glLinkProgram()으로 프로그램 연결함

while (!glfwWindowShouldClose(window)) {
    glClear(GL_COLOR_BUFFER_BIT);

    glUseProgram(shaderProgram);
    glBindVertexArray(VAO[0]);
    glDrawArrays(GL_TRIANGLES, 0, 3);

    glUseProgram(shaderProgram2);
    glBindVertexArray(VAO[1]);
    glDrawArrays(GL_TRIANGLES, 0, 3);

    glfwSwapBuffers(window);
    glfwPollEvents();

}

정리 및 해제

glDeleteBuffers(), glDeleteVertexArrays()로 메모리 해제 가능
glDeleteProgram()으로 셰이더 프로그램 삭제 가능