KiTFOx's Notepad 📝

이벤트 큐 패턴

메시지나 이벤트를 보내는 시점과 처리하는 시점을 디커플링함

보통의 이벤트는 동기적으로 연산

이벤트를 보내고, 처리하는 동안 스레드가 멈춰버리는 상황이 발생

이를 해결하고자 나온 것이 이벤트 큐 패턴이다

이벤트 발생 시, 명령을 담아 둘 공간이 필요한데 Queue에 이벤트를 담아둔다

튜토리얼 시스템에서 사용할 수 있음

그리고 이벤트가 순차적으로 진행이 되길 원할 때 사용할 수 있음

예를 들어 업적을 달성했을 때,

업적 달성에 대한 반응들이 나타나야함

만약 업적 달성이 Popup과 Sound를 출력하는데,

여러가지 업적을 한번에 달성했을 경우 해당 업적 달성에 대한 피드백을 동시적으로 출력하면 안되는 경우 FIFO 방식으로 처리할 수 있도록 이벤트 큐 패턴을 사용하면 된다

큐에 넣는 이유는 결과를 기다리지 않기 위해서이다

이벤트를 보내고, 처리하는 동안 스레드가 멈춰버리는 상황을 방지하기 위해서이다

이벤트 큐는 관찰차 패턴의 비동기형

주의사항

1. 모든 이벤트, 메시지 시스템은 피드백 루프가 생기면 안됨
2. 유기적으로 계속 연결되는 이벤트들을 넣으면 이벤트 큐 패턴을 사용하는 의미가 없어짐
3. 이벤트를 처리하는 코드 내에서는 이벤트를 보내지 않아야함

원문: https://benui.ca/unreal/ui-cpp-basics/

Unreal을 위한 많은 UI 튜토리얼은 Blueprint에 초점을 맞추고 있습니다. 이것은 더 넓은 매력을 가질 수 있지만 전문가 수준의 UI를 만들려면 C++을 사용해야 합니다.

왜 우리는 C++을 사용해야 하는가?

우선, 분명히 우리는 Blueprint로 모든 것을 할 수 있는데, 왜 우리는 C++로 UI를 만들어야 하나요? 라는 질문을 할 수 있습니다. 그것은 맞을수도 있지만 아닐수도 있습니다. Blueprint를 사용하여 전체 게임의 UI를 작성할 수 있지만 그 과정에서 몇 가지 주요 문제에 부딪힐 것입니다.

• Blueprint 기반의 대형 UI에서 성능 문제에 부딪힐 가능성이 높습니다. 작은 1회용 Blueprint는 괜찮지만 모든 프레임으로 불리는 크고 복잡한 로직의 경우 Blueprint 기반의 UI가 실제로 성능에 영향을 미칠 수 있습니다.
• Blueprint에서 복잡한 논리는 악몽을 계속 유지시킵니다. 큰 Blueprint 스크립트를 작성한 사람은 스파게티 코드에 대한 끊임없는 싸움의 원인이 될 것 입니다.
• 수집, 처리 및 데이터 프레젠테이션을 분리할 필요가 없습니다. Blueprint 전용 시스템을 사용하면 서로 다른 소스에서 데이터를 가져오는 것과 표시를 위해 포맷화하는 것을 쉽게 혼합할 수 있습니다. 이것은 디스플레이 그래프 노드가 데이터 수집 노드와 매우 밀접하게 연결되어 있기 때문에 향후 데이터를 변경하거나 구현해야 할 때 실질적인 어려움을 야기합니다.
• 많은 사람들이 한 번에 UI 작업을 하기가 더 어렵습니다. Blueprint는 이진 자산으로 병합이 불가능하므로 한번에 한 사람만 편집할 수 있습니다. UI 아티스트가 위젯의 모양을 업데이트하고 개발자가 Blueprint 로직을 업데이트하려면 아티스트가 기다려야 합니다. 대부분의 로직이 C++이면 두 사람 모두 서로의 발가락을 밟을 가능성이 낮습니다.

C++을 사용한 UI를 만드는 세가지 방법

여기서 일이 조금 까다로워집니다. 모든 UI 디자인과 마찬가지로 동일한 작업을 수행하는 100가지 방법이 있습니다. 이 세 가지 접근 방식은 다음 튜토리얼에서 개별적으로 다루겠지만 대략 다음과 같습니다

• UUserWidget 의 Subclassing(다른 클래스의 코드를 재사용할 목적으로 상속을 사용하는 경우)
• Subclassing 혹은 새로운 UMG 위젯 생성
• Subclassing 혹은 새로은 Slate 위젯 생성

이것들은 각각 장점과 단점이 있습니다. 이것들이 의마하는 바를 알기 위해서는 Slate와 UMG의 차이점에 대해 얘기해야 합니다.

Slate와 UMG

첫 번째 C++ 기반 UserWidget을 만들려면 UUserWidget의 하위 클래스인 C++ 클래스를 만들어야 합니다.

이 작업을 시작하기 전에 이제 편집기에서 UI를 만들고 팔레트에 있는 대부분의 위젯의 목적과 기능을 이해해야 합니다. 이는 에디터와 블루프린트를 사용하여 간단한 UI를 생성해봄으로써 가장 빠르게 이해할 수 있습니다. 그 방법은 시리즈 소개를 참조하십시오.

다음 단계는 C++에서 위젯을 만드는 방법을 배우는 것입니다.

이번 시리즈의 서론에서 언급했듯이 Unreal(4.15 기준)에는 UMG와 Slate 두 가지 UI 시스템이 있습니다.

Slate는 오래된 Unreal UI 시스템이고, UMG와 에디터가 기반을 두고 있습니다. 위젯 설정을 단순화하기 위해 고전적인 외관의 C++을 사용합니다. "오래된" 시스템이라고 해서 오래된 것은 아니라는 것을 이해하는 것이 중요합니다. UI에 더 복잡한 기능을 추가하기 위해 슬레이트를 점차 배워야 할 것입니다.

UMG는 Unreal 4의 일부로 추가된 새로운 UI 시스템입니다. Blueprint 친화적으로 설계되었으며 디자이너가 편집기에서 UI를 시각적으로 배치할 수 있습니다. 각 UMG 위젯은 일반적으로 거의 동일한 이름의 Slate 클래스를 내부에 가지고 있습니다. **Slate 클래스는 대부분의 로직을 처기하고 해당 UMG 클래스는 그것을 감싸는 wrapper입니다. 예를 들어 UImage는 UMG 클래스이며 내부에 SImage 인스턴스를 포함합니다.

먼저, 역사의 작은 부분입니다. 이것을 넘어가지 마세요. 여러분의 이해를 위해 중요합니다!

4.0 버전 이전에는 Unreal의 UI가 Slate라는 시스템을 사용하여 만들어졌습니다. 가능한 한 간단하게 C++의 UI를 만들 수 있도록 설계되었습니다. 나중에 튜토리얼 시리즈에서 여러분도 어떻게 사용할 수 있는지 설명하겠습니다.

언리얼 엔진 4.0 버전으로 에픽은 그들의 새로운 UI 시스템인 UMG를 출시했습니다. UMG는 효과적으로 Slate를 감싸는 wrapper 이고, Blueprints에서 더 쉽게 사용할 수 있도록 하고 UI 디자이너가 언리얼 에디터 내에서 사용자 정의 UI를 만들 수 있도록 합니다.

Slate가 논의할 모든 UMG시스템의 기초가 된다는 것을 이해하는 것이 중요합니다. 슬롯, 다양한 위젯, 위젯에 대한 옵션 등은 Slate와 모두 동일합니다. UMG는 Slate를 위한 에디터 및 Blueprint에 적합한 wrapper일 뿐입니다.

세 가지 접근방법

이 방법에서 벗어나 UI에 C++ 기반 위젯을 추가할 수 있는 방법은 크게 세 가지입니다. 아래에 나열된 것은 점진적으로 낮은 수준의 '더 많은 작업'이며, 그 중 어느 것도 문제를 해결할 수 있는 유일한 '최상의 방법'은 아니며, 각각의 접근 방식에는 각각의 장점과 단점이 있습니다.

맥락상, 여러 해 동안 Unreal UI 프로그래머로 일한 경험은 다음과 같습니다.

• 커스텀 UUserWidget - 95%의 경우 이것으로 충분함
• 커스텀 UMG/Slate subclass - 5%의 경우 (매우 특정한 것을 원할 경우 사용자 정의 UMG/Slate 서브 클래스를 만듬)

모든 것이 그렇듯이, 각 접근 방식에도 장단점이 있습니다. 하지만 일반적으로 계층 구조에서 Slate로 갈수록, 더 많은 사용자 정의를 수행할 수 있지만, Blueprints로 인터페이스를 설정하는 작업이 더 많아질 수 있습니다.

각 접근 방식을 각각의 튜토리얼로 분리했습니다.

원본 : https://ogldev.org/www/tutorial38/tutorial38.html

배경

마침내 수백만명의 독자들이 요구해온 튜토리얼. 스키닝으로도 알려진 골격 애니메이션으로, Assimp 라이브러리를 사용합니다.

골격 애니메이션은 사실 두 부분으로 이루어진 과정입니다.

첫 번째는 아티스트가 실행하고 두 번째는 프로그래머인 사용자(또는 작성한 엔진)가 실행합니다.

첫 번째 부분은 모델링 소프트웨어 내부에서 발생하며 리깅이라고 합니다.

여기서 일어나는 일은 아티스트가 mesh 아래 뼈(skeleton)의 골격(bones)을 정의하는 것입니다.

mesh는 물체의 피부(인간이든 괴물이든 무엇이든)를 나타내며 skeleton은 실제 세계에서 실제 움직임을 모방하는 방식으로 mesh를 움직이는데 사용됩니다.

이 작업은 각 정점을 하나 이상의 뼈에 할당하여 수행됩니다.

정점이 뼈에 할당되면 뼈가 이동할 때 정점에 미치는 영향의 양을 결정하는 가중치가 정의됩니다.

일반적인 방법은 모든 가중치의 합을 (정점당) 1로 만드는 것입니다.

예를 들어, 꼭짓점이 두 뼈 사이에 정확히 위치한다면 우리는 뼈가 꼭짓점에 미치는 영향이 같을 것으로 예상하기 때문에 각 뼈에 0.5의 가중치를 할당하고 싶을 것입니다. 그러나 꼭짓점이 완전히 단일 뼈의 영향 범위 내에 있는 경우 가중치는 1이 됩니다(뼈가 정점의 움직임을 자율적으로 제어함).

블렌더에서 생성된 골격 구조의 예는 다음과 같습니다:

우리가 위에서 본 것은 사실 애니메이션의 중요한 부분입니다. 아티스트는 골격 구조를 연결하고 각 애니메이션 유형("walk","run","die" 등)에 대한 키 프레임 세트를 정의합니다.

키 프레임에는 애니메이션 경로를 따라 임계점에 있는 모든 뼈의 변환이 포함되어 있습니다.

그래픽 엔진은 키 프레임의 변환 사이를 보간하여 키 프레임 간의 부드러운 움직임을 만듭니다.

골격 애니메이션에 사용되는 골격 구조는 종종 계층 구조입니다.

이것은 skeleton이 자식/부모 관계를 가지고 있으므로 skeleton tree가 생성된다는 것을 의미합니다.

root bone을 제외한 모든 뼈에는 부모가 하나씩 있습니다.

예를 들어, 인체의 경우 팔, 다리, 손가락 뼈와 같은 자식 뼈를 다음 단계로 하여 등뼈를 root로 지정할 수 있습니다.

부모의 뼈가 움직이면 모든 자식 뼈들도 움직이지만, 자식의 뼈가 움직이면 부모는 움직이지 않습니다(우리의 손가락은 손을 움직이지 않고도 움직일 수 있지만, 손이 움직이면 모든 손가락이 움직입니다). 실질적인 관점에서 이것은 우리가 뼈의 변형을 처리할 때 그것을 그것으로부터 root로 이끄는 모든 부모 뼈의 변형과 결합할 필요가 있다는 것을 의미합니다.

더 이상 조작에 대해 논의하지 않을 것입니다. 그것은 그래픽 프로그래머의 영역 밖에 있는 복잡한 주제입니다. 모델링 소프트웨어는 예술가가 이 일을 할 수 있도록 도와주는 고급 도구를 가지고 있으며 당신은 멋집 mesh와 skeleton을 만들기 위해 훌륭한 예술가가 되어야 합니다. skeletal 애니메이션을 만들기 위해 그래픽 엔진이 무엇을 해야 하는지 알아보겠습니다.

첫 번재 단계는 정점 버퍼를 정점별 골격 정보로 보강하는 것입니다.

몇 가지 옵션을 사용할 수 있지만 우리가 하려는 것은 매우 간단합니다.

각 꼭짓점에 대해 각 슬롯에 골격 ID와 가중치가 포함된 슬롯 배열을 추가합니다.

우리의 삶을 더 단순하게 만들기 위해 우리는 4개의 슬롯이 있는 배열을 사용할 것입니다.

이것은 4개 이상의 뼈에 의해 영향을 받을 수 있는 정점이 없다는 것을 의미합니다.

골격이 더 많은 모델을 로드하려면 배열 크기를 조정해야 하지만 이 튜토리얼 데모에 포함된 Doom 3 모델의 경우 골격 4개로 충분합니다. 그래서 우리의 새로운 꼭짓점 구조는 다음과 같이 보일 것입니다.

bone ID는 bone 변환 배열의 인덱스입니다.

이러한 변환은 WVP 행렬 앞의 위치와 정규에 적용됩니다(즉, 정점을 "bone space"에서 로컬 공간으로 변환).

가중치는 여러 뼈의 변환을 하나의 변환으로 결합하는 데 사용되며, 어떤 경우에도 총 가중치는 정확히 1(모델링 소프트웨어의 책임)이어야 합니다. 일반적으로 애니메이션 키 프레임 사이를 보간하고 모든 프레임의 골격 변환 배열을 업데이트합니다.

뼈 변형의 배열이 만들어지는 방법은 대개 까다로운 부분입니다.

변환은 계층 구조(즉, 트리)로 설정되며 일반적인 방법은 트리의 모든 노트에 스케일링 벡터, 회전 쿼터 및 변환 벡터를 갖는 것입니다.

실제로 각 노드에는 이러한 항목의 배열이 포함되어 있습니다. 배열의 모든 항목에는 타임스탬프가 있어야합니다. 응용 프로그램 시간이 타임스탬프 중 하나와 정확히 일치하는 경우는 드물기 때문에 응용 프로그램의 시점에 대한 정확한 변환을 얻으려면 코드가 스케일링/회전/번역을 보간할 수 있어야 합니다.

우리는 현재의 뼈에서 root까지 각 노드에 대해 동일한 프로세스를 수행하고 이 변환 체인을 함께 곱하여 최종 결과를 얻습니다. 각 골격에 대해 이 작업을 수행한 다음 쉐이더를 업데이트합니다.

지금까지 우리가 이야기한 모든 것은 꽤 일반적이었습니다.

하지만 이것은 Assimp의 골격 애니메이션에 대한 튜토리얼 입니다.

그래서 우리는 그 라이브러리에 다시 들어가서 어떻게 스키닝을 할 수 있는지 볼 필요가 있습니다.

Assimip의 좋은 점은 여러 형식의 골격 정보 로드를 지원한다는 것입니다.

나쁜점은 쉐이더에 필요한 골격 변환을 생성하기 위해 생성되는 데이터 구조에 대해 여전히 상당한 작업이 필요하다는 것입니다.

정점 수준의 뼈 정보부터 시작해보겠습니다. 다음은 Assimp 데이터 구조의 관련 부분입니다:

아마 Assimp에 대한 튜토리얼에서 기억하시겠지만, 모든 것이 aiScene 클래스(매쉬 파일을 가져올 때 받는 개체)에 포함되어 있습니다. aiScene에는 aiMesh 개체의 배열이 포함되어 있습니다. aiMesh는 모델의 일부이며 위치, 정규 텍스처 좌표 등과 같은 정점 수준의 항목을 포함합니다. 이제 aiMesh에는 aiBone 객체의 배열도 포함되어 있습니다.

놀랄 것도 없이, aiBone은 mesh의 골격에 있는 하나의 뼈를 나타냅니다. 각 골격에는 골격 계층 구조(아래 참조), 정점 가중치 배열 및 4x4 오프셋 행렬에서 찾을 수 있는 이름이 있습니다. 이 행렬이 필요한 이유는 정점이 일반적인 로컬 공간에 저장되기 때문입니다. 이는 골격 애니메이션이 지원되지 않더라도 기존 코드 기반이 모델을 로드하고 올바르게 렌더링할 수 있음을 의미합니다. 그러나 계층 구조의 뼈 변환은 뼈 공간에서 작동합니다.(그리고 모든 뼈는 고유한 공간을 가지고 있습니다. 이것이 우리가 함께 변환을 곱해야 하는 이유입니다). 오프셋 매트릭스의 작업은 매쉬의 국소 공간에서 정점 위치를 특정 뼈의 공간으로 이동시키는 것입니다.

정점 가중치 배열은 사물들이 흥미로워지기 시작하는 곳입니다.

이 배열의 각 항목에는 aiMesh의 정점 배열에 대한 인덱스(꼭짓점이 동일한 길이를 가진 여러 배열에 걸쳐 분산됨)와 가중치가 포함됩니다. 모든 꼭짓점 가중치의 합은 1이어야 하지만 이를 찾으려면 모든 뼈를 통과하고 각 특정 꼭짓점에 대한 일종의 목록으로 가중치를 누적해야 합니다.

정점 수준에서 골격 정보를 구축한 후 골격 변환 계층 구조를 처리하고 쉐이더에 로드할 최종 변환을 생성해야 합니다. 다음 그림에는 관련 데이터 구조가 표시되어 있습니다:

다시, 우리는 aiScene에서 시작합니다. aiScene 개체에는 노드 계층 구조(즉, 트리)의 루트인 aiNode 클래스의 개체에 대한 포인터가 포함되어 있습니다. 트리의 각 노드에는 부모에 대한 포인터와 자식에 대한 포인터 배열이 있습니다. 이것은 우리가 tree를 편리하게 왔다갔다 할 수 있게 해줍니다.

또한 노드는 노드 공간에서 부모 공간으로 변환하는 변환 행렬을 전달합니다. 마지막으로 노드에 이름이 있을 수도 있고 없을 수도 있습니다. 노드가 계층에서 골격을 나타내는 경우 노드 이름이 골격 이름과 일치해야 합니다. 그러나 노드에 이름이 없는 경우(즉, 대응하는 골격이 없음) 노드의 역할은 단순히 모델을 분해하고 중간 변환을 배치하는 것을 돕는 것입니다.

퍼즐의 마지막 조각은 aiScene 객체에도 저장된 aiAnimation 배열입니다. 단일 aiAnimation 객체는 "walk", "run", "shoot" 등과 같은 일련의 애니메이션 프레임을 나타냅니다. 프레임 사이를 보간함으로써 애니메이션 이름과 일치하는 원하는 시각적 효과를 얻을 수 있습니다. 애니메이션에는 눈금의 지속 시간과 초당 눈금 수(예: 100개의 눈금과 25개의 눈금은 4초의 애니메이션을 나타냄)가 있어 애니메이션이 모든 하드웨어에서 동일하게 보이도록 진행 시간을 조정할 수 있습니다. 또한 이 애니메이션에는 채널이라고 하는 aiNodeAnim 객체의 배열이 있습니다. 각각의 채널은 사실 모든 변형이 있는 뼈입니다. 채널에는 계층 구조의 노드 중 하나와 세 개의 변환 배열과 일치해야 하는 이름이 포함되어 있습니다.

특정 시점의 최종 뼈 변환을 계산하기 위해서는 이 세 배열에서 각각 시간과 일치하는 두 개의 항목을 찾고 그 사이를 보간해야 합니다. 그런 다음 변환을 하나의 행렬로 결합해야 합니다. 이 작업을 수행한 후에는 계층 구조에서 해당 노드를 찾아 상위 노드로 이동해야 합니다. 그러면 부모에 해당하는 채널이 필요하고 동일한 보간 과정을 수행해야 합니다. 우리는 두 변환을 함께 곱하고 계층의 root에 도달할 때까지 계속합니다.

Source Walthru

(mesh.cpp:75)

bool Mesh::LoadMesh(const string& Filename)
{
    // Release the previously loaded mesh (if it exists)
    Clear();

    // Create the VAO
    glGenVertexArrays(1, &m_VAO);
    glBindVertexArray(m_VAO);

    // Create the buffers for the vertices attributes
    glGenBuffers(ARRAY_SIZE_IN_ELEMENTS(m_Buffers), m_Buffers);

    bool Ret = false;

    m_pScene = m_Importer.ReadFile(Filename.c_str(), aiProcess_Triangulate | aiProcess_GenSmoothNormals |
                                    aiProcess_FlipUVs);

    if (m_pScene) {
       m_GlobalInverseTransform = m_pScene->mRootNode->mTransformation;
       m_GlobalInverseTransform = m_GlobalInverseTransform.Inverse();
       Ret = InitFromScene(m_pScene, Filename);
    }
    else {
       printf("Error parsing '%s': '%s'\n", Filename.c_str(), m_Importer.GetErrorString());
    }

    // Make sure the VAO is not changed from the outside
    glBindVertexArray(0);

    return Ret;
}

다음은 매쉬 클래스의 업데이트된 진입점으로, 변경 사항은 굵은 글씨로 표시됩니다. 우리가 주목해야 할 몇 가지 변화가 있습니다. 하나는 임포터와 aiScene 개체가 이제 변수를 쌓지 않고 클래스 멤버가 된다는 것입니다. 그 이유는 런타임 중에 우리는 aiScene 객체로 다시 돌아갈 것이기 때문에 수입자와 장면의 범위를 모두 확장해야 합니다. 실제 게임에서는 필요한 것을 복사하여 최적화된 형식으로 저장하고 싶을 수 있지만 교육적인 목적을 위해서는 이것으로 충분합니다.

두 번째 변경 사항은 계층 구조의 루트에 대한 변환 행렬이 추출되고 역방향으로 저장된다는 것입니다. 우리는 앞으로 더 멀리서 그것을 사용할 것입니다. 행렬 역코드가 Assimp 라이브러리에서 Matrix4f 클래스로 복사되었습니다.

(mesh.h:69)

struct VertexBoneData
{
    uint IDs[NUM_BONES_PER_VERTEX];
    float Weights[NUM_BONES_PER_VERTEX];
}

(mesh.cpp:107)

bool Mesh::InitFromScene(const aiScene* pScene, const string& Filename)
{
    ...
    vector<VertexBoneData> Bones;
    ...
    Bones.resize(NumVertices);
    ...
    glBindBuffer(GL_ARRAY_BUFFER, m_Buffers[BONE_VB]);
    glBufferData(GL_ARRAY_BUFFER, sizeof(Bones[0]) * Bones.size(), &Bones[0], GL_STATIC_DRAW);
    glEnableVertexAttribArray(BONE_ID_LOCATION);
    glVertexAttribIPointer(BONE_ID_LOCATION, 4, GL_INT, sizeof(VertexBoneData), (const GLvoid*)0);
    glEnableVertexAttribArray(BONE_WEIGHT_LOCATION);
    glVertexAttribPointer(BONE_WEIGHT_LOCATION, 4, GL_FLOAT, GL_FALSE, sizeof(VertexBoneData), (const GLvoid*)16);
    ...
}

위의 구조는 꼭짓점 수준에서 우리가 필요로 하는 모든 것을 포함하고 있습니다. 기본적으로 4개의 뼈(뼈당 ID 및 무게)를 저장할 수 있는 충분한 저장 공간이 있습니다.

VertexBoneData는 쉐이더에 쉽게 전달할 수 있도록 그렇게 구성되었습니다. 우리는 이미 위치 0, 1, 2에 각각 위치, 텍스처 좌표 및 일반 경계를 확보했습니다. 따라서 위치 3에서 골격 ID를 바인딩하고 위치 4에서 가중치를 바인딩하도록 VAO를 구성합니다. 우리가 glVertexAttribute를 사용한다는 것을 주목하는 것도 매우 중요합니다. ID를 바인딩할 glVertexAttributePointer가 아닌 IPointer입니다. 이 점에 주의하십시오. 그렇지 않으면 쉐이더에 손상된 데이터가 표시됩니다.

(mesh.cpp:213)

void Mesh::LoadBones(uint MeshIndex, const aiMesh* pMesh, vector& Bones)
{
    for (uint i = 0 ; i < pMesh->mNumBones ; i++) {
        uint BoneIndex = 0;
        string BoneName(pMesh->mBones[i]->mName.data);

        if (m_BoneMapping.find(BoneName) == m_BoneMapping.end()) {
            BoneIndex = m_NumBones;
            m_NumBones++;
            BoneInfo bi;
            m_BoneInfo.push_back(bi);
        }
        else {
            BoneIndex = m_BoneMapping[BoneName];
        }

        m_BoneMapping[BoneName] = BoneIndex;
        m_BoneInfo[BoneIndex].BoneOffset = pMesh->mBones[i]->mOffsetMatrix;

        for (uint j = 0 ; j < pMesh->mBones[i]->mNumWeights ; j++) {
            uint VertexID = m_Entries[MeshIndex].BaseVertex + pMesh->mBones[i]->mWeights[j].mVertexId;
            float Weight = pMesh->mBones[i]->mWeights[j].mWeight;
            Bones[VertexID].AddBoneData(BoneIndex, Weight);
        }
    }
}

위의 함수는 단일 aiMesh 개체에 대한 정점 골격 정보를 로드합니다. Mesh::InitMesh()에서 호출됩니다. 이 함수는 VertexBoneData 구조를 채우는 것 외에도 골격 이름과 골격 ID(이 함수에 의해 관리되는 실행중인 인덱스) 사이의 맵을 업데이트하고 골격 ID를 기반으로 벡터에 오프셋 행렬을 저장합니다. 정점 ID가 계산되는 방법을 기록합니다. 정점 ID는 단일 매쉬와 관련이 있고 모든 매쉬를 단일 벡터에 저장하기 때문에 현재 aiMesh의 기본 정점 ID를 mWeights 배열의 정점 ID에 추가하여 절대 정점 ID를 얻습니다.

(mesh.cpp:29)

void Mesh::VertexBoneData::AddBoneData(uint BoneID, float Weight)
{
    for (uint i = 0 ; i < ARRAY_SIZE_IN_ELEMENTS(IDs) ; i++) {
        if (Weights[i] == 0.0) {
            IDs[i] = BoneID;
            Weights[i] = Weight;
            return;
        }
    }

    // should never get here - more bones than we have space for
    assert(0);
}

이 유틸리티 함수는 VertexBoneData 구조에서 빈 슬롯을 찾아 골격 ID와 가중치를 배치합니다. 일부 정점은 4개 미만의 뼈에 의해 영향을 받지만 존재하지 않는 뼈의 무게가 0으로 유지되기 때문에(VertexBoneData 생성자 참조), 이는 모든 뼈 수에 대해 동일한 가중치 계산을 사용할 수 있습니다.

 (mesh.cpp:473)

Matrix4f Mesh::BoneTransform(float TimeInSeconds, vector<Matrix4f>& Transforms)
{
    Matrix4f Identity;
    Identity.InitIdentity();

    float TicksPerSecond = m_pScene->mAnimations[0]->mTicksPerSecond != 0 ?
                            m_pScene->mAnimations[0]->mTicksPerSecond : 25.0f;
    float TimeInTicks = TimeInSeconds * TicksPerSecond;
    float AnimationTime = fmod(TimeInTicks, m_pScene->mAnimations[0]->mDuration);

    ReadNodeHierarchy(AnimationTime, m_pScene->mRootNode, Identity);

    Transforms.resize(m_NumBones);

    for (uint i = 0 ; i < m_NumBones ; i++) {
        Transforms[i] = m_BoneInfo[i].FinalTransformation;
    }
}

앞서 본 정점 수준의 골격 정보 로드는 매쉬가 시작 중에 로드될 때 한 번만 수행됩니다. 이제 우리는 매 프레임마다 쉐이더에 들어가는 뼈 변형을 계산하는 두 번재 부분으로 넘어갑니다. 위의 기능은 이 활동의 시작점입니다. 호출자는 현재 시간을 초 단위로 보고하고(분수일 수 있음), 업데이트해야하는 행렬의 벡터를 제공합니다. 우리는 애니메이션 주기 내에서 상대적인 시간을 찾고 노드 계층 구조를 처리합니다. 결과는 호출자에게 반환되는 일련의 변환입니다.

(mesh.cpp:428)

void Mesh::ReadNodeHierarchy(float AnimationTime, const aiNode* pNode, const Matrix4f& ParentTransform)
{
    string NodeName(pNode->mName.data);

    const aiAnimation* pAnimation = m_pScene->mAnimations[0];

    Matrix4f NodeTransformation(pNode->mTransformation);

    const aiNodeAnim* pNodeAnim = FindNodeAnim(pAnimation, NodeName);

    if (pNodeAnim) {
        // Interpolate scaling and generate scaling transformation matrix
        aiVector3D Scaling;
        CalcInterpolatedScaling(Scaling, AnimationTime, pNodeAnim);
        Matrix4f ScalingM;
        ScalingM.InitScaleTransform(Scaling.x, Scaling.y, Scaling.z);

        // Interpolate rotation and generate rotation transformation matrix
        aiQuaternion RotationQ;
        CalcInterpolatedRotation(RotationQ, AnimationTime, pNodeAnim);
        Matrix4f RotationM = Matrix4f(RotationQ.GetMatrix());

        // Interpolate translation and generate translation transformation matrix
        aiVector3D Translation;
        CalcInterpolatedPosition(Translation, AnimationTime, pNodeAnim);
        Matrix4f TranslationM;
        TranslationM.InitTranslationTransform(Translation.x, Translation.y, Translation.z);

        // Combine the above transformations
        NodeTransformation = TranslationM * RotationM * ScalingM;
    }

    Matrix4f GlobalTransformation = ParentTransform * NodeTransformation;

    if (m_BoneMapping.find(NodeName) != m_BoneMapping.end()) {
        uint BoneIndex = m_BoneMapping[NodeName];
        m_BoneInfo[BoneIndex].FinalTransformation = m_GlobalInverseTransform * GlobalTransformation *
                                                    m_BoneInfo[BoneIndex].BoneOffset;
    }

    for (uint i = 0 ; i < pNode->mNumChildren ; i++) {
        ReadNodeHierarchy(AnimationTime, pNode->mChildren[i], GlobalTransformation);
    }
}

이 함수는 노드 트리를 통과하고 지정된 애니메이션 시간에 따라 각 노드/본에 대한 최종 변환을 생성합니다. 매쉬가 하나의 애니메이션 시퀀스만 가지고 있다고 가정한다는 점에서 제한적입니다.

여러 애니메이션을 지원하려면 애니메이션 이름을 말하고 m_pScene->mAnimations[] 배열에서 검색해야 합니다. 위의 코드는 우리가 사용하는 데모 매쉬에 충분합니다.

노드 변환은 노드의 mTransformation 멤버에서 초기화됩니다. 만약 노드가 뼈와 일치하지 않는다면 그것이 뼈의 최종변환입니다. 그렇게 되면 생성한 행렬로 덮어씁니다. 이 작업은 다음과 같이 수행됩니다. 먼저 애니메이션의 채널 배열에서 노드 이름을 검색합니다. 그런 다음 애니메이션 시간을 기반으로 스케일링 벡터, 회전 쿼터 및 변환 벡터를 보간합니다. 우리는 그것들을 하나의 행렬로 결합하고 매개 변수로 얻은 행렬(GlobablTransformation)로 곱합니다.

이 함수는 재귀적이며 글로벌 변환 매개 변수가 ID 매트릭스인 root 노드에 대해 호출됩니다. 각 노드는 모든 자식에 대해 이 함수를 재귀적으로 호출하고 자체 변환을 전역 변환으로 전달합니다. 처음부터 끝까지 모든 노드에서 통합된 변환 체임을 얻을 수 있습니다.

m_BoneMapping 배열은 노드 이름을 생성하는 인덱스에 매핑하고 이 인덱스를 최종 변환이 저장되는 m_BoneInfo 배열의 항목으로 사용합니다. 최종 변환은 다음과 같이 계산됩니다. 우리는 로컬 공간 위치에서 정점을 노드 공간으로 가져오는 노드 오프셋 행렬로 시작합니다. 그런 다음 모든 노드 부모의 결합된 변환과 애니메이션 시간에 따라 노드에 대해 계산한 특정 변환을 곱합니다.

여기서는 Assimp 코드를 사용하여 수학 문제를 처리합니다. 나는 그것을 우리만의 코드 베이스로 복제하는 것이 의미가 없다고 생각해서 그냥 Assimp를 사용했습니다.

(mesh.cpp:387)

void Mesh::CalcInterpolatedRotation(aiQuaternion& Out, float AnimationTime, const aiNodeAnim* pNodeAnim)
{
    // we need at least two values to interpolate...
    if (pNodeAnim->mNumRotationKeys == 1) {
        Out = pNodeAnim->mRotationKeys[0].mValue;
        return;
    }

    uint RotationIndex = FindRotation(AnimationTime, pNodeAnim);
    uint NextRotationIndex = (RotationIndex + 1);
    assert(NextRotationIndex < pNodeAnim->mNumRotationKeys);
    float DeltaTime = pNodeAnim->mRotationKeys[NextRotationIndex].mTime - pNodeAnim->mRotationKeys[RotationIndex].mTime;
    float Factor = (AnimationTime - (float)pNodeAnim->mRotationKeys[RotationIndex].mTime) / DeltaTime;
    assert(Factor >= 0.0f && Factor <= 1.0f);
    const aiQuaternion& StartRotationQ = pNodeAnim->mRotationKeys[RotationIndex].mValue;
    const aiQuaternion& EndRotationQ = pNodeAnim->mRotationKeys[NextRotationIndex].mValue;
    aiQuaternion::Interpolate(Out, StartRotationQ, EndRotationQ, Factor);
    Out = Out.Normalize();
}

이 방법은 애니메이션 시간을 기준으로 지정된 채널의 회전쿼터를 보간합니다(채널에 키 쿼터 배열이 포함되어 있음). 먼저 필요한 애니메이션 시간 직전의 핵심 쿼터의 인덱스를 찾습니다. 애니메이션 시간에서 이전 키까지의 거리와 해당 키와 다음 키 사이의 거리 사이의 비율을 계산합니다. 우리는 그 요소를 사용하여 이 두 키 사이를 보간해야 합니다. 우리는 Assimp 코드를 사용하여 보간을 수행하고 결과를 정규화합니다. 위치 및 스케일링에 대한 해당 방법은 매우 유사하므로 여기서는 인용하지 않습니다.

(mesh.cpp:335)

uint Mesh::FindRotation(float AnimationTime, const aiNodeAnim* pNodeAnim)
{
    assert(pNodeAnim->mNumRotationKeys > 0);

    for (uint i = 0 ; i < pNodeAnim->mNumRotationKeys - 1 ; i++) {
        if (AnimationTime < (float)pNodeAnim->mRotationKeys[i + 1].mTime) {
            return i;
        }
    }

    assert(0);
}

이 유틸리티 방법은 애니메이션 시간 직전의 키 회전을 찾습니다. N 키 회전이 있으면 결과는 0에서 N-2가 될 수 있습니다. 애니메이션 시간은 항상 채널의 지속 시간 내에 포함되므로 마지막 키(N-1)는 유효한 결과가 될 수 없습니다.

(skihnning.vs)

#version 330

layout (location = 0) in vec3 Position;
layout (location = 1) in vec2 TexCoord;
layout (location = 2) in vec3 Normal;
layout (location = 3) in ivec4 BoneIDs;
layout (location = 4) in vec4 Weights;

out vec2 TexCoord0;
out vec3 Normal0;
out vec3 WorldPos0;

const int MAX_BONES = 200;

uniform mat4 gWVP;
uniform mat4 gWorld;
uniform mat4 gBones[MAX_BONES];

void main()
{
    mat4 BoneTransform = gBones[BoneIDs[0]] * Weights[0];
    BoneTransform += gBones[BoneIDs[1]] * Weights[1];
    BoneTransform += gBones[BoneIDs[2]] * Weights[2];
    BoneTransform += gBones[BoneIDs[3]] * Weights[3];

    vec4 PosL = BoneTransform * vec4(Position, 1.0);
    gl_Position = gWVP * PosL;
    TexCoord0 = TexCoord;
    vec4 NormalL = BoneTransform * vec4(Normal, 0.0);
    Normal0 = (gWorld * NormalL).xyz;
    WorldPos0 = (gWorld * PosL).xyz;
}

이제 매쉬 클래스의 변경 작업을 마쳤으므로 쉐이더 수준에서 수행해야 할 작업을 살펴보겠습니다.

먼저 VSInput 구조에 골격 ID 및 가중치 배열을 추가했습니다.

다음으로, 골격 변환을 포함하는 새로운 균일 배열이 있습니다. 쉐이더 자체에서 우리는 정점의 뼈 변환 행렬과 가중치의 조합으로 최종 뼈 변환을 계산합니다. 이 최종 행렬은 위치와 노말을 골격 공간에서 로컬 공간으로 변환하는데 사용됩니다. 여기서 부터 모든 것이 동일합니다.

(tutorial38.cpp:140)

float RunningTime = (float)((double)GetCurrentTimeMillis() - (double)m_startTime) / 1000.0f;

m_mesh.BoneTransform(RunningTime, Transforms);

for (uint i = 0 ; i < Transforms.size() ; i++) {
    m_pEffect->SetBoneTransform(i, Transforms[i]);
}

우리가 마지막으로 해야 할 일은 이 모든 것들을 애플리케이션 코드에 통합하는 것입니다.

이 작업은 위의 간단한 코드로 수행됩니다. 이 작업은 위의 간단한 코드로 수행됩니다.

GetCurrentTimeMillis() 함수는 응용 프로그램 시작 이후의 시간을 밀리초 단위로 반환합니다(분수를 수용하려면 부동 소수점을 참고하십시오).

모든 작업을 올바르게 수행한 경우 최종 결과는 이것과 유사합니다.

소스 코드 주소 : https://github.com/emeiri/ogldev/tree/master/tutorial28_youtube

원본 : http://www.opengl-tutorial.org/kr/intermediate-tutorials/tutorial-16-shadow-mapping/

튜토리얼 15에서는 정적 조명을 포함하는 라이트 맵을 만드는 방법을 배웠습니다.

아주 멋진 그림자를 만들어내기는 하지만, 애니메이션 모델은 다루지 않습니다.

Shadow Map은 현재(2016년 기준) 동적 Shadow를 만드는 방법입니다. 이 방법의 좋은 점은 작업을 시작하기에 꽤 쉽다는 것입니다. 나쁜점은 제대로 작업 하기가 매우 어렵다는 것입니다.

이 튜토리얼에서는 먼저 기본 알고리즘을 소개하고 단점을 확인한 다음 몇 가지 기술을 구현하여 더 나은 결과를 얻을 것입니다. Shadow Map을 작성할 당시(2012년)에는 여전히 많은 연구가 진행 중인 주제이기 때문에 필요에 따라 자체 Shadow Map을 더욱 개선할 수 있는 몇 가지 방법을 알려드리겠습니다.

기본 Shadowmap

기본 Shadow Map 알고리즘은 두 개의 패스로 구성됩니다.

먼저, 장면은 빛의 관점에서 렌더링됩니다. 각 fragment의 깊이만 계산됩니다.

그런 다음 씬(scene)이 평소와 같이 렌더링되지만 추가 테스트를 통해 현재 조각이 그림자에 표시됩니다.

"그림자 속에 있는 물체" 테스트는 사실 매우 간단합니다.

현재 샘플이 동일한 점에서 그림자 맵보다 빛에서 멀리 떨어져 있으면 씬(scene)에 빛에 더 가까운 개체가 포함되어 있음을 의미합니다.

즉, 현재 fragment는 그림자에 있습니다.

다음 이미지는 원리를 이해하는 데 도움이 될 수 있습니다.

Shadowmap 렌더링하기

이 튜토리얼에서는 directional lights(모든 광선이 평행하다고 간주될 수 있을 정도로 멀리 떨어져 있는 조명)만 고려합니다. 따라서 Shadow Map 렌더링은 직교 투영 행렬을 사용하여 수행됩니다. 직교 행렬은 원근법이 고려되지 않는다는 점을 제외하고는 일반적인 원근법 투영 행렬과 같습니다. 물체는 카메라 가까이에 있는 멀리있든 동일하게 보입니다.

렌더 대상 및 MVP 매트릭스 설정

튜토리얼 14부터는 쉐이더에서 나중에 액세스하기 위해 장면을 텍스처로 렌더링하는 방법을 배웠습니다.

여기서는 Shadow Map을 포함하기 위해 1024x1024 16비트 depth 텍스처를 사용합니다.

Shadow Map에는 일반적으로 16비트로 충분합니다. 이 값들을 자유롭게 시험해보세요. 나중에 샘플링해야 하므로 depth 렌더 버퍼가 아닌 depth 텍스처를 사용합니다.

// The framebuffer, which regroups 0, 1, or more textures, and 0 or 1 depth buffer.
 GLuint FramebufferName = 0;
 glGenFramebuffers(1, &FramebufferName);
 glBindFramebuffer(GL_FRAMEBUFFER, FramebufferName);

 // Depth texture. Slower than a depth buffer, but you can sample it later in your shader
 GLuint depthTexture;
 glGenTextures(1, &depthTexture);
 glBindTexture(GL_TEXTURE_2D, depthTexture);
 glTexImage2D(GL_TEXTURE_2D, 0,GL_DEPTH_COMPONENT16, 1024, 1024, 0,GL_DEPTH_COMPONENT, GL_FLOAT, 0);
 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
 glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);

 glFramebufferTexture(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, depthTexture, 0);

 glDrawBuffer(GL_NONE); // No color buffer is drawn to.

 // Always check that our framebuffer is ok
 if(glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE)
 return false;

빛의 관점에서 장면을 렌더링하는 데 사용되는 MVP 매트릭스는 다음과 같이 계산됩니다:

• Projection 행렬은 X,Y 및 Z 축에서 각각 축 정렬 상자(-10, 10), (-10,10), (-10, 20)의 모든 것을 포함하는 직교 행렬입니다. 이러한 값은 전체 *가시적인* 장면을 항상 볼 수 있도록 만들어졌으며, 이에 대한 자세한 내용은 추가 진행 섹션을 참조하십시오.
• View 행렬은 카메라 공간에서 조명 방향이 -Z가 되도록 월드를 회전시킵니다(튜토리얼 3 참조)
• Model 행렬은 원하는 대로 사용할 수 있습니다.

glm::vec3 lightInvDir = glm::vec3(0.5f,2,2);

 // Compute the MVP matrix from the light's point of view
 glm::mat4 depthProjectionMatrix = glm::ortho<float>(-10,10,-10,10,-10,20);
 glm::mat4 depthViewMatrix = glm::lookAt(lightInvDir, glm::vec3(0,0,0), glm::vec3(0,1,0));
 glm::mat4 depthModelMatrix = glm::mat4(1.0);
 glm::mat4 depthMVP = depthProjectionMatrix * depthViewMatrix * depthModelMatrix;

 // Send our transformation to the currently bound shader,
 // in the "MVP" uniform
 glUniformMatrix4fv(depthMatrixID, 1, GL_FALSE, &depthMVP[0][0])

쉐이더

이 패스 동안 사용되는 쉐이더는 매우 간단합니다. vertex 쉐이더는 균질 좌표에서 정점의 위치를 간단히 계산하는 통과 쉐이더입니다:

#version 330 core

// Input vertex data, different for all executions of this shader.
layout(location = 0) in vec3 vertexPosition_modelspace;

// Values that stay constant for the whole mesh.
uniform mat4 depthMVP;

void main(){
 gl_Position =  depthMVP * vec4(vertexPosition_modelspace,1);
}

fragment 쉐이더는 단순하기 때문에 fragment의 깊이를 위치 0(즉, 깊이 텍스처)에 기록하기만 하면 됩니다.

#version 330 core

// Ouput data
layout(location = 0) out float fragmentdepth;

void main(){
    // Not really needed, OpenGL does it anyway
    fragmentdepth = gl_FragCoord.z;
}

Shadow Map을 렌더링하는 속도는 일반적으로 일반 렌더링보다 두 배 이상 빠릅니다. 깊이와 색상 대신 정밀도가 낮은 깊이만 기록되기 때문입니다. 메모리 대역폭은 GPU에서 가장 큰 성능 문제입니다.

결과

결과 텍스처는 다음과 같습니다.

어두운 색상은 작은 z를 의미합니다. 따라서 벽의 오른쪽 상단 모서리가 카메라 근처에 있습니다.

반대로 흰색은 z=1(동일한 좌표)을 의미하므로 매우 멀리 떨어져 있습니다.

Shadowmap 사용하기

기본 쉐이더

이제 평소의 쉐이더로 돌아갑니다. 계산하는 각 fragment에 대해 Shadow Map 뒤에 있는지 여부를 테스트해야 합니다.

이를 위해 Shadow Map을 만들 때 사용한 공간과 동일한 공간에서 현재 fragment의 위치를 계산해야 합니다. 따라서 일반적인 MVP 행렬로 한 번 변환하고 깊이 MVP 행렬로 한 번 변환해야 합니다.

하지만 약간의 속임수가 있습니다. 정점 위치에 깊이를 곱하면 MVP는 [-1,1]에 있는 균일한 좌표를 제공하지만 텍스처 샘플링은 [0,1]에서 수행해야 합니다.

예를 들어, 화면 중앙에 있는 fragment는 균일한 좌표로 (0,0)에 있을 것입니다. 그러나 질감 중간은 샘플링해야 하므로 UV는 (0.5,05)이어야 합니다.

이것은 fragment shader에서 직접 fetch 좌표를 조정하여 해결할 수 있지만, 단순히 좌표를 2(대각선 : [-1.1] -> [-0.5,0.5])로 나누고 변환하는 행렬(아래 행 : [-0.5,0.5]->[0,1])을 곱하는 것이 더 효율적입니다.

glm::mat4 biasMatrix(
0.5, 0.0, 0.0, 0.0,
0.0, 0.5, 0.0, 0.0,
0.0, 0.0, 0.5, 0.0,
0.5, 0.5, 0.5, 1.0
);
glm::mat4 depthBiasMVP = biasMatrix*depthMVP;

이제 vertex 쉐이더를 작성할 수 있습니다. 이전과 동일하지만 1:1이 아닌 2개의 위치를 출력합니다:

• gl_Position 은 현재 카메라에서 볼 수 있는 정점의 위치입니다.
• ShadowCoord는 마지막 카메라(빛)에서 볼 수 있는 정점의 위치입니다.

// Output position of the vertex, in clip space : MVP * position
gl_Position =  MVP * vec4(vertexPosition_modelspace,1);

// Same, but with the light's view matrix
ShadowCoord = DepthBiasMVP * vec4(vertexPosition_modelspace,1);

그런 다음 fragment 쉐이더는 매우 간단합니다:

• texture(shadowMap, ShadowCoord.xy).z 는 빛과 가장 가까운 빛을 차단하는 폐색자 사이의 거리입니다.
• ShadowCoord.z는 빛과 현재 fragment 사이의 거리입니다.

...따라서 현재 fragment가 가장 가까운 폐색자보다 멀리 있으면, 이것은 우리가 (해당 가장 가까운 폐색자의) 그림자에 있다는 것을 의미합니다.

float visibility = 1.0;
if ( texture( shadowMap, ShadowCoord.xy ).z  <  ShadowCoord.z){
    visibility = 0.5;
}

우리는 이 지식을 이용하여 음영을 수정해야 합니다. 물론 주변 색상은 수정되지 않습니다. 생활 속의 목적은 우리가 그림자 속에 있을 때도 들어오는 빛을 가짜로 만드는 것이기 때문입니다(또는 모든 것이 순수한 검은색일 것입니다)

color =
 // Ambient : simulates indirect lighting
 MaterialAmbientColor +
 // Diffuse : "color" of the object
 visibility * MaterialDiffuseColor * LightColor * LightPower * cosTheta+
 // Specular : reflective highlight, like a mirror
 visibility * MaterialSpecularColor * LightColor * LightPower * pow(cosAlpha,5);

결과 - 쉐도우 아크네

다음은 현재 코드의 결과입니다. 분명히, 아이디어는 뛰어나지만 , 품질은 받아들일 수 없습니다.

이 이미지의 각 문제를 살펴보겠습니다.

코드에는 ShadowMap과 ShadowMap_simple의 두 가지 프로젝트가 있으며, 둘 중 더 마음에 드는 것으로 시작하세요.

간단한 버전은 위의 이미지만큼 품질이 좋지 않지만 이해하기가 더 쉽습니다.

문제점들

Shadow acne

가장 명백한 문제점은 shadow acne이다:

이 현상은 간단한 이미지로 쉽게 설명할 수 있습니다:

이에 대한 일반적인 "수정"은 error margin을 추가하는 것입니다. 현재 fragment의 depth(다시말해, 빛 공간)가 라이트맵 값에서 정말 멀리 떨어져 있는 경우에만 음영 처리합니다. 편향을 추가하여 이를 수행합니다:

float bias = 0.005;
float visibility = 1.0;
if ( texture( shadowMap, ShadowCoord.xy ).z  <  ShadowCoord.z-bias){
    visibility = 0.5;
}

결과물은 훨씬 나아집니다:

하지만, 여러분은 우리의 편견 때문에 땅과 벽 사이의 인공물이 더 나빠졌다는 것을 알아차릴 수 있습니다.

게다가, 0.005의 편향은 땅에서는 너무 많이 보이지만, 곡면에서는 충분하지 않습니다: 몇몇 인공물들은 실린더와 구에 남아 있습니다.

일반적인 접근 방식은 기울기에 따라 치우침을 수정하는 것입니다:

float bias = 0.005*tan(acos(cosTheta)); // cosTheta is dot( n,l ), clamped between 0 and 1
bias = clamp(bias, 0,0.01);

Shadow acne는 이제, 구부러진 표면에서도 사라졌습니다.

지오메트리에 따라 작동하거나 작동하지 않을 수 있는 또 다른 방법은 ShadowMap에서 뒷면만 렌더링하는 것입니다. 이것은 우리가 두꺼운 벽을 가진 특별한 기하학적 구조(다음 섹션 - Peter Panning 참조)를 갖도록 강요하지만, 적어도 acne는 그림자에 있는 표면에 있을 것입니다.

ShadowMap을 렌더링할 때 전면 삼각형을 잘라냅니다.

        // We don't use bias in the shader, but instead we draw back faces,
        // which are already separated from the front faces by a small distance
        // (if your geometry is made this way)
        glCullFace(GL_FRONT); // Cull front-facing triangles -> draw only back-facing triangles

그리고 씬(scene)을 렌더링할 때는 정상적으로 렌더링합니다(뒷면 절단)

         glCullFace(GL_BACK); // Cull back-facing triangles -> draw only front-facing triangles

이 방법은 편향 외에도 코드에 사용됩니다.

Peter Panning

우리는 더 이상 Shadow acne가 없지만, 여전히 잘못된 음영의 땅을 가지고 있고, 벽을 날아다니는 것처럼 보이게 합니다(이후 "피터 패닝"이라는 용어). 사실, 편향(bias)을 더하는 것은 상황을 더 악화시켰습니다.

이것은 매우 쉽게 고칠 수 있습니다. 얇은 기하학적 구조를 피하기만 하면 됩니다. 두 가지 이점이 있습니다.

• 먼저, 피터 패닝을 해결합니다. 기하학이 여러분의 편견보다 더 깊다면, 여러분은 준비가 다 된 것입니다.
• 두 번째로, 라이트맵을 렌더링할 때 후면 절단 기능을 설정할 수 있습니다. 왜냐하면 이제 벽의 다각형이 빛을 향하고 있기 때문입니다. 이 다각형은 뒷면 절단 기능을 사용하여 렌더링되지 않을 수 있습니다.

단점은 렌더링할 삼각형이 더 많다는 것입니다(프레임당 두 번!)

Aliasing

이 두 가지 방법에도 불구하고, 여러분은 그림자의 경계에 여전히 앨리어싱이 있다는 것을 알아차릴 것입니다. 즉, 한 픽셀은 흰색이고 다음 픽셀은 검은색입니다. 그 사이에 매끄러운 전환이 없습니다.

PCF

이를 개선하는 가장 쉬운 방법은 ShadowMap의 샘플러 유형을 Sampler2D 쉐이더로 변경하는 것입니다.

결과적으로 ShadowMap을 한 번 샘플링하면 하드웨어가 실제로 인접한 텍셀도 샘플링하고 모든 텍셀에 대해 비교를 수행하며 비교 결과의 이중 선형 필터링과 함께 [0,1]의 부동 소수점을 반환합니다.

예를 들어, 0.5는 두 개의 표본이 그림자에 있고 두 개의 표본이 빛에 있다는 것을 의미합니다.

필터링된 깊이 맵의 단일 샘플링과 동일하지 않습니다! 비교는 항상 true 또는 false를 반환합니다. PCF는 4 "true 또는 false"의 보간값을 제공합니다.

보시다시피 그림자 테두리는 매끄럽지만 그림자 맵의 텍스처는 여전히 보입니다.

Poisson Sampling

이 문제를 해결하는 쉬운 방법은 쉐도우 맵을 한 번이 아니라 N번 샘플링하는 것입니다. PCF와 함께 사용하면 N이 작더라도 매우 좋은 결과를 얻을 수 있습니다. 샘플 4개에 대한 코드는 다음과 같습니다:

for (int i=0;i<4;i++){
  if ( texture( shadowMap, ShadowCoord.xy + poissonDisk[i]/700.0 ).z  <  ShadowCoord.z-bias ){
    visibility-=0.2;
  }
}

poissonDisk는 예를 들어 다음과 같이 정의된 상수 배열입니다:

vec2 poissonDisk[4] = vec2[](
  vec2( -0.94201624, -0.39906216 ),
  vec2( 0.94558609, -0.76890725 ),
  vec2( -0.094184101, -0.92938870 ),
  vec2( 0.34495938, 0.29387760 )
);

이 방법은 통과할 쉐도우 맵 샘플 수에 따라 생성된 fragment가 다소 어두워집니다.

700.0 상수는 표본이 "확산"되는 정도를 정의합니다. 너무 적게 퍼뜨리면 다시 앨리어싱이 발생하고, 너무 많이 퍼뜨리면 밴딩이 발생합니다.*(이 스크린샷은 더 극적인 효과를 위해 PCF를 사용하지 않고 대신 16개의 샘플을 사용합니다.*

Stratified Poisson Sampling

픽셀마다 다른 샘플을 선택하여 이 밴딩을 제거할 수 있습니다.

두 가지 주요 방법이 있습니다 : Stratified Poisson 또는 Rotated Poisson

Stratified는 서로 다른 표본을 선택합니다. Rotated는 항상 같은 것을 사용하지만 랜덤 회전을 사용하여 서로 다르게 보입니다. 이 튜토리얼에서는 Stratified 버전만 설명하겠습니다.

이전 버전과의 유일한 차이점은 랜덤 인덱스로 poissonDisk를 인덱싱한다는 것입니다:

    for (int i=0;i<4;i++){
        int index = // A random number between 0 and 15, different for each pixel (and each i !)
        visibility -= 0.2*(1.0-texture( shadowMap, vec3(ShadowCoord.xy + poissonDisk[index]/700.0,  (ShadowCoord.z-bias)/ShadowCoord.w) ));
    }

다음과 같은 코드로 난수를 생성할 수 있으며,[0,1]에서 난수를 반환합니다:

    float dot_product = dot(seed4, vec4(12.9898,78.233,45.164,94.673));
    return fract(sin(dot_product) * 43758.5453);

우리의 경우 seed4는 i(4개의 서로 다른 위치에서 샘플을 채취할 수 있도록)와 ...의 조합이 됩니다.

gl_FragCord(화면의 픽셀 위치)또는 Position_worldspace를 사용할 수 있습니다.

        //  - A random sample, based on the pixel's screen location.
        //    No banding, but the shadow moves with the camera, which looks weird.
        int index = int(16.0*random(gl_FragCoord.xyy, i))%16;
        //  - A random sample, based on the pixel's position in world space.
        //    The position is rounded to the millimeter to avoid too much aliasing
        //int index = int(16.0*random(floor(Position_worldspace.xyz*1000.0), i))%16;

이렇게 하면 위의 그림과 같은 패턴이 사라지고 시각적 노이즈가 사라집니다.

그럼에도 불구하고 잘 수행된 노이즈는 종종 이러한 패턴보다 덜 불쾌합니다.

세 가지 구현에 대한 예는 tutorial16/ShadowMapping.fragmentshader 를 참조하십시오.

더 나아가기

이 모든 방법에도 불구하고, 우리의 그림자를 개선할 수 있는 많은 방법들이 있습니다.

가장 일반적인 것은 다음과 같습니다.

Early bailing

각 fragment에 대해 16개의 표본을 추출하는 대신(다시 말하면 많은 양) 4개의 멀리 있는 표본을 추출합니다.

만약 그들 모두가 빛이나 그림자 속에 있다면, 여러분은 16개의 샘플 모두가 같은 결과를 냈을 것이라고 생각할 수 있습니다: Early bailing. 만약 어떤 것들이 다르다면, 여러분은 아마도 그림자 경계에 있을 것이기 대문에 16개의 샘플이 필요합니다.

Spot lights

스포트라이트를 다루는 데는 변경 사항이 거의 필요하지 않습니다. 가장 확실한 것은 직교 투용 행렬을 원근 투영 행렬로 변경하는 것입니다.

glm::vec3 lightPos(5, 20, 20);
glm::mat4 depthProjectionMatrix = glm::perspective<float>(glm::radians(45.0f), 1.0f, 2.0f, 50.0f);
glm::mat4 depthViewMatrix = glm::lookAt(lightPos, lightPos-lightInvDir, glm::vec3(0,1,0));

같은 것이지만, orthographic frustum 대신에 perspective frustum을 사용합니다.

texture2Dproj 를 사용하여 원근 분할을 합니다.(자습서4- 행렬의 각주 참조)

두번째 단계는 쉐이더의 관점에서 고려하는 것입니다.(자습서 4- 행렬의 각주 참조). 간단히 말해서, 투시 투영 행렬은 실제로 어떤 투시도 하지 않습니다. 이 작업은 하드웨어에서 예상 좌표를 w로 나누어 수행합니다.

여기서, 우리는 쉐이더의 변형을 모방하기 때문에, 우리는 우리 자신을 분할하는 관점을 해야 합니다. 참고로, orthographic 행렬은 항상 w=1의 균질 벡터를 생성하므로 원근법을 생성하지 않습니다).

GLSL에서 이를 수행하는 방법이 있습니다. 두 번째줄은 내장 textureProj 함수를 사용하지만 두 방법 모두 정확하게 동일한 결과를 생성합니다.

if ( texture( shadowMap, (ShadowCoord.xy/ShadowCoord.w) ).z  <  (ShadowCoord.z-bias)/ShadowCoord.w )
if ( textureProj( shadowMap, ShadowCoord.xyw ).z  <  (ShadowCoord.z-bias)/ShadowCoord.w )

Point lights

동일하지만 depth 규브 맵을 사용합니다. 큐브 맵은 큐브의 각 면에 하나씩 있는 6개의 텍스처 세트입니다. 또한 표준 UV 좌표를 사용하지 않고 방향을 나타내는 3D 벡터를 사용하여 액세스 할 수 있습니다.

깊이는 공간의 모든 방향에 대해 저장되므로 점광 주위에 그림자가 드리울 수 있습니다.

여러개의 빛 혼합

알고리즘은 여러 개의 조명을 처리하지만 각 조명은 그림자 맵을 생성하기 위해 장면을 추가로 렌더링해야 합니다. Shadow를 적용할 때 엄청난 메모리가 필요하며 대역폭이 매우 빠르게 제한될 수 있습니다.

자동 빛 frustum

이 튜토리얼에서는 전체 장면을 포함하도록 손으로 만든 빛 frustum입니다. 이 제한된 예제에서는 이 작업이 작동하지만 이 작업은 피해야 합니다.

만약 당신의 지도가 1Km x 1Km이라면, 당신의 1024x1024 그림자 지도의 각 텍스트는 1평방미터를 차지할 것입니다. 이것은 형편 없습니다. 조명의 투영 행렬은 가능한한 타이트해야합니다.

스포트라이트의 경우 범위를 조정하여 쉽게 변경할 수 있습니다.

태양과 같은 방향 조명은 더 까다롭습니다. 그것들은 정말로 전체 장면을 비추죠. 광격자를 계산하는 방법은 다음과 같습니다:

1. 잠재적 그림자 수신기 또는 줄여서 PSR은 빛의 frustum, view frustum 및 장면 경계 상자에 동시에 속하는 객체 입니다. 이름에서 알 수 있듯이, 이 물체들은 음영을 받기 쉽습니다. 카메라와 빛으로 볼 수 있습니다.
2. 잠재적 그림자 캐스터(PCF)는 모두 잠재적 그림자 수신기이며, 그 사이에 있는 모든 물체(물체는 보이지 않지만 여전히 보이는 그림자를 드리울 수 있음)입니다.

따라서 빛 투영 행렬을 계산하려면 보이는 모든 객체를 가져와서 너무 멀리 있는 객체를 제거하고 경계 상자를 계산합니다. 이 경계 상자와 조명 사이에 있는 객체를 추가하고 새 경계 상자를 계산합니다(그러나 이번에는 조명 방향을 따라 정렬됨).

이러한 집합의 정확한 계산에는 볼록 껍질 교차점 계산이 포함되지만, 이 방법은 구현하기가 훨씬 쉽습니다.

이 방법을 사용하면 그림자 맵 해상도가 갑자기 증가하기 때문에 물치가 frustum에서 사라지면 팝핑이 발생합니다. 계단식 Shadow Map에는 이러한 문제가 없지만 구현하기가 더 어려우며 시간이 지남에 따라 값을 매끄럽게 하여 보정할 수 있습니다.

지수 shadow maps

지수 그림자 맵은 그림자에 있지만 빛 표면 근처에 있는 fragment가 실제로 "가운데 어딘가"라고 가정하여 앨리어싱을 제한하려고 합니다. 테스트가 더이상 이진법이 아니라는 점을 제외하면 이는 편향과 관련 있습니다. 빛이 있는 표면까지의 거리가 증가하면 fragment가 점점 어두워집니다.

이것은 명백히 부정행위이며, 두 물체가 겹칠 때 인공물이 나타날 수 있습니다.

빛-공간 원근법 shadow maps

LiSPSM은 카메라 근처에서 더 정확하게 하기 위해 빛 투영 행렬을 조정합니다. 이것은 "불안정한 frustra"의 경우에는 특히 중요합니다. 여러분은 방향을 바라지만, 스폿라이트는 반대 방향을 바라봅니다. 당신은 빛 근처, 즉 당신으로부터 멀리 떨어진 곳에 많은 그림자 지도 정밀도를 가지고 있고, 당신이 가장 필요로 하는 카메라 근처에 낮은 해상도를 가지고 있습니다.

그러나 LiSPSM은 구현하기가 까다롭습니다. 구현에 대한 자세한 내용은 레퍼런스를 참조하십시오.

계단식 shadow maps

CSM은 LiSPSM과 완전히 동일한 문제를 다루지만 다른 방식으로 처리합니다. 단순히 view frustum의 여러 부분에 대해 여러 개의(2-4) 표준 그림자 맵을 사용합니다.

첫 번째 것은 첫 번째 미터를 다루기 때문에 꽤 작은 구역에 대해서는 훌륭한 해상도를 얻을 수 있습니다. 다음 그림자 지도는 더 먼 물체를 다룹니다. 마지막 shadow map은 장면의 큰 부분을 다루지만, 관점 때문에 가장 가까운 구역보다 시각적으로 더 중요하지는 않을 것입니다.

계단식 쉐도우 맵은 작성 당시(2012년) 최고의 복잡성/품질 비율을 가지고 있습니다. 이것은 많은 경우에 선택의 해결책입니다.

결론

보시다시피, 그림자 지도는 복잡한 주제입니다. 매년 새로운 변형과 개선사항이 발표되고 있으며, 현재로서는 어떤 솔루션도 완벽하지 않습니다.

다행히, 제시된 대부분의 방법은 함께 혼합될 수 있습니다. 빛 공간 관점에서 계산식 shadow map을 PCF로 매끄럽게 만드는 것이 완벽하게 가능합니다.. 이 모든 기술을 사용하여 실험해 보십시오.

결론적으로, 저는 당신이 가능할 때마다 미리 계산된 라이트맵을 고수하고, 동적 객체에만 shadowmap을 사용할 것을 제안합니다. 그리고 두 가지의 시작적 품질이 동일한지 확인하십시오. 완벽한 정적 환경과 모양새가 좋지 않은 그림자가 있는 것도 좋지 않습니다.

원본 - https://learnopengl.com/Getting-started/Creating-a-window

멋진 그래픽을 만들기 전에 먼저 해야 할 일은 OpenGL 컨텐스트와 어플리케이션 창을 만들어서 끌어오는 것입니다.

그러나 이러한 작업은 운영 체제마다 다르며 OpenGL은 의도적으로 이러한 작업에서 추상화하려고 합니다.

즉, 창을 만들고, 컨텍스트를 정의하고, 사용자 입력을 직접 처리해야 합니다.

다행히도, 우리가 찾는 기능을 제공하는 꽤 많은 라이브러리가 있으며, 일부 라이브러리는 특히 OpenGL을 목표로 합니다.

이러한 라이브러리는 운영 체제별 작업을 모두 저장하고 렌더링할 수 있는 창과 OpenGL 컨텍스트를 제공합니다.

GLUT, SDL, SFML, GLFW 등이 유명합니다.

LearnOpenGL에서는 GLFW를 사용합니다.

대부분의 설정은 GLFW의 설정과 유사하므로 다른 라이브러리를 자유롭게 사용하십시오.

GLFW

GLFW는 C로 작성된 라이브러리로, 특히 OpenGL을 대상으로 합니다.

GLFW는 화면에 상품을 렌더링하는데 필요한 최소한의 필수품을 제공합니다.

이를 통해 OpenGL 컨텍스트를 만들고, 창 매개 변수를 정의하고, 사용자 입력을 처리할 수 있으며, 이는 우리의 목적에 충분합니다.

이 장과 다음 장의 추점은 GLFW를 가동하여 OpenGL 컨텍스트를 적절하게 생성하고 우리가 장난칠 수 있는 간단한 창을 표시하도록 하는 것입니다.

이 창에서는 GLFW 라이브러리를 검색, 구축 및 연결하는 단계별 접근 방식을 사용합니다.

이 문서에서는 Microsoft Visual Studio 2019 IDE를 사용합니다(더 최신 Visual Studio 버전에서도 프로세스는 동일합니다).

Visual Studio(또는 이전 버전)를 사용하지 않는 경우 대부분의 다른 IDE에서도 프로세스가 유사합니다.

GLFW 빌드하기

GLFW는 웹 페이지의 다운로드 페이지에서 얻을 수 있습니다.

GLFW는 이미 2019년까지 Visual Studio 2012용으로 미리 컴파일된 이진파일과 헤더 파일을 가지고 있지만, 완전성을 위해 소스 코드에서 GLFW를 직접 컴파일할 것입니다.

이것은 모든 라이브러리가 미리 컴파일된 바이너리를 사용할 수 있는 것은 아니기 때문에 오픈 소스 라이브러리를 직접 컴파일하는 과정에 대한 느낌을 주기 위한 것입니다.

소스 패키지를 다운로드해 보겠습니다.

소스 패키지를 다운로드한 후 압출을 풀고 내용을 엽니다.

우리는 몇 가지 품목에만 집중할 것입니다.

• 컴파일의 결과인 라이브러리
• include 폴더

소스 코드에서 라이브러리를 컴파일하면 결과 라이브러리가 CPU/OS에 완벽하게 맞춤화되어 고급 사전 컴파일된 바이너리가 항상 제공되는 것은 아닙니다(시스템에서 사전 컴파일된 바이너리를 사용할 수 없는 경우도 있음).

그러나 오픈 월드에 소스 코드를 제공할 때의 문제는 모든 사람이 자신의 애플리케이션을 개발하기 위해 동일한 IDE 또는 빌드 시스템을 사용하지 않는다는 것입니다.

즉, 제공된 프로젝트/솔루션 파일이 다른 사용자의 설정과 호환되지 않을 수 있습니다.

따라서 사용자는 지정된 .c .cpp 및 .h .hpp 파일을 사용하여 자신만의 프로젝트/솔루션을 설정해야 합니다.

이는 번거러운 작업입니다.

바로 이러한 이유로 Cmake라는 도구가 있습니다.

CMake

CMake는 미리 정의된 CMake 스크립트를 사용하여 소스 코드 파일 모음에서 사용자가 선택한 프로젝트/솔루션 파일(예: Visual Studio, 코드::블럭, Eclipse)을 생성할 수 있는 도구입니다.

이를 통해 라이브러리를 컴파일하는 데 사용할 수 있는 GLFW의 소스 패키지에서 Visual Studio 2019 프로젝트 파일을 생성할 수 있습니다.

먼저 다운로드 페이지에서 다운로드할 수 있는 CMake를 다운로드하여 설치해야 합니다.

CMake가 설치되면 명령줄 또는 GUI를 통해  CMake를 실행하도록 선택할 수 있습니다.

너무 복잡하지 않기 때문에 GUI를 사용할 예정입니다.

CMake에는 이진 파일에 대한 소스 코드 폴더와 대상 폴더가 필요합니다.

소스 코드 폴더의 경우 다운로드한 GLFW 소스 패키지의 루트 폴더를 선택하고 빌드 폴더의 경우 새 디렉토리 빌드를 만든 다음 해당 디렉토리를 선택합니다.

소스 및 대상 폴더를 설정했으면 구성 단추를 클릭하여 CMake가 필요한 설정과 소스 코드를 읽을 수 있도록 합니다.

그런 다음 프로젝트의 생성자를 선택해야 하며 Visual Studio 2019를 사용하기 때문에 Visual Studio 16 옵션을 선택합니다(Visual Studio 2019는 Visual Studio 16으로도 알려져 있습니다).

그런 다음 CMake는 결과 라이브러리를 구성하기 위해 가능한 빌드 옵션을 표시합니다. 설정을 기본값으로 유지하고 구성을 다시 클릭하여 설정을 저장할 수 있습니다.

셋팅이 설정되면 생성을 클릭하면 결과 프로젝트 파일이 빌드 폴더에 생성됩니다.

Compilation(모음집)

빌드 폴더에서 GLFW.sin 파일을 찾을 수 있으며 Visual Studio 2019에서 엽니다.

CMake는 이미 적절한 구성 설정이 포함된 프로젝트 파일을 생성했기 때문에 솔루션을 구축하기만 하면 됩니다.

CMake는 64비트 라이브러리로 컴파일할 수 있도록 솔루션을 자동으로 구성했어야 합니다.

이제 빌드 솔루션을 선택하십시오.

이렇게 하면 glfw3.lib라는 이름의 build/src/debug 에서 찾을 수 있는 컴파일된 라이브러리 파일이 제공됩니다.

라이브러리를 생성한 후에는 IDE가 라이브러리와 OpenGL 프로그램의 포함 파일을 찾을 수 있는 위치를 알고 있는지 확인해야 합니다.

이 작업에는 두 가지 일반적인 접근 방식이 있습니다:

1. IDE/컴파일러에서 /lib 와 /include 폴더를 찾아서 GLFW의 include 폴더의 내용을 IDE의 /include 폴더에 추가하고 마찬가지로 glfw3.lib를 IDE의 /lib 폴더에 추가합니다. 이 방법은 효과가 있지만 권장되는 방법은 아닙니다. 라이브러리를 추적하고 파일을 포함하는 것은 어렵고 IDE/컴파일러를 새로 설치하면 이 프로세스를 처음부터 다시 수행해야 합니다.
2. 또 다른 방법은 IDE/compiler 에서 참조할 수 있는 타사 라이브러리의 모든 header files/libraries를 포함하는 디렉터리 세트를 원하는 위치에 새로 만드는 것입니다. 예를 들어 OpenGL 프로젝트의 모든 라이브러리 및 헤더 파일을 각각 저장하는 Libs 및 Include 폴더가 포함된 단일 폴더를 만들 수 있습니다. 이제 모든 타사 라이브러리가 단일 위치(여러 컴퓨터에서 공유할 수 있음) 내에 구성됩니다. 그러나 새 프로젝트를 생성할 때마다 IDE에 해당 디렉토리를 찾을 수 있는 위치를 알려줘야 합니다.

필요한 파일이 원하는 위치에 저장되면 첫 번째 OpenGL GLFW 프로젝트를 시작할 수 있습니다.

우리의 첫번째 프로젝트

먼저 Visual Studio를 열고 새 프로젝트를 만들어 보겠습니다. 여러 옵션이 지정된 경우 C++를 선택하고 빈 프로젝트를 선택합니다(프로젝트에 적합한 이름을 지정하는 것을 잊지 마십시오). 64비트로 모든 작업을 수행할 예정이며 프로젝트의 기본값은 32비트이므로 상단의 디버그 옆에 있는 드롭다운을 x86에서 x64로 변경해야 합니다.

이 작업이 완료되면 최초의 OpenGL 애플리케이션을 만들 수 있는 작업 공간을 확보할 수  있습니다!

링킹

프로젝트가 GLFW를 사용하기 위해서 라이브러리와 우리의 프로젝트를 연결해야 합니다. 이는 링커 설정에서 glfw3.lib를 사용할 것을 지정함으로써 수행할 수 있지만, 타사 라이브러리를 다른 디렉토리에 저장하기 때문에 우리 프로젝트는 glfw3.lib를 어디서 찾을 수 있는지 아직 모릅니다. 따라서 먼저 이 디렉토리를 프로젝트에 추가해야 합니다.

IDE가 라이브러리를 찾고 파일을 포함해야 할 때 이 디렉토리를 고려하도록 지시할 수 있습니다. 솔루션 탐색기에서 프로젝트 이름을 마우스 오른쪽 버튼으로 클릭한 다음 아래 이미지와 같이 VC++ 디렉토리로 이동합니다.

그런 다음 사용자 자신의 디렉토리를 추가하여 프로젝트가 검색할 위치를 알 수 있도록 할 수 있습니다. 텍스트에 수동으로 삽입하거나 적절한 위치 문자열을 클릭하고 <편집> 옵션을 선택하면 됩니다. 라이브러리 디렉토리와 포함 디렉토리 모두에 대해 이 작업을 수행합니다.

여기서 원하는 만큼 디렉토리를 추가할 수 있으며, 이때부터 IDE는 라이브러리 및 헤더 파일을 검색할 때 해당 디렉터리도 검색합니다. GLFW의 Include 폴더가 포함되는 즉시 <GLFW/..>를 포함하여 GLFW의 모든 헤더 파일을 찾을 수 있습니다. 라이브러리 디렉토리도 마찬가지입니다.

VS가 이제 필요한 모든 파일을 찾을 수 있으므로 Linker 탭으로 이동하여 다음과 같이 입력하면 GLFW를 프로젝트에 연결할 수 있습니다.

그런 다음 라이브러리에 연결하려면 링커에 대한 라이브러리 이름을 지정해야 합니다. 라이브러리 이름이 glfw3.lib이므로 이를 Additional Dependencies 필드에 추가합니다(수동 또는 <Edit> 옵션 사용) 그리고 그 시점부터 우리가 컴파일할 때 GLFW가 연결될 것입니다. GLFW 외에도 OpenGL 라이브러리에 링크 항목을 추가해야 하지만 운영 체제에 따라 다를 수 있습니다.

Windows에서의 OpenGL

Windows에서 OpenGL 라이브러리 opengl32.lib는 Visual Studio를 설치할 때 기본적으로 설치할 때 기본적으로 설치되는 Microsoft SDK와 함께 제공됩니다. 이 장에서는 VS 컴파일러를 사용하고 윈도우에 있으므로 링커 설정에 opengl32.lib를 추가합니다. OpenGL 라이브러리의 64비트 등가는 32비트 등가와 마찬가지로 opengl32.lib라고 합니다.

Linux에서의 OpenGL

Linux 시스템에서는 링커 설정에 -IGL을 추가하여 libGL.so 라이브러리에 연결해야 합니다. 라이브러리를 찾을 수 없는 경우 Mesa, NVidia 또는 AMD dev 패키지를 설치해야 할 수 있습니다.

그런 다음 GLFW 및 OpenGL 라이브러리를 모두 링커 설정에 추가하면 다음과 같이 GLFW의 헤더 파일을 포함 할 수 있습니다.

이것으로 GLFW의 설정 및 구성이 완료되었습니다.

GLAD

아직 한 가지 더 해야 할 일이 있기 때문에 아직 거기까지는 이르지 못했습니다. OpenGL은 실제로 표준/사양에 불과하므로 특정 그래픽 카드가 지원하는 드라이버에 이 사양을 구현하는 것은 드라이버 제조업체에 달려 있습니다. 다양한 버전의 OpenGL 드라이버가 있기 때문에 컴파일 시 대부분의 기능 위치를 알 수 없으며 런타임에 쿼리해야 합니다. 그런 다음 필요한 기능의 위치를 검색하여 나중에 사용할 수 있도록 기능 포인터에 저장하는 것이 개발자의 작업입니다. 이러한 위치 검색은 OS별로 다릅니다. Windows에서는 다음과 같이 표시됩니다.

코드가 복잡해 보이고 아직 선언되지 않은 각 기능에 대해 이를 수행하는 것은 번거러운 프로세스입니다. 감사하게도, GLAD와 같이 인기 있고 최신인 라이브러리들이 있습니다.

GLAD 설정하기

GLAD는 우리가 이야기한 모든 번거러운 작업을 관리하는 오픈 소스 라이브러리입니다. GLAD는 대부분의 일반적인 오픈 소스 라이브러리와 약간 다른 구성 설정을 가지고 있습니다. GLAD는 어떤 버전의 OpenGL에 대해 해당 버전에 따라 모든 관련 OpenGL 기능을 정의하고 로드할 것인지를 GLAD에 알려줄 수 있는 웹 서비스를 사용합니다.

GLAD 웹 서비스로 이동하여 언어가 C++로 설정되어 있는지 확인하고 API 섹션에서 3.3이상의 OpenGL 버전을 선택합니다. 또한 프로파일이 Core로 설정되어 있고 Generate a loader 옵션이 선택되어 있는지 확인합니다.

확장명을 무시하고 생성을 클릭하여 결과 라이브러리 파일을 생성합니다.

지금쯤 GLAD는 두 개의 포함 폴더가 포함된 zip 파일과 하나의 glad.c 파일을 제공했어야 합니다. 포함 폴더(glad 및 KHR)를 모두 포함 디렉터리에 복사하고(또는 이 폴더를 가리키는 항목을 추가합니다) glad.c 파일을 프로젝트에 추가합니다.

이전 단계를 수행한 후에는 파일 위에 다음 포함 지시문을 추가할 수 있습니다.

컴파일 버튼을 눌러도 오류가 발생하지 않으므로 다음 장에서 GLFW와 GLAD를 사용하여 OpenGL 컨텍스트를 구성하고 창을 생성하는 방법에 대해 설명합니다. 포함 및 라이브러리 디렉토리가 모두 올바르고 링커 설정의 라이브러리 이름이 해당 라이브러리와 일치하는지 확인하십시오.

원본 - https://learnopengl.com/Getting-started/OpenGL

여정을 시작하기 전에 먼저 OpenGL이 실제로 무엇인지 정의해야 합니다.

OpenGL은 주로 그래픽과 이미지를 조작하는데 사용할 수 있는 많은 기능을 제공하는 API(Application Programming Interface)로써 후보로 거론됩니다.

그러나 OpenGL 자체는 API가 아니라 크로노스 그룹이 개발하고 유지 관리하는 사양에 불과합니다.

OpenGL 사양은 각 기능의 결과/출력과 수행 방법을 정확하게 명시합니다.

그런 다음 이 기능이 어떻게 작동해야 하는지에 대한 해결책을 마련하는 것은 이 사양을 구현하는 개발자에게 달려있습니다.

OpenGL 사양에는 구현 세부 정보이 나와 있지 않으므로, 실제 개발된 OpenGL 버전은 결과가 사양과 일치하는 한(따라서 사용자에게 동일한) 다른 구현을 허용합니다.

실제 OpenGL 라이브러리를 개발하는 사람들은 대개 그래픽 카드 제조업체입니다.

구입한 각 그래픽 카드는 해당 카드용 특별히 개발된 OpenGL 버전인 특정 OpenGL 버전을 지원합니다.

Apple 시스템을 사용할 때 OpenGL 라이브러리는 Apple이 직접 관리하며 Linux 아래에는 그래픽 공급업체의 버전과 이러한 라이브러리에 대한 애호가의 적응이 결합되어 있습니다.

이는 OpenGL이 하지 말아야 할 이상한 동작을 보일 때마다 그래픽 카드 제조업체(또는 라이브러리를 개발/유지 관리한 사람)의 잘못일 가능성이 높다는 것을 의미합니다.

Khronos는 모든 OpenGL 버전에 대한 모든 사양 문서를 공개적으로 호스팅합니다.

관심 있는 독자는 여기에서 버전 3.3의 OpenGL 사양(우리가 사용할 버전)을 찾을 수 있습니다.

이 사양은 OpenGL의 세부 사항을 자세히 살펴보고 싶다면 좋은 읽을거리입니다(구현이 아닌 결과만 설명합니다).

또한 사양은 기능의 정확한 작동을 찾는데 유용한 참고 자료를 제공합니다.

코어 프로파일 vs 즉시 모드(고정 함수 파이프라인)

옛날에는 OpenGL을 사용하는 것은 그래픽을 그리기 위한 사용하기 쉬운 방법인 즉시 모드(고정 함수 파이프라인이라고도 함)로 개발하는 것을 의미했습니다.

OpenGL의 대부분의 기능은 라이브러리 안에 숨겨져 있었고 개발자들은 OpenGL이 계산을 수행하는 방식을 크게 통제하지 못했습니다.

개발자들은 결국 더 많은 유연성을 원했고, 시간이 지남에 따라 사양이 더 유연해졌고, 개발자들은 그들의 그래픽을 더 많이 통제하게 되었습니다.

고정 함수 파이프라인을 사용하는 것은 정말 사용하기 쉽고 이해하기 쉽지만, 또한 매우 비효율적입니다.

이러한 이유로 이 사양은 버전 3.2 이후 즉시 모드 기능을 더 이상 사용하지 않기 시작했으며 개발자들이 OpenGL의 코어 프로파일 모드로 개발하도록 동기를 부여하기 시작했습니다.

이 모드는 오래된 모든 사용되지 않는 기능을 제거한 OpenGL의 사양의 한부분입니다.

OpenGL의 핵심 프로파일을 사용할 때 OpenGL은 현대적 관행을 사용하도록 강요합니다.

OpenGL에서 사용되지 않는 함수 중 하나를 사용하려고 할 때마다 OpenGL에서 오류가 발생하고 그리기가 중지됩니다.

현대적인 접근법을 배우는 것의 장점은 그것이 매우 유연하고 효율적이라는 것입니다.

하지만, 그것은 또한 배우기가 더 어렵습니다. 고정 함수 파이프라인은 OpenGL이 수행한 실제 작업에서 상당히 많은 부분을 추상화했으며 학습하기는 쉬웠지만 실제로 OpenGL이 어떻게 작동하는지 파악하기는 어려웠습니다.

현대적인 접근 방식은 개발자가 OpenGL과 그래픽 프로그래밍을 진정으로 이해해야 하며, 다소 어렵긴 하지만 훨씬 더 많은 유연성과 효율성, 그리고 가장 중요한 것은 그래픽 프로그래밍에 대한 훨씬 더 나은 이해를 가능하게 합니다.

이것은 또한 이 책이 핵심 프로필 OpenGL 버전 3.3에 맞춰진 이유입니다. 비록 그것이 더 어렵지만, 그것은 노력할 가치가 있습니다.

현재 OpenGL 4.6을 작성하는 시점에서 상위 버전의 OpenGL을 선택할 수 있습니다.

OpenGL 4.6이 출시된 상태에서 OpenGL 3.3을 제가 선택한 이유는 무엇일까요?

그 질문에 대한 대답은 비교적 간단합니다. 3.3 이후 버전의 모든 OpenGL은 OpenGL의 핵심 메커니즘을 변경하지 않고 OpenGL에 유용한 기능을 추가합니다.

새로운 버전은 동일한 작업을 수행하는 데 약간 더 효율적이거나 유용한 방법을 도입할 뿐입니다.

그 결과 모든 개념과 기술이 최신 OpenGL 버전에서 동일하게 유지되므로 OpenGL 3.3을 학습하는 것이 완벽하게 유효합니다.

언제든지 준비가 되었거나 경험이 풍부하면 최신 OpenGL 버전의 특정 기능을 쉽게 사용할 수 있습니다.

일부 챕터에서는 다음과 같이 기록된 보다 현대적인 기능을 확인할 수 있습니다.

확장

OpenGL의 큰 특징은 확장 기능을 지원한다는 것입니다.

그래픽 회사에서 렌더링을 위한 새로운 기술이나 새로운 대규모 최적화를 제안할 때마다 드라이버에 구현된 확장 기능에서 종종 발견됩니다.

응용프로그램이 실행되는 하드웨어가 이러한 확장을 지원하는 경우 개발자는 확장에서 제공하는 기능을 사용하여 보다 고급 또는 효율적인 그래픽을 구현할 수 있습니다.

이러한 방식으로 그래픽 개발자는 확장 기능이 그래픽 카드에서 지원되는지 확인하기만 하면 OpenGL이 향후 버전에 기능을 포함할 떄까지 기다리지 않고도 이러한 새로운 렌더링 기술을 사용할 수 있습니다.

종종 확장이 인기가 있거나 매우 유용한 경우 나중에 OpenGL 버전의 일부가 됩니다.

개발자는 이러한 확장을 사용하기 전(또는 OpenGL 확장 라이브러리를 사용하기 전) 사용 가능한 확장이 있는지 문의해야 합니다.

이를 통해 개발자는 확장을 사용할 수 있는지 여부에 따라 더 나은 작업 또는 더 효율적인 작업을 수행할 수 있습니다.

예를 들어, OpenGL이 삼각형 대신 선을 그리고 싶다고 말할 때마다 OpenGL이 그리는 방법을 설정하는 일부 컨텐스트 변수를 변경하여  OpenGL의 상태를 변경합니다.

OpenGL에 선을 그어야 한다고 말해 컨텍스트를 변경하는 즉시 다음 그리기 명령은 삼각형 대신 선을 그립니다.

OpenGL에서 작업할 때 컨텍스트를 변경하는 여러 상태 변경 기능과 OpenGL의 현재 상태를 기반으로 일부 작업을 수행하는 여러 상태 사용 기능을 만나게 됩니다.

OpenGL이 기본적으로 하나의 대형 상태 시스템이라는 것을 기억하는 한, 대부분의 기능은 더 의미가 있을 것입니다.

오브젝트

OpenGL 라이브러리는 C로 작성되어 있으며 다른 언어로 많은 파생을 허용하지만 핵심적으로는 C라이브러리로 남아 있습니다.

C 언어 구조 중 많은 부분이 다른 고급 언어로 잘 번역되지 않기 때문에 OpenGL은  몇 가지 추상화를 염두에 두고 개발되었습니다.

이러한 추상화 중 하나는 OpenGL의 객체입니다.

OpenGL의 개체는 OpenGL 상태의 하위 집합을 나타내는 옵션 모음입니다.

예를 들어, 도면 창의 설정을 나타내는 객체를 사용할 수 있습니다. 그런 다음 객체의 크기, 지원되는 색상 수 등을 설정할 수 있습니다.

그런 다음 객체의 크기, 지원되는 색상 수 등을 설정할 수 있습니다.

물체를 C와 같은 구조로 시각화할 수 있습니다.

객체를 사용하고자 할 때마다 일반적으로 다음과 같이 보입니다(OpenGL의 컨텍스트가 큰 구조로 시각화됨)

이 작은 코드 조각은 OpenGL로 작업할 때 자주 볼 수 있는 워크플로우입니다.

먼저 개체를 만들고 참조를 ID로 저장합니다(실제 개체의 데이터는 씬 뒤에 저장됨).

그럼 다음 개체(ID 사용)를 컨텐스트의 대상 위치에 바인딩합니다(예: 창 개체 대상 위치는 GL_WINDOW_TARGET으로 정의됨).

다음으로 창 옵션을 설정하고 마지막으로 창 대상의 현재 개체 ID를 0으로 설정하여 개체의 바인딩을 해제합니다.

설정한 옵션은 objectId에서 참조하는 개체에 저장되고 개체를 GL_WINDOW_TARGET에 다시 바인딩하는 즉시 복원됩니다.

이러한 개체를 사용하면 응용 프로그램에서 둘 이상의 개체를 정의하고 옵션을 설정할 수 있으며 OpenGL의 상태를 사용하는 작업을 시작할 때마다 원하는 설정으로 개체를 바인딩할 수 있습니다.

예를 들어 3D 모델 데이터(집 또는 캐릭터)의 컨테이너 개체 역할을 하는 개체가 있으며, 이 중 하나를 그리고 싶을 때마다 우리는 우리가 그릴 모델 데이터가 들어 있는 개체를 바인딩합니다(이러한 개체에 대한 옵션을 먼저 만들고 설정했습니다).

객체가 여러 개 있으면 많은 모델을 지정할 수 있고 특정 모델을 그리고 싶을 때마다 모든 옵션을 다시 설정하지 않고 해당 객체를 그리기 전에 간단히 바인딩할 수 있습니다.

시작하자

이제 OpenGL의 사양과 라이브러리, OpenGL이 후드 아래에서 어떻게 작용하는지, 그리고 OpenGL이 사용하는 몇 가지 사용자 지정 기술에 대해 알아봤습니다.

모든 것을 이해하지 못했더라도 걱정하지 마십시오.

이 책에서는 각 단계를 통해 OpenGL을 제대로 파악할 수 있는 충분한 예를 볼 수 있습니다.

추가 자료들

• opengl.org : OpenGL의 공식 웹사이트입니다.
• OpenGL registry : 모든 OpenGL 버전에 대한 OpenGL 사양 및 확장을 호스트합니다.

원본 페이지 - https://learnopengl.com/Introduction

당신이 이 페이지를 방문한 것은 컴퓨터 그래픽의 내적인 작용을 배우고 멋진 이들이 하는 모든 것을 혼자서 하고 싶을 것이다.

혼자서 무언가를 하는 것은 매우 재미있고, 지략이 풍부하며, 그래픽 프로그래밍에 대한 큰 이해를 준다.

그러나 시작하기 전에 고려해야 할 몇 가지 항목이 있습니다.

전제조건

OpenGL은 자체 플랫폼이 아닌 그래픽 API이기 때문에 동작하기 위한 언어가 필요하며 선택 언어는 C++입니다.

따라서 이 장들을 위해서는 C++ 프로그래밍 언어에 대한 적절한 지식이 필요합니다.

하지만, 필요한 경우 고급 C++ 주제를 포함하여 사용되는 대부분의 개념을 설명하려고 노력할 것입니다.

따라서 C++ 전문가가 될 필요는 없지만 "Hello World" 프로그램 이상의 것을 만들 수 있어야 합니다.

C++에 대한 경험이 많지 않다면 www.learncpp.com  에서 무료 튜토리얼을 추천합니다.

또한, 도중에 수학 (선형 대수학, 기하학, 삼각법)을 사용할 것이고 필요한 수학의 모든 필수 개념을 설명하려고 노력할 것입니다.

하지만 저는 수학자가 아니기 때문에 설명이 이해하기 쉽더라도 불완전할 가능성이 높습니다.

그래서 필요한 경우에는 자료를 보다 완벽하게 설명할 수 있는 좋은 자료에 대한 지침을 제공할 것입니다.

OpenGl로의 여정을 시작하기 전에 필요한 수학적 지식에 대해 두려워하지 마십시오.

거의 모든 개념은 기본적인 수학적 배경으로 히애할 수 있습니다.

가능한 한 수학을 최소화하도록 노력하겠습니다.

대부분의 기능은 사용법을 알고 있는 한 모든 수학을 이해할 필요조차 없습니다.

구조

Learn OpenGL은 여러 개의 일반적인 섹션으로 나뉩니다.

각 섹션에는 서로 다른 개념을 자세히 설명하는 여러 장이 포함되어 있습니다.

각 장은 왼쪽 메뉴에서 찾을 수 있습니다.

개념들은 선형적인 방식으로 가르쳐지며(따라서 다른 지시가 없는 한 위에서 아래로 시작하는 것이 좋습니다) 각 장에서 배경 이론과 실제적인 측면을 설명한다.

개념을 더 쉽게 따르고 추가된 구조를 제공하기 위해 이 책에는 상자, 코드 블록, 색상 힌트 및 기능 참조가 포함되어 있습니다.

박스

코드

아래와 같이 구문이 강조된 코드와 함께 어두운 회색 상자에 있는 수많은 작은 코드 조각을 웹 사이트에서 찾을 수 있습니다;

이것들은 코드 조각만 제공하기 때문에, 필요하다면 주어진 주제에 필요한 전체 소스 코드에 대한 링크를 제공할 것입니다.

색상 힌트

일부 단어는 다른 색으로 표시되어 이 단어들이 특별한 의미를 더 명확하게 표현합니다.

• 정의 : 녹색 단어는 정의, 즉 더 자주 들을 수 있는 것의 중요한 측면/이름을 지정합니다.
• 프로그램 구조 : 빨간색 단어는 함수 이름 또는 클래스 이름을 지정합니다.
• 변수 :  파란색 단어는 모든 OpenGL 상수를 포함하는 변수를 지정합니다.

OpenGL 함수 참조

특히 LearnOpenGl의 기능은 콘텐츠에 나타나는 모든 곳에서 OpenGL의 기능을 검토할 수 있는 기능입니다.

웹사이트에 문서화된 콘텐츠에서 기능을 발견될 때마다, 그 기능은 약간 눈에 띄는 밑줄과 함께 나타날 것입니다.

마우스를 기능 위에 올려놓으면 잠시 후 팝업 창에 기능이 실제로 수행하는 작업에 대한 멋진 개요를 포함하여 이 기능에 대한 관련 정보가 표시됩니다. 마우스를 glEnable 위에 올려 놓으면 동작을 볼 수 있습니다.

시작 섹션으로 이동하여 OpenGL 여정을 시작하십시오!

error LNK2005 ~~~~~~~.obj에 이미 정의되어 있습니다

라는 오류가 뜰 시 헤더파일을 #include 하는 곳에서 중복으로 헤더 파일을 불러오면서 충돌을 일으켰을 가능성이 높다.

따라서 변수 선언 및 함수 선언은 헤더 파일에 하되, 구체적인 함수 작성은 cpp 파일에다가 하면 해결된다.

1. shared_ptr

- 하나의 변수를 동시에 여러개의 포인터가 참조가 가능

- 참조하는 과정에서 count를 함

- 서로를 참조해야할 경우(여러명이서 같은 정보 하나를 사용할 때)

- 단, 순환 참조가 일어날 수 있음

2. unique_ptr

- 한 포인터당 한 요소만을 가리킴

- 일반적인 대입 연산은 불가능하지만 move 함수를 통해 소유권을 넘겨주는것은 가능(소유권을 넘겨주면 원본 포인      터는 NULL로 설정됨)

- NULL이 아닌 unique_ptr은 항상 자신이 가리키는 객체를 소유하고 소멸 시 자신이 가리키는 자원을 파괴함

- 팩토리 함수에서 반환하는 형태로 사용됨

- 소유권 독점 자원 관리에 사용하자

3. weak_ptr

- 하나의 변수를 동시에 여러개의 포인터가 참조 가능

- count를 하지 않고 변수가 사라지면 자동으로 참조할 대상을 잃게됨

- 메모리해제 기능은 없음

4. auto_ptr

- C++ 11 이후에는 사라진 포인터

- 템플릿 기반의 포인터라서 어떤 타입의 포인터든지 받을 수 있음

- new로 생성한 단일 객체에서만 메모리 해제를 보장해서 malloc 등으로 할당할 경우 해제가 되지 않음

- 동일한 메모리 위치를 가리키는 객체를 2개 이상 생성하면 안됨(이러한 문제점을 shared_ptr에서는 참조 카운트를 통해서 해결함)

- 단점때문에 unique_ptr로 대체하여 사용하면 됨

보통 초보 게임 개발자들이 유니티에서 C#을 사용하다가 한번 설정해놓은 설정들을 끌어다 쓰려고 접하게 되는 디자인 패턴이라고 볼 수 있다.(본인 경험담..)

최근 면접에서 싱글톤과 전역변수의 차이점에 대해 제대로 대답하지 못하였기때문에 블로그로 한번 제대로 정리해보려고 한다.

싱글톤이란 애플리케이션이 시작될 때 어떤 클래스가 최초로 한번만 메모리를 할당하고 그 메모리에 인스턴스를 만들어 사용하는 디자인 패턴이다.

싱글톤과 전역변수는 최초로 한번만 메모리를 할당하고 그 자원을 끌어다 쓴다는 점에서 비슷한데 둘은 차이점이 있다.

싱글톤 패턴과 전역변수의 차이점

1. 생성시점

전역변수는 애플리케이션이 실행될 때 생성

싱글톤 패턴은 해당 함수가 initialize되면서 생성

2. 자원할당

전역 변수는 자원의 양이 엄청나게 크다고 가정함(특정 시점에서만 사용된다면 엄청난 낭비)

싱클톤 패턴은 사용할 때 자원을 할당하고 자신이 원할 때 자원을 해제 가능

싱글톤 패턴의 단점

- 상속이 불가능(private 생성자를 가지기 때문)

- 상태를 가진 객체를 싱글톤으로 만들면 안됨(상태가 공유된다는 것은 매우 위험함, 유일해야하는 컴포넌트를 싱글톤으로 만들어야함)

- 싱글톤을 사용하는 곳과 싱글톤 클래스 사이에 의존성이 생기게 되서 결합도가 높아져서 수정 및 단위테스트의 어려움이 생기게 됨

- 전역 상태를 갖는 것은 객체지향 프로그래밍에서 지양되어야 할 모델(위와 같이 결합도가 높아지기 떄문)

- 멀티쓰레드 환경에서 인스턴스가 두개 생성되는 경우가 발생할 수 있음

Unity C#에서 쓰는 패턴은 다음과 같다.

템플릿 함수는 컴파일되지도 호출되지도 않은 함수의 틀

제네릭 함수를 선언하고 컴파일 시점에 구체화시키기 위한 틀을 만드는 것

매크로(#define)와 달리 복잡한 함수나 클래스를 표현하는데 한계가 없다.

제네릭 클래스(generic class)도 만들 수 있다.

템플릿 함수의 장점

- 함수 코드의 재사용을 가능하게 하여 소프트웨어의 생산성과 유연성을 높임

템플릿 함수의 단점

- 컴파일러에 따라서 템플릿이 지원되지 않을 수 있어서 포팅에 취약

- 오류 메시지가 빈약하여 디버깅에 많은 어려움이 있음

*swap 함수를 템플릿 함수로 표현*

앞선 개념

새로운 개념인 Reciprocal Velocity Obstacle(이하 RVO)를 제안함
각 에이전트가 다른 에이전트와 명시적으로 통신하지 않고 독립적으로 움직이는 경우를 고려함

다른 객체들이 유사한 충돌 회피 추론을 암묵적으로 가정함으로써 다른 객체의 반응적 행동을 고려함
정적 장애물과 이동 장애물을 모두 포함하는 인구 밀도가 높은 환경에서 수백 개의 에이전트를 탐색하는 것에 개념을 적용하고, 도전적인 시나리오에서 실시간 및 확장 가능한 성능을 달성한다는 것을 보여줌
사용하는 ORCA 개념의 경우 로보틱스에서 로봇간의 충돌을 막기 위해서도 쓰임

수정하고자 한 것

Velocity Obstacle(VO)에서 발생하는 진동현상을 수정하고자 제작함

핵심 내용

움직이는 장애물들 사이에서의 자연스러운 움직임을 위해 도입된 VO(Velocity Obstacle) 개념의 확장

ORCA(Optimal Reciprocal Collision Avoidance)라는 개념을 도입하여 각 객체간의 속도를 계산한 후 그 책임을 각각 반틈씩 가지게 만들어서 군중의 뭉치는 현상을 줄어들도록 만드는 것

결국 병목 현상(Bottleneck)을 개선하기 위해서 제작

- 민코우스키 합 (민코프스키 덧셈)

기하학에서, 유클리드 공간의 위치벡터 A와 B의 두 집합의 민코스키 합(팽창)은 A에 있는 모든 벡터를 B에 있는 각각의 벡터에 더해서 만들어진다.
 

 
 
민코프스키 덧셈은 장애물 사이로 지나는 모션계획에 사용된다.

추가 참고 자료

실제 작동 RVO2 Library

💡RVOSimulator-> doStep()

doStep을 실행하면 한프레임이 진행된다.

void RVOSimulator::doStep(float powfScalar)
{
    kdTree_->buildAgentTree();

    this->powfScalar = powfScalar;

#ifdef _OPENMP
#pragma omp parallel for
#endif
    for (int i = 0; i < static_cast<int>(agents_.size()); ++i) {
        agents_[i]->computeNeighbors();
        agents_[i]->computeNewVelocity();
        //agents_[i]->computeNewVelocityE();
    }

#ifdef _OPENMP
#pragma omp parallel for
#endif
    for (int i = 0; i < static_cast<int>(agents_.size()); ++i) {
        agents_[i]->update();
    }

    globalTime_ += timeStep_;
}

먼저 kdTree에 대한 정보들을 다시 생성한다.

void KdTree::buildAgentTree()
{
	if (agents_.size() < sim_->agents_.size()) {
		for (size_t i = agents_.size(); i < sim_->agents_.size(); ++i) {
			agents_.push_back(sim_->agents_[i]);
		}

		agentTree_.resize(2 * agents_.size() - 1);
	}

	if (!agents_.empty()) {
		buildAgentTreeRecursive(0, agents_.size(), 0);
	}
}

현재 agent의 수와 시뮬레이션에서 가지고 있는 agent의 수가 변경될 때 (즉, 추가될 때) 새로운 agent를 vector에 추가한다.

그리고 Agent kd-tree를 생성한다.

void KdTree::buildAgentTreeRecursive(size_t begin, size_t end, size_t node)
{
	agentTree_[node].begin = begin;
	agentTree_[node].end = end;
	agentTree_[node].minX = agentTree_[node].maxX = agents_[begin]->position_.x();
	agentTree_[node].minY = agentTree_[node].maxY = agents_[begin]->position_.y();

	for (size_t i = begin + 1; i < end; ++i) {
		agentTree_[node].maxX = std::max(agentTree_[node].maxX, agents_[i]->position_.x());
		agentTree_[node].minX = std::min(agentTree_[node].minX, agents_[i]->position_.x());
		agentTree_[node].maxY = std::max(agentTree_[node].maxY, agents_[i]->position_.y());
		agentTree_[node].minY = std::min(agentTree_[node].minY, agents_[i]->position_.y());
	}

	if (end - begin > MAX_LEAF_SIZE) {
		/* No leaf node. (leaf node : 부모가 없는 최상위 노드) */
		const bool isVertical = (agentTree_[node].maxX - agentTree_[node].minX > agentTree_[node].maxY - agentTree_[node].minY);
		const float splitValue = (isVertical ? 0.5f * (agentTree_[node].maxX + agentTree_[node].minX) : 0.5f * (agentTree_[node].maxY + agentTree_[node].minY));

		size_t left = begin;
		size_t right = end;

		while (left < right) {
			while (left < right && (isVertical ? agents_[left]->position_.x() : agents_[left]->position_.y()) < splitValue) {
				++left;
			}

			while (right > left && (isVertical ? agents_[right - 1]->position_.x() : agents_[right - 1]->position_.y()) >= splitValue) {
				--right;
			}

			if (left < right) {
				std::swap(agents_[left], agents_[right - 1]);
				++left;
				--right;
			}
		}

		if (left == begin) {
			++left;
			++right;
		}

		agentTree_[node].left = node + 1;
		agentTree_[node].right = node + 2 * (left - begin);

		buildAgentTreeRecursive(begin, left, agentTree_[node].left);
		buildAgentTreeRecursive(left, end, agentTree_[node].right);
	}
}

💡Agent -> computeNeighbors()

void Agent::computeNeighbors()
{
	obstacleNeighbors_.clear();
	float rangeSq = sqr(timeHorizonObst_ * maxSpeed_ + radius_);
	sim_->kdTree_->computeObstacleNeighbors(this, rangeSq);

	agentNeighbors_.clear();

	if (maxNeighbors_ > 0) {
		rangeSq = sqr(neighborDist_);
		sim_->kdTree_->computeAgentNeighbors(this, rangeSq);
	}
}

먼저 Agent의 이웃들(나랑 같이 움직이고 있다고 가정하는 Agent들에 대해 계산을 한다.

rangeSq는 속도와 timeHorizonObst(옵션)에 따라 달라지도록 만든 sqr(루트)를 적용한 반지름이다.

해당 변수를 kdTree->computeAgentNeighbors() 함수로 넘겨준다.

이중에 RVO는 Nearest Neighbor 방법을 사용하는듯하다.

computeObstacleNeighbors는 움직이지 않는 방해물을 계산할 때 사용하려고 계산한다.

💡k-d Tree
k차원 공간의 점들을 구조화하는 공간 분할 자료 구조
보통 다차원 공간에서 탐색할 때 사용되는 기법
Range Search, Nearest neighbor 등의 문제에 적용

💡kNN
주어진 Point와 가장 가까운(주어진 set안의) 점을 찾는 것
1. k 이웃의 기준을 정의
2. test 셋의 개별 포인트에 대해서 k 개의 이웃을 찾음
3. 이웃의 output을 가지고 예측값을 생성

void KdTree::computeAgentNeighbors(Agent *agent, float &rangeSq) const
{
    queryAgentTreeRecursive(agent, rangeSq, 0);
}

kd-tree 내에서 위치를 찾아서 insert해준다.

찾은 agentTree가 10개 이하면 그대로 삽입하고, 그렇지 않으면 kd-tree 내에서 위치를 다시 정확하게 탐색한다.

kNN에서 주어진 set이 10개라고 생각하면 된다.

void KdTree::queryAgentTreeRecursive(Agent *agent, float &rangeSq, size_t node) const
{
	//agentTree의 크기가 10보다 작다면 agent의 이웃에 해당 agent를 insert
	if (agentTree_[node].end - agentTree_[node].begin <= MAX_LEAF_SIZE) {
		for (size_t i = agentTree_[node].begin; i < agentTree_[node].end; ++i) {
			agent->insertAgentNeighbor(agents_[i], rangeSq);
		}
	}
	else {
		const float distSqLeft = sqr(std::max(0.0f, agentTree_[agentTree_[node].left].minX - agent->position_.x())) + sqr(std::max(0.0f, agent->position_.x() - agentTree_[agentTree_[node].left].maxX)) + sqr(std::max(0.0f, agentTree_[agentTree_[node].left].minY - agent->position_.y())) + sqr(std::max(0.0f, agent->position_.y() - agentTree_[agentTree_[node].left].maxY));

		const float distSqRight = sqr(std::max(0.0f, agentTree_[agentTree_[node].right].minX - agent->position_.x())) + sqr(std::max(0.0f, agent->position_.x() - agentTree_[agentTree_[node].right].maxX)) + sqr(std::max(0.0f, agentTree_[agentTree_[node].right].minY - agent->position_.y())) + sqr(std::max(0.0f, agent->position_.y() - agentTree_[agentTree_[node].right].maxY));

		if (distSqLeft < distSqRight) {
			if (distSqLeft < rangeSq) {
				queryAgentTreeRecursive(agent, rangeSq, agentTree_[node].left);

				if (distSqRight < rangeSq) {
					queryAgentTreeRecursive(agent, rangeSq, agentTree_[node].right);
				}
			}
		}
		else {
			if (distSqRight < rangeSq) {
				queryAgentTreeRecursive(agent, rangeSq, agentTree_[node].right);

				if (distSqLeft < rangeSq) {
					queryAgentTreeRecursive(agent, rangeSq, agentTree_[node].left);
				}
			}
		}

	}
}

💡Agent -> computeNewVelocity()

주변 이웃을 결정하였으면 새로운 속도를 탐색한다.

새로운 속도를 위해 ORCA 라인을 새롭게 만든다.

행렬식의 절대값은 도형의 면적을 의미한다.

		const Obstacle *obstacle1 = obstacleNeighbors_[i].second;
		const Obstacle *obstacle2 = obstacle1->nextObstacle_;

		const Vector2 relativePosition1 = obstacle1->point_ - position_;
		const Vector2 relativePosition2 = obstacle2->point_ - position_;

		/*
		 * Check if velocity obstacle of obstacle is already taken care of by
		 * previously constructed obstacle ORCA lines.
		 * 장애물의 속도 장애물이 이전에 구축된 장애물 ORCA 라인에 의해 
		 * 이미 처리되었는지 확인합니다.
		 */
		bool alreadyCovered = false;

		for (size_t j = 0; j < orcaLines_.size(); ++j) {
			//det : 행렬식, radius_ : agent의 반지름
			if (det(invTimeHorizonObst * relativePosition1 - orcaLines_[j].point, orcaLines_[j].direction) - invTimeHorizonObst * radius_ >= -RVO_EPSILON 
			&& det(invTimeHorizonObst * relativePosition2 - orcaLines_[j].point, orcaLines_[j].direction) - invTimeHorizonObst * radius_ >=  -RVO_EPSILON) {
				alreadyCovered = true;
				break;
			}
		}

		if (alreadyCovered) {
			continue;
		}

먼저 구축된 장애물 ORCA 라인에 의해 이미 처리되었는지 확인하고, 처리 되었다면 생략한다.

그렇지 않다면 장애물 ORCA 라인을 만든다.

	/* Create obstacle ORCA lines. */
	for (size_t i = 0; i < obstacleNeighbors_.size(); ++i) {
	
		/* Not yet covered. Check for collisions. */

		const float distSq1 = absSq(relativePosition1);
		const float distSq2 = absSq(relativePosition2);

		const float radiusSq = sqr(radius_);

		const Vector2 obstacleVector = obstacle2->point_ - obstacle1->point_;
		const float s = (-relativePosition1 * obstacleVector) / absSq(obstacleVector);
		const float distSqLine = absSq(-relativePosition1 - s * obstacleVector);

		Line line;

		if (s < 0.0f && distSq1 <= radiusSq) {
			/* Collision with left vertex. Ignore if non-convex. */
			if (obstacle1->isConvex_) {
				line.point = Vector2(0.0f, 0.0f);
				line.direction = normalize(Vector2(-relativePosition1.y(), relativePosition1.x()));
				orcaLines_.push_back(line);
			}

			continue;
		}
		else if (s > 1.0f && distSq2 <= radiusSq) {
			/* Collision with right vertex. Ignore if non-convex
			 * or if it will be taken care of by neighoring obstace */
			if (obstacle2->isConvex_ && det(relativePosition2, obstacle2->unitDir_) >= 0.0f) {
				line.point = Vector2(0.0f, 0.0f);
				line.direction = normalize(Vector2(-relativePosition2.y(), relativePosition2.x()));
				orcaLines_.push_back(line);
			}

			continue;
		}
		else if (s >= 0.0f && s < 1.0f && distSqLine <= radiusSq) {
			/* Collision with obstacle segment. */
			line.point = Vector2(0.0f, 0.0f);
			line.direction = -obstacle1->unitDir_;
			orcaLines_.push_back(line);
			continue;
		}

		//아래 코드들 실행
        //...

		/*
		 * No collision.
		 * Compute legs. When obliquely viewed, both legs can come from a single
		 * vertex. Legs extend cut-off line when nonconvex vertex.
		 * 충돌은 없습니다.
		 * leg를 계산하세요. 비스듬히 볼 때, 두 leg는 하나의 꼭짓점에서 나올 수 있습니다. 
		 * leg는 볼록하지 않은 꼭짓점에서 절단선을 연장합니다.
		 */

		Vector2 leftLegDirection, rightLegDirection;

		if (s < 0.0f && distSqLine <= radiusSq) {
			/*
			 * Obstacle viewed obliquely so that left vertex 
			 * defines velocity obstacle.
			 * 왼쪽 꼭짓점이 속도 장애물을 정의하도록 비스듬히 보이는 장애물.
			 */
			if (!obstacle1->isConvex_) {
				/* Ignore obstacle. */
				continue;
			}

			obstacle2 = obstacle1;

			const float leg1 = std::sqrt(distSq1 - radiusSq);
			leftLegDirection = Vector2(relativePosition1.x() * leg1 - relativePosition1.y() * radius_, relativePosition1.x() * radius_ + relativePosition1.y() * leg1) / distSq1;
			rightLegDirection = Vector2(relativePosition1.x() * leg1 + relativePosition1.y() * radius_, -relativePosition1.x() * radius_ + relativePosition1.y() * leg1) / distSq1;
		}
		else if (s > 1.0f && distSqLine <= radiusSq) {
			/*
			 * Obstacle viewed obliquely so that
			 * right vertex defines velocity obstacle.
			 * 오른쪽 꼭짓점이 속도 장애물을 정의하도록 비스듬히 보이는 장애물.
			 */
			if (!obstacle2->isConvex_) {
				/* Ignore obstacle. */
				continue;
			}

			obstacle1 = obstacle2;

			const float leg2 = std::sqrt(distSq2 - radiusSq);
			leftLegDirection = Vector2(relativePosition2.x() * leg2 - relativePosition2.y() * radius_, relativePosition2.x() * radius_ + relativePosition2.y() * leg2) / distSq2;
			rightLegDirection = Vector2(relativePosition2.x() * leg2 + relativePosition2.y() * radius_, -relativePosition2.x() * radius_ + relativePosition2.y() * leg2) / distSq2;
		}
		else {
			/* Usual situation. */
			if (obstacle1->isConvex_) {
				const float leg1 = std::sqrt(distSq1 - radiusSq);
				leftLegDirection = Vector2(relativePosition1.x() * leg1 - relativePosition1.y() * radius_, relativePosition1.x() * radius_ + relativePosition1.y() * leg1) / distSq1;
			}
			else {
				/* Left vertex non-convex; left leg extends cut-off line. */
				leftLegDirection = -obstacle1->unitDir_;
			}

			if (obstacle2->isConvex_) {
				const float leg2 = std::sqrt(distSq2 - radiusSq);
				rightLegDirection = Vector2(relativePosition2.x() * leg2 + relativePosition2.y() * radius_, -relativePosition2.x() * radius_ + relativePosition2.y() * leg2) / distSq2;
			}
			else {
				/* Right vertex non-convex; right leg extends cut-off line. */
				rightLegDirection = obstacle1->unitDir_;
			}
		}

/*
		 * Legs can never point into neighboring edge when convex vertex,
		 * take cutoff-line of neighboring edge instead. If velocity projected on
		 * "foreign" leg, no constraint is added.
		 */

		const Obstacle *const leftNeighbor = obstacle1->prevObstacle_;

		bool isLeftLegForeign = false;
		bool isRightLegForeign = false;

		if (obstacle1->isConvex_ && det(leftLegDirection, -leftNeighbor->unitDir_) >= 0.0f) {
			/* Left leg points into obstacle. */
			leftLegDirection = -leftNeighbor->unitDir_;
			isLeftLegForeign = true;
		}

		if (obstacle2->isConvex_ && det(rightLegDirection, obstacle2->unitDir_) <= 0.0f) {
			/* Right leg points into obstacle. */
			rightLegDirection = obstacle2->unitDir_;
			isRightLegForeign = true;
		}

		/* Compute cut-off centers. */
		const Vector2 leftCutoff = invTimeHorizonObst * (obstacle1->point_ - position_);
		const Vector2 rightCutoff = invTimeHorizonObst * (obstacle2->point_ - position_);
		const Vector2 cutoffVec = rightCutoff - leftCutoff;

		/* Project current velocity on velocity obstacle. */

		/* Check if current velocity is projected on cutoff circles. */
		const float t = (obstacle1 == obstacle2 ? 0.5f : ((velocity_ - leftCutoff) * cutoffVec) / absSq(cutoffVec));
		const float tLeft = ((velocity_ - leftCutoff) * leftLegDirection);
		const float tRight = ((velocity_ - rightCutoff) * rightLegDirection);

		if ((t < 0.0f && tLeft < 0.0f) || (obstacle1 == obstacle2 && tLeft < 0.0f && tRight < 0.0f)) {
			/* Project on left cut-off circle. */
			const Vector2 unitW = normalize(velocity_ - leftCutoff);

			line.direction = Vector2(unitW.y(), -unitW.x());
			line.point = leftCutoff + radius_ * invTimeHorizonObst * unitW;
			orcaLines_.push_back(line);
			continue;
		}
		else if (t > 1.0f && tRight < 0.0f) {
			/* Project on right cut-off circle. */
			const Vector2 unitW = normalize(velocity_ - rightCutoff);

			line.direction = Vector2(unitW.y(), -unitW.x());
			line.point = rightCutoff + radius_ * invTimeHorizonObst * unitW;
			orcaLines_.push_back(line);
			continue;
		}

/*
		 * Project on left leg, right leg, or cut-off line, whichever is closest
		 * to velocity.
		 */
		const float distSqCutoff = ((t < 0.0f || t > 1.0f || obstacle1 == obstacle2) ? std::numeric_limits<float>::infinity() : absSq(velocity_ - (leftCutoff + t * cutoffVec)));
		const float distSqLeft = ((tLeft < 0.0f) ? std::numeric_limits<float>::infinity() : absSq(velocity_ - (leftCutoff + tLeft * leftLegDirection)));
		const float distSqRight = ((tRight < 0.0f) ? std::numeric_limits<float>::infinity() : absSq(velocity_ - (rightCutoff + tRight * rightLegDirection)));

		if (distSqCutoff <= distSqLeft && distSqCutoff <= distSqRight) {
			/* Project on cut-off line. */
			line.direction = -obstacle1->unitDir_;
			line.point = leftCutoff + radius_ * invTimeHorizonObst * Vector2(-line.direction.y(), line.direction.x());
			orcaLines_.push_back(line);
			continue;
		}
		else if (distSqLeft <= distSqRight) {
			/* Project on left leg. */
			if (isLeftLegForeign) {
				continue;
			}

			line.direction = leftLegDirection;
			line.point = leftCutoff + radius_ * invTimeHorizonObst * Vector2(-line.direction.y(), line.direction.x());
			orcaLines_.push_back(line);
			continue;
		}
		else {
			/* Project on right leg. */
			if (isRightLegForeign) {
				continue;
			}

			line.direction = -rightLegDirection;
			line.point = rightCutoff + radius_ * invTimeHorizonObst * Vector2(-line.direction.y(), line.direction.x());
			orcaLines_.push_back(line);
			continue;
		}

	const size_t numObstLines = orcaLines_.size();

	const float invTimeHorizon = 1.0f / timeHorizon_;

	/* Create agent ORCA lines. */
	for (size_t i = 0; i < agentNeighbors_.size(); ++i) {
		const Agent *const other = agentNeighbors_[i].second;

		const Vector2 relativePosition = other->position_ - position_;
		const Vector2 relativeVelocity = velocity_ - other->velocity_;
		const float distSq = absSq(relativePosition);
		const float combinedRadius = radius_ + other->radius_;
		const float combinedRadiusSq = sqr(combinedRadius);

		Line line;
		Vector2 u;

		if (distSq > combinedRadiusSq) {
			/* No collision. */
			const Vector2 w = relativeVelocity - invTimeHorizon * relativePosition;
			/* Vector from cutoff center to relative velocity. */
			const float wLengthSq = absSq(w);

			const float dotProduct1 = w * relativePosition;

			if (dotProduct1 < 0.0f && sqr(dotProduct1) > combinedRadiusSq * wLengthSq) {
				/* Project on cut-off circle. */
				const float wLength = std::sqrt(wLengthSq);
				const Vector2 unitW = w / wLength;

				line.direction = Vector2(unitW.y(), -unitW.x());
				u = (combinedRadius * invTimeHorizon - wLength) * unitW;
			}
			else {
				/* Project on legs. */
				const float leg = std::sqrt(distSq - combinedRadiusSq);

				if (det(relativePosition, w) > 0.0f) {
					/* Project on left leg. */
					line.direction = Vector2(relativePosition.x() * leg - relativePosition.y() * combinedRadius, relativePosition.x() * combinedRadius + relativePosition.y() * leg) / distSq;
				}
				else {
					/* Project on right leg. */
					line.direction = -Vector2(relativePosition.x() * leg + relativePosition.y() * combinedRadius, -relativePosition.x() * combinedRadius + relativePosition.y() * leg) / distSq;
				}

				const float dotProduct2 = relativeVelocity * line.direction;

				u = dotProduct2 * line.direction - relativeVelocity;
			}
		}
		else {
			/* Collision. Project on cut-off circle of time timeStep. */
			const float invTimeStep = 1.0f / sim_->timeStep_;

			/* Vector from cutoff center to relative velocity. */
			const Vector2 w = relativeVelocity - invTimeStep * relativePosition;

			const float wLength = abs(w);
			const Vector2 unitW = w / wLength;

			line.direction = Vector2(unitW.y(), -unitW.x());
			u = (combinedRadius * invTimeStep - wLength) * unitW;
		}

		line.point = velocity_ + 0.5f * u;
		orcaLines_.push_back(line);
	}

	size_t lineFail = linearProgram2(orcaLines_, maxSpeed_, prefVelocity_, false, newVelocity_);

	if (lineFail < orcaLines_.size()) {
		linearProgram3(orcaLines_, numObstLines, lineFail, maxSpeed_, newVelocity_);
	}

계산된 ORCA 라인들과 Linear Programming을 이용해서 새로운 속도를 얻는다.

💡Linear Programming
다양한 제약 조건을 고려하면서 선형 함수를 최대화하거나 최소화하는 수학적 모델링 기술

size_t lineFail = linearProgram2(orcaLines_, maxSpeed_, prefVelocity_, false, newVelocity_);

if (lineFail < orcaLines_.size()) {
	linearProgram3(orcaLines_, numObstLines, lineFail, maxSpeed_, newVelocity_);
}

result == newVelocity_랑 같다.

size_t linearProgram2(const std::vector<Line> &lines, float radius, const Vector2 &optVelocity, bool directionOpt, Vector2 &result)
{
	if (directionOpt) {
		//최적화되어 있는 방향. 이 경우 최적화 속도는 단위 길이입니다.
		result = optVelocity * radius;
	}
	else if (absSq(optVelocity) > sqr(radius)) {
		/* 가장 가까운 점과 바깥쪽 원을 최적화합니다. */
		result = normalize(optVelocity) * radius;
	}
	else {
		/* 가장 가까운 점과 안쪽 원을 최적화합니다. */
		result = optVelocity;
	}

	for (size_t i = 0; i < lines.size(); ++i) {
		//두 선이 같으면 0을 출력
		if (det(lines[i].direction, lines[i].point - result) > 0.0f) { // 평행사변형의 면적
			/* 결과가 제약조건 i를 만족하지 않습니다. 새로운 최적의 결과를 계산합니다. */
			const Vector2 tempResult = result;

			if (!linearProgram1(lines, i, radius, optVelocity, directionOpt, result)) {
				result = tempResult;
				return i;
			}
		}
	}

	return lines.size();
}

bool linearProgram1(const std::vector<Line> &lines, size_t lineNo, float radius, const Vector2 &optVelocity, bool directionOpt, Vector2 &result)
{
	//스칼라 곱, 벡터의 내적
	const float dotProduct = lines[lineNo].point * lines[lineNo].direction;
	const float discriminant = sqr(dotProduct) + sqr(radius) - absSq(lines[lineNo].point);

	if (discriminant < 0.0f) {
		/* 최대 속도 원은 line lineNo를 완전히 무효화합니다. */
		return false;
	}

	const float sqrtDiscriminant = std::sqrt(discriminant);
	float tLeft = -dotProduct - sqrtDiscriminant;
	float tRight = -dotProduct + sqrtDiscriminant;

	for (size_t i = 0; i < lineNo; ++i) {
		//분모
		const float denominator = det(lines[lineNo].direction, lines[i].direction);
		//분자
		const float numerator = det(lines[i].direction, lines[lineNo].point - lines[i].point);
		//fabs() : 절대값 연산
		if (std::fabs(denominator) <= RVO_EPSILON) {
			/* Lines lineNo과 i는 (거의) 나란하다. */
			if (numerator < 0.0f) {
				return false;
			}
			else {
				continue;
			}
		}

		const float t = numerator / denominator;

		if (denominator >= 0.0f) {
			/* Line i bounds line lineNo on the right. */
			tRight = std::min(tRight, t);
		}
		else {
			/* Line i bounds line lineNo on the left. */
			tLeft = std::max(tLeft, t);
		}

		if (tLeft > tRight) {
			return false;
		}
	}

	if (directionOpt) {
		/* 최적화 방향 */
		if (optVelocity * lines[lineNo].direction > 0.0f) {
			/* 오른쪽으로 극단적으로. */
			result = lines[lineNo].point + tRight * lines[lineNo].direction;
		}
		else {
			/* 왼쪽으로 극단적으로. */
			result = lines[lineNo].point + tLeft * lines[lineNo].direction;
		}
	}
	else {
		/* 가장 가까운 지점을 최적화합니다. */
		const float t = lines[lineNo].direction * (optVelocity - lines[lineNo].point);

		if (t < tLeft) {
			result = lines[lineNo].point + tLeft * lines[lineNo].direction;
		}
		else if (t > tRight) {
			result = lines[lineNo].point + tRight * lines[lineNo].direction;
		}
		else {
			result = lines[lineNo].point + t * lines[lineNo].direction;
		}
	}

	return true;
}

void linearProgram3(const std::vector<Line> &lines, size_t numObstLines, size_t beginLine, float radius, Vector2 &result)
{
	float distance = 0.0f;

	for (size_t i = beginLine; i < lines.size(); ++i) {
		if (det(lines[i].direction, lines[i].point - result) > distance) {
			/* 결과가 선 i의 제약 조건을 만족하지 않습니다. */
			std::vector<Line> projLines(lines.begin(), lines.begin() + static_cast<ptrdiff_t>(numObstLines));

			for (size_t j = numObstLines; j < i; ++j) {
				Line line;

				float determinant = det(lines[i].direction, lines[j].direction);

				if (std::fabs(determinant) <= RVO_EPSILON) {
					/* Line i 과 line j 는 나란하다 */
					if (lines[i].direction * lines[j].direction > 0.0f) {
						/* Line i 과 line j 는 같은 방향을 가리킨다 */
						continue;
					}
					else {
						/* Line i 과 line j 는 반대 방향을 가리킨다 */
						line.point = 0.5f * (lines[i].point + lines[j].point);
					}
				}
				else {
					line.point = lines[i].point + (det(lines[j].direction, lines[i].point - lines[j].point) / determinant) * lines[i].direction;
				}

				line.direction = normalize(lines[j].direction - lines[i].direction);
				projLines.push_back(line);
			}

			const Vector2 tempResult = result;

			if (linearProgram2(projLines, radius, Vector2(-lines[i].direction.y(), lines[i].direction.x()), true, result) < projLines.size()) {
				/* 원칙적으로 이런 일은 없어야 합니다. 
				 * 그 결과는 정의상 이 선형 프로그램의 실행 가능 영역에 이미 존재합니다.
				 * 실패할 경우 작은 부동 소수점 오차로 인해 발생하며 현재 결과는 그대로 
				 * 유지됩니다.
				 */
				result = tempResult;
			}

			distance = det(lines[i].direction, lines[i].point - result);
		}
	}
}

연관 키워드

half plane, ORCA, Linear Programming, Velocity Obstacle, 민코우스키 합

* 장애물에서 걸리는 현상이 많이 나오는 이유는 RVO 자체가 움직이는 Obstacle들이 서로 책임을 반틈씩 나누어 가지기 때문에 고정 장애물에서는 효과가 덜 나는 것으로 추측*

참고 사이트

논문의 핵심 내용

속도 장애물은 바뀌는 시간 환경을 위한 configuration space obstacle의 확장 개념이다.

즉 실시간 환경에 적합하다.

Velocity Obstacle(속도 장애물)은 객체의 Velocity가 속도 장애물인 VO 영역에 들어가지 않으면 물체는 충돌하지 않는다는 개념이다.
 

만약 위 그림과 같이 A와 B 객체가 존재한다면, A와 B가 충돌하지 않기 위해서 A는 B가 존재할 수 있는 공간에 들어가지 않으면 피할수 있다는 생각을 가지는 속도 조절 방법이다.
 

 
군중에서 한개의 객체들은 각각의 Velocity(방향을 가진 속도)를 가진다.  위의 그림에서는 A가 가진 속도는 VA로 나타내고, B가 가진 속도는 VB로 나타내었다.

VO를 계산하기 위해서는 Configurations Space로 변환해야하는데, Configuration Space는 수학에서는 위상 공간의 위치에 대한 점 모음 할당을 설명하는데 사용된다.
위상공간은 특정한 계가 가질 수 있는 모든 상태들의 공간이다.

점 A의 위치에서 바라볼 때 A의 몸체(원형)과 B의 몸체(원형)이 닿지 않는 점까지 고려해야 하기 때문에 A와B의 몸체의 위치들을 고려한 A+B 몸체(원형)과 맞닿아 있는 2개의 직선을 그어서 VO를 정의한다.
A에서 B에 대한 VO를 계산할 때, 위의 그림과 같이 점 A의 위치에서 B의 외곽을 지나는 직선 2개를 구한다. 이 직선 두개를 기준으로 VO는 회색 공간으로 표시된 공간이다. 현재 프레임에서 이 공간에 들어가지 않으면 B와 절대 충돌하지 않는다.
군중 시뮬레이션에서 Path Planning(경로 계획)을 지정할 때, 이러한 속도 장애물을 응용해서 넣는다.

다음 프레임에서 A가 B에 대해 계산한 회색 영역은 VB만큼 이동할 것이다.
회색 영역은 "Collision cone"이라고 부른다.
Collision cone은 계산할때 A와 B의 반지름을 더한 원에 대해서 외곽을 지나는 선 2개를 이용하여 구한다.
 
따라서, A의 Velocity를 조절할 때 VB만큼 이동한 회색 영역 VO를 침범하지 않는 Velocity를 조절하면 다음 프레임에서 A는 B를 피해서 이동하는 것처럼 보일것이다.

따라서 기존의 VA 속도를 VO를 피해서 빨간색 부분만큼으로 조정하면서 시뮬레이션을 진행시키면 충돌을 회피하는 시뮬레이션을 제작할 수 있다.

VO의 진동 현상을 줄인 RVO

 
velocity obstacle 관련 자료 : https://en.wikipedia.org/wiki/Velocity_obstacle

논문 참고 : Motion Planning in Dynamic Environments using Velocity Obstacles - 1998년도 발행 

버블정렬을 이용하여 랭킹 시스템을 c++로 구현해보았습니다.

앞으로 게임을 짤때 랭킹 시스템에 종종 이용할 수 있겠군요

sweep and prune은 교수님께서 특정 논문을 읽으라고 하셨을 때 본 방법입니다

하지만 한글 해석이 된 포스팅이 없어서 간단하게 번역하여 놓고 점점 추가 및 보완할 예정입니다

해당 포스팅은 https://github.com/mattleibow/jitterphysics/wiki/Sweep-and-Prune 을 한국어로 해석한 포스팅으로 문제가될 시 삭제하도록 하겠습니다

광역 충돌 시스템은 모든 물리 엔진의 핵심 과정 중 하나입니다.

이미 광역 충돌에 대해 놓친 게 있다면 광역 충돌시스템을 최적화하는 코드를 짜서 복구하기는 어렵습니다.

물리 엔진에서 충돌 단계에는 3가지가 있습니다.

1. Broadphase : 광대한 범위

- 여기서 어떤 충돌이 실제로 일어날 수 있는지를 감지하고, 충돌할 수 없는 충돌을 폐기합니다.

참고할만한 사이트 : https://developer.nvidia.com/gpugems/gpugems3/part-v-physics-simulation/chapter-32-broad-phase-collision-detection-cuda

2. Midphase : 중간 범위

- 구나 천 물체 같은 기하학적 단계에서의 충돌을 말합니다. 

3. Narrowphase : 좁은 범위

- 이 단계에서 실제 충돌 감지를 수행합니다.  교차점, 충돌 법선 또는 침투 깊이와 같은 충돌 데이터를 검색하는 작업을 합니다.

거의 모든 광역 시스템은 객체의 축 정렬된 경계 상자(aabb)를 사용합니다.

aabb는 꽤 빨리 계산될 수 있으며 교차점을 확인하는 것도 몇 줄의 코드로 수행됩니다.

참고할만한 사이트 : https://blog.naver.com/mycode333/50031266282

그렇다면, 어떻게 하면 "겹치지 않는 쌍의 정렬 과정"을 가속화 할 수 있을까요?

충돌을 감지하기 위한 예전의 접근방식에 대해 몇 가지를 알아봅시다.

for (int i = 0; I < rigidBodies.Count; i++)
{
    for (int e = i; e < rigidBodies.Count; e++)
    {
        if (CheckBoundingBoxForOverlap(i, e))
            DetectNarrowPhase(i,e);
    }
}

그렇게 나쁘지는 않지만..

만약 10x10x10 충돌 감지 되는 큐브가 있다면, 최상의 경우 수천 개의 충돌 가능한 쌍을 확인하여 위의 코드를 수행해야 합니다. 좁은 범위의 충돌 체크는 0.25백만 개를 체크해야합니다.

자연적으로 광역 범위는 O(n^2) 문제가 생기는데 이에 대해 무엇을 할 수 있을까요?

데이터 구조를 가속화해야 합니다.

웹에서 "광역상 충돌 탐지"를 검색하면 Sweep And Prune(SAP)접근법을 발견하게 됩니다.

많은 변형된 구현들이 있지만 분류한 다음 다듬는다(Prune)는 공통점이 있습니다.

SAP 알고리즘에서 가장 간단한 "flavor"를 지속되지 않는 단일 축 SAP에서 사용한다는 것이 무엇을 의미하는지 알아봅시다.

1. 공간 안의 모든 물체들은 "AxisList"라는 목록 안에 들어있습니다. 경계상자의 시작을 이용해 한 개의 축(여기서는 X축)으로 리스트를 정렬합니다. 따라서 물체 5의 가장 왼쪽 지점이 X축을 직접 볼 때 물체 6의 가장 왼쪽 지점보다 더 왼쪽에 있다는 것을 알 수 있습니다.

2. "ActiveList"라는 새로운 임시 리스트를 만들자. 이제 "AxisList"의 다음 항목을 보고 "ActiveList"의 모든 항목과 비교합니다.(현재는 단 하나) 만약 새 항목의 왼쪽이 더 크면 현재 "ActiveList"의 오른쪽 항목이 제거되고 "ActiveList"에서 현재 "ActiveList" 아이템이 제거됩니다. 그렇지 않으면 새 "AxisList" 항목과 현재 "ActiveList" 항목 간의 충돌 가능성이 생깁니다. 새 항목 자체를 "ActiveList"에 추가하고 "AxisList"의 다음 항목을 계속합니다.

이 접근법이 지속적이지 않다는 것을 알게됩니다.

정렬은 처음부터 모든 프레임에서 수행되며(quicksort 성능이 좋다) 한 축(여기에서는 X축)에 대해 정렬된다.

우리는 장면의 일관성을 이용하지 않는다.(한 프레임에서 장면이 많이 변하지 않을 가능성이 있다)

속도 향상은 어디서 발생하는것일까?

정답은 충돌 탐지는 검색 문제이기 때문입니다. 그리고 사전 분류된 목록을 검색은 O(nlog(n)) 보다 빠릅니다.

이 쉬운 접근법을 구현하면 무차별 힘 알고리즘(brute force algorithm)에 비해 엄청난 속도 향상이 가능합니다.

JigLib (Danny Chapman이 만든 코드)에서 C # (JigLibX)로 이식되었을 때, JigLib의 원래 버전은 무차별적인 힘과 매우 기본적인 그리드 접근법을 포함하고있었습니다.
존 와트는 위에서 설명한 코드를 정확하게 사용하는 프로젝트에 SAP 알고리즘을 적용했는데, 이는 복잡한 그리드 접근법을 쉽게 극복했습니다.

따라서 이 코드는 이미 꽤 잘 수행되지만, 그럼에도 불구하고 X축에서 모든 물체가 겹치면 런타임은 다시 O (n *2)이다.

(따라서, 대부분의 물체가 그곳에서 겹치기 때문에, 분리 축으로 up-축을 사용하지 않아야 합니다)

Sweep and Prune을 하기 위한 더 복잡한(그리고 더 빠른) 접근법은 완전한 3축 검사를 하는 것입니다.

두 물체가 충돌하면 세 축 모두 겹치는 경우에만 충돌합니다 (분리 축 정리).

지속적 3Axis SAP는 다음과 같이 요약하여 작동합니다.

우리는 세 개의 목록 (각 축 1에 대해)을 사용하고 삽입 정렬을 사용하여 정렬된 목록을 유지합니다.

삽입 정렬은 거의 정렬된 목록에서 O(n)입니다.

삽입 정렬 알고리즘의 스왑은 개체가 다른 본체와 중첩되기 시작/중지하는 것을 의미합니다.

그래서 한 개의 해시 테이블을 겹쳐서 보관하고, 각 프레임은 삽입구역을 하고, 해시 테이블 구조를 업데이트하는 데 사용하는 변경사항만 보고받습니다.

Jitter의 절차

private void SortAxis(List<SweepPoint> axis)
{
    for (int j = 1; j < axis.Count; j++)
    {
        SweepPoint keyelement = axis[j];
        float key = keyelement.Value;
        
        int i = j - 1;
        
        while (i >= 0 && axis[i].Value > key)
        {
            SweepPoint swapper = axis[i];
            
            if (keyelement.Begin && !swapper.Begin)
            {
                if (CheckBoundingBoxes(swapper.Body, keyelement.Body))
                {
                    lock (fullOverlaps)
                    {
                        fullOverlaps.Add(new BroadphasePair(swapper.Body, keyelement.Body));
                    }
                }
            }
            
            if (!keyelement.Begin && swapper.Begin)
            {
                lock (fullOverlaps) 
                {
                    fullOverlaps.Remove(new BroadphasePair(swapper.Body, keyelement.Body));
                }
            }
            
            axis[i + 1] = swapper;
            i = i - 1;
        }
        axis[i + 1] = keyelement;
    }
}

만약 당신이 전형적인 SAP 데이터 구조의 모든 세부사항에 관심이 있다면, 나는 피에르 테르디만이 쓴 훌륭한 기사를 읽을 것을 추천합니다.

그렇지 않다면 각 프레임에 "A가 축 C에서 B와 겹친다"는 정보나 "A가 축 C에서 B의 중첩을 중지했다"는 정보만 전달받으면 X, Y 또는 Z축이 될 수 있습니다.

처음 이것을 시행했을 때, 나는 내가 받는 값싼 결과에 매우 만족했고, 그리고 나서 실수를 했습니다.

각각의 쌍이 얼마나 중복되는지를 기억하는 데이터 구조를 구현했습니다.

겹치는 횟수가 3회(모든 축에서 겹치는 횟수가 1회임을 의미)인 경우, 물체는 충돌합니다.

이것은 효과가 있지만 끔찍합니다.

한 축에 겹치는 쌍의 수는 매우 높을 수 있으므로 중복 계수 = 1인 수천 개의 잠재적 겹치는 쌍을 저장해야 한다. 단지 몇 개만 두 번째 축에 겹치고 겹치는 횟수가 2이고, 세 번째 축에 겹치는 횟수는 3이라는 것을 깨달았습니다.

결국 런타임은 O(nlogn)였지만 메모리 사용량은 O(n^2)이었다(내 사전 구조를 죽이는 것)

이 문제의 해결책은 간단합니다. 아무것도 저장하지 마라.

한 축이 중첩을 보고하는 경우 저렴한 전체 경계 상자 확인 – 양수일 경우 해당 쌍을 풀오버랩에 추가하십시오.

한 축에 두 개의 몸체가 분리되어 있다고 보고된 경우, 풀오버랩에서 쌍을 제거하십시오. (이것은 위의 코드로 행해진다.) 따라서 SAP에 사용되는 메모리는 다시 O(n)에 지나지 않습니다.

("CollisionSystemPersistent"에서 Jitter의 구현을 찾을 수 있음) SAP.cs".)

지속적인 Sweep and Prune 알고리즘의 단점 중 하나는 많은 비활성 객체를 가진 정말 큰 세계를 경험한다는 것이다.

총알이 정적인 물체가 많은 마을을 관통하는 것을 상상해보라.

각 물체(총탄으로부터 수마일 떨어져 있어도)와 탄환 자체 사이에 교환이 있다

이 문제는 그리드(광범위 단계)를 구성하는 여러 개의 소형 SAP를 사용하여 해결할 수 있다.

내가 알아차린 또 다른 문제는 광선과 경계 상자 질의가 효율적으로 수행될 수 없다는 것이다.

레이캐스팅의 경우, 정렬된 세 개의 목록은 균일하지 않은 복셀 그리드로 해석될 수 있으므로, 주문한 레이 쿼리를 얻을 수 있다.

이것은 실제로는 다소 느리다.

왜냐하면 많은 복셀 그리드가 비어 있고 초기 타격을 받은 광선에 대한 해결책일 뿐이기 때문이다.

단지 각 물체에 대해 거친 힘 검사를 하는 것이 종종 더 빠르기 때문이다.

또 다른 문제는 장면에 하나의 큰 물체(대개 지면이나 레벨)가 포함되어 있다는 것이다.
이 개체의 끝점은 완전히 왼쪽에 있고 목록 오른쪽에 있다.

스위프 포인트에 저장된 추가 정보가 없으면 개체가 훨씬 더 큰 엔티티의 끝점에 의해 둘러싸이는지 여부를 효율적으로 감지할 수 있는 방법이 없다.

새 프로젝트를 눌러주자!

이런 창이 뜨면 Win32 콜솔 응용 프로그램을 만들것이다.

이름을 바꿔주면 프로젝트의 이름이 바뀌고 위치는 자신이 설정해주고 싶은 곳에 지정해주면 된다.

(참고로 이름과 솔루션 이름은 동일하게 자동으로 입력된다.)

확인을 누르고 그다음 뜨는 창에서 다음을 또 눌러주자.

이러한 창이 뜨게 되면 우리가 만들고 싶은 것은 빈 프로젝트이기에 빈프로젝트를 체크하고 마침을 눌러주면 생성된다.

자 그러면 이제 솔루션 탐색기에 내가 만든 프로젝트가 뜨게 되는데 여기에서

[소스파일] 우클릭 -> 추가 -> 새 항목 을 눌러주자

그러면 이러한 창이 뜨게 되는데

C++ 파일 을 클릭해놓고 이른에는 소스이름(소스이름은 꼭 영어로 만들도록 하자).c 를 해주어야한다.

소스이름.cpp 파일을 만들게 되면 C언어가 아닌 C++언어로 만들어지므로 확장자는 꼭 .c로 만들어주도록 하자.

야생의 빈 소스파일이 하나 만들어졌다!

그러면 이제 수학의 집합단원과 같은 C언어의 Hello,World! 출력하는 코드를 한번 만들어보자.

이렇게 적었으면 Ctrl+F5 번을 눌러서 솔루션을 빌드해보자.

이런 창이 떳다면 성공한것이다. (한글 윈도우에서는 "계속하려면 아무 키나 누르십시오..." 일것이다.)

한글을 적어도 잘 출력된다.

음 그런데 여기서 창의 색깔이 흰색인게 마음에 안든다 싶으면 창에서 마우스 우클릭을 하면

여기서 Properties(속성)에 들어가보자.

여기서 여러가지 속성을 바꿀 수 있다.

이렇게 바꿀 수 있다!

*C언어는 절차지향적 특성을 지닌다.

C언어는 정해진 순서의 실행흐름을 중시한다. 절차지향적이기 때문에 처음 접하는 사람도 조금만 공부하면 쉽게 익숙해질 수 있다.

*C언어로 구현된 프로그램은 좋은 성능을 보인다.

사용하는 메모리의 양이 상대적으로 적고, 속도를 저하시키는 요소들을 최소화한 언어이기 때문이다.

까먹지 말고 복습하자 STL은 꽤나 유용한 라이브러리이다.

간단하게 설명하자면 STL은 템플릿으로 작성된 많은 제네릭 클래스와 함수 라이브러리이다.

컨테이너,iterator,알고리즘로 분류된다.

- 컨테이너 종류

- iterator 종류

- 알고리즘