둘은 상당히 비슷한 기능을 하죠. mipmap 제어라는...

그치만 공식의 작동법은 미묘하게 달라요.

lod가 shader3.0을 요구한다는 것도 다르고요...

프로그래머들에게 물어보면 공식에 대한 차이만 말해주니까요

자세한 느낌을 보기 위해 직접 테스트를 해 봤습니다.

예제를 만들어 봤습니다. 둘이 똑같아 보이죠?

근데 제 눈에는 살짝 오른쪽 텍스쳐가 추가 샘플링 된 것처럼 보입니다.

그래서 정말 그런가 테스트

오호라 과연 정말입니다.

tex2Dlod는 고정된 mipmap을 유지하지만, bias 는 이름값대로 추가로 바이어스를 걸어주고 있는 느낌입니다.

그럼 이번에는 값에 따른 변화를 테스트 하기 위해 다시 근접시킵니다.

음 겜브리오때는 밉맵을 수동 설정 가능했는데. 유니티는 방법이 없을까낭...

뭐 투덜대도 할 수 없으니까 이번에는 값을 비교해 보죠

지금 두 그림이 똑같아 보입니다만... 오른쪽이 밉맵 1 상태라고 보여집니다. 한 단계 낮은 이미지요.

어쨌거나 일단 비교.

lod/bias 값 1

lod/bias 값 1.5

lod/bias 값 2

lod/bias 값 2.5

lod/bias 값 3

lod/bias 값 3.5

lod/bias 값 4

lod/bias 값 4.5

lod/bias 값 5

lod/bias 값 5.5

lod/bias 값 6

음... 일단 오른쪽 bias의 값이 더 낮아 보입니다.

그 이유는... 현재 보이는 거리 때문에 밉맵이 한 단계 더 먹은 상태라서 그렇습니다.

그에 반해 tex2Dlod는 거리고 뭐고 상관 안하고 mipmap 값이 강제지정됩니다. 호옹이.

이런 차이로군요.

그래서 정말 그런가 추가 테스트

다시 6단계에서부터 추가 테스트. 이번에는 필터링을 개뿌연 Box 필터링에서 그나마 날카로운  Kaiser 필터링으로 바꿔 보았습니다. 카메라를 좀 근접시키니 두 이미지가 상당히 비슷하네요 그래도 lod가 더 선명해 보이는게, 1단계 앞인 느낌입니다.

거리를 멀게 하자 오호라. 역시 bias는 거리에 따라 mipmap이 더 먹습니다.

그렇다는것은...

거리만 가깝다면 bias가 더 선명하다는 말도 된단 말입니다. lod는 고정이니까. 오호호라...

즉  lod는 무조건 고정시키는 거고 bias는 말그대로 기존 값에 bias 시킨다는 말이겠습니다.

이 기능은 주로 싸구려 블러 효과로 사용됩니다만, 값을 반대로 처리하면 싸구려 샤픈 효과도 가능하겠죠.

뭐 그 외에도 사실 많이 쓸 데가 있습니다. Matcap 과 같이 어떻게 저렇게 응용하면 모바일용 러프니스 흉내도 ... 케케케케케 꼼수질...

뭐 그래서 위 내용이 정말 사실인가 테스트.

이렇게 밉맵을 수동으로 제어할 수 없는 엔진에서는 텍스쳐를 작게 만들면 잘 보입니다. 데헷. 역시 꼼수.

네네네 증명되었습니다 역시.

32 *32 이미지를 가지고 밉맵을 가동시켜보니 역시 이렇게 나오는군요. 어쩔 수 없지요.

이런건 오히려 곡면일때가 더 문제죠 .

이렇게 되어 버리니까요.

Tex2Dbias를 쓰려면 텍스쳐가 작으면 일단 안 되겠군요. * 위는 Bilinear 상태입니다.

겸해서 추가로 알아낸 lod와 bias의 차이.

bias는 float으로 소숫점 단위까지 하나하나 연산해서 mipmap을 흐리는데,

lod는 그렇게 변하질 않네요.

lod로 하면 0.0~0.49까지는 같고

0.5~1.49 일때 변하고

1.5~2.49 일때 변하고

2.5~3.49 일때 변....

한다는 것입니다.

* 위의 경우는 텍스쳐가 Bilinear 로 되어 있을때였네요.

Trilinear일 경우에는 밉맵간 인터폴레이션이 되니까 저렇게 되진 않습니다.

그래도 오른쪽 아티펙트도 조금 줄긴 하지만 여전히 아티펙트는 남습니다.

그리고

lod는 0 이하의 값이 존재할 리가 없지만

bias는 - 값을 사용하면 알리아싱이 없는 가짜 샤픈 효과를 낼 수 있다는 것 정도.(물론 아주 가까우면 아무 의미가 없지만)

 재밌네요.

재미있는 연구였습니다. 이상.

* 텍스쳐를 인터페이스용으로 쓰던걸 밉맵만 생성해서 쓰다가 그만 필터링 옵션을 Trilinear로 바꾸는걸 잊고 있었군요.

그래서 Bilinear로 돌고 있었습니다. 이런 실수를!!

그래서 보너스로 Bilinear 와 Trilinear 차이를 보여드리겠습니다.

원본 이미지. 엄청 작습니다. 16*16 짜리이죠.

이게 Point Sampling. 밉맵 있음. 밉맵이 작동되는 라인이 선명하게 보입니다.

픽셀이 확대되거나 축소될때 옆 픽셀과 어떤 블렌딩도 없죠.

이게 Bilinear 샘플링 밉맵있음. 밉맵라인이 훤히 보입니다.

확대되거나 축소되는 픽셀은 옆 픽셀들과 블렌딩됩니다.

이게 Trilinear 샘플링 밉맵있음. 밉맵끼리 블렌딩이 되기 때문에 거의 안 보입니다.

확대되거나 축소되는 픽셀은 역시 옆 픽셀들과 블렌딩됩니다.

마지막으로 Anisotropic 샘플링 * 16

기울어진 각도를 인식해서 비례로 샘플링하기 때문에 기울어졌을때 가장 선명하게 샘플링되지만 가장 느립니다.

언제 한 번 샘플링도 알기 쉽게 정리를 해야..

카메라에는 보이는 영역, 원뿔 .. 은 아니고 사각뿔 영역이 있습니다.

이 영역을 View frustom 뷰 프러스텀 이라고 하고, 이 영역 안에 있으면 화면에 보이는 걸로 치고 렌더링합니다.

http://en.wikipedia.org/wiki/Viewing_frustum

네 뭐 좋습니다. 안보이면 안그리고 딱 좋지요.

보이면 그리는 겁니다.

하지만

이따만한 오브젝트가 있을 때, (2만 폴리곤이군요)

그 와중에 화면에 요따시만큼만 보일 때, 어떻게 될까요?

우선, 이 오브젝트는 보이는 건가요? 안보이는 건가요?

... 네 보이는 겁니다. 큰 오브젝트의 폴리곤 하나라도 보이면 이 오브젝트는 '보이는 겁니다'

CPU는 매 프레임마다 이 화면에 어떤 오브젝트가 있는지를 검사하고 있습니다. '일' 을 하고 있는거지요. 일을 하면 당연히 자원이 듭니다. 그런 입장에서 보았을때, 이 2만 폴리의 플렌은 반드시 '보이는' 겁니다. 네 뭐 그렇지요.

어디 진짜인가 실험해 보죠. 플레이를 해 봅니다.

네 오브젝트는 하나이므로 드로우콜은 1입니다. 뭐 오케이

그리고 폴리곤은... 여전히 2만입니다!!! 그렇습니다. 끄트머리 하나가 보였는데도, 이 2만 폴리 플렌은 다 보인다고 계산되고 있습니다. 픽셀 드로잉 연산은 좀 벗어날 수 있어도 버텍스 연산은 얄짤없이 전부 계산하고 있습니다.

이것을 제가 강의할때 주로 하는 비유로 말하면, '만리장성의 벽돌 하나만 보여도 만리장성은 다 보이는 거랑 같다' 라는 겁니다.

그렇다면 방법은 없을까요? 네 방법이 없지는 않습니다.

오브젝트를 이렇게 디테치 시키는 겁니다. 맥스에서.

그렇게 되면 총 9개의 오브젝트가 되는 거지요!!! 그렇게 하고 다시 끄트머리만 보면...?

짜잔

폴리곤이 1/10으로 줄었습니다. 만세!!

대충 맞죠 . 9개로 나눴으니까 말이죠. 이렇게 보이는 녀석만 보이게 되는 겁니다.

만세

정말 좋아진 것 같습니다. 와아 그럼 여러개로 막 나누면 좋을까요? 더 자질구레하게 나누면 좋을 거잖아요

물론 그렇지는 않습니다. 이렇게 나누면 처리해야 하는 폴리곤은 줄어드는 대신...

전부 다 한번에 보자, 드로우 콜이 9가 되었습니다!!!  

폴리곤 양보다 더 무서운, 드로우 콜이 늘어나거든요. 이렇게 전체를 볼 때는 말입니다.

즉 이렇게 한 화면에 들어오는걸 여러 개로 자르는건 오히려 더 퍼포먼스의 낭비가 일어나게 됩니다.

이럴때는 차라리 안 나누는게 더 좋아요. 한 화면에 전부 보인다면 말입니다. 이럴때는 앞에 썼던 방법이 오히려 좀 더 효율적입니다.

결론내리다면, 기본적으로 '드로우 콜을 줄여야 하는데, 그렇다고 폴리곤이 너무 많아지지 않게끔 너무 안보이는건 잘라라' 가 기본 조건이란 말이지요. 적절한 드로우 콜과 적절한 폴리곤 양의 배분을 위해, 배경에서 이걸 자르는 크기를 잡는건 매우 경험이 필요한 기술입니다.

그러므로

'만리장성은 적절한 크기로 잘라야 합니다'

이것을 '프러스텀 컬링' 이라고 하고, 가장 가벼운 지형 최적화 방법중 하나입니다. 유니티 터레인이나 언리얼 랜드스케이프에서도 적용되어 있는 방법이지요 (보통 동적 LOD와 함께 동작할 수 있도록 적절한 사이즈의 청크로 잘라져 있습니다. 안보이지만 안보이지만)

그리고 뭐 모든 엔진의 기본이기도 합니다.

http://hoidu.tistory.com/78

물론 여기에 추가로 버텍스가 안보이면 버텍스를 하나하나 정말 잘라버리는 '클리핑' 이란 기술도 있습니다.

그렇지만 그 기술은... 상식적으로도 컬링보다 더 무겁습니다! ㄷㄷㄷ

그도 그럴 것이, 보이는 버텍스는 남겨두고 안보이는 버텍스를 없애버리게 되면 일단 매 프레임 전체 '버텍스' 의 충돌을 검사해야 하는 데다가 (덜덜덜)

보이는 버텍스를 두고 안보이는 버텍스를 지우면 이번엔 그 중간의 폴리곤이 날라가게 되어서 뚫려 보이게 됩니다 (덜덜덜2)

그러다보니까 클리핑 기술에는 반드시 버텍스를 추가 생성해서 면을 만들어 버리는 기술까지 같이 들어가 있습니다.... (덜덜덜3)

http://gamercampuk.tumblr.com/post/22716607528/a-brief-history-of-graphics-and-rendering

이걸 실시간으로 처리한다면 그야말로 엄청난 부하가 유발되는 작업이 되기 때문에 PC 에서도 잘 안쓰는 기법이지요.

(마영전의 옷 처리도 클리핑 플렌을 미리 설치해 놔서 실시간 계산양을 줄였을 정도...)

결론적으로 최적화의 기본은 "안보이게 하는 것"이지만, 그 안보이게 하는 기술 자체가 무거운 경우가 많아서 참으로 요령있게 사용해야 하는 영역이라는 겁니다. 그럼 총총

타입은 다른데 같은 작업을 하는 클래스나 함수를 구현을 할때 템플릿을 사용합니다. 아래와 같이 말이죠.

template<typename T>
class CFoo
{
public:
	T Add(T lhs, T rhs)
	{
		return lhs + rhs;
	}
};

int _tmain(int argc, _TCHAR* argv[])
{
	CFoo<int> integer;
	std::cout << integer.Add(3, 5) << std::endl;

	CFoo<float> floating;
	std::cout << floating.Add(2.5f, 8.2f) << std::endl;

	return 0;
}

여기까지는 계획대로 잘 되는거 같습니다. 그렇다면 Add 함수에 아래와 같이 문자열을 넣어서 두 문자열이 합쳐지게 만드려면 어떨까요?

CFoo<char*> szStr;
std::cout << szStr.Add("Hello, ", "World!!") << std::endl;

결과는 error C2110: '+' : 두 포인터를 더할 수 없습니다. 라는 메시지와 함께 에러가 나버립니다. 두 문자열이 합쳐지게 하려면 char* 타입용 CFooCharPointer 클래스를 따로 구현해야 할까요? 아니면 클래스 전체를 구현하기는 귀찮으니 char* 인자를 받는 AddCharPointer 함수만 추가로 구현해줄까요? 

비슷한 일을 하는 클래스를 또 만드는 것도, 다른 타입의 템플릿 클래스에서는 굳이 사용안할 멤버 함수를 추가하는 것도, 둘다 그리 좋은 모습은 아닙니다. 이런 상황의 해결책으로 템플릿 특수화 기능을 사용하면 됩니다. 특정 타입에서만 다르게 동작하는 함수를 만들수 있는 것이죠. 위의 상황에서 int나 float 같은 일반적인 타입에서는 기존에 정의한 Add 함수대로 동작하고, char* 같은 예외 타입이 들어오면 특수화 시킨 함수를 호출 시키게 하면 되는 것입니다.

template<typename T>
class CFoo
{
public:
	T Add(T lhs, T rhs)
	{
		return lhs + rhs;
	}
};

// char* 타입용 특수화 함수
template<> char* CFoo<char*>::Add(char* lhs, char* rhs)
{
	char *sz = new char[128];
	memset(sz, 0, sizeof(sz));
	strcat(sz, lhs);
	strcat(sz, rhs);
	return sz;
}

int _tmain(int argc, _TCHAR* argv[])
{
	CFoo<int> integer;
	std::cout << integer.Add(3, 5) << std::endl;

	CFoo<float> floating;
	std::cout << floating.Add(2.5f, 8.2f) << std::endl;

	CFoo<char*> szStr;
	char *resultString = szStr.Add("Hello, ", "World!!");
	std::cout << resultString << std::endl;
	delete[] resultString;

	return 0;
}

CFoo에 위와 같이 char* 타입에 대해 함수를 재정의 해줍니다. 이렇게 할 경우 char* 타입으로 템플릿을 생성했을 경우 Add 함수를 호출 하면, 특수화된 Add 함수가 호출되고, 결과는 아래와 같이 원하는대로 출력되는 것을 확인할 수 있습니다.

참고 : https://msdn.microsoft.com/ko-kr/library/c401y1kb.aspx

PS : CFoo<std::string> 을 사용하면 char* 특수화를 안해도되지만, 예를 위해 위와 같이 샘플 코드를 작성해보았습니다.

요즘 유니티를 이용해 C#으로 코딩을 하시는 분들이 많은데, 간혹 면접을 보다보면 Boxing과 Unboxing에 대해 제대로 이해하지 못하는 분들이 많더군요. 이를 C/C++의 캐스팅 같은 것으로 생각하고 마구잡이로 사용하시는 분들이 많은듯 합니다. 하지만 C/C++의 캐스팅과 다르게 C#의 Boxing은 그 과정에서 개체 할당이 일어 나기 때문에 성능 이슈가 생길수 있습니다.

int num1 = 123;
object obj = num1;      // boxing
int num2 = (int)obj;    // unboxing

C#에서 사용되는 모든 타입들은 object 에서 직/간접적으로 상속을 받게 됩니다. 즉, 최상위 부모 클래스 같은 존재지요. 이것이 C/C++에서 였다면, 위의 num1에서 obj로의 대입은 단순 업캐스팅으로 변환되는 거기 때문에 큰 문제는 없을 겁니다. 하지만 C#에서는 다릅니다. C#에서는 이를 Boxing이라 부르며 아래와 같이 힙 Heap에 새로운 개체를 할당하고 그 곳에 값을 복사하게 됩니다. 

C++ 코드로 보자면 아래와 같은 상황인겁니다.

int num1 = 123;
int *obj = new int;
(*obj) = num1;

이 때문에 MSDN에서도 Boxing, Unboxing에 대해 아래와 같이 조언하고 있습니다.

• System.Collections.ArrayList 같은 제네릭이 아닌 컬렉션 클래스의 예와 같이 많은 수의 boxing이 필요한 경우에는 값 형식을 사용하지 않는 것이 좋습니다. System.Collections.Generic.List 같은 제네릭 컬렉션을 사용하면 값 형식의 boxing을 방지할 수 있습니다. boxing 및 unboxing 과정에는 많은 처리 작업이 필요합니다. 값 형식을 boxing할 때는 완전히 새로운 개체가 만들어져야 하며, 이러한 작업은 간단한 참조 할당보다 최대 20배의 시간이 걸립니다. unboxing을 할 때는 캐스팅 과정에 할당 작업보다 4배의 시간이 걸릴 수 있습니다.

반대로 Unboxing의 경우 Boxing과는 다르게 대입하려는 타입을 명시적으로 지정해주어야 합니다. Bxoing 되어있는 타입과 명시한 타입이 같으면, 해당 객체의 값을 복사합니다.

C#은 C/C++에 비해 타입에 엄격하기 때문에 Boxing 타입과 다른 타입으로 Unboxing을 시도하면 InvalidCastException 같은 에러를 냅니다.

참조 : MSDN Boxing 및 Unboxing