'컴퓨터:Computer/프로그래밍:Programing'에 해당되는 글 21건 RSS Icon ATOM Icon

  1. 2009/02/03 음... (2)
  2. 2009/01/16 HV3 Decoder 1.0 (37)
  3. 2008/07/13 중간 보고 (3)
  4. 2008/07/10 근황 (2)
  5. 2008/07/04 오늘의 교훈
  6. 2008/06/26 스레드를 이용한 윈도우에서의 선형 프로그래밍 (1)
  7. 2008/05/29 스마트 포인터/참조 횟수 관리자 적용
  8. 2008/05/13 으리얍! 나는 카우보이 프로그래머다
  9. 2008/05/06 도구를 만들 때 (3)
  10. 2008/04/28 뭐라도 좀 보면서.... (3)

음...

컴퓨터:Computer/프로그래밍:Programing RSS Icon ATOM Icon 2009/02/03 22:53 posted by 정기
견과류

Nut


또 갈아 엎었다.

자꾸 갈아 엎게 되어서 이젠 아예 한 번에 만들 생각은 접어버리고 프로토타입 완성으로 목표를 바꿨다.

처음의 계획대로 모든 것이 추상화되고, 자료 주도적(data-driven)으로 돌아가게끔 만드는 것이, 생각보다 그렇게 무리는 아니었나보다. 갖은 아이디어들이 떠오르고, 아이디어들을 설계에 반영하여 의외로 순조롭게 진행되어가고 있긴 하니까 말이다.

지금까지 갈아 엎고 다른 것들을 참고하면서 많은 것을 배웠다. 특히나 다양한 방면으로 접근하여 사고하는 법이라던가, 의식하지 못했던 고정관념들을 의심하여 타파하는 것, 하지만 그럼에도 불구하고 새롭지 않더라도 기존의 것이 나쁜 것이 아니다라는 것 등등..

대기만성, 그릇이 크면 늦게 찬다는데, 대체 내가 바라는 건 과연 큰가 싶기도 하고, 언제 끝날까 싶기도 하다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2009/02/03 22:53 2009/02/03 22:53
HV3 포맷의 파일을 읽어내는 프로그램.

주의 사항
꿀뷰의 제작자의 의도를 존중하여 사적 복제를 위한 용도로만 사용하셔야 합니다. 그 외의 경우에는 사용을 금합니다. 이 프로그램을 사용하는 것은 명시된 주의 사항을 숙지하였음과 이에 충실히 따를 것에 동의함으로 간주됩니다.

용법
hv3dec.exe 파일 경로
혹은
단독 실행 (파일 열기 대화창으로 파일 지정)
으로 사용이 가능하며 파일 이름으로 된 폴더가 생겨, 그 안에 파일들이 풀림.
관련 법규 : 저작권법 제27조 (사적이용을 위한 복제) 공표된 저작물을 영리를 목적으로 하지 아니하고 개인적으로 이용하거나 가정 및 이에 준하는 한정된 범위 안에서 이용하는 경우에는 그 이용자는 이를 복제할 수 있다.
"본인은 위 사항들을 충분히 숙지하였기에 다운로드합니다."
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2009/01/16 23:25 2009/01/16 23:25
TAG

일단은 삼각형으로...


게임 만들려고 엔진 만든답시고 설친지 벌써 3개월이 넘었다.

장면 그래프 구조 설계,
렌더링 시스템 설계,
셰이더의 추상화

등등등 그동안 생각해온 것은 정말 많았다.

위 화면은,
장면 그래프를 이용해서 루트 노드에 카메라와 삼각형을 붙인 다음에 렌더링 한 것이다.
위 삼각형은 하드웨어 정점 버퍼를 이용하여 렌더링했다.

얼마 진행도 안됐는데 벌써부터 hack 코드가 몇 개가 있다.

심사숙고해서 설계했지만, 여전히 비직관적이고 OOP의 장점을 제대로 살리지 못한 부분이 많다.


개인적으로 보기에, 카메라의 개체로의 추상화가 그나마 제일 잘한 듯 싶다.
메세지 펌프를 다른 스레드로 분리한 것도 나름 잘하지 않았나 싶다. 물론 아직은 hack 코드로 구현 중이지만 하루 날 잡아서 깔끔하게 완성해야겠다.

단점은 너무 많으므로 적을 수가 없다....;


Ogre나, Irrlicht 등의 공개 엔진들을 접해보고 이 엔진들이 불필요하게 너무 복잡하게 설계되어 있음을 깨닫고 직접 만들기 시작했으나, 어쩔 수 없는 것(당연한 것)이었는지 똑같이 복잡해져가고 있다. 결론은 얼마나 직관적으로 만드냐에 달려있는 것 같다(예를 들어, 빛 반사 상수, 텍스쳐, 셰이더 등을 재질이라는 개념으로 추상화).
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/07/13 21:07 2008/07/13 21:07

근황

컴퓨터:Computer/프로그래밍:Programing RSS Icon ATOM Icon 2008/07/10 22:45 posted by 정기
열악한 작업 환경

열악한 작업 환경 : P3 900Mhz / PC100 256MB


설계 컨셉이 대략적으로 잡힌 뒤로 설계의 속도가 가속화됐다.

구현도 점점 빨라지고 있으니,

리팩토링 몇 번만 거치면,

곧 나쁘지 않은 녀석이 나올 것 같다.


재질을 어떻게 생각하고, 어떻게 다룰지에 대해서 고민을 해야겠다.

셰이더도 재질로 분류해야 할까? 그냥 GPU 프로그램으로 분류해야 할까?

여러가지 고민을 할 게 너무 많다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/07/10 22:45 2008/07/10 22:45
해보지도 않고 지레 짐작만 하고서 삽질하기를 두려워하지 말지어다.
2008.07.04 JK
32비트 단정도 부동소수점형의 정밀도 한계로 원점에서부터 멀리 떨어진 물체를 변환할 때

애니메이션이 떨린다든가, 메시의 틈이 벌어진다고 한다.

그래서 GPG 4권을 참고해서 열심히 세그먼트가 적용된 위치와 변환을 엔진에 통합시켜고 애썼는데,

만들다보니 필요성의 검증이 필요한 것 같아서, 정밀도 테스트를 해봤다.


그런데 200,000.0f 정도에서도 그런 현상은 잘 보이지 않았다.
(시야 행렬, 투영 행렬을 따로 설정했을 때에도)

근데 어차피 100.000.0f 이상으로 쓸 일이 없으니, 그냥 원점으로 돌아가자.


(괜히 뻘짓했네 시밤)
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/07/04 19:55 2008/07/04 19:55
이라고는 거창하게 적었으나 별 거 없다..;
그저 윈도우 메세지 루프를 별도의 스레드로 뺐을 뿐이다.

여기서 중요한 점은 무작정 루프만 뺐다간 굉장히 삽질하게 될지도 모른다.
나도 그렇게 했다가 몇 시간만에 겨우 원인을 찾을 수 있었다.

아무리 해도 메세지 프로시저가 안돌아가고 그냥 멈춰버리는 것이었다.
처음엔 DLL로 메세지 루프를 뽑아내서 그런 줄 알아서,
인스턴스 핸들을 이리저리 바꿨지만 별 소득이 없었다.

결국 MSDN 포럼에서 답을 찾을 수 있었다.

'윈도우를 생성하는 스레드와 메세지 펌프가 돌아가는 스레드는 동일한 스레드이어야 한다.'
오 쉿...
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/06/26 23:27 2008/06/26 23:27
참조 횟수 관리자 클래스인 NutCount와 스마트 포인터인 NutPtr를 적용했다.

별로 유별난 건 없고, 통상의 intrinsic pointer과 똑같은 개념이다.

기본적인 것들은 전부 구현했는데, 캐스팅 연산자를 어떻게 해줘야 할까 고민하다가 intrinsic_ptr에서 아이디어를 따왔다.

NutPtr<TO> static_pointer_cast<class TO, class FROM>(NutPtr<FROM> const & p)
NutPtr<TO> const_porinst_cast<class TO, class FROM>(NutPtr<FROM> const & p)
NutPtr<TO> dynamic_pointer_cast<class TO, class FROM>(NutPtr<FROM> const & p)
를 구현해줬다.

처음에도 이와 비슷하게 할까 고민했다가 별로 좋은 방법 같지 않아서 관뒀는데, 뭐 boost에서도 쓰고 있으니 그냥 그대로 했다.

파라메터를 넘길 때에도 전부 스마트 포인터로 떡칠을 해놓을 정도로 소스코드에서 *을 없애버렸는데, 솔직히 이게 좀 오버인지 궁금하기도 하다. 해보다가 오버헤드가 너무 심하다 싶으면 파라메터에선 네이티브 포인터를 쓰고, 원래는 없던 네이티브 포인터 연산자도 추가해야겠다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/05/29 22:10 2008/05/29 22:10
아니 뭐 그렇다고 원래 있던 걸 전부 배제하겠다는 얘기는 아니지만,

불확실하더라도 한 번 내 식대로 가보려고 한다. 근데 이미 있는지도 모르겠다.


오늘 학교에서 내 맘대로 생각해낸 장면 관리 방법.
장면큐 : Scene Queue (가칭)

개요 : 렌더링 전에 장면 노드를 정렬하여 비슷한 장면 노드를 묶음으로써 응집성을 높여 성능을 꾀하기 위한 방법.

본문 :
장면노드들을 전부 순회해서 프리렌더링을 먼저 한다. 프리렌더링에서는 상대 변환을 절대 변환으로 고치는 등의 작업이 이루어지고, 그 작업이 모두 끝나면 장면큐에 넣는다.

노드들의 프리렌더링의 모두 끝나면 그 장면큐를 성능을 위해서 알맞게 정렬한다. 이렇게 정렬함의 이유는 성격(셰이더 등)이 비슷한 노드들을 묶음으로써 불필요한 상태 전환을 줄임으로써 성능을 꾀하기 위함이다.

비트플래그를 사용하면 노드의 성격의 표현과 정렬이 쉬워지고, 상태 전환의 비용이 높은 항목을 상위 비트에 둠으로써 효과적으로 상태 전환을 줄일 수 있다.
막상 써놓고 보니, 이런 것이 없는 게 더 이상할지도 모르겠다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/05/13 18:13 2008/05/13 18:13
도구를 만들 때에는, 그게 왜 필요한 것이고, 용도가 무엇이며, 어떻게 쓰일 지가 명확해야한다.
왜 필요한 지를 모르면 만들어 놓고도 헛짓을 한 것에 불과하게 될 것이며
용도를 모르면 아무 짝에도 쓸모 없는 도구가 만들어질 것이고,
어떻게 쓰일 지를 모르면 쓰기에 불편한 도구가 만들어질 것이다.

이 셋 중에 하나라도 명확하게 말로 풀어낼 수 없다면, 필히 원점으로 돌아가야 할 것이다.
너무나 당연한 것이지만, 실상 도구를 만들 때 쉽게 망각되곤 하는 것이기도 하다.

어떻게 쓰일 지를 어떻게 정해야 할 지 가장 난감하다.


처음엔 Orge 엔진을 모델로 두고 시작했지만, 장면노드와 개체가 다르다는 점에서 조금 내키지가 않았다(원래의 설계 방향과 전혀 달랐기 때문). 결국 장면노드와 개체를 하나의 개념으로 보는 Irrlicht 엔진을 기본 모델로 두려고 한다.

엔진 구조는 속도에 중점을 두기보다는, 아무래도 배움에 더 뜻이 있어, 구조에 더 중점을 두려고 한다. 물론 설계가 아닌 구현 상에서는 속도를 위해 아주 약간의 트릭이 적용될 수도 있겠다.
[2008.5.6]
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/05/06 19:45 2008/05/06 19:45
Orge 엔진 강좌 글이 있길래 전부 다운 받아서 참고 하는 중.

내가 하는 방법이 제대로 된 방법인지 확신이 안서서 진행도가 느렸는데,
때 아닌 참에 좋은 자료가 되었다.


신기하게 그래도 나름 혼자서 생각해온 것 치고 잘 해온 것 같다.
크리에이티브 커먼즈 라이센스
Creative Commons License
이올린에 북마크하기(0) 이올린에 추천하기(0)
2008/04/28 21:13 2008/04/28 21:13