반응형

연산자 오버로딩의 경우에는 개인적으로는 구현을 해볼 일이 없었다.
엔진을 사용하기 때문에 기본적인 자료형들의 연산자들은 구현이 되어 있었기 때문이다.
최근에 연산자 오버로딩을 하는 부분을 본 것은 stream처리를 하는 부분을 추가할 때 정도였다.
개인적으로는 많이 사용하지는 않기 때문에 간략히 정리해보고자 한다.

항목5 - 사용자 정의 타입변환 함수에 대한 주의를 놓지 말자.

암시적 타입변환은 원하든 원하지 않든 컴파일러에 의해 자동으로 일어난다.
암시적 타입변환을 하는 함수는 두 가지가 있다.

단일 인자 생성자

template<class T>
class Array
{
  public:
    Array(int lowBound, int highBound);
    Array(int size);

    T& operator[] (int index);
    ...
}

bool operator == (const Array<int>& lhs, const Array<int>& rhs);

Array<int> a(10);
Array<int> b(10);

for (int i = 0; i < 10; ++i)
{
  if (a == b[i])
  {
  }
  else
  {
  }
}

a == b[i]는 오타가 나서 컴파일 에러가 나기를 원한다.
하지만 b[i]는 int 이므로 임시로 Array 생성자로 변환된다.

위와 같은 생성자에는 explicit를 넣어주자.

암시적 타입변환 연산자

class Rational
{
  public:
    ...
    operator double() const;
    ... 
}

Rational r;
double d = 0.5 * r;

cout << r;

<< 연산자를 구현하지 않았지만 동작을 한다!
원하는 결과는 아닐 수 있다.

컴파일 에러를 원한다.

이를 막기위해 암시적 타입변환 연산자를 제거하고 같은 기능을 하는 함수를 제공하자.
asDouble()과 같은 함수.

항목6 - 증가 및 감소 연산자와 전위, 후위 형태를 반드시 구분하자.

전위, 후위 증감 연산자는 인자를 넘기지 않는다.
그래서 약속된 형식이 아래와 같다.
후위 ++의 경우에는 숫자 0을 넘기는 식으로 구분하게 되었다.

class UPInt
{
  public:
    UPInt& operator++();                // 전위++
    const UPInt operator++(int);      // 후위++
    ...
}

UPInt& UPInt::operator++()
{
  *this += 1;
  return *this;
}

const UPInt UPInt::operator++(int)
{
  const UPInt oldValue = *this;
  ++(*this);
  return oldValue;
}

후위 연산자의 경우에 const를 리턴하지 않는 경우에는 i++++과 같은 이상한 문법이 가능해진다.
i.operator++(0).operator++(0); 과 같다.
그리고 oldValue와 같은 임시객체가 필요한것도 마음에 들지 않는다.
그렇기 때문에 가능하면 전위 연산자를 사용하도록 하자!
또한 구현의 일치성을 보장하기 위해 후위 연산자에서 위의 예제와 같이 전위 연산자를 호출 해주는게 좋다!

항목7 - &&, ||, 혹은 . 연산자는 오버로딩 대상이 절대로 아니다.

복잡한 조건을 검사할 때 단축처리가 가능하다.
가령 if ((p != 0) && (strlen(p) > 0)) 와 같은 조건이 있다면 p가 0(nullptr)이면 strlen()이 호출되지 않는다.

그런데 우리가 굳이 위의 &&, || 연산자를 재정의 한다면 위의 단축처리가 불가능하다.

if (expression1 && expression2)
-> expression1.operator&&(expression2)
-> operator&&(expression1, expression2)

둘 중의 하나로 해석될 것이기 때문이다.

즉 expression2가 실행이 된다는 이야기다.

, 연산자의 경우에도 마찬가지다.

항목8 - new, delete의 의미를 정확하게 구분하고 이해하자.

new 연산자의 동작

  1. 메모리 할당
  2. 객체의 생성자 호출

오버로딩할 수 있는 부분은 메모리를 할당하는 부분이다.

void* operator new(size_t size);

메모리 지정 new (placement new)

이미 할당된 메모리에 new 연산자를 사용할 수 있다.
예를 들면 new (buffer) Widget (widgetSize);

메모리를 받아서 객체를 생성해주는 기능을 만들때 사용하면 된다.

void* operator(size_t size, void* location);

#include <new>를 추가해주면 사용 가능하다!

delete 연산자의 동작

  1. 객체의 소멸자 호출
  2. 메모리 제거

  • 메모리 지정 new를 이용해 생성된 객체를 delete로 지우지 말자.
    • 메모리가 어디서 할당되었는지 모르기 때문이다.
    • 메모리 지정 new를 이용했다면 메모리 생성, 해제하는 기능이 어딘가 있을테니
    • 소멸자 호출 후에 이를 이용해 메모리를 해제해주자.

배열의 할당 해제

opearator new[], delete[]는 오버로딩 가능하기는 하지만
쉽지 않기 때문에 사용하지 않는게 좋겠다 ㅋㅋㅋ

반응형
Posted by msparkms
,
반응형

Recently, a university undergraduate asked me on twitter for advice on becoming a graphics programmer within the games industry. I wrote a fairly detailed email response and thought the information was good enough to make an article for AltDevBlogADay. This is all my personal opinion of course.


최근에, 한 대학교 재학생이 나에게 트위터로 게임 산업에서 그래픽스 프로그래머가 되기 위한 조언을 구했다. 나는 꽤 상세하게 이메일 답장을 적었고 이 정보가 아티클로 만들기 충분하다고 생각했다. 이것은 물론 모두 나의 개인적인 의견이다.

 

If you're at university, you should research whether there's a programme to do a summer or year long internship at a games studio. There was nothing like that when I was at the University of Liverpool '97-'00 (or I wasn't aware of it), but I've seen people come through that kind of programme with much greater practical game development knowledge and it goes a long way towards persuading an employer to take you on. EA, Lionhead and other large companies tend to run this sort of programme so look on their job pages too. Beware that sometimes companies don't respond to intern applications for various reasons (team is deep in crunch, budget spent elsewhere, etc) and places are extremely limited.


만약 당신이 대학교에 재학중이라면, 게임 스튜디오에서 하계나 일년동안 할 수 있는 인턴쉽 프로그램이 있는지 조사해야한다. 내가 리버풀 대학교에 1997년 부터 2000년까지 다녔을때는 그런게 없었다. (혹은 내가 몰랐을 수도 있다.) 그러나 나는 훨씬 더 실용적인 게임 개발 지식을 가진 프로그램을 통해 온 사람들을 보았고 고용주에게 당신을 뽑도록 하게 끔 한다. EA Lionhead나 다른 대기업은 그들의 구인 페이지에 이런 종류의 프로그램을 볼 수 있도록 하는 경향이 있다. 몇몇 회사들은 다양한 이유로(팀이 크런치 모드에 들어갔다던가 예산이 다른곳에 낭비되었던가 등등) 인턴을 뽑지 않을 수 있으니 주의하라. 그리고 자리도 매우 제한적이다.

 

Your best bet is to make a graphics demo, either on your own or with a small group of people. You learn more by doing than by just reading. Pick a modern graphics technique that interests you and implement it. Even better, do more than one. This is also great training for motivating yourself to get a project finished which is often the hardest part of games development, for all disciplines. Make sure you're prepared to talk in detail about the choices you made, performance (in milliseconds, not frames per second!), quality, alternatives and trade offs in a job interview.


당신의 가장 좋은 베팅은 혼자서 혹은 사람들과 작은 그룹을 만들어 그래픽스 데모를 만드는 것이다. 당신은 단지 읽는 것 보다는 해보는 것에 의해 더 많이 배울 수 있다. 당신이 관심있는 최신 그래픽스 테크닉을 하나 고르고 구현해봐라. 물론 하나보다 더 많이 하면 더 좋다. 이것은 또한 게임 개발의 모든 분야에서 종종 가장 어려운 부분이라고 여겨지는 하나의 프로젝트를 완료했다는 것에 대해서 스스로에게 동기를 주는데 훌륭한 연습이 된다. 당신은 잡 인터뷰에서 만든 것, 퍼포먼스(밀리 세컨드 단위, fps아니고), 퀄리티, 대안, 트레이드오프에 대해 당신이 선택한 부분에 대해서 자세하게 말할 준비를 확실히 하라.
 

When I was in university I did a straight computer science course - there were barely any games courses available back then, but I still think that employers still value computer science graduates above games graduates as there's a perception that you learn a greater range of software engineering skills. This could be a misconception though, as games courses are a lot better than they used to be, but you may have to fight your corner in an interview and prove you know your stuff (and not just the curriculum you were taught).


내가 대학교에 다닐때, 나는 컴퓨터 사이언스 과목을 들었다. - 거의 어떠한 게임 관련 과목도 가능한 게 없었다. 하지만 나는 여전히 고용주들이 컴퓨터 사이언스 졸업생을 게임과 졸업생보다 더 넓은 범위의 소프트웨어 엔지니어링 스킬을 배웠다고 인식하고 있기 때문에 더 가치있게 본다고 생각한다. 이것은 게임 과목들이 예전보다 많이 좋아졌기 때문에 오해일 수 있지만 면접을 볼때 맞써 싸워야 하는 부분이고 당신이 알고있는 것들을 증명해야만 한다. (당신이 배웠던 커리큘럼 뿐만 아니라)
 
Computer science courses also tend to be quite maths heavy (I would hope games courses are similar), which is vital for graphics programming. Make sure you understand homogeneous coordinates, matrix maths, dot products, cross products, quaternions, normal vectors, tangent bases, etc and how these things (and countless others) are useful for transforming and lighting geometry. Learn big O notation for algorithmic execution time, understand colour spaces, gamma correction, what high dynamic range means and so on. Learn some basic lighting models - Lambert, Phong, Blinn, etc.

컴퓨터 사이언스 과목은 또한 그래픽스 프로그래밍에 필수인 꽤 깊은 수준의 수학을 배우는 경향이 있다. (나는 게임 과목도 비슷할 거라고 희망한다.) 동차 좌표계, 행렬  수학, 내적, 외적, 쿼터니언, 노말 벡터, 탄젠트 기저 등등을 확실히 이해하고 있어야 하고 이것들(셀수 없이 많은 다른 것들도)이 어떻게 변환과 조명, 기하에 유용한지를 이해해야 한다. 알고리즘의 실행 시간을 위해 빅-O 표기법을 배우고 색상 공간, 감마 보정, HDR의 무슨 의미인가 등등을 배워야 한다. 몇가지 기본적인 조명 모델을 배워야 한다. - 램버트, 퐁, 블린 등등.

 

Software

In my experience, Visual Studio is pretty much universal as a code IDE (except for Apple, Linux, Android and Nintendo games), though you can of course use your favourite editor if you really want to, as long as you know Visual Studio. There is a free Express edition available from Microsoft (http://www.microsoft.com/express/Windows/), so it won't cost you any money to learn. The PS3 is a little different as there is a separate hardware specific debugger, but you should be able to learn that on the job.

소프트웨어
물론 당신이 정말 원한다면 당신이 가장 좋아하는 에디터를 사용할 수 있지만, 내 경험으로는 Visual Studio가 꽤 많이 세계적으로 사용되는 코드 IDE이기 때문에 (애플, 리눅스, 안드로이드, 닌텐도 게임을 제외하고) 적어도 Visual Studio는 알아두자. Microsoft에서 Express 버전은 무료로 사용가능하며 배우는데 어떠한 돈도 지불하지 않는다. PS3는 별도의 하드웨어 종속적인 디버거가 있어 조금 다르지만 직장에서 그것을 배울 수 있어야 한다.
 
You should be familiar with a source control system. Perforce (www.perforce.com) is a good choice as a lot of game studios use it and it's free for single users. Try to learn it on a project with other people as merging, branching and integration are good skills to have. With all source control systems, similar concepts apply so it's essential knowledge to have. Shockingly, my university course never mentioned source control and I was naive enough to believe that people just shared code over the network or on floppy disks.
 
당신은 소스 컨트롤 시스템에도 친숙해야만 한다. 퍼포스가 많은 게임 스튜디오에서 사용하기 때문에 하나의 좋은 선택이될 수 있고 개인 사용자에게 무료다. 머징, 브랜칭, 인티그레이션은 알아둬야 할 좋은 기술이므로 다른사람들과 함께 하나의 프로젝트를 통해 배우도록 노력해라. 모든 소스 컨트롤 시스템에는 유사한 컨셉이 적용되기 때문에 필수적인 지식이다. 놀랍게도 나의 대학 강의에서는 소스 컨트롤에 대해 전혀 언급하지 않았고 나는 사람들이 단지 네트워상으로나 플로피 디스크로 코드를 공유한다고 믿었었다.

As you're unlikely to have access to devkits at home or in university, you'll most likely be learning your skills on PC. In what may come as a surprise from someone with a decade's game development experience, I don't know much OpenGL as there's never been a pressing need for me to learn it. Most PC games use DirectX, though if you learn DirectX 11, make sure you also learn DirectX 9 as it's still current for Xbox 360 and many PC games still use it to support the dwindling, but still large Windows XP market. DirectX 10 is completely superseded by DirectX 11, so it is not worth learning (you can write DirectX 11 games for DirectX 10 hardware, and even DirectX 9 hardware).

집이나 학교에서는 개발킷에 접근할 수 없기 때문에 PC에서의 기술을 배워게 될 것이다. 십년간 게임 개발 경험을 가진 사람에게 놀라움으로 다가올만한게 나는 OpenGL을 배워야만 할 필요가 없었기 때문에 잘 모른다. 대부분의 PC게임은 DirectX를 사용하고 만약 DirectX 11을 배웠더라도 Xbox 360과 줄어들고는 있지만 윈도우 XP 시장이 여전히 크기 때문에 많은 PC 게임들이 여전히 DirectX9을 사용하고 있어서 배워야 한다. (하지만 번역중인 현재는 Window 10이 나왔기 때문에 DirectX 11로 봐도 될 듯 하다!) DirectX 10은 완전히 DirectX 11에 의해 대체되었기 때문에 배울 필요는 없다. (DirectX 10 하드웨어, 심지어 DirectX 9 하드웨어에서 돌리는 게임을 DirectX 11로 작성할 수 있다.)
 
It's also definitely worth learning a graphical debugger. PIX for Windows isn't as good as the Xbox 360 version, but there are fantastic free alternatives (Intel GPA - http://software.intel.com/en-us/articles/intel-gpa/, Nvidia Parallel Nsight - http://developer.nvidia.com/nvidia-parallel-nsight). These tools are not just for performance tuning on the GPU - they're also for debugging your draw calls, working out why something doesn't draw, why it looks wrong, and so on. You can also learn about how a GPU works as you can see all the renderstates, shaders, meshes, textures, etc for any draw call in a frame and really understand what the GPU is actually doing with the data you give it.

또한 그래픽 관련 디버거는 배울 가치가 있다. PIX for Windows는 Xbox 360 버전만큼 좋지 않지만 멋진 무료 대체 프로그램들이 있다. (Intel GPA, Nvidia Parallel Nsight) 이 툴들은 GPU상에 퍼포먼스 튜닝을 위한 것 뿐만 아니라 드로우콜, 왜 어떤것이 안 그려지는가, 왜 이상하게 보이는가 등등을 디버깅할 수 있다. 한 프레임 안의 어떠한 드로우 콜에 대해서 렌더 스테이트, 쉐이더, 메쉬, 텍스쳐등 모든것을 볼 수 있기 때문에 GPU가 어떻게 동작하는지에 대해서 배울수 있고 GPU가 당신이 보낸 데이터를 가지고 실제로 어떤 일을 하는지에 대해서 이해할 수 있게 된다.
 
Other Duties
As a graphics coder you'll probably have to do some tools work too, working with mesh compilers, animation compilers, plugins for Maya/3DS Max or in-house editors for the artists to use. Remember that your job is to provide technology to support the artists in their daily work, so it needs to be presented in a friendly manner. If you give your art team a tool that lets them tweak some coefficients of a fancy rendering algorithm and they have no idea what the numbers mean, they probably won't use it. Also, technical artists are your friends - they're the best people to talk about requirements for artists and to work out the best workflow for the content creators.

다른 의무들
그래픽스 개발자로서 당신은 또한 메쉬 컴파일러, 애니메이션 컴파일러, Maya/3DS Max 플러그인이나 아티스트가 사용하는 인 하우스 에디터와 같은 몇개의 툴들을 다룰 수 있어야 한다. 당신의 일은 아티스트들이 일상 업무를 지원해주기 위한 기술을 제공하는 것임을 기억하고 그들에게 친숙한 방식을 제공해야 할 필요가 있다. 만약 당신의 아트 팀에게 환상적인 렌더링 알고리즘을 위한 몇개의 계수 값을 바꾸기 위해서 하나의 툴을 제공한다면 그들은 그 숫자들이 의미하는 것에 대해 알지 못할 것이고 아마도 사용하지 못할 것이다. 물론 테크니컬 아티스트들은 여러분의 동료이다. - 그들은 아티스트들의 요구사항에 대해서 이야기할 수 있는 가장 좋은 사람이고 컨텐츠 생성을 위한 가장 좋은 워크플로우를 찾아낸다.

It's also good to learn general performance and optimisation techniques as this often falls to the graphics/engine team to do. You probably won't have to write any (or very little) raw assembler, but you ought to be familiar with what the C/C++ compiler is doing to your code, how to spot problems and what to do about them. For example, one of the biggest performance problem will be L2 cache misses (you lose hundreds of cycles per miss on all modern hardware), so learn techniques to reduce them (almost always changing the data, not the code is the fix).

또한 그래픽스/엔진 팀이 해야하는 일반적인 퍼포먼스, 최적화 기법을 배우면 좋다. 당신은 아마도 거의(혹은 매우 적게) 어셈블리어를 작성해야만 하지는 않을 것이지만 C/C++ 컴파일러가 당신의 코드를 어떻게 하는지, 어떻게 문제점을 발견하고 그것들에 대해서 무엇을 하는지에 대해서는 친숙할 필요가 있다. 예를들어 가장 큰 퍼포먼스 문제중 하나는 L2 캐쉬 미스 문제일 것이다. (모든 현대 하드웨어에서 미스당 수백 사이클을 잃어버린다.) 그것들을 줄이기 위한 기술을 배운다. (거의 항상 코드가 아닌 데이터를 변경하는 것으로 해결한다.)

 

Online Learning Resources

Online resources are a goldmine, and there's much better stuff out there than there was when I was at university as a lot of companies publish papers on their techniques which are pretty useful stuff. A few examples...

http://www.valvesoftware.com/company/publications.html

http://publications.dice.se/

Also there are a few good blogs posting regularly about graphics. A few good examples...

http://aras-p.info/blog/ - Lost in the Triangles. Aras Pranckevičius's blog (a lead programmer for Unity).

http://www.realtimerendering.com/blog/ - Real Time Rendering has good information (also the book is a worthwhile read!)

http://www.humus.name/ - Another good graphics programming blog.

온라인 강좌
온라인 리소스는 금광과 같고 내가 대학교에 다닐때 보다 훨씬 더 좋은 것들이 많다. 많은 회사들이 자신들의 기술에 대해서 매우 유용한 자료들을 공개하고 있다. 예를들어 위 링크와 같다.
또한 그래픽스에 대해 규칙적으로 포스팅 하는 좋은 블로그들이 몇개 있다.
위에 링크 참조!
 

Make sure you read the relevant presentations from GDC (very useful) and SIGGRAPH (slightly less useful as a lot of it is for non-realtime graphics, but useful as a crystal ball for future techniques).

My last handy tip is that if you live near a big dev studio, find out which pub they go drinking at after work and join in on a Friday night. You'll learn a lot just chatting with developers. You can also join twitter and talk to many games developers there who are willing to share their experience.


GDC(매우 유용한)와 SIGGRAPH (리얼타임이 아닌 그래픽스에 대해 더 많이 유용해서 약간 덜 유용하지만 미래의 기술들에 대해 수정구슬(?)과 같이 유용한) 관련있는 발표를 읽어라. 나의 마지막 유용한 팁은 만약 당신이 큰 개발 스튜디오 근처에 산다면 그들이 업무가 끝나고 술 마시러 가는 펍을 찾고 금요일 밤에 가라. 당신은 개발자과 많은 이야기를 나누며 배울 수 있을 것이다. 또한 트위터에 가입하고 그들의 경험을 기꺼이 공유해줄 많은 게임 개발자들과 이야기를 나누어라.

 

출처: <http://www.altdev.co/2011/05/10/so-you-want-to-be-a-graphics-programmer/>

반응형
Posted by msparkms
,
반응형

항목1 - 포인터와 참조자를 구분하자.


C언어에서 열심히 사용되던 포인터와 C++에서 포인터를 대신하기 위한 레퍼런스.

비슷하지만 다른 특징을 가진 두 가지 개념을 구분해서 사용하는 것이 이번 정리의 목적이다.

 

구분을 위해서는 각각의 특징을 정리해보자.

 

레퍼런스

  1. 클래스나 구조체의 값을 접근할 때 '.'연산자를 이용한다.

  2. NULL 값을 저장할 수 없다. ( 메모리 공간을 차지하는 객체를 참조해야 한다. )

  3. 선언될 때 반드시 초기화해야 한다. ( 한번 참조하면 다른 객체를 참조 할 수 없다. )

 

포인터

  1. 클래스나 구조체의 값을 접근할 때 '->'연산자를 이용한다.

  2. NULL 값을 저장할 수 있다.

  3. 값을 참조하려면 * 연산자를 붙여야 한다.

 

특징을 통한 사용법

  • 만약 내가 가리킬 객체가 NULL이 될 경우가 있는 경우에는 무조건 포인터를 사용해야 한다.

  • NULL이 되지 않을 것이 보장된다면 레퍼런스를 사용해도 된다.

  • 반대로 생각하면 포인터의 경우에는 NULL 값인지 체크를 해야 한다.

  • opeator[]를 리턴할때 포인터면 *을 붙여야 값에 접근할 수 있으니 이럴때는 레퍼런스를 사용하는게 이쁘다.


책에서 NULL값을 가진 포인터를 레퍼런스가 받거나 하는 극단적인 예제들이 나와있는데

현업에서 코드가 복잡할 때 함수 리턴값이나 인자값 혹은 컨테이너들을 이용하다 보면 실수가 있을 수는 있을 것 같다.

만약 이런일이 발생한 다면 크래쉬가 나서 덤프를 확인하면서 힘들게 고치거나 안전하게 스마트 포인터를 이용하자!





항목2 - 가능한 C++ 스타일의 캐스트를 즐겨 쓰자.


C 스타일의 캐스트에 비해서 C++ 스타일의 캐스트는 기능별로 세부적으로 나누어져 있는 편이다.

그렇기 때문에 필요에 맞게 C++ 스타일의 캐스트를 이용하면 실수를 줄일 수 있고 코드를 볼 때 더 명확하게 의도를 파악할 수 있다.

C++ 스타일 캐스트를 이용하는것이 확실히 더 좋아보인다.


대신에 정말 간단한 캐스트이고 명확한 경우에는 기존 C 스타일 캐스트를 이용해도 될 것 같기는 하다.

그래도 가능하면 C++ 캐스트를 이용하자.


C++ 캐스트 간단 설명  

  • const_cast

    • 상수성 (const) / 휘발성 (volatile)을 붙이거나 제거할 때만 사용한다.

  • dynamic_cast

    • 파생 혹은 형제 클래스로 캐스팅할 때만 사용한다. 

    • 가능하지 않으면 NULL을 리턴함으로 NULL 체크가 필요하다.

    • 가상함수가 있는 경우에만 가능하다.

  • static_cast

    • 상수성 / 휘발성 / 상속관계가 아닌 경우에만 사용한다.

  • reinterpret_cast

    • 예제상으로는 함수 포인터 캐스팅 정도에 사용한다고 나와있다.

    • C 캐스팅과 비슷한 느낌이라고 보면 된다.

    • 컴파일러마다 결과가 다를 수 있어서 코드 이식에 문제가 있을 수도 있다고 한다.


항목3 - 배열과 다형성은 같은 수준으로 놓고 볼 것이 아니다.

엄청 중요한 내용은 아니라서 간단히 정리하면...

부모클래스와 자식클래스가 있다고 할때 C++에서는 다형성을 통해

부모클래스 포인터에 자식클래스의 주소를 받을 수 있고 오버라이딩해서 사용할 수 있다.

부모클래스 배열에 자식클래스 인스턴스를 넘겼다고 하자.

이때 직접적으로 배열의 인덱스를 통해 접근한다거나

new []로 부모클래스 배열을 만들고 자식클래스 인스턴스의 주소를 넣고 delete []를 한다거나

하는 직접적으로 주소에 접근할 경우에 배열은 부모클래스의 사이즈만큼 이동할 것이기 때문에 예기치 않은 동작을 할 거라는 내용;;



항목4 - 쓸데 없는 기본 생성자는 그냥 두지 말자.

여기서 말하는 기본 생성자는 아무런 인자를 받지 않고 호출될 수 있는 생성자를 말한다.

초기화 리스트등을 이용해서 디폴트 초기값을 넣어두는 용도로 보통 사용한다.

근데 만약에 디폴트값을 정의할 수 없고 인자를 받아야지만 초기화 할 수 있는 객체라면 인자를 받는 생성자를 만들어줘야 한다.

이렇게 되면 객체를 생성할 때 인자를 넣어줘야 하기 때문에 생성부분의 코드가 살짝 복잡해진다.

class EquipmentPiece {
public:
    EquipmentPiece(int IDNumber);
    ....
};

위와 같은 객체가 있다고 했을 때 배열을 생성하면 조금 귀찮아진다.

EquipmentPiece bestPiece[10]; // error
EquipmentPiece bestPiece[] = 
{
  EquipmentPiece(0),
  EquipmentPiece(1),
  ...
}; // OK

EquipmentPiece* bestPiece = new EquipmentPiece[10]; // error

typedef EquipmentPiece* PEP;
PEP bestPiece[10];
for (int i = 0; i < 10; ++i)
{
  bestPiece[i] = new EquipmentPiece(i); // OK
}

포인터를 사용하는 것이 깔끔해 보이기는 하는데 포인터를 동적할당해야 해서 메모리를 더 쓰는 문제가 있다.

이를 막기 위해서 그냥 10개짜리 메모리를 할당한다음에 placement new 연산자를 이용해서 미리 잡아놓은 메모리에 객체를 생성하는 방법을 사용해도 된다.

이럴 경우에는 소멸자도 따로 호출해줘야 하고 메모리 해제도 해야되고 마찬가지로 귀찮아진다.

자세한건 다른 항목에 나오니 일단 패스...


다른 문제점은 템플릿으로 구현된 컨테이너의 경우에 기본 생성자만 지원되는 경우가 있을 수 있어서 이런 경우에도 사용하기 힘들다.


다른 생각해볼 점은 가상 기본 클래스를 만들 때 기본 생성자를 지원하지 않는 경우이다.

이럴 경우 상속받는 쪽에서 생성자를 제대로 이해하고 구현해줘야 하는 문제가 있다.

상속받아서 사용하는것 치고는 불편한 느낌이라 잘 설계되었다고 말할 수 없을 것이다.

class EquipmentPiece {
public:
    EquipmentPiece(int IDNumber = UNSPECIFIED);
    ....
private:
    static const int UNSPECIFIED;
};

신선하게 위와 같이 만들어 기본 생성자인척 하게 끔 만들었다고 해보자.

인자를 안 넣어도 UNSPECIFIED가 들어가 지기 때문에 위에 문제들은 모두 해결된다.

하지만 생성만 편해진거고 나머지 구현에서는 IDNumber가 UNSPECIFIED인가를 검사하는 부분들이 들어갈 것이기 때문에

전체적으로 보면 오히려 더 안 좋은 코드가 될 것이다.


그때 그때 다르겠지만...

생성자에서 인자를 받아야만 한다면 그냥 받는 쪽으로 구현하자 ㅠㅠ

반응형
Posted by msparkms
,
반응형



    출처: <http://gamasutra.com/blogs/OliverFranzke/20140718/221347/How_to_become_a_Graphics_Programmer_in_the_games_industry.php>


    As we were recently hiring a new Graphics Programmer at work I had to identify what kind of technical knowledge and skills we would expect from a potential candidate. Although this definition will be somewhat specific to what we look for in a candidate, it might still be of interest to other coders trying to score a job in the industry as a Rendering Engineer.
     

    최근에 새로운 그래픽스 프로그래머를 고용할 우리가 잠재적인 후보자로 부터 기대하는 기술적인 지식과 스킬을 가지고 있는가를 확인해야만 했다.  비록 정의가 한명의 후보자에게서 우리가 찾고자 하는 특정의 어떤것이기는 하지만 렌더링 엔지니어로써 산업에서 하나의 직업으로 점수를 얻고자 하는 다른 코더들에게도 흥미로울 이다.
     

    This post might help you to identify areas to learn about in order to get you closer to your goal of becoming a Graphics Engineer, whether you just finished your degree or perhaps have been working in the games industry in a different role. Alternately, if you are a seasoned Rendering Programmer, then you know all of this stuff and I would love to hear your comments on the topic.
     

    포스트는 당신이 학위를 마쳤든 아니면 다른 직업 군으로 게임 산업에서 일을 하고 있는 중이든 그래픽스 엔지니어가 되려는 당신의 목표에 가까워 지기 위해서 배워야 하는 영역을 배우는데 도움을 것이다.  반대로, 만약 당신이 숙련된 렌더링 프로그래머라면 당신은 내용의 모든 부분을 것이고 주제에 대해서 당신의 코멘트를 듣고 싶다.

     

    Know the Hardware
     

    Learning about the strengths and weaknesses of the hardware that will execute your code should be important for any programmer, but it's an essential skill for a Graphics Engineer. Making your game look beautiful is important; getting all of the fancy effects to run at target frame rate is often the trickier part.

     

    당신의 코드가 실행되는 하드웨어의 장점과 단점에 대해서 배우는 것은 어떤 프로그래머에게도 중요하지만 그래픽스 엔지니어에게는 필수적인 스킬이다. 당신의 게임을 아름답게 보이도록 만드는 것은 중요하다.  환상적인 이펙트들을 타겟 프레임 레이트에 모두 실행시키는 것은 보통 트릭키한 부분이다.

     

    Of course, it would be unrealistic to expect you to know every little detail about the underlying hardware (especially if you are just starting out) but having a good high-level understanding of what is involved to make a 3D model appear on screen is a mandatory skill, in my opinion. A candidate should definitely know about the common GPU pipeline stages (e.g. vertex- and pixel-shader, rasterizer, etc.), what their functionality is and whether or not they are programmable, configurable or fixed.

     

    물론 하드웨어 기초를 이루는 부분에 대해 모든 작은 디테일까지 당신이 안다고 기대하는것(특히 만약 당신이 이제 시작한 사람이라면) 비현실적이지만, 생각으로는 화면에 하나의 3D 모델이 표시되는데 연관된 것들에 대해 훌륭한 고수준의 이해는 필요한 스킬이다. 후보자들은 공통의 GPU 파이프라인 스테이지(예를 들어 버텍스, 픽셀 쉐이더, 레스터라이져 등등) 대해서 그것들의 기능이 무엇이고 프로그래밍 가능한지, 설정이 가능한지, 고정된건지를 분명하게 알아야만 한다.

     

    Very often, there are many ways to implement a rendering effect, so it’s important to know which solution will work best on a given target device. Nothing is worse than having to tell the artists that they will have to modify all of the existing assets, because the GPU doesn’t support a necessary feature very well.

     

    때때로, 렌더링 이팩트를 구현하는 방법은 많이 있어서 주어진 타겟 디바이스에서 가장 동작하는 솔루션이 무엇인지 아는 것이 중요하다. 아티스트들에게 GPU 필요한 기능을 지원해주지 않기 때문에 존재하는 어셋들의 모두를 수정해야만 한다 라고 말해야 하는 보다 최악인 것은 없다.

     

    For example, the game that I am currently working on is targeting desktop computers as well as mobile devices, which is important because mobile GPUs have very different performance characteristics compared to their desktop counterparts (check out my 5 minute micro talk on this topic if you are interested). Our team took this difference into account when making decisions about the scene complexity and what kind of effects we would be able to draw.

     

    예를 들어, 내가 현재 작업중인 게임은 데스크탑 컴퓨터 타겟으로 하고 있고 또한 모바일 디바이스를 타겟으로 하고 있다. 모바일 디바이스는 데스크탑에 있는 부분과 비교하여 매우 다른 퍼포먼스 특성을 가지고 있는 모바일 GPU 때문에 중요. (만약 관심이 있다면 토픽에 대해서 나의 5 마이크로 토크를 확인해봐라) 우리 팀은 씬의 복잡도와 우리가 그릴 있는 이펙트들의 종류를 결정할 차이점을 고려했다.

     

    A great way to learn more about GPUs is to read chapter 18 of Real-Time Rendering (Third Edition), because it contains an excellent overview of the Xbox 360, Playstation 3 and Mali (mobile) rendering architectures.

     

    GPU 대해서 많은 것을 배우는 좋은 방법은 Real-Time Rendering (3rd) 18번째 챕터를 읽는 것이다. 왜냐하면 여기에 Xbox 360, PS3, Mali (모바일) 렌더링 아키텍쳐의 훌륭한 오버뷰를 포함하고 있기 때문이다.

     

     

    Good Math Skills

     

    Extensive knowledge of trigonometry, linear algebra and even calculus is very important for a Graphics Programmer, since a lot of the day to day work involves dealing with math problems of varying complexities.

     

    나날이 가지각색의 복잡한 수학적 문제들을 다루는 것을 포함한 업무를 하기 때문에 삼각법, 선형대수학, 심지어 미적분의 해박한 지식은 그래픽스 프로그래머에게 매우 중요하다.

     

    I certainly expect a candidate to know about the dot and cross products and why they are very useful in computer graphics. In addition to that, it is essential to have an intuitive understanding for the contents of a matrix, because debugging a rendering problem can make it necessary to manually ‘decompose’ a matrix in order to identify incorrect values. For example, not that long ago I had to fix a problem in our animation system and was able to identify the source of the problem purely by looking at the joint matrices.

     

    나는 내적과 외적에 대해 알고 그것들이 컴퓨터 그래픽스에서 매우 유용한지를 아는 후보자를 기대한다. 추가적으로 행렬 개념에 대해 직관적인 이해를 가진 것은 필수다. 왜냐하면 렌더링 문제의 디버깅은 올바르지 않은 값을 식별하기 위해서 행렬을 수동적으로 분해하는 것을 필요로 할 수 있기 때문이다. 예를 들어, 얼마전에 우리 애니메이션 시스템의 문제를 해결해야만 했고 조인트 행렬을 살펴 보는 것으로 문제의 근원을 찾을 있었다.

     

    In my opinion, a candidate should be able to analytically calculate the intersection between a ray and a plane. Also, given an incident vector and a normal, I would expect every Rendering Engineer to be able to easily derive the reflected vector.

     

    생각에는 후보자는 광선과 평면 사이의 충돌을 분석적으로 계산할 있어야만 한다. 또한 입사 벡터와 노말이 주어졌을 , 나는 모든 렌더링 엔지니어들이 쉽게 반사 벡터를 구할 있다고 기대한다.

     

    There are plenty of resources available on the web. You can find some good resources here. The book "3D Math Primer for Graphics and Game Development" does a great job explaining a lot of the fundamentals like vectors, matrices and quaternions to name just a few topics. I would also strongly recommend attempting to solve some of these problems on a piece of paper instead of looking at a preexisting solution. It’s actually kind of fun, so you should definitely give it a try.

     

    웹상에 유용한 리소스들이 많이 있다. 당신은 여기서 몇몇개의 좋은 리소스들을 찾을 있을 것이다. 3D Math Primer for Graphics and Game Development 책은 몇가지 예를 들어 벡터, 행렬, 쿼터니언과 같은 많은 기초들에 대해 멋지게 설명해준다. 나는 또한 기존의 해답을 보는 대신에 종이에 문제들 일부를 풀어보기를 강력하게 추천한다. 이것은 실제로 재밌기도 하고 분명히 한번 해봐야 한다.

     

    Passion for Computer Graphics

     

    An ideal candidate will keep up to date with the latest developments in computer graphics especially since the field is constantly and rapidly advancing (just compare the visual fidelity of games made 10 years ago with what is possible today).

     

    이상적인 후보자는 특히 끊임없이 빠르게 발전하는 분야이기 때문에 최신의 컴퓨터 그래픽스 개발에 대해 최신 트렌드를 유지할 것이다. (단지 10년전 게임과 오늘날 있는 것들의 비주얼적인 정확함을 비교해보라.)

     

    There are plenty of fascinating research papers (e.g. current SIGGRAPH publications), developer talks (e.g. GDC presentations) and technical blogs available on the internet, so it should be pretty easy to find something that interests you. Make sure to check out the blogs of fellow Rendering Engineers for some really inspiring articles!

     

    매혹적인 논문들(예를 들어 최근 씨그래프에서 발행) 개발자들의 발표(예를 들어 GDC 발표) 그리고 인터넷 상에 유용한 기술적 블로그들이 많이 있다. 당신이 관심있어 하는 어떤 것이든 쉽게 찾을 있다. 몇몇개의 정말 감명 깊은 아티클들을 위해 렌더링 엔지니어 동료들의 블로그들을 확인해 봐라.

     

    Of course implementing an algorithm is the best way to learn about it, plus it gives you something to talk about in an interview. Writing a cool graphics demo also helps you to practice your skills and most of all it is a lot of fun.

     

    물론 알고리즘을 구현하는것은 그것을 배우는 가장 좋은 방법이다. 추가로 면접때 이것에 대해 말할거리도 준다. 멋진 그래픽스 데모를 작성하는 것은 또한 당신의 스킬을 연습하는데 도움을 주고 무엇보다도 재밌다.

     

    If you want to maximize your chances of getting a job make sure to spend some time making your demo look pretty. You may have implemented the most efficient tessellation algorithm, but if people can't see what's going on they might not be as impressed as they should be. Creating visually pleasing images is a big part of the profession, so it's generally a good idea to show that you have this skill as well.

     

    만약 취직의 기회를 최대로 높이길 원한다면 당신의 데모가 예뻐 보이도록 만드는데 시간을 사용해야만 한다. 당신이 가장 효과적인 테셀레이션 알고리즘을 구현했지만 만약 사람들이 무슨 일인지 알지 못한다면 감명을 받았어야 만큼 받지 못할 것이다. 시각적으로 만족을 주는 이미지를 만드는 것은 프로의 부분이고 또한 일반적으로 당신이 가진 스킬을 보여주는 좋은 아이디어다.

     

    Performance Analysis and Optimization

     

    One of the responsibilities of a Graphics Programmer is to profile the game in order to identify and remove rendering related bottlenecks. If you are just starting out I wouldn’t necessarily expect you to have a lot of practical experience in this area, but you should definitely know the difference between being CPU and GPU bound.

     

    그래픽스 프로그래머의 책임중 하나는 렌더링과 관련된 보틀넥을 찾고 없애기 위해서 게임을 프로파일링 하는 것이다. 만약 당신이 시작하는 사람이라면 당신이 분야에서 많은 실용적인 경험을 가지는게 필수라고 기대하지는 않는다. 하지만 CPU GPU 바운드 사이의 차이점을 분명하게 알아야만 한다.

     

    An ideal candidate will have used at least one graphics analysis tool like PIX (part of the DirectX SDK), gDEBugger or Intel’s GPA. These applications are available for free allowing you to take a closer look at what’s going on inside of a GPU, isolate bugs (e.g. incorrect render-state when drawing geometry) and identify performance problems (e.g. texture stalls, slow shaders, etc.)

     

    이상적인 후보자는 적어도 하나의 PIX(DirectX SDK 포함되어 있음),  gDEBugger, Intel's GPA 같은 그래픽스 분석 툴을 사용할 있을 것이다. 어플리케이션들은 무료로 GPU 내부가 어떻게 동작하는지 가까이 있도록 해주고 버그들을 격리 시키고 (예를들어 지오메트리를 그릴 잘못된 렌더 스테이트) 퍼포먼스 문제(텍스쳐 스톨, 느린 쉐이더 등등) 식별할 있게 해준다.

     

    Conclusion

     

    The job of a Graphics Programmer is pretty awesome since you’ll be directly involved with the visual appearance of a product. The look of a game is very often the first thing a player will know about it (e.g. trailers, screenshots) which has been very gratifying for me personally.

     

    그래픽스 프로그래머의 잡은 제품의 시각적 외향에 직접적으로 참여하게 되면 멋지다.  게임의 외형은 때때로 플레이어에게 개인적으로 나에게 매우 기쁨을 준다는 것에 대해 처음으로 알게 해준다. (예를들어 트레일러나 스크린샷)

     

    Truth be told, you won’t be able to write fancy shaders every day. You should be prepared to work on other tasks such as: data compression (e.g. textures, meshes, animations), mathematical and geometry problems (e.g. culling, intersection computations) as well as plenty of profiling and optimizations. Especially, the latter task can be very challenging since the GPU and the associated driver cannot be modified.


    사실대로 말하자면 당신은 매일 환상적인 쉐이더를 작성할 수는 없다. 당신은 데이터 압축 (예를들어 텍스쳐, 메쉬, 애니메이션), 수학적이고 기하학적인 문제들(컬링, 충돌 계산), 또한 많은 프로파일링과 최적화와 같은 다른 작업들도 준비가 되어 있어야만 한다. 특히 후자의 일이 GPU 관련된 드라이버들은 수정할 없기 때문에 매우 도전적일 있다.

     

    To sum up, becoming Rendering Engineer requires a lot of expert knowledge, and it is certainly not the easiest way to get a foot in the proverbial games industry door, but if you are passionate about computer graphics it might be the right place for you!

     

    요약하자면 렌더링 엔지니어가 되는 것은 많은 전문적인 지식이 필요하고 유명한 게임업계의 문안에 발을 들이는 가장 쉬운 방법은 분명하게 없다. 하지만 만약 당신이 컴퓨터 그래픽스에 대해 갈망을 가지고 있다면 그것이 당신을 올바른 위치에 있게 것이다.

     

    The Beginner's Checklist


반응형
Posted by msparkms
,
반응형


png파일을 dds로 변환할 필요가 생겨서 검색해 보니 nvdxt라는 유틸리티가 있다는 것을 알게되었다.


https://developer.nvidia.com/legacy-texture-tools


legacy texture tool이라니... ㅎㅎ


nvdxt.exe를 이용해 쉽게 모든 폴더의 png를 변환하기 위해 다음과 같은 배치파일을 작성해서 테스트해보았다.


for /D %%d in (*) do (

  cd %%d

  nvdxt.exe -file *.png -quality_highest -dxt5 -nomipmap -overwrite

  cd ..

)


간단 설명


-file *.png : 모든 PNG 파일을 변환해라.

-quality_highest : 최상급의 퀄리티로 뽑아라.

-dxt5 : dxt5 포맷으로 뽑아라.

-pre_modulate : PremultipliedAlpha를 적용하려면 이 옵션을 설정하자.

-nomipmap : 밉맵을 생성하지 않는다. (생성하려면 -mipmaps 2 였던가?? 물론 width / height가 2의 승수여야 한다.)

-overwrite : 기존에 파일이 있으면 덮어쓴다.



이상적인 결과를 얻기 위한 옵션은 계속 실험을 통해 찾아봐야 될 것 같다. ㅠㅠ

반응형
Posted by msparkms
,

SSAO

프로그래밍 2015. 1. 15. 15:45
반응형



예전에 SSAO에 대해서 정리했던 PT를 올려본다.


네이버 카페에 SlideShare PT가 바로 올라가지 않기 때문에 (Chrome에서 안 보이는 문제...) 블로그에서 잘 올라가나 테스트 해보고 


카페에는 링크를 올리는 식으로 해보기 위해서 테스트 삼아 올려본다!




반응형
Posted by msparkms
,
반응형




작업중에 특정 상수값이 설정되길래 언제 그 값이 설정되나 보려고 했는데 그 설정되는 함수가 워낙 많이 불려서 


Breakpoint를 걸어서 작업하기가 힘들었다.

예전같으면 이 함수안에다가 if문을 넣어서 특정 상수면을 체크한다음 Breakpoint를 걸면 되었지만 

요즘에는 VisualStudio에서 해당 기능을 제공해준다.


- 사용 방법 -


1. 일단 원하는 곳에 Breakpoint를 건다.

2. Breakpoint를 건 라인에서 마우스 오른쪽 버튼을 누른다.

3. Breakpoint 메뉴를 누른다.

4. Conditions를 누른다.

5. 원하는 조건을 넣어준다. (Is true를 선택하면 그 조건에 걸리고 Has changed를 선택하면 변경되었을 때 걸리는듯 하다.)



이것말고도 Breakpoint 메뉴를 보면 다양한 기능을 제공해준다.

- Breakpoint를 건 위치를 확인

- 몇번 Breakpoint가 Hit 되었는지 감지하고 처리

- 특정 프로세스나 스레드에서는 안 걸리도록 Filter를 추가

- Breakpoint가 걸렸을 때 특정 메시지나 매크로를 동작






반응형
Posted by msparkms
,
반응형


기존에 있던 DB 스키마를 분석하면서 DB쪽 관련된 명령어 부분을 잘 모르는 것 같아서 간단히 정리해 보았다.


주석 관련


-- 한줄 주석


/*

블록주석

*/


USE [데이터베이스 네임] -> 사용할 DB를 지정, 이 명령어 후 쿼리문은 해당 DB에 적용된다.


SELECT 열 이름 FROM 테이블명 -> 해당 테이블에서 해당 열을 가져온다.


ex) SELECT * FROM MSPark.Test -> Test에 있는 모든 열을 가져온다.

ex) SELECT id, pwd FROM MSPark.Test -> Test에 있는 id, pwd 열을 가져온다.

ex) SELECT id as 아이디, pwd '비밀번호', [직업] = job FROM MSPark.Test -> Test에 있는 id, pwd, job 열을 가져온다.

-> 표시될 때 id는 아이디로 pwd는 비밀번호로 job은 직업으로 변경되서 나온다.


GO -> 쿼리문을 실행한다.


SET ANSI_NULLS (ON / OFF) -> ON : 해당 열에 NULL이 있어도 가져오지 않는다.

                                               OFF : 해당 열에 NULL이 있으면 그 열을 가져온다.


SET QUOTED_IDENTIFIER (ON / OFF) -> ON : 식별자를 구분할 때 쌍따옴표와 대괄호만 가능하다. 리터럴 문자열은 홑따옴표만 가능하다.

                                                           OFF : 식별자를 구분할 때 대괄호만 가능하다. 리터럴 문자열은 홑따옴표, 쌍따옴표만 가능하다.


CREATE TABLE [테이블명] (                -> 해당 테이블명의 테이블을 만든다.

[추가할 열의 이름] [타입] [조건]    -> 해당 테이블에 해당 열을 추가한다.

) ON [파일그룹명]                               -> 해당 테이블을 해당 파일 그룹에 만든다.


ex) CREATE TABLE [dbo].[Test] (       -> dbo.Test 테이블이 생성된다.

[ID] [varchar](32) NOT NULL,        -> 32자 문자열인 ID 열이 생긴다. NULL은 들어갈 수 없다.

[PWD] [varchar](32) NOT NULL     -> 32자 문자열인 PWD 열이 생긴다. NULL은 들어갈 수 없다.

) ON [PRIMARY]                                -> 기본적으로 존재하는 PRIMARY 파일 그룹에 생성된다.


* IDENTITY(시작번호, 증가량) -> 시작번호부터 시작하여 증가량만큼 거진다.


ex) [NO] [int] IDENTITY(1,1) NOT NULL -> NO는 1부터 시작해서 1씩 커진다.


* CONSTRAINT : 제약 조건

  PRIMARY KEY 제약 조건 -> 기본키 설정

  FOREIGN KEY 제약 조건

  UNIQUE 제약 조건

  CHECK 제약 조건

  DEFAULT 정의 -> 기본적으로 들어가는 값 정의

  Null 값 허용


* 기본적으로 B-Tree의 구조로 Indexing을 처리함


Clustered Index -> 테이블당 한 개만 생성 가능

   인덱스로 지정한 열에 맞춰서 자동 정렬

   Primary Key로 지정되면 자동으로 Clustered Index 생성

   Primary Key나 Unique와 같이 중복되지 않는 제약 조건에 한해서 생성

   생성할 때 데이터 페이지 전체를 다시 정렬

   기존에 대용량 데이터가 입력된 상태면 심각한 시스템 부하를 줄 수 있음

   인덱스 자체의 리프 페이지가 데이터 자체

   검색속도는 더 빠르지만 입력/수정/삭제는 더 느리다. 


Nonclustered Index  -> 테이블당 여러 개 생성 가능

                                  생성할 때 데이터 페이지는 그대로 두고 별도의 페이지에 인덱스만 구성

                                  인덱스 자체의 리프 페이지는 데이터가 위치하는 포인터다.

                                  검색은 더 느리지만 입력/수정/삭제는 더 빠르다.

                                  남용할 경우 시스템 성능이 떨어질 수 있음


CREATE UNIQUE 옵션 CLUSTERED INDEX [인덱스명] ON [테이블명]

CREATE UNIQUE 옵션 NONCLUSTERED INDEX [인덱스명] ON [테이블명]

(

[열 이름] ASC or DESC

)

INCLUDE 옵션

WHERE 옵션

WITH 옵션

ON 파일 그룹 옵션

FILESTREAM_ON 옵션


* WITH 옵션 -> PAD_INDEX = {ON | OFF} -> 인덱스 페이지에 여유를 얼마나 두겠는가? (ON이면 아래 fillfactor만큼 적용)

                      FILLFACTOR = fillfactor

    SORT_IN_TEMPDB = {ON | OFF} -> 인덱스를 생성할때 임시 파일을 이용함

    IGNORE_DUP_KEY = {ON | OFF}

    STATISTICS_NORECOMPUTE = {ON | OFF}

    DROP_EXISING = {ON | OFF}

    ONLINE = {ON | OFF} -> 인덱스 생성 중에도 기본 테이블의 쿼리 가능

    ALLOW_ROW_LOCKS = {ON | OFF} -> 인덱스에 접근할 때 행 수준의 잠금을 허용

    ALLOW_PAGE_LOCS = {ON | OFF} -> 인덱스에 접근할 때 페이지 수준의 잠금을 허용

    MAXDOP = maxdop -> 인덱스 생성에 사용할 CPU 개수 강제 지정

    DATA_COMPRESSION = {NONE | ROW | PAGE} -> 압축 관련

    ON PARTITIONS 


반응형

'프로그래밍' 카테고리의 다른 글

SSAO  (0) 2015.01.15
Breakpoint Condition 기능 활용  (0) 2013.08.27
Bullet Helper 클래스  (0) 2012.11.26
warning LNK4099 해결방법  (0) 2012.10.06
Visual Studio Property Sheets를 이용해서 공통된 속성 관리하기  (0) 2012.10.04
Posted by msparkms
,
반응형



Bullet을 Direct3D로 연동시키기 위해서는 Vector, Quaternion, Matrix 값들을 각자에 맞게 연결시켜줘야 한다.


Bullet 엔진을 통해서 물리 연산을 한 뒤 해당 객체의 위치와 회전값을 얻어와서 Direct3D에 적용해 렌더링 해줘야 하고 클라이언트에서 특정 값을 적용시킬때 사용된다.


편하게 사용하기 위해서 만든 툴킷 객체이다.


#pragma once

#pragma warning(push)
#pragma warning(disable : 4127)
#include "btBulletDynamicsCommon.h"
#pragma warning(pop)

class CMSBulletHelper
{
public:
    static D3DXVECTOR3             BT_TO_DX_VECTOR3(const btVector3& vector);
    static D3DXQUATERNION       BT_TO_DX_QUATERNION(const btQuaternion& quaternion);
    static D3DXMATRIX               BT_TO_DX_MATRIX(const btMotionState& motionState);
    static D3DXMATRIX               BT_TO_DX_MATRIX(const btTransform& transform);

    static btVector3                    DX_TO_BT_VECTOR3(const D3DXVECTOR3& vector);
    static btQuaternion               DX_TO_BT_QUATERNION(const D3DXQUATERNION& quaternion);
    static btTransform                DX_TO_BT_TRANSFORM(const D3DXVECTOR3& pos, const D3DXVECTOR3& rot);
    static btTransform                DX_TO_BT_TRANSFORM(const D3DXVECTOR3& pos, const D3DXQUATERNION& rot);
};



#include "DXUT.h"
#include "MSBulletHelper.h"

D3DXVECTOR3     CMSBulletHelper::BT_TO_DX_VECTOR3(const btVector3& vector)
{
    return D3DXVECTOR3(vector.x(), vector.y(), vector.z());
}

D3DXQUATERNION  CMSBulletHelper::BT_TO_DX_QUATERNION(const btQuaternion& quaternion)
{
    return D3DXQUATERNION(quaternion.x(), quaternion.y(), quaternion.z(), quaternion.w());
}

D3DXMATRIX      CMSBulletHelper::BT_TO_DX_MATRIX(const btMotionState& motionState)
{
    btTransform worldTransform;
    motionState.getWorldTransform(worldTransform);

    return BT_TO_DX_MATRIX(worldTransform);
}

D3DXMATRIX      CMSBulletHelper::BT_TO_DX_MATRIX(const btTransform& transform)
{
    btQuaternion           rotation    = transform.getRotation();
    btVector3                origin       = transform.getOrigin();

    D3DXQUATERNION   rot        = BT_TO_DX_QUATERNION(rotation);

    D3DXMATRIX          matTrans;
    D3DXMATRIX          matRot;
    D3DXMATRIX          matWorld; 

    D3DXMatrixTranslation(&matTrans, origin.x(), origin.y(), origin.z());
    D3DXMatrixRotationQuaternion(&matRot, &rot);
    D3DXMatrixMultiply(&matWorld, &matRot, &matTrans);

    return matWorld;
}

btVector3       CMSBulletHelper::DX_TO_BT_VECTOR3(const D3DXVECTOR3& vector)
{
    return btVector3(vector.x, vector.y, vector.z);
}

btQuaternion    CMSBulletHelper::DX_TO_BT_QUATERNION(const D3DXQUATERNION& quaternion)
{
    return btQuaternion(quaternion.x, quaternion.y, quaternion.z, quaternion.w);
}

btTransform     CMSBulletHelper::DX_TO_BT_TRANSFORM(const D3DXVECTOR3& pos, const D3DXVECTOR3& rot)
{
    btVector3         origin  = DX_TO_BT_VECTOR3(pos);

    btTransform     transform;

    transform.setIdentity();
    transform.getBasis().setEulerZYX(rot.x, rot.y, rot.z);
    transform.setOrigin(origin);

    return transform;
}

btTransform     CMSBulletHelper::DX_TO_BT_TRANSFORM(const D3DXVECTOR3& pos, const D3DXQUATERNION& rot)
{
    btVector3         origin       = DX_TO_BT_VECTOR3(pos);
    btQuaternion    rotation    = DX_TO_BT_QUATERNION(rot);

    btTransform     transform;

    transform.setIdentity();
    transform.getBasis().setRotation(rotation);
    transform.setOrigin(origin);

    return transform;
}


반응형
Posted by msparkms
,
반응형









http://undergraduate.csse.uwa.edu.au/units/CITS4241/Project/references/Lorensen-Cline-brief.pdf

http://www.ia.hiof.no/~borres/cgraph/explain/marching/p-march.html

http://www.me.berkeley.edu/~mcmains/290D/s08MarchingCubes.pdf


http://procworld.blogspot.kr/2010/11/from-voxels-to-polygons.html

http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html

http://www.oocities.org/tzukkers/isosurf/isosurfaces.html

http://www.geisswerks.com/about_terrain.html

반응형
Posted by msparkms
,