객체동산 꼬꼬마

사용자가 로그인 했을때의 처리는 크게 2가지로 나눌수가 있다.

1 . 사용자가 로그인을 했을때 세션에 그 사용자의 모든 정보를 저장해놓고 페이지가 이동할때마다 그 세션에 접근해서 사용자 데이타를 참조하느냐, 2. 아니면 사용자가 로그인 했을때 사용자의 아이디 값만 세션에 저장해놓은후
페이지가 이동될때마다 매번 db에 접근해서 필요한 정보를 뽑아 오느냐 크게 2가지로 나눌수가 있다.

나는 이때까지 전자의 방식만을 사용했는데 그이유는

1. 일단 편하다. 페이지 이동될때마다 쿼리를 날려서 db에 접근할 필요가없고, 단지 세션에만 접근하는것이다.
 2. 부하가 적다. 후자의 경우라면 매번 db를 왕복해야 하는데 이것에 드는 비용(resource)이 꽤나 클 것이다. 하지만 세션은 서버내의 data 를 저장하고 있는 변수이기때문에 훨씬 빠르다.

그런데 왜 그누보드에서는 후자의 방식으로 처리를 할까?

곰곰히 생각해봤는데, 후자의 방식에는 몇가지 이점이 있다

1. 로그인된 상태에서, 사용자의 정보가 변경될 경우(포인트가 증가되었다든가, 회원 연락처가 변경되었다든가) 아무런 추가 프로그래밍 필요하지않다. 페이지 이동시에 어차피 db에 접근할것이기 때문에, db로 부터 가져오는 데이타는 당연히 갱신된 정보일 것이다. 그러므로 추가적인 갱신 프로그래밍이 필요하지 않다는 것이다.
만약 전자였다면 사용자의 정보가 변경될때마다 이 변경된 사용자에 대응되는 모든 세션 정보를 갱신하는 코드를 새로이 추가해야 할것이다.(DB와 세션의 동기화) 이것은 상당히 귀찮은 작업이 될것이다. 대부분의 웹사이트에서 사용자의 변경은 상당히 자주 일어남을 고려할때 그누보드 방식이 개발자의 수고를 덜어준다는것을 알 수 있다.

2. 만약 웹서버가 해킹당한다면 어떻게 될까. 세션은 서버의 메모리에 저장되는 것이므로 웹서버가 해킹을 당한다면 세션또한 안전하지 않을것이다. 이 세션에 사용자의 비밀번호, 연락처, 주민번호 같은것들이 저장되어있다고 생각해보자.(전자의 방식) 상당히 위험하다. 하지만 후자의 방식으로, 즉 사용자의 아이디만 세션에 저장되어있는 상태라면 전혀 위험하지않을것이다. 사용자 아이디만 가지고 해커가 뭘 할수 있겠는가? 웹서버를 해킹했다고 DB 까지 접근 할 수는 없다. 그러므로 후자의 방식이 더 보안적인 측면에서 볼때 튼튼하다는 것이다.

이올린에 북마크하기(0) 이올린에 추천하기(0)

라이팅을 계산하는 방법에는 크게 두가지가 있는데

하나는 면(폴리곤) 마다 하나씩 NormalVector(법선벡터) 를 할당해줘서 면단위로 라이팅을 계산하는 방법과
또 하나는 정점(버텍스)마다 하나씩 NormalVector 를 할당해줘서 버텍스 단위로 라이팅을 계산하는 방법이다.

전자를 사용하면 명암이 폴리곤 단위로 입혀지므로 뚝뚝 끊겨있다는 느낌을 받을것이다
반면에 후자를 사용하면 DirectX 내부적으로 버텍스 사이에 보간을 해서(추측임) 라이팅이 부드럽게 나오도록 할 것이다.
 
CreateTeapt 같은 곡면이 있는 메쉬를 화면에 그려보면 라이팅(Diffuse)이 폴리곤의 경계를 구분할수 없을 정도로 아주 부드럽게 들어가있다는 것을 발견할 수 있다.

그럼 버텍스 마다 법선벡터를 어떻게 정의해야할까?
A라는 버텍스가 있다고할때, 이 A 버텍스를 공유하는 이 폴리곤들 각각의 법선벡터를 구한후 평균값을 버텍스 A의 법선벡터로 정하면 된다.(이 버텍스를 공유하고있는 폴리곤은 1개 일수도있고 2개일수도있고. 100개가 될수도있다.)

그렇다면 버텍스 마다 자신을 공유하고있는 폴리곤들을 어떻게 관리하지.?
버텍스당 매핑되는 polygons 라는 배열변수를 선언해서 폴리곤들의 인덱스값을 넣어놓는다든가 해서 초기에 한번 계산하고 메모리에서 해제해 버리는 방법을 생각하고있다(어차피 법선벡터는 한번 계산되어진후에는 다시 계산될 필요가없으므로)

이올린에 북마크하기(0) 이올린에 추천하기(0)

D3DXLoadHierachyMeshFromX() 함수를 사용할때

 HRESULT result = D3DXLoadMeshHierarchyFromX(L"mesh.X", D3DXMESH_MANAGED, m_device,
 m_allocator, NULL, &m_frameRoot, NULL);

보다시피 4번째 인자에 ID3DXAllocateHierarchy 를 구현한 객체를 하나 넘겨주게된다.
D3DXLoadMeshHierachyFromX 함수를 호출하면 m_allocator의 CrateFrame 메서드와 CreateMeshContainer 메서드를 호출하는데 여기서 CreateMeshContainer 를 호출할때 D3DXMESHDATA 의 포인터를 인자로 넘겨준다
CreateMeshContainer 메서드는 이 값을 받아서 일련의 처리를 하게되는데 다음과같다.

CreateMeshContainer(..... , D3DXMESHDATA *meshData , ... ,
                                LPD3DXMESHCONTAINER *refNewMeshContainer, ....)
{
   ....
   ....
    newMeshContainer.MeshData.pMesh = meshData.pMesh;
   *refNewMeshContainer = newMeshContainer;
}

이런식으로해서 함수의 종료부분에 새로만든 D3DXMESHCONTAINER 구조체의 포인터를 반환한다.
그런데 여기서 문제가 하나있다

CreateMeshContainer 함수가 종료된후에 pMesh 가 가리키고 있던 메모리가 해제되어버리는 일이 발생한다.
그렇게 되면 반환된 newMeshContainer 의 MeshData.pMesh 또한 쓰레기값이 되어버린다.

그럼 무엇이 문제일까.... 이거갖고 2시간은 고민했다..-ㅠ-;;

문제는 레퍼런스카운트 였다..

CreateMeshContainer 가 종료된후에 D3DXLoadHierarchyMeshFromX 함수는 자신이 넘긴 D3DXMESHDATA 의 pMesh 의 레퍼런스 카운트가 얼마인지 검사해서 증가되지않았다면 pMesh 가 가리키는 메모리를 해제해버리는것이다..(어디까지나 나의 추측이다) 그래서 pMesh 의 레퍼런스카운트를 증가해야하는데
바로이때 사용하는것이 pMesh.AddRef(); 이다. (ID3DXMesh 인터페이스에 AddRef 가 정의되어있다)
이 메서드는 프로그래머가 명시적으로 호출해줘서 pMesh 에 대한 레퍼런스카운트가 증가되었다는것을
D3DXLoadHierarchyMeshFromX 함수에 알려서 메모리 해제를 막는 기능을 할것이다.

수정된 코드는 아래와같다.

CreateMeshContainer(..... , D3DXMESHDATA *meshData , ... ,
                                LPD3DXMESHCONTAINER *refNewMeshContainer, ....)
{
   ....
   ....
    newMeshContainer.MeshData.pMesh = meshData.pMesh;
    meshData->pMesh->AddRef();
   *refNewMeshContainer = newMeshContainer;
}

이올린에 북마크하기(0) 이올린에 추천하기(0)