블로그 이미지
대갈장군

calendar

1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

Notice

2010. 5. 15. 04:20 OpenGL
OpenGL에서 작게는 10만개에서 많게는 100만개 정도 까지의 점을 그려야 하는 일이 있었다. 각각의 점들은 UTM 좌표들인데 이 UTM은 타원인 지구를 2차원 평면을 평평하게 편 다음 각 구역을 나누어 기준점으로부터의 거리를 미터로 나타낸다.

그래서 UTM은 좌표의 구성이 Easting, Northing, Altitude 요렇게 세가지 축으로 구성된다. 뭐, 걍 X,Y,Z라고 보면 된다. 

이 UTM 좌표 값은 미터로 표시되기 때문에 그 값이 무지 크다. 내가 스캔한 영역의 점들은 기본적으로 Easting 값이 710,000 이상이었으니까 무지하게 큰 값이다.

이론에 따라 이 UTM 좌표를 XYZ로 생각하고 각 점들을 그려내 보았는데 이상하게도 몇개의 점들이 서로 서로 모여서 Z 방향으로 라인을 만드는 것이었다.

다른 형태로 출력한 같은 데이터를 QT modeler라는 프로그램을 이용해서 보면 훨씬 조밀조밀하게 나오는데 이상하게 OpenGL로 렌더링 한 점들은 모두가 띄엄띄엄 한 것이었다.

아무리 옵션을 바꿔봐도 문제는 고쳐지지 않았고 데이터 스트럭쳐 확인 및 브레이크 포인트를 이용해 각각의 요소를 확인해 보았지만 어디에도 타입 변경에 따른 문제는 없었다.

고민고민하다가 생각한 것이 너무 큰 정수부분을 없애자는 것이었다. 임의의 인접한 두점은 대략 0.001 정도의 간격을 가지는데 정수부분의 70만 인것을 감안하면 소수 부분은 턱없이 적은 차이라는 점이 맘에 걸렸었다.

그래서 모든 점들을 다 읽어들인후 중간값을 찾아내 그 정수값을 모두 빼내었다. 그리고 나서 다시 똑같은 방법으로 렌더링을 했더니 이제서야 모든 점들이 제대로 분포하는 것이었다.

그렇게 고치고 나서 생각해보니 한 3년전에 들었던 수치 분석 수업에서 제한된 표현크기를 가지는 컴퓨터의 타입들(예를 들자면 integer, double 같은 것)을 사용할때는 아주가까운 두값이 연산에서 수많은 에러가 발생가능하다는 교수님의 말이 스쳐 지나갔다.

아직 왜 인지는 정확히 모르겠으나 분명히 큰 정수부분의 표현을 위해 제한된 비트를 소모해 버리느라 소수점 이하 영역의 차이를 제대로 계산해 내지 못한 것은 분명하다.

아무튼 이번 경험은 소중한 헤딩이었다. ㅋㅋㅋ
posted by 대갈장군