{{ label!='' ? 'Label : ' : (q!='' ? '검색 : ' : '전체 게시글') }} {{ label }} {{ q }} {{ ('('+(pubs|date:'yyyy-MM')+')') }}

[Troubleshooting] 테스트 프로젝트에서의 LNK2019, LNK1120 에러

설명

  테스트 프로젝트에서 단위 테스트를 진행할 때, 같은 솔루션 내 프로젝트의 함수를 제대로 링킹하지 못하는 현상이 일어남: LNK2019, LNK1120.

  해당 클래스가 존재하는 프로젝트 내에서는 같은 코드여도 링킹 에러가 일어나지 않고, 테스트 프로젝트에서만 해당 현상이 발생.


원인

  테스트 클래스에서 외부 참조 클래스의 헤더 파일을 포함하나, 해당하는 목적 파일을 찾을 수 없음.


해결

  1. 링크 에러를 발생시키는 클래스의 헤더(.h)를 포함하는 것 대신 소스파일(.cpp)을 포함하는 것으로 해결할 수 있음.
  2. 허나 이는 별로 좋지 않은 해결이며, 테스트 프로젝트 빌드 속성에서 링커의 추가 의존에 목적 파일들이 있는 경로를 추가해주는 것으로 해결할 수 있음. 가령: $(SolutionDir)MyProjectName\$(IntDir)*.obj
  3. 혹은, 이러한 문제가 발생하는 근본적인 이유는 executable한 두 프로젝트가 서로 참조를 하는 과정에서 링크를 할 수 없다는 것에 있으므로 참조를 받는 프로젝트 쪽에서 *.lib 등으로 빌드를 하여 링크할 수 있도록 만들면 됨.

댓글

댓글 쓰기

이 블로그의 인기 게시물

[코딩의탑] 4층: 툰 쉐이딩

이미지
가끔은 만화스러운 느낌이 좋을 때도 있죠.   셀 쉐이딩(Cel shading)이라고도 불리는 툰 쉐이딩 기법은 절제된 빛 표현으로 화면을 그리는 비사실적(non-photorealistic) 렌더링 기법 중 하나입니다.  <Borderlands 시리즈>   이러한 툰 쉐이딩은 다양한 방식으로 실현되고 있으며, 언리얼 엔진을 활용한 툰 쉐이딩 역시 어렵지 않습니다. 특히, 포스트 프로세싱을 이용하여 만화스럽게 후처리를 해주는 방법은 클라이언트 프로그래머들이 손쉽게 사용할 수 있는 방법입니다.   하지만, 포스트 프로세싱을 이용한 툰 쉐이딩은 다음과 같은 단점이 존재하는데요: 포스트 프로세싱 자체의 비용이 존재합니다. 특정한 머티리얼에만 툰 쉐이딩을 적용하기 어렵습니다. (커스텀 스텐실 버퍼를 활용하는 것이 대표적인 방법이며, 이는 개발자를 피곤하게 합니다)   따라서, 우리는 포스트 프로세싱을 활용하지 않는 툰 쉐이딩을 구현해보도록 하죠. 우리는 다음을 구현할 것입니다: 특정 물체의 윤곽선을 추가로 렌더링합니다. 특정 물체의 음영을 부드럽지 않은 단계별 음영으로 변경합니다. 이들의 사용 여부와 윤곽선 굵기, 색을 머티리얼 에디터 속성으로 결정할 수 있습니다. 반복되는 컴파일을 줄이기 위해 머티리얼 인스턴스로 만들 수 있으며, 윤곽선의 굵기를 재컴파일 없이 변경할 수 있습니다.   이는  언리얼 엔진 5의 소스를 직접 수정하는 방법임에 주의하세요. 이러한 방법 역시 마법이 아니므로, 비용이 존재합니다. 이는 차차 이야기하도록 하겠습니다. 그 전에 언리얼 엔진 5를 살펴보도록 하죠. 렌더링 패스 디퍼드 쉐이딩으로 렌더링에 필요한 다양한 정보를 담는 버퍼들   언리얼 엔진은 기본적으로 PC 게임에 한해 디퍼드 쉐이딩을 수행합니다. 디퍼드 쉐이딩이란 포워드 쉐이딩의 반대 개념입니다. 한 물체를 렌더링한다고 생각해보죠. 그 물체의 3차원 세계 좌표와 물체 표면의 법선, 표면 거칠기의 정도, 표면에 매핑된 텍스처와 변위 등 수많은 요소들을 고려해 우리 눈에 보
자세한 내용 보기

[코딩의탑] 3층: 바다 렌더링

이미지
바다를 그려봅시다.   수많은 게임들은 바다를 배경으로 하고 있습니다. 굳이 바다를 게임의 메인 배경으로 하지 않더라도, 게임 어느 중간에는 꼭 바다를 볼 수 있는 순간이 나오기 마련이죠.  <Sea of Thieves>   이러한 바다를 유체역학적 지식으로 구현하는 것은 쉽지 않습니다. 화면에 보이는 입자가 너무 많아 현실적으로 계산 능력이 부족하기 때문입니다. 따라서 많은 게임들은 바다를 구현하기 위해서 수많은 편법을 활용하고 있습니다. 대표적인 방법은 Displacement Mapping(변위 매핑)을 이용하는 것이죠.  Displacement Mapping   Displacement Mapping이란 Displacement Map을 이용해 물체를 구성하는 일련의 정점들을 재배치하는 것을 의미합니다. 가령, 평평한 격자의 물체가 있고 다음과 같은 두 개의 Displacement Map이 있다면 우리는 파도와 같은 현상을 만들어낼 수 있습니다. 하나는 큰 파도(저주파)를, 다른 하나는 작은 파도(고주파)를 재현합니다. 흰색일수록 위에 있으며, 검은색일수록 아래에 있게 됩니다.   이러한 Displacement Map들을 겹친 후에, 서로 다른 방향으로 움직이게 만들고 겹쳐진 값을 이용해서 Displacement Mapping을 한다면 저렴한 연산으로 파도와 같은 환상을 만들어낼 수 있습니다. 하지만 이 방법은 정적으로 파도가 만들어진다는 한계가 있습니다. 바람의 방향, 파도의 세기 등을 조절하기가 어렵죠. 조금 더 멋진 Displacement Map을 만들 수 있는 방법이 있을까요? Jerry Tessendorf의 'Simulating Ocean Water'   영화 프로듀서이자 교수인 Tessendorf는 그럴듯한 바다를 시뮬레이션할 수 있는 방법을 논문으로 정리해 제안하였습니다. 제가 다룰 내용을 간단히 요약하면 다음과 같습니다: 파도는 일종의 사인파와 코사인파의 합입니다. 따라서 푸리에 변환의 철학을 이용해서 복잡한 주기적 파
자세한 내용 보기

[코딩의탑] 5층: 포탈(Portal), 더 나아가기

이미지
2층에서 많은 부족함이 있었죠..   2층 에서 우리가 구현한 포탈은 다음과 같은 부족함이 있습니다: 포탈을 단순히 월드에 배치하기만 했으며, 포탈 건의 요구사항을 고려하지 않았습니다. 가령 포탈은 벽에 생성될 수 있어야 합니다. 플레이어의 포탈 이동만을 고려했습니다. 큐브 등 다른 오브젝트 역시 통과할 수 있어야 합니다. 포탈에 걸쳐있는 오브젝트는 포탈 양면에서 보일 수 있어야 합니다. 즉, 오브젝트의 복사가 이루어져야 합니다. Near plane clippng으로 인해 포탈에 들어가기 직전 카메라가 평면과 겹치는 순간, 포탈 평면의 뒷면 모습이 비춰집니다. 포탈에 비추는 플레이어의 모습이 3인칭으로 보여야 합니다. 효율적인 포탈 재귀 렌더링 방법이 필요합니다. 복습해봅시다. 벡터와 점의 변환   포탈 건너편으로 이동하는 효과를 주기 위해서, 우리는 적절히 오브젝트를 이동 및 회전시켜야 합니다. 속도 역시 적절한 방향으로 보존되어야 하죠. 포탈   먼저 위치와 속도는 3차원 벡터로 표현될 수 있습니다. 그리고 이것이 포탈과 포탈 사이에서 자연스럽게 이어져야 하죠. 마치 포탈이 붙어있는 것처럼요! 다음 그림을 참고해보세요. 블루 포탈과 오렌지 포탈은 서로가 위 방향 축을 기준으로 180도 회전한 상태에서 맞붙어있는 것처럼 느껴야 합니다. 블루 포탈과 오렌지 포탈   이는 각 포탈을 일종의 지역 좌표계로 생각해볼 수 있습니다. 포탈의 [앞 방향 벡터, 우측 방향 벡터, 위 방향 벡터]를 각각 [X, Y, Z]축으로 삼는 셈이죠. 우리는 마치 "이어져 있는" 환상을 선사해야 하므로, 한쪽 지역 좌표계의 좌표 값을 그대로 다른쪽 지역 좌표계의 좌표 값으로 자연스럽게 넘겨주면 됩니다. 다양한 방법이 있겠지만 성능을 위해, 각 축에 대한 내적의 값을 이용하도록 합시다. 각 축은 정규화되어 있고 수직이므로, 내적을 이용할 수 있습니다. 좌표계의 변환 소스 코드: APortal::TransformVectorToDestSpace(), TransformPoi
자세한 내용 보기