[글쓴이:] 김 형준

작성일자

Mobile 3D Graphics, 역자 서문 작성 완료..!

사용자 삽입 이미지9월말에 번역 끝내고 출판사에 보냈더랬습니다. 대략 1달정도 교정되어 인쇄된 교정지를 받아보고 참으로 감동스러웠더랬는데… 다시 교정하시는 분이 지적한 부분을 보완해서 보내고.. 다시 2주 정도 기다린 지금.. 역자 서문을 요청 받아 그것까지 보냈습니다. 아마 11월 말쯤 출판이 된다고 하니.. 실제로 출판된 책을 보면 또 어떤 기분일지 궁금합니다..

아래는 오늘 작성해서 보낸 역자 서문입니다. 이 서문은 교정을 보지 않아서 어색한 부분이 많습니다. 이해해 주시고 살펴보시면 감사하겠습니다..

역자 서문


현대의 컴퓨팅 환경은 웹을 뛰어 넘어 언제 어디서나 원하는 정보를 쉽게 접근할 수 있는 모바일 디바이스를 이용한 모바일 플랫폼이 대세를 이루고 있다.


개발자에게 모바일 플랫폼에서의 개발 환경은 마이크로소프트의 Windows Mobile, 구글의 안드로이드, 애플의 iPhone 등이 있습니다. 이들 모두가 서로 상이한 개발 API를 제공함으로써 개발자를 혼란스럽게 하지만 3차원 그래픽 개발에 있어서는 OpenGL ES나 M3G라는 공개된 표준 API를 제공하여 개발 방법을 단일화 해주고 있습니다.


C/C++과 같은 네이티브 언어에서의 OpenGL ES와 Java에서의 M3G라는 표준 API를 사용함으로써 거의 대부분의 모바일 플랫폼에서 개발자가 원하는 3차원 그래픽 어플리케이션을 개발할 수 있는 편의성과 효율성을 제공해 주고 있습니다.


향후 수년 내에 모바일 폰과 같은 디바이스가 지금의 데스크탑 PC는 물론 노트북을 대체할 것이라는 전망이 있습니다. 하지만 이런 전망이 현실화되기까지는 아직 해결 해야 할 과제가 많습니다. 하지만 모바일 폰이 PC나 노트북에서만 가능한 영역을 하나 하나 대체해 나갈 것이라는 사실은 부인할 수 없습니다. 이러한 사실을 놓고 볼 때 향후 사용자의 컴퓨팅 환경에서 데이터를 효과적으로 표현하고 사용자 경험(UX)를 극대화시키기 위한 사용자 인터페이스를 효과적으로 제공하기 위하여 3D 그래픽은 미래의 어플리케이션에서 필수불가결한 요소가 될 것입니다.


이 책은 자신이 개발하고 있는 모바일 어플리케이션에 3D 그래픽 기능을 체계적이고 효과적으로 추가할 수 있도록 모바일 3D 그래픽 API인 OpenGL ES와 M3G를 자세하고 명확하게 설명합니다. 또한 저자들의 경험을 통해 빠지기 쉬운 함정에 대한 해법을 제시해 주고 있습니다. 그리고 3D 그래픽에 대한 수학적인 내용을 꼼꼼히 설명하여 더 정교하게 3D 그래픽 API를 사용할 수 있도록 하였습니다.


특히 이 책의 저자들 모두가 OpenGL ES와 M3G의 명세서 정의에서부터 구현까지 참여했던 코어 개발자이며 아키텍쳐임과 동시에 모바일 3D 그래픽 분야의 리더들이라는 점에서 이 책의 가치가 더욱 빛납니다.


끝으로 이 책의 번역할 수 있는 기회를 준 사이텍미디어의 홍성신 대리님과 부족한 원고를 교정해주고 편집해준 사이텍미디어의 박경민님께 감사드립니다. 그리고 수개월동안 회사생활과 이 책의 번역을 함께 하며 항상 즐겁지만은 않았을 저에게 항상 밝은 모습으로 응원해 준 아내 지은이에게 끝없는 사랑과 감사를 전합니다.

작성일자

Java와 C의 zip 압축 연산에 대한 퍼포먼스 비교

먼저 C의 zip 압축은 Jean-loup Gailly님이 만들어 공개한 zlib 1.2.2를 사용했습니다. C/C++에서 데이터의 압축에서 사용하는 압축 라이브러리는 흔히 이 zlib를 사용합니다.  그리고 Java에서 압축은 기본적으로 제공하는 java.util.zip.Deflater 클래스를 사용했습니다. 테스트를 한 이유는 Java가 C/C++에 비해서 얼마나 느릴까… 하는 기대였습니다. =_=;

Java와 C/C++ 모두 사용한 압축 데이터는 0.2메가 정도되는 jpg 파일로 했습니다. 그리고 Java와 C/C++ 모두 결과는 압축 레벨을 3으로 했을때 동일한 결과와 크기였으며 원본 크기에 비해 75% 정도의 압축되었습니다. 결과는 다음 같습니다. 첫번째 이미지는 Java의 결과이고.. 두번째는 C/C++의 결과입니다.

사용자 삽입 이미지
와우!! Java가 C/C++에 비해 상당히 느릴것으로 기대했는데… 그렇지 않았습니다. C/C++와 성능은 거의 비슷한 것으로 생각됩니다. 두 경우 모두 최악의 경우 0.016초정도 소요됩니다. 다만…. Java의 경우 가끔씩 튀는 부분이 있었는데.. 0.031초 정도 소요되는 부분이 가끔 나옵니다. 아마도 Java의 gc기능 때문이 아닌가… 가볍게 짐작해봅니다. 하지만 이런 부분은 제외하면 정말 C/C++과 같은 Native 컴파일러 못지 않은 성능이라고 판단됩니다.

아래는 Java에서 퍼포먼스 테스트로 사용했던 코드입니다.

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.util.zip.DataFormatException;
import java.util.zip.Deflater;
import java.util.zip.Inflater;
import java.io.*;

public class TestMain {
    public static void main(String[] args) 
        throws IOException, DataFormatException
    {
        FileInputStream fis = new FileInputStream("d:/a.jpg");
        ByteArrayOutputStream baos = new ByteArrayOutputStream(fis.available());
        byte [] buffer = new byte[512];
        int cntRead;
        while((cntRead=fis.read(buffer)) != -1) {
            baos.write(buffer, 0, cntRead);
        }

        byte[] compressedBytes = null;
        for(int i=0; i<20; i++) { // 20 times repeat..
            System.out.println("Performance Test Start...");
            long stime = System.currentTimeMillis();
 
            compressedBytes = Compress(baos.toByteArray());
   
            long etime = System.currentTimeMillis();
            System.out.println("Performance Test Result : " 
                + (etime-stime)+" MS.");
        }   
 
         FileOutputStream fos = new FileOutputStream("d:/a_java.jpg.zip");
         ByteArrayInputStream bais = new ByteArrayInputStream(compressedBytes);
         while((cntRead=bais.read(buffer)) != -1) {
             fos.write(buffer, 0, cntRead);
         }
    }

    private static byte[] Compress(byte[] bytesToCompress) throws IOException
    {
        Deflater compressor = new Deflater(3);
        compressor.setInput(bytesToCompress);
        compressor.finish();
 
        ByteArrayOutputStream bos = 
            new ByteArrayOutputStream(bytesToCompress.length);
 
        byte[] buf = new byte[bytesToCompress.length + 100];
        while (!compressor.finished())
        {
            bos.write(buf, 0, compressor.deflate(buf));
        }

        bos.close();
 
        return bos.toByteArray();
    }
}

대략 살펴보시면 위의 코드에는 IO에 대한 Buffer 기능과 같은.. 여전히 최적화의 여지가 남아 있습니다. 더 이상 제가 갖고 있는 “자바는 느리다”라는 선입견이 상당 부분 깨진 느낌입니다.

작성일자

[GIS] ArcObjects, 도형의 좌표 구하기

ArcObjects를 통해 SHP 파일을 읽어서 만든 레이어를 화면상에 표시한 후… 이 레이어를 구성하는 도형(Shape) 좌표를 구하는 방법을 정리해 보았습니다. ArcObjects에서 제공하는 Map 컨트롤을 통해 SHP 레이어가 하나 추가되었다고 가정하겠습니다. 참고로 이 포스트는 레이어가 폴리곤 도형으로 구성된 레이어를 대상으로 합니다.

가장 먼저 해야할 일은 지도 컨트롤이 가지고 있는 레이어를 가져오는 일입니다. 가져올때 도형 정보에 접근해야 하므로 IFeatureLayer 인터페이스 타입으로 가져와야 합니다.

ESRI.ArcGIS.Carto.IFeatureLayer pFL;
pFL = axMapControl1.get_Layer(0) as ESRI.ArcGIS.Carto.IFeatureLayer;

이렇게 가져온 IFeatureLayer 변수인 pFL을 통해 각각의 Feature를 얻어오기 위해 IFeatureClass와 IFeatureCursor를 이용합니다.

ESRI.ArcGIS.Geodatabase.IFeatureClass pFClass;
pFClass = pFL.FeatureClass;

ESRI.ArcGIS.Geodatabase.IFeatureCursor pFCursor;
pFCursor = pFClass.Search(null, false);

이제 레이어를 구성하는 Feature를 읽을 수 있는 준비가 되었습니다. 아래의 반복문을 통해 각각의 Feature를 순회하면서 원하는 좌표를 읽게 됩니다.

ESRI.ArcGIS.Geodatabase.IFeature pFeature;            
while((pFeature=pFCursor.NextFeature()) != null) {
    ....
}

아래의 코드가 위의 코드의 반복문 사이(while문)에 들어가는 코드입니다. 도형은 Point의 집합이므로 IPointCollection 인터페이스 타입이 필요하며 각 포인트 좌표값과 관련 정보를 얻기 위해 IEnumVertex 인터페이스가 필요합니다.

    ESRI.ArcGIS.Geometry.IPointCollection pPC;
    pPC = pFeature.Shape as ESRI.ArcGIS.Geometry.IPointCollection;

    ESRI.ArcGIS.Geometry.IEnumVertex pEV = pPC.EnumVertices;

    ESRI.ArcGIS.Geometry.IPoint pPt;
    int outPartIndex;
    int vertexIndex;
    listBox1.Items.Add("FID: " + pFeature.OID);
    for(int i=0; i<pPC.PointCount; ++i) {
        pEV.Next(out pPt, out outPartIndex, out vertexIndex);
        listBox1.Items.Add("    Part Idx :" + outPartIndex + 
            " Vertex Idx : " + vertexIndex + " (" + pPt.X + "," + pPt.Y + ")");
    }

비록 이 포스트의 글은 폴리곤 레이어에 대한 내용이지만 이 보다 간단한 포인트나 폴리라인에 대해서도 쉽게 좌표를 읽을 수 있습니다. 마지막으로 아래는 위의 코드들을 실행했을때의 결과 입니다.

사용자 삽입 이미지

작성일자

[GIS] ArcObjects, 속상값에 따라 다른 색상 지정(UniqueValueRenderer)

ArcObjects는 공간분석등을 포함한 지오프로세싱과 공간 데이터 편집에도 탁월한 기능을 제공하지만 공간 데이터의 표현에도 매우 뛰어난 기능을 제공합니다. 여기서는 공간 데이터에 대한 각 속성값에 따라 다른 그리기 심벌을 지정할 수 있는 UniqueValueRenderer에 대해 정리해 보도록 하겠습니다. UniqueValueRenderer는 특정 값에 대한 그리기 심벌을 정의할 수 있는 렌더러입니다. 이 포스트는 기본적으로 SHP 파일을 통한 레이어를 ArcObjects에서 제공하는 지도 컨트롤에 추가하고 있다고 가장합니다.

ESRI.ArcGIS.Carto.IFeatureLayer pFL;
pFL = axMapControl1.get_Layer(0) as ESRI.ArcGIS.Carto.IFeatureLayer;

ESRI.ArcGIS.Geodatabase.IFeatureClass pFClass;
pFClass = pFL.FeatureClass;

ESRI.ArcGIS.Geodatabase.IQueryFilter pQF;
pQF = new ESRI.ArcGIS.Geodatabase.QueryFilter();

ESRI.ArcGIS.Geodatabase.IFeatureCursor pFCur;
pFCur = pFClass.Search(pQF, false);

앞의 코드는 먼저 지도 컨트롤에 추가된 SHP 데이터에 대한 레어이의 IFeatureLayer 인터페이스를 구하고 있습니다. IFeatureLayer를 통해 속성값에 접근할 수 있는 IFeatureClass 인터페이스를 구할 수 있으며 이 IFeatureClass의 검색 메서드인 Search에 인자로 IQueryFilter 타입의 값을 넘겨주면 레이어의 전체 속성 레코드를 얻어오게 되고 그 결과는 IFeautreCursor 인터페이스를 통해 접근할 수 있습니다.

ESRI.ArcGIS.Display.IRandomColorRamp pRCR;
pRCR = new ESRI.ArcGIS.Display.RandomColorRamp();
pRCR.MinSaturation = 0;
pRCR.MaxSaturation = 100;
pRCR.MinValue = 0;
pRCR.MaxValue = 100;
pRCR.StartHue = 0;
pRCR.EndHue = 360;
pRCR.UseSeed = true;
pRCR.Seed = 87;

앞의 코드는 색상 심벌을 손쉽게 만들어 낼 수 있는 유틸리티 인터페이스인 IRandomColorRamp를 인스턴스화 하고 있습니다. 이 인터페이스는 사용자가 지정한 색조와 채도등의 값을 지정하고 지정된 값의 범위 내에서 임의의 난수 발생을 통해 색상 심벌을 뽑아 낼 수 있습니다. 참고로 지정할 수 있는 Hue의 최소와 최대값은 각각 0, 360이며 Saturation의 최소와 최대값은 각각 0, 100 그리고 Value의 최소, 최대값은 0, 100입니다. 또한 난수 발생에 대한 Seed값을 지정할 수 있는 속성을 제공합니다.

ESRI.ArcGIS.Carto.IUniqueValueRenderer pRender;
pRender = new ESRI.ArcGIS.Carto.UniqueValueRenderer();

pRender.FieldCount = 1;
pRender.set_Field(0, "SGG_NM");

ESRI.ArcGIS.Display.ISimpleFillSymbol pSFS;
pSFS = new ESRI.ArcGIS.Display.SimpleFillSymbol();
pSFS.Style = ESRI.ArcGIS.Display.esriSimpleFillStyle.esriSFSSolid;
pSFS.Outline.Width = 0.4;
pRender.DefaultSymbol = pSFS as ESRI.ArcGIS.Display.ISymbol;
pRender.UseDefaultSymbol = true;

앞의 코드는 이 포스트의 주인공인 UniqueValueRenderer를 생성하고 속성값을 설정하는 코드의 일부입니다. 앞서 언급했듯이 UniqueValueRenderer는 속성값에 기반하여 서로 다른 속성값에 따라 각기 다른 색상 심벌을 지정한다고 했습니다. 4번과 5번 코드는 속성값을 얻어올 필드의 개수의 필드명(여기서는 SGG_NM)을 지정합니다. 또한 지정하지 못한 속성값을 가지는 도형에 대해 기본적으로 사용할 그리기 심벌을 지정하는 코드가 7~12번의 코드입니다.

ESRI.ArcGIS.Geodatabase.IFeature pFeat;
long n = pFClass.FeatureCount(pQF);
ESRI.ArcGIS.Geodatabase.IFields pFields;
pFields = pFClass.Fields;
int iField = pFields.FindField("SGG_NM");
for(long i = 0; i

앞의 코드부분은 각 속성값에 대한 그리기 심벌(정확히 말하면 SimpleFillSymbol)을 지정합니다. 동일한 값의 중복되는 속성값에 대해 이중으로 그리기 심벌을 지정하지 않도록 valFound 변수를 통해 걸러내고 있습니다. 코드 라인 별로 살펴보면, 2번 코드는 레이어가 가지고 있는 전체 속성 레코드의 개수를 얻어와 n 변수에 저장하고 있습니다. 그리고 3번, 5번 코드는 속성값을 가져올 필드명에 대한 인덱스를 얻어와 iField에 저장합니다. 6번 코드의 for문은 모든 레코드에 대해서 앞서 지정한 필드의 값을 가져오고 그 필드 값에 대해 그리기 심벌을 생성하여 지정하고 있습니다. 15번 라인의 for문은 앞서 저장해둔 속성값들 중에 중복된 속성값에 대해서는 이중으로 심벌을 지정하지 않도록 하는 코드입니다. 여기서 눈여겨 봐야 할 점은 생성해 지정한 그리기 심벌에 대한 색상값을 지정하고 있지 않다는 점입니다. 일단 그리기 심벌을 생성해 두기만 하고 다음에 색상값을 지정합니다.


pRCR.Size = pRender.ValueCount;
bool bOK = true;
pRCR.CreateRamp(out bOK);
ESRI.ArcGIS.Display.IEnumColors pEnumClrs;
pEnumClrs = pRCR.Colors;
pEnumClrs.Reset();
for(int ny=0; ny

앞의 코드는 이전 부분에서 생성해둔 그리기 심벌을 IRandomColorRamp 인터페이스 타입으로 생성해둔 객체를 통해 색상을 얻어와 실제 지정하는 코드입니다. 앞서서 pRCR이라는 변수 명으로 IRandomColorRamp 인터페이스의 CoClass를 생성해 놓았습니다. 이 pRCR로부터 생성할 색상의 개수를 지정하고 CreateRamp 매서드를 호출하여 원하는 개수만큼 원하는 색상 계열로 색상을 생성해 두는 코드가 1번~3번 코드입니다. 이제 생성해 놓은 색상을 얻기 위해 Iterator 디자인 패턴의 방법을 통해 얻어 오는 부분이 4,5,6번 코드와 12번 코드입니다. 7번 코드의 for문은 고유한 필드값으로 저장된 그리기 심벌들을 가져와서 이 심벌의 색상을 pRCR에서 얻어온 색상으로 지정하기 위한 반복문입니다. 이 부분까지가 UniqueValueRenderer에 대한 필요한 속성값들을 설정하기 위한 모든 과정입니다. 이렇게 구성한 UniqueValueRenderer를 레이어에 지정하는 코드는 아래와 같습니다.


pRender.ColorScheme = "Custom";
pRender.set_FieldType(0, true);

ESRI.ArcGIS.Carto.IGeoFeatureLayer pGFL = 
    pFL as ESRI.ArcGIS.Carto.IGeoFeatureLayer;
pGFL.Renderer = pRender as ESRI.ArcGIS.Carto.IFeatureRenderer;

axMapControl1.ActiveView.Refresh();


레이어의 렌더러는 IGeoFeatureLayer 인터페이스를 통해 접근할 수 있으므로 4번~6번 코드와 같은 형태로 렌더러를 지정할 수 있습니다. 최종적인 실행 결과는 아래와 같습니다.


사용자 삽입 이미지