EPPEngine

deferred 에 대한 단상

2011-09-20T17:23:19P

allgd.net 라는 사이트를 통해 여러 개발자 분들의 생각을 많이 보고 느끼고 있는 도중

http://cagetu.egloos.com/ 라는 분의 사이트에서 deferred 에 대한 공감가는 부분들이 있어 글을 적습니다.

요즘 게임에서 지연렌더링이 필수인가 라고 한다면.. 전 아닌것 같다는 의견입니다.

필수가 아니라는 거죠.

물론 내부지형에서 많은 수의 라이트가 동적으로 오브젝트들에 빛을 조사하는 형태가 필요한 게임이라면,

혹은 외부지형에서라도 특정 이벤트에 따른 수십개의 빛이 동적으로 계산되어야 하는 경우라면,

또 다른 부분이라 생각듭니다.

하지만 위의 경우라 하더라도, 실제 단일 객체가 영향을 받는 라이트 수는 사실 생각보다 많지는 않습니다.

책상, 의자, 가구, 말, 자동차 등과 같이 일반적인 크기의 단일 객체라면, 실제 태양광 과 역광을 제외한 영향을 받는 라이트가

3개 이상만 되어도 크게 잘 느껴지지가 않더군요. 그래서 대략 5개 정도라면 (태양광, 역광을 포함한 7개정도?) 충분히 다양한

느낌을 표현 할 수 있지 않을까 생각이 듭니다.

물론 큰 건물 이라던지, 지형 이라던지 와 같은 큰 객체의 경우라면 적용되는 라이트가 넓은 공간에 걸쳐서 많이 존재하기에

작은수의 라이트로는 표현이 안 될지 모르지만, 그 부분의 경우라도, 데칼을 통한 실시간 라이트 묘사 등을 같이 활용한다면

충분히 표현 할 수 있지 않을까 라고 생각이 듭니다.

물론 최근 게임들이 글로벌 라이팅에 대한 여러가지 시도를 많이 하고는 있고, 그에 따른 라이트 사용수가 엄청나게 증가는

하고 있지만, 이 역시 화면 후처리를 통해 어느정도의 수준까지는 표현 할 수 가 있지 않나 생각 합니다. (아니면 라이트맵 -_-;)

그러므로 제 점수는.... -_-;; 제 결론은

게임에 따라서 렌더링 방식을 정하는 것은 당연 하겠지만, 일반적인 상황에서조차 최신 기술 혹은 " 빠르다던데".. 등의 이유에서

지연렌더링으로 가는 것은 좋은 생각이 아닌것 같습니다.

충분히 foward 로도 표현이 ... ...

p.s. deferred 로 변경하면 퀄리티가 좋아진다더라.. 라고 이야기 하는 분들도 있었습니다. 물론 deferred 방식의 도입을 통해

얻어지는 여러가지 부산물로 다양한 후처리를 할 수는 있지만, deferred == 높은 퀄리티 를 이야기 하는 분들을 보면

좀 아니다 싶더군요. deferred 는 단지 빛 계산을 보다 효율적으로 처리하기 위한 방식일 뿐인데 말이죠..

빛 계산이 효율적일 뿐, foward 랑 다른 공식을 쓰는 것도 아니고..

HSV 공간을 RGB 공간으로, RGB 공간을 HSV 공간으로 전환.

2011-07-30T11:50:55P

출처 : http://ploobs.com.br/?p=1499

float3 Hue(float H)
{
    float R = abs(H * 6 - 3) - 1;
    float G = 2 - abs(H * 6 - 2);
    float B = 2 - abs(H * 6 - 4);
    return saturate(float3(R,G,B));
}

float4 HSVtoRGB(in float3 HSV)
{
    return float4(((Hue(HSV.x) - 1) * HSV.y + 1) * HSV.z,1);
}

float4 RGBtoHSV(in float3 RGB)
{
    float3 HSV = 0;
    HSV.z = max(RGB.r, max(RGB.g, RGB.b));
    float M = min(RGB.r, min(RGB.g, RGB.b));
    float C = HSV.z - M;
    if (C != 0)
    {
        HSV.y = C / HSV.z;
        float3 Delta = (HSV.z - RGB) / C;
        Delta.rgb -= Delta.brg;
        Delta.rg += float2(2,4);
        if (RGB.r >= HSV.z)
            HSV.x = Delta.b;
        else if (RGB.g >= HSV.z)
            HSV.x = Delta.r;
        else
            HSV.x = Delta.g;
        HSV.x = frac(HSV.x / 6);
    }
    return float4(HSV,1);
}

게임메카 기사 떳습니다. ㅠ,.ㅠ 주르륵

2011-05-20T21:18:03P

http://www.gamemeca.com/news/news_view.html?seq=35&ymd=20110520&page=1&point_ck=1&search_ym=&sort_type=&search_text=&send=&mission_num=&mission_seq=

기사를 써준 강민호 기자님께 감사를 전하며...

주르륵..

국내 게임업계에 보탬이 될만한 업체가 되도록 최선을 다하겠습니다.

감사합니다.

16-Bit Color Encoding on the GPU

2011-01-16T10:30:19P

출처 : http://theinstructionlimit.com/?p=33

float2 EncodeR5G6B5(float3 rgb24)
{
	// scale up to 8-bit
	rgb24 *= 255.0f;
 
	// remove the 3 LSB of red and blue, and the 2 LSB of green
	int3 rgb16 = rgb24 / int3(8, 4, 8);
 
	// split the green at bit 3 (we'll keep the 6 bits around the split)
	float greenSplit = rgb16.g / 8.0f;
 
	// pack it up (capital G's are MSB, the rest are LSB)
	float2 packed;
	packed.x = rgb16.r * 8 + floor(greenSplit);		// rrrrrGGG
	packed.y = frac(greenSplit) * 256 + rgb16.b;		// gggbbbbb
 
	// scale down and return
	packed /= 255.0f;
	return packed;
}
 
float3 DecodeR5G6B5(float2 packed) {
	// scale up to 8-bit
	packed *= 255.0f;
 
	// round and split the packed bits
	float2 split = round(packed) / 8;	// first component at bit 3
	split.y /= 4;				// second component at bit 5
 
	// unpack (obfuscated yet optimized crap follows)
	float3 rgb16 = 0.0f.rrr;
	rgb16.gb = frac(split) * 256;
	rgb16.rg += floor(split) * 4;
	rgb16.r *= 2;
 
	// scale down and return
	rgb16 /= 255.0f;
	return rgb16;
}

게임 엔진..(잡생각 + 잡고찰)

2010-12-29T19:02:54P

게임 엔진이라는게, 단순히 렌더러만 있다고해서 엔진이라고 할 수 는 없습니다.

전부는 아니더라도, 게임에 필요한 각종 기능을 담아야 하는 것은 물론이거니와,

그런 기능들 조차 적지 않습니다.

기능 이외에도 툴을 제공해야 하는데, 이 툴이 가장 문제입니다.

툴이라는게, 단순히 리소스를 만들어내는 도구는 아니라고 생각합니다.

툴에서 어떤 정보들을 뽑아낼 수 있느냐에 따라서 작업방향, 작업 프로세스가 결정되게 되는거죠.

그 정보의 범위가 요즘은 상당히 넓습니다.

EPPENGINE 의 경우는 각종 LOD 정보 ( 셰이더 교체, 오브젝트 교체, 폴리곤LOD, 셰이더 Pass LOD, Animation Frame LOD, Bone LOD ...)

를 툴에서 설정 할 뿐아니라, 인스턴싱으로 그릴지 말지에 대한 설정들도 툴에서 하게 됩니다.

물론 헤어렌더링과 같이 복잡한 렌더스테이트를 가진 정보역시, 툴에서 설정하게 됩니다. (심지어 스키닝을 GPU 에서 할지 CPU 에서 할지

에 대한 정보도)

이렇게 많은 정보들이 툴에서 생성되다 보니, 디자이너가 프로그래머를 기다리던 상황도 많이 해소가 되며, 프로그래머가 하던 각종

설정들도 엔진에서 자동으로 처리되게 됩니다.

하지만 이또한 문제가 있더군요. 그래픽쪽에 넘겨준 각종 설정들은 프로그램적 지식없이 접근하기 힘들다는 점 입니다.

이처럼 툴이라는게, 어느 정보를 담느냐에 전체 작업프로세스가 달라지게 되는거죠.

툴 다음은 역시 API 가 되겠네요.

얼마나 명확하게 API 가 구성되어 있고, 이런 것들이 얼마나 편하게 엔진 안쪽에서 알아서 잘~ 처리해 주느냐가 관건 인데요,

이것 또한 쉽지 않은 문제더군요. 뭐 저희야 나름 잘 하고 있다고 생각들지만, 이건 정말 끝이 없는것 같습니다.

나중에는 create_good_game( MMORPG ) 하면 좋은게임이 툭 하고 나와버리는.... 그런 API 하나 나오면.......

여튼 게임엔진이라는게, 기획, 그래픽, 프로그램 등 프로젝트의 많은 구성원들이 함께쓰는 도구이다 보니, 참 힘든것 같습니다.

winsock.h 와 windows.h includ 순서에 따른 문제 해결

2010-11-16T02:58:06P

winsock.h 중복 재정의 에러

원인windows.h 가 구버전의 winsock.h 를 포함하고 있기 때문이다.

해결방법#include <windows.h > 문장 위에 아래 문장을 추가해 준다.

#ifndef _WINSOCKAPI_

#define _WINSOCKAPI

#endif

Reconstructing Position from depth

2010-10-01T07:45:03P

출처 : http://blog.daum.net/rockeracer/38

일반적으로 Deferred 시스템에서 오브젝트의 위치값은 따로 저장하지 않고 깊이값을 이용해 계산해내는 방식을 사용한다. 추가적인 RenderTarget 사용을 없앨 수 있기 때문이다. 깊이값으로 위치값을 계산하는데는 여러 방법이 있는데 그 중 몇가지만 소개하고자한다.

1. Projection-Inverse 행렬 사용

가장 간단한 방법은 깊이 버퍼에 저장되는 값을 계산하는 과정을 거꾸로 적용하는 것이다. 깊이 버퍼에는 위치에 View-Projection 행렬을 적용한 값을 저장하고, 위치를 계산할 때는 깊이 버퍼에 저장된 값에 Projection 행렬의 역행렬을 적용하는 것이다. Projection 행렬의 역행렬을 적용하면 View-공간 위치를 얻을 수 있고 View-Projection행렬의 역행렬을 적용하면 World-공간 위치를 얻을 수 있다.

코드를 보면...

* 깊이 저장

VSOUTPUT VS(VSINPUT input)

{

...

output.position = mul(input.position, matWVP);

output.depth = output.position.z/output.position.w;

...

}

PSOUTPUT PS(VSOUTPUT input)

{

...

output.depth = input.depth;

...

}

* 위치 계산

float4 PS (VSOUTPUT input)

{

float depth = tex2D(DepthBuffer, input.screencoord);

float4 PosInProj = {input.screencoord.x, input.screencoord.y, depth , 1};

float4 PosInView = mul(PosInProj , matProjInverse);

PosInView /= PosInView .w;

...

}

가장 간단한 방식이긴 하지만 행렬 연산이기 때문에 비용이 크다.

2. 카메라에서 원평면으로의 광선

또 다른 방법은 정점 쉐이더에서 카메라에서 원평면까지의 벡터를 계산하고 픽셀 쉐이더에서 이 벡터와 깊이값을 사용해 위치를 계산하는 방법이다. 깊이 버퍼에는 Linear-깊이 값을 저장하고, 카메라-To-원평면 벡터에 이 깊이 값을 곱하면 위치값을 구할 수 있다.

우선, 이 방법은 스크린-공간 사각형을 렌더링할 때 사용할 수 있다. 정점 쉐이더에서 카메라-To-정점 벡터를 구해서 픽셀 쉐이더에 넘겨주고, 픽셀 쉐이더에서는 이 벡터들이 선형 보간되어 해당 픽셀을 지나는 카메라-To-원평면 벡터(위 그림의 파란 백터)가 된다. 그럼 구하고자 하는 위치(위 그림의 빨간점)는 이 벡터위에 있게 된다.

이제 이 벡터의 길이만 조절해주면 카메라-To-위치 벡터(위 그림의 녹색 벡터)가 된다. 이 때 사용하는 것이 깊이-버퍼에 저장된 값이다. 깊이-버퍼에는 해당 위치의 Linear-깊이 값이 저장된다. 위 그림에서 보면 Depth/Far_Distance 값이 저장된다. 카메라-To-원평면 벡터에 이 값을 곱하기만 하면 카메라-To-위치 벡터가 된다. 정점 쉐이더에서 카메라-To-정점 벡터가 View-공간에서 계산되었다면 카메라-To-위치 벡터가 그대로 View-공간 위치가 된다. 카메라-To-정점 벡터가 World-공간에서 계산되었다면 카메라의 World-공간 위치에 카메라-To-위치 벡터를 더하면 World-공간 위치를 구할 수 있다. View-공간 위치를 구하는 것이 비용상 이득이다.

코드를 보면,

* 깊이 저장

VSOUTPUT VS(VSINPUT input)

{

...

output.depth = PosInView.z / g_FarDistance;

...

}

PSOUTPUT PS(VSOUTPUT input)

{

...

output.depth = input.depth;

...

}

* 위치 계산

VSOUTPUT VS(VSINPUT input)

{

...

//View-공간 카메라-To-정점 벡터

//= View-공간 위치 - View-공간 카메라 위치

//= View-공간 위치 - float3(0,0,0) = View-공간 위치

ouput.ray = PosInView;

...

}

PSOUTPUT PS(VSOUTPUT input)

{

...

//스크린-공간 사각형을 사용하기 때문에 기하의 텍스쳐 좌표가 곧 스크린 좌표가 된다.

float depth = tex2D(DepthBuffer, input.texcoord);

float3 PosInView = input.ray * depth;

...

}

이 방법은 곱셈 한번으로 위치를 구할 수 있기 때문에 첫번째 방법에 비해 비용이 훨씬 싸다. 그리고 깊이 버퍼에 Linear-깊이를 저장하기 때문에 Linear-깊이가 필요한 다른 Post-이펙트에서 깊이 버퍼 값을 그대로 사용할 수 있다. 단점은 스크린-공간 사각형을 렌더링할 때만 사용할 수 있다는 것이다.

3. 카메라에서 기하(geometry)까지의 광선

Deferred 시스템에서는 일반적으로 Point Light 나 Spot Light 를 렌더링할 때는 Light 범위에 맞는 기하(구, 원뿔등) 를 사용하기 때문에 두번째 방법을 그대로 사용할 수 없다. 이 방법은 스크린-공간 사각형을 포함하여 어떤 기하 형태든 사용할 수 있도록 두번째 방식을 약간 변형한 것이다. Ray를 이용하는 것은 동일하지만 깊이-버퍼에 저장하는 값이 다르다. 깊이 버퍼에 Linear-깊이가 아닌 카메라까지의 거리를 저장한다.

위치를 계산할 때는 우선 정점 쉐이더에서 받은 벡터를 정규화한다. 방향이 있으므로 크기만 있으면 카메라-To-위치 벡터를 구할 수 있다. 크기는 깊이-버퍼에 저장되어 있으므로 정규화된 벡터에 깊이-버퍼에 저장된 값을 곱하기만 하면 된다. 여기서 주의할 점은 정점 쉐이더에서 벡터를 정규화하는 것은 의미가 없다는 것이다. 정점 쉐이더에서 정규화를 하더라도 선형 보간되어 픽셀 쉐이더로 넘어가면 정규화되지 않은 벡터가 되기 때문이다. 따라서 꼭 픽셀 쉐이더에서 정규화해주어야 한다.

코드를 보면,

* 깊이 저장

VSOUTPUT VS(VSINPUT input)

{

...

output.depth = length(PosInView);

...

}

PSOUTPUT PS(VSOUTPUT input)

{

...

output.depth = input.depth;

...

}

* 위치 계산

VSOUTPUT VS(VSINPUT input)

{

...

//View-공간 카메라-To-정점 벡터

//= View-공간 위치 - View-공간 카메라 위치

//= View-공간 위치 - float3(0,0,0) = View-공간 위치

ouput.ray = PosInView;

...

}

PSOUTPUT PS(VSOUTPUT input)

{

...

float depth = tex2D(DepthBuffer, input.screencoord);

float3 PosInView = normalize(input.ray) * depth;

...

}

4. 픽셀 쉐이더에서 카메라-To-원평면 광선 계산

2, 3번째 방법의 단점은 해당 픽셀 외에 다른 픽셀의 위치를 계산할 수 없다는 것이다. SSAO같은 Post-이펙트는 다른 픽셀에서의 위치값이 필요하기 때문에 또 다른 방식이 필요하다. 2, 3번째 방식은 정점 쉐이더에서 Ray를 계산해서 픽셀 쉐이더에 넘겨주는 방식이기 때문에 다른 픽셀에 대한 Ray를 얻을 수 없다. 정점 쉐이더가 아닌 픽셀 쉐이더에서 Ray를 계산할 수 있으면 이런 제한이 사라진다.

픽셀 쉐이더에서 Ray를 계산하는 것은 간단하다. 원평면의 네 꼭지점을 스크린 좌표로 보간하기만 하면 된다. 원평면의 top-right 점과 left-bottom 점을 보간하면 되는데, View-공간 Ray를 계산한다면 실제로 픽셀 쉐이더에서 필요한 값은 top-right 점의 View-공간 위치 하나이다. left-bottom 점의 View-공간 위치는 top-right 점의 부호만 바꾸면 되기 때문이다.

깊이-버퍼에 저장되는 값은 두번째 방법과 동일하다. 두번재 방법과 마찬가지로 카메라-To-원평면 Ray를 사용하기 때문이다.

코드를 보면,

* 위치 계산

//정점 쉐이더는 필요없다.

PSOUTPUT PS(VSOUTPUT input)

{

...

float3 ray = lerp(-g_FarTopRight, g_FarTopRight, input.screencoord);

float depth = tex2D(DepthBuffer, input.screencoord);

float3 PosInView = ray * depth;

...

}

이 방식의 또 다른 장점은 두번째 방법과 마찬가지로 어떤 기하 모양을 사용하든 적용할 수 있다는 것이다. 또한 두번째 방법과 비교했을 때 normalize() 연산을 하는 대신에 lerp() 연산을 하기 때문에 추가 비용도 없다.

Reference:

http://mynameismjp.wordpress.com/2009/03/10/reconstructing-position-from-depth/

선헌한 날씨 만큼이나 기분 좋네요.

2010-09-27T22:33:00P

일은 많지만 회사도 안정화에 접어들고,

기분 좋습니다.

선선한 날씨 만큼이나 오늘 왠지 기분이 좋네요.

그냥 들뜬다고 해야 하나요?

개발자 분들 명절 잘 보내셨나요?

GPU에 최적화된 프레임 구성

2010-09-13T21:55:42P

원문 : http://www.gamecode.org/tt/entry/1851

Present 호출후 대기 시간의 활용에 대한 부분입니다.

좋은 글 이네요.

#include <stdio.h>
#include <windows.h>

HANDLE g_hFlip, g_hRenderScene;

void _process()
{
static int cnt=0;
printf("process(%d)n", cnt++);
Sleep(500);
}

void _flip()
{
Sleep(500);
}

int g_done = 1;

DWORD WINAPI _flipper(void * ptr)
{
WaitForSingleObjectEx(g_hFlip, INFINITE, FALSE);
while(g_done) {
_flip();
SetEvent(g_hRenderScene);
WaitForSingleObjectEx(g_hFlip, INFINITE, FALSE);
}
return 0;
}

void _display()
{
static int cnt=0;
static int time = timeGetTime();

WaitForSingleObjectEx(g_hRenderScene, INFINITE, FALSE);

int delta = timeGetTime() - time;
time += delta;

printf("tdisplay (%d) %dn", cnt++, delta);

Sleep(500);

SetEvent(g_hFlip);
}

void main()
{
DWORD threadid;
int i;

g_hFlip = CreateEvent(NULL, FALSE, FALSE, NULL);
g_hRenderScene = CreateEvent(NULL, FALSE, TRUE, NULL);

CreateThread(NULL, 0, _flipper, 0, 0, &threadid);

for(i=0; i<5; i++) {
_process();
_display();
}

CloseHandle(g_hFlip);
CloseHandle(g_hRenderScene);
}

http://legendfinger.com/403

2010-07-21T17:59:01P

http://legendfinger.com/403

엔진 개발자 구인중

2010-06-12T13:24:03P

엔진 라이선스가 늘어남에 따라

개발자 구인이 필요해 졌습니다.

좋은 사람 없나요?

p.s. 신입도 상관 없어요. 누가 추천좀 해주세요~ 개발자분 모시면서 일 열심히 하겠습니다.

좋은 욕심.

2010-06-01T13:27:18P

사람은 누구나 욕심이 있다.

욕심이 없다던 사람도 마지막에 가서는 욕심을 보인다.

나는 그래서 욕심 없다는 말을 믿지를 않는다.

욕심을 내지 않는것이 좋다고는 생각 들지 않는다.

사람은 적당한 욕심을 부릴줄 아는 것 이 한걸음 성장하게 한다고 믿고 있다.

욕심을 부리되, 적당히 부리고, 상대방을 이용하거나 피해를 주는 행위를 하지 않는다면,

좋은 욕심이 아닐까?

어릴적부터 남에게 피해주지 않고 자라는걸 배워왔다. 오랫동안 몸에 배여서 그런지,

다른사람들도 당연히 남들에게 피해 안주려고 하나보다 라고 생각했다.

그런데 그렇지 못한 사람들이 너무 많다라....

상대방의 장점을 자기가 손해보지 않는이상 이용하려 드는.... 그런 하이에나 같은 사람들......

EPPEngine2.0 주요기능 정리

2010-04-13T17:21:41P

기능 전체라기 보다는 주요 기능들만 정리해 두었습니다.

Post Processing

HDR (높은 다이나믹 레인지를 바탕으로 실제 환경에서의 라이팅 효과를 모사 할 수 있다.)

Tone Mapping ( 빛의 세기를 기록하여, 동굴속 혹은 하늘을 바라봤을때의 동공의 움직임에 따른 빛의 받아들임을 모사 할 수 있다.)

SSAO ( 글로벌 라이팅 기술의 일종으로, 환경광 차폐에 따른 자연스러운 화면연출이 가능하다.)

SSGI ( 글로벌 라이팅 기술의 일종으로, 모든 오브젝트들이 빛을 반사한다는 계념으로 녹색 오브젝트가 벽 근처에 놓여졌을 때, 벽의 색이 녹색이 묻어나게 한다.)

DOF ( 카메라의 조리개를 표현한 것으로 조리개가 열렸을 때 초점을 맞은부분을 제외하고는 흐려지게 한다. )

Deferred / Inferred Rendering ( 지연렌더링으로 Forward 렌더링과 다른계념으로 이미지 단위의 라이팅 처리기술로써, 많은수의 라이팅을 보다 빠르게 처리한다.)

Bright Bloom Filter ( 화면에서 밝은 부분만 추출하여 Blur 처리함으로써 몽환적인 느낌을 나타낸다.)

2.5D Motion Blur (카메라 혹은 빠르게 움직이는 오브젝트의 표현을 자연스럽게 모사한다.)

Light Shafts ( 빛줄기 표현 , 대기에서 빛의 양을 모사하여 태양을 바라보는 상황이 아니더라도 빛줄기 를 표현.)

Effect

Particle System ( 아래의 여러가지 시스템들을 중첩하여 표현가능)

Soft Particle ( 입자들이 오브젝트와 중첩될 때 어색한 라인을 제거한다.)

Refract Particle ( 입자들을 외부 환경과 굴절시킨다. 예> 불에서 이글거림 표현 )

Distort Particle ( 입자에 사용될 텍스쳐를 외곡하여 표현한다. )

Screen Particle ( 입자를 화면전체에 덮는다. 예>FPS 에서 피격당했을 때 화면에 나타나는 표현)

Mesh Effect System

Effect Group System ( Mesh Effect 와 Particle 을 하나로 묶어 다양한 효과의 표현이 가능하다.)

Texture

Bump Maping

Specular Maping

Diffuse Maping

Opacity Maping

Parallax Maping

Parallax Occlusion Mapping

Offset Mapping

Light Mapping ( multi uv channel )

Font

Freetype library 를 활용한 고품질 폰트 렌더링을 지원, 특정 폴더의 폰트를 로드

Loading System

Zone 기반 Loading System ( 지역단위로 로딩처리)

Backgrounds Loading System (스래드를 활용하여, 작업 뒤쪽에서 로딩한다.)

Stream Loading System ( 매틱당 조금씩 로딩한다.)

Seamless Loading System ( 위의 로딩 시스템을 활용하여 최대한 끈김없는 로딩처리)

Multi Threading

XBOX360 의 트리플코어에 최적화된 멀티 스래딩 ( EPPENGIEN 1.0 에만 해당됨 /프로세스/렌더링/물리와 입력)

PC ( 코어수에 따른 멀티 스래딩 , OpenMP 를 활용한 스래딩처리 + 프로세스/렌더링/물리(physicX 자체 스래딩)/사운드(FMOD 자체 스래딩) 를 나누어 스래딩 처리)

Threading 작업시 별도의 코드수정이 필요하지 않으며, 단순히 엔진컴파일 만으로 자동으로 처리됨.

Material System

ShaderModel 2.0, ShaderModel 3.0 , ShaderModel 4.0 지원

Shader 를 자동으로 Parsing 하여 정보를 툴에 표현한다.

Material Editor 제공예정. ( Uber System + Visual Material Editor)

Animation

Vertex Animation ( LOD 지원 , Animation Blending 지원 )

Skeletal Animation ( LOD 지원 , Animation Blending 지원 , software / hardware skinning )

Sound

Fmod 를 활용한 다양한 Sound System 지원 (별도)

Physics

PhysicX 를 IPP 하여 PhysicX 의 각종 기능들을 사용 할 수 있음

Signal System

툴을 통해 에니메이션의 특정 프레임에 특정 시그널을 삽입하여 call back 형태로 정보를 자동으로 받을 수 있음.

Default Signal 제공 ( 사운드, 이펙트, 화면효과, 카메라 진동, 트레일 (칼 잔상표현등..) )

Object

Base Object ( Geometry + Texture ) *.eoj

Skin Object ( Base Object + Rendering + LOD( Bone Lod, Geometry Lod, Material Lod) + Physics ) *.skin

Entity Object ( Skin Object + Object Signal + Animation + Animation Signal ) *.eeo

World

Outdoor System ( Layer 쵀대 4개, Layer 별로 텍스쳐1장 범프맵1장 지원)

Seamless 지형 생성 ( 하나의 World 에 여러 개의 Outdoor 등록/편집 가능)

Ase or Obj 파일로 익스포트 가능 ( Max 를 통한 라이트맵 생성시 )

Indoor System ( BSP/PVS 를 통한 내부지형 생성, 임의 Potal 면 지정 가능)

World = OutDoor + Indoor (특정 Trigger 를 통해 OutDoor 과 연결가능)

Trigger System

Shadow

Single Shadow Map / Multi Shadow Map (Cascade Shadow System)

Depth shadow ( Self Shadow )

Projection Shadow

Volume Shadow ( Self Shadow )

C++ 개발자/게임개발자를 위한 VS2010 세미나 참가

2010-04-02T10:59:02P

저도 이 세미나를 들어볼까 해서 참가 신청을 했습니다.

그때 게임 개발자분들이라면 서로 인사도 하고 그랬으면 좋겠네요.

그럼 좋은하루 되시고, 가시는 분들 계시면 리플이라도 달아주세요.

거기서 같이 인사도 하고 점심도 먹고 하자구요. ^^

엔진사업을 위해서 새로운 사무실준비 완료.

2010-02-23T13:05:51P

구로쪽에 사무실을 하나 구입했습니다.

바로앞에 공원도 있고, 산책하기도 좋군요. 전경도 좋고...

다들 좋은 하루 되시고 복받으십시요.

저도 열심히 살야야 겠습니다. ^^