전 기사에서 딱 한달만에 로그를 적습니다.
안드로이드 개발을 잠시 놓고 그래픽관련 샘플쪽에만 집중 하고있던지라 이쪽의 기록이 한달간 없었네요.
일단 아래에 이은 작업진척을 정리하자면
AmanithVG의 동작이 이해할수 없을정도로 이상해, ShivaVG로 Implementation을 전환하여 작업했습니다.
샘플의 내용은 3D모델 데이터를 2D벡터화 하는 내용인데
현재 단계에서는 Culling(Clockwise) 작업을 거친 메쉬중 1회만 사용된 선을 골라내어 통합하는 방식으로 3D데이터를 2D벡터화 시키는 처리를 시켜봤습니다.
아이디어만 들으면 그럴싸 한데 막상 굴려보니 심도가 틀린데서 꼬이는 현상같은게 보여 좀 난항중이네요.
물론 이 과정에서 처리과정이 제법 되는데.. 향후에 OpenCL을 써서 하드웨어 가속처리를 시켜볼까 생각은 했습니다.
만.. 결과물이 좀 애매하여 이걸 이대로 진행해도 될런지.. 방향을 좀 바꿔야 할지도 모르겠네요
구체적인 처리순서는
1. 정점을 공유하지 않는 실질적으로는 같은 정점의 인덱스 통합
-> n+i = vi 진행중인 루프에 대해 vi+n, 단 vi+n <= length 과 같은 범위의 탐색을 하면서 같은 값의 인덱스를 기록, 인덱스만 변조.
2. Triangle 의 Culling 작업
3. 남은 Triangle의 각 라인에 대한 사용빈도 투표작업
(일일히 대조하고 있어서는 끝이 없으므로 사용수를 검사)
4. 1회씩 사용된 라인의 추출
5. 추출된 라인의 정점간 통합. 같은 정점으로 돌아오는 선을 1개의 폴리곤으로 분류
6. 분류 과정을 되풀이 한 후에 남은 정점들을 각각 선으로 분류
해서 나온 결과가..
와 같은 상황입니다.
일부 정점을 제대로 인식 못하거나 하는 문제가 좀 보이고있네요
단순히 정점의 탐색과정의 문제이거나 싶은 부분도 있는가 하면
이론대로 처리는 되었으나 발생하는 문제점..
예를들자면 아래 드워프의 겨드랑이 부분과 같은것 말이죠
처리과정중에 일일히 정렬탐색하는 기능이 들어가서는 리얼타임 처리에 있어서 치명적이기도 할테고.. 일단 연구삼아 만들어보긴 했지만 결국 비현실적인 처리방식이 아니려나 싶네요
우선은 탐색부분의 버그를 그나마 마저 찾아보고.. 이 연구 샘플은 이정도 선에서 접어둬야 할거 같습니다. 툰 랜더의 개선이라는 주제는 좀더 다른 방식으로 접근 해봐야할거같이 보이네요
그리고 한동안 놓았던 Android ADT가 20.0.3버전까지 진행되어 있었습니다.
아래 기사에 언급되었던 대로 20.0.1버전에서 패스를 인식하지 못하는 버그를 고쳤다
라고 하는데 왜 전 그대로인지 알수가 없는 노릇이네요.
이 한달사이에 또 노후화된 맥북이 사망해버려 이쪽에서 테스트를 할수가 없는 상황입니다만.
20.0.0버전에서는 맥에서도 똑같이 패스인식이 안되었는데.. 윈도우만 국한되어 이야기하는건 제 설정에 뭔가 문제가 있는거였을까요 (랄까 그 설정 자체가 안보이던데?)
일단 고쳤다고 하니 이 부분은 좀 만져보고 알아봐야할거같습니다.
2012년 8월 19일 일요일
2012년 7월 19일 목요일
AmanithVG using memo
샘플의 tiger_gle 프로젝트의 흐름을 정리
libAmanithVG.lib, opengl32.lib, glu32.lib를 의존합니다.
샘플은 VS2010으로 작성되어있으므로, 이전 버전으로 열려고 할때는 일반 프로젝트로 연 후에 위 3개 라이브러리파일을 지정해줄 필요가 있습니다.
샘플을 살펴보면서 대체적인 처리의 흐름
initOpenVG
vgPrivSurfaceDestroyMZT
vgPrivContextDestroyMZT
PS_CONSTRUCT라는 로컬함수에서 각종 파라메터 설정을 명령배열에 따라서 처리하고 있습니다. 향후 3D->2D변환 과정에서는 일련의 3D정점을 일괄적으로 투영한 후에, 그 배열을 VG로 넘겨주는 식으로 처리가 되어야할것으로 보입니다.
이 과정에서는 행렬 처리가 가능할것으로 예상되니 OpenML같은 처리를 할수있으면 해두는게 좋을듯 해보입니다. 투영처리 관련쪽으로는 관련 오픈 라이브러리의 코드를 참고해서 만들까 생각하고 있습니다.
drawScene (in main loop)
libAmanithVG.lib, opengl32.lib, glu32.lib를 의존합니다.
샘플은 VS2010으로 작성되어있으므로, 이전 버전으로 열려고 할때는 일반 프로젝트로 연 후에 위 3개 라이브러리파일을 지정해줄 필요가 있습니다.
샘플을 살펴보면서 대체적인 처리의 흐름
initOpenVG
vgPrivContextCreatMZT=> release with
vgPrivSurfaceCreateMZT
vgPrivMakeCurrentMZT
vgPrivSurfaceDestroyMZT
vgPrivContextDestroyMZT
PS_CONSTRUCT라는 로컬함수에서 각종 파라메터 설정을 명령배열에 따라서 처리하고 있습니다. 향후 3D->2D변환 과정에서는 일련의 3D정점을 일괄적으로 투영한 후에, 그 배열을 VG로 넘겨주는 식으로 처리가 되어야할것으로 보입니다.
이 과정에서는 행렬 처리가 가능할것으로 예상되니 OpenML같은 처리를 할수있으면 해두는게 좋을듯 해보입니다. 투영처리 관련쪽으로는 관련 오픈 라이브러리의 코드를 참고해서 만들까 생각하고 있습니다.
drawScene (in main loop)
* get width&height by vgGetSurfaceWidth(or Height)MZT(); vgSeti(VG_RENDERING_QUALITY, ...);
vgSeti(...);
vgClear();
vgLoadIdentity
vgTranslate...
vgScale...
...
...
PS_RENDER() {
vgSeti(VS_FILL_RULE,rule of array);
setting styles.. by vgSeti
vgSetPaint
}
vgDrawPath
}
2012년 7월 18일 수요일
Research direction has changed
일단 이 블로그에서 하려 했던 작업 자체가, 모바일 환경에서 가능한 최대 품질의 툰랜더의 제작이었습니다만. 모바일이라는 전제를 가지고 작업을 들어가려니, 현 시점에서는 장애요소가 많다고 판단했습니다.
예를 들자면 NDK의 생산성 문제, 공식 플러그인이 불안정 하다는 문제, OpenGL ES의 테스트환경 문제, 화질 개선을 위한 베지어곡면등의 처리문제(는 결국 하드웨어 가속 전제로는 불가능하다고 결론) 등등
해서 최종적으로는 다 다뤄야 할 주제들이긴 하지만, 사용 라이브러리나 환경문제를 제쳐놓고 최종 목적인 툰랜더러에 다시 초점을 맞춰 생각을 해볼까 합니다.
우선적으로 지금 생각하고있는 툰랜더의 처리방향은
기존의 단순히 폴리곤의 음영을 단순화 해 처리해온 툰 랜더와는 다르게
3D오브젝트를 2D벡터 데이터로 투영한 후에, 투영된 2D벡터 데이터를 이용하여 처리하는 방향으로 연구를 진행할까 생각하고 있습니다.
기본적으로 만화라는 작화 스타일이라는게, 인간의 인식 스키마상의 통계라는 요소에서 그 그림을 아름답다고 느끼는 요소가 있다면, 어중간한 3D오브젝트보다는 결과적인 2D화상의 보정을 통해서 그 어중간함을 메꿀수 있는 가능성이 있다고 생각했습니다.
해서 이후의 개발 방향은
- 3D 데이터의 2D 벡터 화상으로의 투영
- 외곽 2D벡터의 형태보정 (이 부분에서 구체적으로 수정 되어야할 보정패턴의 연구)
- 음영 2D벡터의 형태보정
- 배색의 표현기법
- 위 처리과정상의 하드웨어 가속화 가능여부
그리고 비 우선 연구과제입니다.
- 인물의 표정표현에 관련된 부분
- 소재에 따른 표현방법(유리, 금속, 천, 피부)
일단 리얼타임 2D 벡터라는 요소를 끄집어 냄으로서 기대하고 있는 결과는 다음과 같습니다.
- 일단 3D에서 2D로 옮겨오면서 베지어 곡선으로의 보정가능 여부
- 3D 툰랜더러의 밋밋함을 회피할수 있을 가능성
현 시점에서 파악된 도입관련요소
- OpenVG / ShivaVG
전자는 좀 느리다는거같고, 후자는 어느정도 가볍다는 기록이 있네요, 2009년 정도의 기록이라 좀더 알아봐야 할 듯합니다
- 안드로이드 관련 프로젝트
http://code.google.com/p/androidvg/
예를 들자면 NDK의 생산성 문제, 공식 플러그인이 불안정 하다는 문제, OpenGL ES의 테스트환경 문제, 화질 개선을 위한 베지어곡면등의 처리문제(는 결국 하드웨어 가속 전제로는 불가능하다고 결론) 등등
해서 최종적으로는 다 다뤄야 할 주제들이긴 하지만, 사용 라이브러리나 환경문제를 제쳐놓고 최종 목적인 툰랜더러에 다시 초점을 맞춰 생각을 해볼까 합니다.
우선적으로 지금 생각하고있는 툰랜더의 처리방향은
기존의 단순히 폴리곤의 음영을 단순화 해 처리해온 툰 랜더와는 다르게
3D오브젝트를 2D벡터 데이터로 투영한 후에, 투영된 2D벡터 데이터를 이용하여 처리하는 방향으로 연구를 진행할까 생각하고 있습니다.
기본적으로 만화라는 작화 스타일이라는게, 인간의 인식 스키마상의 통계라는 요소에서 그 그림을 아름답다고 느끼는 요소가 있다면, 어중간한 3D오브젝트보다는 결과적인 2D화상의 보정을 통해서 그 어중간함을 메꿀수 있는 가능성이 있다고 생각했습니다.
해서 이후의 개발 방향은
- 3D 데이터의 2D 벡터 화상으로의 투영
- 외곽 2D벡터의 형태보정 (이 부분에서 구체적으로 수정 되어야할 보정패턴의 연구)
- 음영 2D벡터의 형태보정
- 배색의 표현기법
- 위 처리과정상의 하드웨어 가속화 가능여부
그리고 비 우선 연구과제입니다.
- 인물의 표정표현에 관련된 부분
- 소재에 따른 표현방법(유리, 금속, 천, 피부)
일단 리얼타임 2D 벡터라는 요소를 끄집어 냄으로서 기대하고 있는 결과는 다음과 같습니다.
- 일단 3D에서 2D로 옮겨오면서 베지어 곡선으로의 보정가능 여부
- 3D 툰랜더러의 밋밋함을 회피할수 있을 가능성
현 시점에서 파악된 도입관련요소
- OpenVG / ShivaVG
전자는 좀 느리다는거같고, 후자는 어느정도 가볍다는 기록이 있네요, 2009년 정도의 기록이라 좀더 알아봐야 할 듯합니다
- 안드로이드 관련 프로젝트
http://code.google.com/p/androidvg/
2012년 7월 16일 월요일
Native Bezier Curve/surface Rendering
요 며칠 알아본 자료들을 정리합니다.
기본적으로 Shader레벨에서는 현재 시점에서 순수한 Programmable Rasterizer는 없습니다.
Native하게 곡선을 그려내려면 위와 같은 기능이나, 혹은 베지어곡선 내지는 곡면을 그려내는 처리가 필요합니다만. 적어도 현재 나와있는 DX, OpenGL에서는 본질적인 Native Bezier rasterizer/Programmable Rasterizer은 존재하지 않습니다.
하드웨어 가속을 무시한다면 개발도 가능하겠지만. 이 경우 Performance적인 의미로 상당히 문제가 될거라 예상되기때문에 이런 방법은 현실적이지 않겠지요.
현재의 GL개발의 흐름은 Tessellation Shader/ Geometry shader등으로 좀더 세밀한 표현을 하고자 하는 방향으로 그 흐름이 기울어져있는듯 합니다.
기존에 잘 알려진 Bump mapping의 일종인 normal mapping은 fragment shader레벨에서 구현이 가능할것이고. 실제로 굴곡을 만들어내는 displacement mapping은 tessellation shader, geometry shader등을 도입함으로서 구현 가능할것으로 보입니다.
tessellation은 기존의 폴리곤을 좀더 세분하게 분할하는 작업 등을 지칭합니다.
displacement mapping은 잘게 잘라진 폴리곤에 displacement map(bitmap, perhaps grayscale)를 할당해 주어진 화소의 값을 깊이로 이용하여 평면 폴리곤에 굴곡을 만들어내는 표현기법입니다.
zbrush등에서 사용되고 있는 구현방법의 하나라고 할수있겠네요.
geometry shader는 tessellation의 일환으로, 기존의 삼각형을 확장하여 삼각형 이외의 다른 도형을 만들어냅니다. 현재 현실적인 구현 방법으로 베지어곡선을 그려내고자 한다면, geometry shader를 이용하여 의사적으로 구현하는 방법은 있겠네요.
실제로 그 샘플을 연구한 사례도 있는듯 합니다.
http://www.pixelnerve.com/v/2010/05/11/evaluate-a-cubic-bezier-on-gpu/
geometry shader와 tessellation shader는 각각 OpenGL 3.2/DirectX 10과 OpenGL 4.x/DirectX 11에서 지원되고 있습니다.
웹이나 모바일에서 이 두 쉐이더를 이용하기에는 호환성의 문제가 대두될거라 보아지네요.
기본적으로 Shader레벨에서는 현재 시점에서 순수한 Programmable Rasterizer는 없습니다.
Native하게 곡선을 그려내려면 위와 같은 기능이나, 혹은 베지어곡선 내지는 곡면을 그려내는 처리가 필요합니다만. 적어도 현재 나와있는 DX, OpenGL에서는 본질적인 Native Bezier rasterizer/Programmable Rasterizer은 존재하지 않습니다.
하드웨어 가속을 무시한다면 개발도 가능하겠지만. 이 경우 Performance적인 의미로 상당히 문제가 될거라 예상되기때문에 이런 방법은 현실적이지 않겠지요.
현재의 GL개발의 흐름은 Tessellation Shader/ Geometry shader등으로 좀더 세밀한 표현을 하고자 하는 방향으로 그 흐름이 기울어져있는듯 합니다.
기존에 잘 알려진 Bump mapping의 일종인 normal mapping은 fragment shader레벨에서 구현이 가능할것이고. 실제로 굴곡을 만들어내는 displacement mapping은 tessellation shader, geometry shader등을 도입함으로서 구현 가능할것으로 보입니다.
tessellation은 기존의 폴리곤을 좀더 세분하게 분할하는 작업 등을 지칭합니다.
displacement mapping은 잘게 잘라진 폴리곤에 displacement map(bitmap, perhaps grayscale)를 할당해 주어진 화소의 값을 깊이로 이용하여 평면 폴리곤에 굴곡을 만들어내는 표현기법입니다.
zbrush등에서 사용되고 있는 구현방법의 하나라고 할수있겠네요.
geometry shader는 tessellation의 일환으로, 기존의 삼각형을 확장하여 삼각형 이외의 다른 도형을 만들어냅니다. 현재 현실적인 구현 방법으로 베지어곡선을 그려내고자 한다면, geometry shader를 이용하여 의사적으로 구현하는 방법은 있겠네요.
실제로 그 샘플을 연구한 사례도 있는듯 합니다.
http://www.pixelnerve.com/v/2010/05/11/evaluate-a-cubic-bezier-on-gpu/
geometry shader와 tessellation shader는 각각 OpenGL 3.2/DirectX 10과 OpenGL 4.x/DirectX 11에서 지원되고 있습니다.
웹이나 모바일에서 이 두 쉐이더를 이용하기에는 호환성의 문제가 대두될거라 보아지네요.
Android socket programming memo
주의점을 아래에 정리합니다
- 소켓은 기본적으로 JAVA의 기본 socket을 이용
- 모든 Socket은 메인Thread에서는 사용할수 없습니다(Android 3.0 이후) *1
- socket을 이용시에 AndroidManifest에 다음과같은 Permission설정이 필요합니다
*1 메인Thread에서 socket을 사용 시도시에 NetworkOnMainThreadException이 발생합니다.
- 소켓은 기본적으로 JAVA의 기본 socket을 이용
- 모든 Socket은 메인Thread에서는 사용할수 없습니다(Android 3.0 이후) *1
- socket을 이용시에 AndroidManifest에 다음과같은 Permission설정이 필요합니다
<uses-permission android:name="android.permission.INTERNET"></uses-permission>
*1 메인Thread에서 socket을 사용 시도시에 NetworkOnMainThreadException이 발생합니다.
2012년 7월 11일 수요일
Android ADT R20 do not recognize NDK header(include) path automatically
며칠간 분투했습니다만... Android ADT R20에는 현재 NDK header path를 자동으로 인식해주지 않는 버그가 있습니다. 거기에 수동으로 path설정하는 위치는 없고.. 비슷한곳도 시험은 해보았으나 먹통이더군요.
しばし奮闘いたしましたが・・・。Android ADT R20では現在NDK header pathを自動で認識してくれないバグがあるようです。さらには手動でpathを設定するところも無くて、それっぽい箇所をいくつか試しては見たのですが、そううまくもいきませんでした。
일단 아래 기사에 따르면 다음 20.0.1 버전에서는 이 버그가 개선 예정이라고 합니다.
以下の記事によると次の20.0.1ではこのバグが解消されるようで
http://tools.android.com/recent/usingthendkplugin
뭐.. 아직 알파버전이라니 하다못해 베타로 올라오면 어느정도 쓸수있는 물건이 되어있으려나요.
공식 지원이 제대로 되기 시작하면 디버깅도 가능한듯 하니 좀 기다려보기로 했습니다.
まぁ、まだαバージョンらしいので、仕方ないといえばそうでしょうけどね。せめてものβになると多少は使えるものになるのではないかと期待してみます。
公式でサポートされ出すとデバッグの可能になるらしいので、待ってみたほうがよさそうですね。
낮은 버전에서도 시험 해봤으나 역시 증상은 같고.. 이는 OSX나 Windows7 x64환경에서도 동일하더군요.
해서 지금은 NDK를 사용하기엔 좋은 시기가 아니라고 판단되어 우선순위를 나중으로 두기로 했습니다.
昔のバージョンのEclipseでも試した見ましたが、症状も変わらず・・・これはOSXや窓7 x64の環境でも同一でした。
で、今はNDKを使うにはいいタイミングではないと判断され、優先順位を後にしました。
일단 조금더 연구해서 OpenGL 2.0이상에서 베지어 곡면처리, 수채표현처리 등의 연구를 우선 후에 Android개발쪽을 더 알아보기로 하겠습니다.
後もう少し研究を続けて、OpenGL 2.0以上でのベジェ曲面の処理、水彩の表現処理などの研究を優先にした上で、Android開発の方を調べることにいたします。
しばし奮闘いたしましたが・・・。Android ADT R20では現在NDK header pathを自動で認識してくれないバグがあるようです。さらには手動でpathを設定するところも無くて、それっぽい箇所をいくつか試しては見たのですが、そううまくもいきませんでした。
일단 아래 기사에 따르면 다음 20.0.1 버전에서는 이 버그가 개선 예정이라고 합니다.
以下の記事によると次の20.0.1ではこのバグが解消されるようで
http://tools.android.com/recent/usingthendkplugin
Known Issues
1. Eclipse does not automatically find the include paths to all the NDK headers on Windows. This issue will be fixed in the next update (20.0.1) when it is released.2. Eclipse does not automatically find the include paths with CDT 8.1.0 (Juno). This issue is tracked in Bug 33788.
뭐.. 아직 알파버전이라니 하다못해 베타로 올라오면 어느정도 쓸수있는 물건이 되어있으려나요.
공식 지원이 제대로 되기 시작하면 디버깅도 가능한듯 하니 좀 기다려보기로 했습니다.
まぁ、まだαバージョンらしいので、仕方ないといえばそうでしょうけどね。せめてものβになると多少は使えるものになるのではないかと期待してみます。
公式でサポートされ出すとデバッグの可能になるらしいので、待ってみたほうがよさそうですね。
낮은 버전에서도 시험 해봤으나 역시 증상은 같고.. 이는 OSX나 Windows7 x64환경에서도 동일하더군요.
해서 지금은 NDK를 사용하기엔 좋은 시기가 아니라고 판단되어 우선순위를 나중으로 두기로 했습니다.
昔のバージョンのEclipseでも試した見ましたが、症状も変わらず・・・これはOSXや窓7 x64の環境でも同一でした。
で、今はNDKを使うにはいいタイミングではないと判断され、優先順位を後にしました。
일단 조금더 연구해서 OpenGL 2.0이상에서 베지어 곡면처리, 수채표현처리 등의 연구를 우선 후에 Android개발쪽을 더 알아보기로 하겠습니다.
後もう少し研究を続けて、OpenGL 2.0以上でのベジェ曲面の処理、水彩の表現処理などの研究を優先にした上で、Android開発の方を調べることにいたします。
2012년 7월 6일 금요일
Developing Environment Setting up + Emulator Hardware Acceleration
공식 문서 및 인터넷상의 기록을 참조하여 구축한 개발환경의 세팅법, 그 과정상의 주의점 등을 이하에 기록합니다.
さらにpathの設定が必要です。
pathにはandroid-ndk-r?のフォルダのパスが設定される必要があります。
windowsではpathのほかにANDROID_NDK_ROOT=c:\android-ndk-r8
のような設定が必要の様です。
이후에 필요에 따라 환경설정을 변경하게 될 경우 그 내용을 모두 이 문서에 저장합니다.
(중간에 기록이 변경될 수도 있습니다)
公式ガイド及びネット上の記録を参照して構築した開発環境のセッティング方法、その過程上の注意点などを以下に記録いたします。
以後、必要によって環境設定を変更される場合、その内容をすべてこの文書に保存いたします。
(途中で記録が変わる可能性だってあります)
Installing Eclipse
현 시점에서 Android개발팀은 Eclipse Classic Version의 사용을 추천하고 있습니다.
現時点で、Android開発チームはEclipse Classic Versionの使用を勧めております。
If you need to install Eclipse, you can download it from http://www.eclipse.org/downloads/. We recommend the "Eclipse Classic" version. Otherwise, you should use a Java or RCP version of Eclipse.
그런 관계로, Classic 버전을 사용하였습니다.
윈도우7에서는 Eclipse의 사용을 위해서, 직접 JAVA를 인스톨 할 필요가 있었습니다.
반면, OSX Lion에서는 처음 JAVA가 설치 되지 않은 환경에서 Eclipse를 실행하였더니, 따로 찾을 필요 없이 알아서 설치를 마쳐주었습니다. 편리한 환경인거 같네요.
そういう訳で、Classicバージョンを使用いたしました。
Windows7ではEclipseの使用において、自分でJAVAをインストールしておく必要がありました。
それに比べ、OSX Lionでは最初、Javaがインストールされてない環境では特別に探すことなく、実行したら勝手に探してくれました。便利でしたね。
Installing Android SDK+AVD
Eclipse에 플러그인을 설치 이후, 최신판 SDK (API16)을 설치합니다.
추가적으로 Windows쪽은 VT가 지원되는 하드웨어 환경이라,
Eclipseでプラグインをインストした後、最新版のSDK(API16)をインストいたしました。
さらにWindowsの方のマシーンはVTがサポートされるハードウェア環境だったので
Eclipseでプラグインをインストした後、最新版のSDK(API16)をインストいたしました。
さらにWindowsの方のマシーンはVTがサポートされるハードウェア環境だったので
위 페이지를 참조하여 Intel Hardware Accelerated Execution Manager를 추가설치하였습니다.
참고로 VT등에 관련되는 기능은, 컴퓨터의 설정에서 OFF되어 있는 경우가 있는듯 합니다. (보통은 쓰지 않으니 OFF로 되어있는듯)
저의 하드웨어 환경의 경우 BIOS설정에서 Enable/Disable설정이 가능하게 되어 있었습니다.
이 부분은 각자 환경에 따라 설정할 필요가 있는듯 하네요.
上記のページを参考にしてIntel Hardware Accelerated Execution Managerも導入いたしました。
ちなみにVTに纏わる機能たるものは、各パソコンの設定上OFFにされている場合があるみたいです。(通常は使わないので、問うことみたいですね)
自分のマシーンの場合、BIOS設定から有効・無効設定ができるようになっておりました。
ここいらの設定はマシーンによって違うらしく、マシーンごとで調べる必要があるらしいです。
위 가이드에는 sc query intelhaxm이라는 커맨드를 설치후에 프롬프트상에서 입력해 확인해보라고 되어있습니다만.
ちなみにVTに纏わる機能たるものは、各パソコンの設定上OFFにされている場合があるみたいです。(通常は使わないので、問うことみたいですね)
自分のマシーンの場合、BIOS設定から有効・無効設定ができるようになっておりました。
ここいらの設定はマシーンによって違うらしく、マシーンごとで調べる必要があるらしいです。
위 가이드에는 sc query intelhaxm이라는 커맨드를 설치후에 프롬프트상에서 입력해 확인해보라고 되어있습니다만.
sc라는 명령어 자체는 실제로는 실행 프로그램의 일종으로, windows/system32상에 위치하고있습니다. 가끔 path설정에서 위 path가 빠져있어 실행이 안되는 경우가 있는듯 하니
한번 시도해보고 안된다면 c:\windows\system32에 들어가 실행해보는게 나을듯 해보이네요.(저는 path설정이 되어있지 않았습니다)
上記のガイドでは、sc query intelhaxmなるコマンドをソフトウェア導入の後、プロンプトで入力することで動作確認ができるとのことですが。
scという命令自体は実際では一種の実行プログラムの一つで、それはwindows/system32上に一誌手降ります。たまにpath設定で上記のパスが外れている場合は実行できない場合があるみたいなので、一度試してだめならば、c:\windows\system32に移るかパスの設定をした上で実行してみた方がよさそうですね。(自分はパスが外れてました)
scという命令自体は実際では一種の実行プログラムの一つで、それはwindows/system32上に一誌手降ります。たまにpath設定で上記のパスが外れている場合は実行できない場合があるみたいなので、一度試してだめならば、c:\windows\system32に移るかパスの設定をした上で実行してみた方がよさそうですね。(自分はパスが外れてました)
Installing Android NDK
Windows 환경에서는 NDK를 이용하기 위해 cygwin의 설치가 불가피합니다.
cygwin의 설치시에 필요한 명령들의 임포트는 아래 페이지가 참고되었습니다.
Windows環境でNDKを利用するためには、cygwinのインストが不可欠です。
cygwinのインストの際に必要な命令の一覧は以下のページが参考になりました。
Windows環境でNDKを利用するためには、cygwinのインストが不可欠です。
cygwinのインストの際に必要な命令の一覧は以下のページが参考になりました。
OSX환경은 그 자체로 UNIX환경이라 따로 설치가 필요하진 않습니다.
OSX環境ではそれ自体がUNIX環境なので、cygwinは不要です。
그리고 별도의 path설정이 필요합니다.
path에는 android-ndk-r?의 패스가 설정될 필요가 있습니다.
path에는 android-ndk-r?의 패스가 설정될 필요가 있습니다.
windows의 경우 path값 이외에 ANDROID_NDK_ROOT = c:\android-ndk-r8
같은 추가설정이 필요한듯 합니다.
さらにpathの設定が必要です。
pathにはandroid-ndk-r?のフォルダのパスが設定される必要があります。
windowsではpathのほかにANDROID_NDK_ROOT=c:\android-ndk-r8
のような設定が必要の様です。
OSX쪽은 vi등을 이용하여 /Home/.bash_profile을 수정합니다
OSXの方はviなどを利用し、Home直下の.bash_profileを修正します。
ANDROID_NDK=/Applications/android-ndk-r8
export PATH=$PATH:${ANDROID_NDK}
Hello NDK
ndk소스의 빌드는 cygwin(windows) 혹은 terminal(OSX)에서 이루어집니다.
예를들어 샘플소스의 경우 ndk의 samples 폴더 밑에 있는 각 샘플 폴더의 루트상에서
ndk-build를 실행해주면 샘플이 빌드됩니다.
NDKソースのビルドはcygwin(windows)またはterminal(OSX)で行われます。
たとえば、サンプルで提供されたソースの場合NDKのsamplesフォルダに含まれた各サンプルフォルダのルート上でndk-buildを実行してやるとサンプルがビルドされます。
이렇게 빌드된 샘플은 Eclipse에서 New Project > Android folder > "Android Project from Existing Code" (API16기준) 에서 샘플의 루트폴더 (예를들면 samples/hellojni)를 지정해주면 실행할 수 있습니다. 일단 프로젝트를 임포트 하신 후에 디버깅을 실시하시면 되고, 실행시에는 AVD로 작성된 안드로이드 에뮬레이터가 필요하며, 구동중인 에뮬레이터를 사용할 수도 있습니다. 일반적으로 에뮬레이터는 한번 부팅하는데 상당한 시간이 소요되니, 디버깅시에는 에뮬레이터를 하나 구동해놓은 상태에서 빌드후 실행을 되풀이 할 필요가 있어보입니다.
こうしてビルドされたサンプルは、Eclipse上でNew Project > Android folder > "Android Project from Existing Code" (API16基準)でサンプルのルートフォルダ(例えばsamples/hellojni)を指定してあげると実行可能な状態になります。一旦プロジェクトをインポートした後、デバッグを実施できます。実行の際にはAVDで作成されたエミュレータが必要であり、駆動中のエミュレータを使用することも可能です。一般的にエミュレータは一度起動するのに相当な時間を要するので、デバッグの際はエミュレータを予め起動した状態でビルド・実行を繰り返したほうが効率的だろうと思います。
Hardware HAX Acceralation
소프트웨어 기반 VM을 사용하는 안드로이드 에뮬레이터는 심히 속도가 느립니다.
혹여 개발환경의 하드웨어가 VT, VT-x, vmx를 서포트하는 프로세서라면, 소프트웨어 기반이 아닌 하드웨어 기반 VM을 이용할수 있습니다.
일단 VM보단 나은정도 인듯하지만, 결국 큰 차이는 느낄수 없네요. 다만 GPU가속기능을 사용하게되면 화면상의 속도문제는 어느정도 해결을 볼수 있습니다. 이 부분은 굳이 VT기능이 없는 CPU라도 이용이 가능한것 같더군요.
ソフトウェア基盤のVMを使用するアンドロイドエミュレータは物凄く重いです。
もしマシーンのハードウェアがVT、VT-x、vmxをサポートするプロセッサーならば、ソフトウェア基盤でない、ハードウェア基盤のVMが利用できます。
一先ずはソフトウェアVMよりは多少マシになりますが。大きな差は得られませんでした。ただGPU加速機能を使うと、画面上感じられるパフォーマンスダウンの問題は多少解決できます。ここいらのISSUEはVT機能がなくとも利用可能のようです。
하드웨어로 에뮬레이터를 구동하기 위해선 다음 요소의 설치가 필요합니다.
ハードウェア加速を使うためには、以下の様な要素の導入が必要です。
SDK Manager
Extras > Intel Hardware Accelerated Execution Manager
API15 > Intel x86 Atom System Image
위 매니저 프로그램을 설치한후에, 다운로드된 폴더를 직접 찾아들어가 intelHaxm.exe를 실행합니다.
上記のマネージャプログラムをインストした後、ダウンロードされたフォルダに直接アクセスしてintelHaxm.exeを実行します。
저의 경우는
自分の場合は
の様な場所にダウンロードされてました。
API15의 이미지를 사용하는 점은 현 시점에서 API16에 Intel x86 Atom System Image가 없기때문입니다.
API15のイメージを利用しているのは、現時点でのAPI16にIntel x86 Atom System Imageが別途に添付されてなかったからです。
설치를 마쳤다면, AVD Manager에서의 타겟을 Android 4.0.3 - API Level 15로 지정해줍니다.
아래 CPU/ABI는 변경이 불가능하나, Intel Atom (x86)으로 표시가 되고 있는지 확인합시다.
インストを済ませたのなら、AVD ManagerでのターゲットをAndroid 4.0.3 - API Level 15で指定しておきます。その直下のCPU/ABIは変更ができないのですが、Intel Atom (x86)になっているかだけは確認しておきましょう。
추가적으로 Hardware의 프로퍼티 설정값에 GPU emulation : yes를 추가하여 GPU 가속화가 이루어지게끔 설정합니다. ( 이 설정이 이루어지지 않으면 큰 변화를 느끼긴 힘든것 같습니다 )
さらにハードウェアのプロパティー値にGPU emulation : YESを追加して、GPU加速化が行われるように設定しておきます(この設定なしでは大きな変化は感じられないようであります)
그리고 각 프로젝트의 Properties > android 에서 Project build target을 에뮬레이터의 이미지와 동일 버전의 API인 API 15(Android 4.0.3)으로 설정해줍니다.
이 값이 설정되지 않으면 구동 이미지(API15) 보다 최신버전으로 빌드된 샘플은 에뮬레이터에서 동작하지 않습니다.
さらに、各プロジェクトのProperties > androidでProject build targetをエミュレータのイメージと同様のバージョンのAPI15(Android 4.0.3)に設定しておきましょう。
この設定なしでは、駆動イメージ(API15)より最新のAPIでビルドされたサンプルはエミュレータで動作しません。
정상적으로 하드웨어 가속이 동작하고 있다면
正常にハードウェア加速が動作しているのならば
이런 메세지가 Eclipse 상의 console탭에 표시될것입니다.
このようなメッセージがEclipse上のConsoleタブに表示されるはずです。
NDKソースのビルドはcygwin(windows)またはterminal(OSX)で行われます。
たとえば、サンプルで提供されたソースの場合NDKのsamplesフォルダに含まれた各サンプルフォルダのルート上でndk-buildを実行してやるとサンプルがビルドされます。
이렇게 빌드된 샘플은 Eclipse에서 New Project > Android folder > "Android Project from Existing Code" (API16기준) 에서 샘플의 루트폴더 (예를들면 samples/hellojni)를 지정해주면 실행할 수 있습니다. 일단 프로젝트를 임포트 하신 후에 디버깅을 실시하시면 되고, 실행시에는 AVD로 작성된 안드로이드 에뮬레이터가 필요하며, 구동중인 에뮬레이터를 사용할 수도 있습니다. 일반적으로 에뮬레이터는 한번 부팅하는데 상당한 시간이 소요되니, 디버깅시에는 에뮬레이터를 하나 구동해놓은 상태에서 빌드후 실행을 되풀이 할 필요가 있어보입니다.
こうしてビルドされたサンプルは、Eclipse上でNew Project > Android folder > "Android Project from Existing Code" (API16基準)でサンプルのルートフォルダ(例えばsamples/hellojni)を指定してあげると実行可能な状態になります。一旦プロジェクトをインポートした後、デバッグを実施できます。実行の際にはAVDで作成されたエミュレータが必要であり、駆動中のエミュレータを使用することも可能です。一般的にエミュレータは一度起動するのに相当な時間を要するので、デバッグの際はエミュレータを予め起動した状態でビルド・実行を繰り返したほうが効率的だろうと思います。
Hardware HAX Acceralation
소프트웨어 기반 VM을 사용하는 안드로이드 에뮬레이터는 심히 속도가 느립니다.
혹여 개발환경의 하드웨어가 VT, VT-x, vmx를 서포트하는 프로세서라면, 소프트웨어 기반이 아닌 하드웨어 기반 VM을 이용할수 있습니다.
일단 VM보단 나은정도 인듯하지만, 결국 큰 차이는 느낄수 없네요. 다만 GPU가속기능을 사용하게되면 화면상의 속도문제는 어느정도 해결을 볼수 있습니다. 이 부분은 굳이 VT기능이 없는 CPU라도 이용이 가능한것 같더군요.
ソフトウェア基盤のVMを使用するアンドロイドエミュレータは物凄く重いです。
もしマシーンのハードウェアがVT、VT-x、vmxをサポートするプロセッサーならば、ソフトウェア基盤でない、ハードウェア基盤のVMが利用できます。
一先ずはソフトウェアVMよりは多少マシになりますが。大きな差は得られませんでした。ただGPU加速機能を使うと、画面上感じられるパフォーマンスダウンの問題は多少解決できます。ここいらのISSUEはVT機能がなくとも利用可能のようです。
하드웨어로 에뮬레이터를 구동하기 위해선 다음 요소의 설치가 필요합니다.
ハードウェア加速を使うためには、以下の様な要素の導入が必要です。
SDK Manager
Extras > Intel Hardware Accelerated Execution Manager
API15 > Intel x86 Atom System Image
위 매니저 프로그램을 설치한후에, 다운로드된 폴더를 직접 찾아들어가 intelHaxm.exe를 실행합니다.
上記のマネージャプログラムをインストした後、ダウンロードされたフォルダに直接アクセスしてintelHaxm.exeを実行します。
저의 경우는
自分の場合は
C:\Users\cruwel\AppData\Local\Android\android-sdk\extras\intel\Hardware_Accelerated_Execution_Manager/와 같은 위치에 다운로드 되어 있었습니다.
の様な場所にダウンロードされてました。
API15의 이미지를 사용하는 점은 현 시점에서 API16에 Intel x86 Atom System Image가 없기때문입니다.
API15のイメージを利用しているのは、現時点でのAPI16にIntel x86 Atom System Imageが別途に添付されてなかったからです。
설치를 마쳤다면, AVD Manager에서의 타겟을 Android 4.0.3 - API Level 15로 지정해줍니다.
아래 CPU/ABI는 변경이 불가능하나, Intel Atom (x86)으로 표시가 되고 있는지 확인합시다.
インストを済ませたのなら、AVD ManagerでのターゲットをAndroid 4.0.3 - API Level 15で指定しておきます。その直下のCPU/ABIは変更ができないのですが、Intel Atom (x86)になっているかだけは確認しておきましょう。
추가적으로 Hardware의 프로퍼티 설정값에 GPU emulation : yes를 추가하여 GPU 가속화가 이루어지게끔 설정합니다. ( 이 설정이 이루어지지 않으면 큰 변화를 느끼긴 힘든것 같습니다 )
さらにハードウェアのプロパティー値にGPU emulation : YESを追加して、GPU加速化が行われるように設定しておきます(この設定なしでは大きな変化は感じられないようであります)
그리고 각 프로젝트의 Properties > android 에서 Project build target을 에뮬레이터의 이미지와 동일 버전의 API인 API 15(Android 4.0.3)으로 설정해줍니다.
이 값이 설정되지 않으면 구동 이미지(API15) 보다 최신버전으로 빌드된 샘플은 에뮬레이터에서 동작하지 않습니다.
さらに、各プロジェクトのProperties > androidでProject build targetをエミュレータのイメージと同様のバージョンのAPI15(Android 4.0.3)に設定しておきましょう。
この設定なしでは、駆動イメージ(API15)より最新のAPIでビルドされたサンプルはエミュレータで動作しません。
정상적으로 하드웨어 가속이 동작하고 있다면
正常にハードウェア加速が動作しているのならば
[2012-07-06 10:31:58 - Emulator] HAX is working and emulator runs in fast virt mode
이런 메세지가 Eclipse 상의 console탭에 표시될것입니다.
このようなメッセージがEclipse上のConsoleタブに表示されるはずです。
2012년 7월 5일 목요일
Developing Direction
이 블로그에서는 OpenGL ES 2.0을 이용하여 자체적인 모델 쉐이딩을, 구체적으로는
3D를 이용하여 모바일에서 표현가능한 최대한의 비실사적 2D효과(Non-Photorealistic Renderer)의 제작을 목적으로 합니다.
このブログでは、OpenGL ES 2.0を用いて、カスタマイズされたモデルシェーディングを、さらに詳しく説明するならば、3Dを用いて、モバイル上で表現可能な最大限の非実写の2D効果(Non-Photorealistic Renderer)を得ることを目標とします。
우선적인 목표는 로우폴리곤의 자연스러운 표현을 위한 버지어곡면의 묘사, 그리고 수채화 스타일의 표현방법을 목적으로 합니다.
優先的な目標はローポリゴンの自然な表現のためのベジェー曲面の描写、さらには水彩スタイルの表現を目的といたします。
3D를 이용하여 모바일에서 표현가능한 최대한의 비실사적 2D효과(Non-Photorealistic Renderer)의 제작을 목적으로 합니다.
このブログでは、OpenGL ES 2.0を用いて、カスタマイズされたモデルシェーディングを、さらに詳しく説明するならば、3Dを用いて、モバイル上で表現可能な最大限の非実写の2D効果(Non-Photorealistic Renderer)を得ることを目標とします。
우선적인 목표는 로우폴리곤의 자연스러운 표현을 위한 버지어곡면의 묘사, 그리고 수채화 스타일의 표현방법을 목적으로 합니다.
優先的な目標はローポリゴンの自然な表現のためのベジェー曲面の描写、さらには水彩スタイルの表現を目的といたします。
This blog is...
이 블로그는 취업전 안드로이드 입문과정을 기록한 개발일지입니다.
취업예정관계상 한글 및 일본어로 작성합니다
このブログは僕個人の就職活動の一環として記録したアンドロイド入門過程日誌です。
就職先の都合の関係上、韓国語および日本語で作成いたします。
이곳에 기록된 내용이 한국이나 일본, 양측 어느쪽에라도 조금이나마 도움이 되었으면 하는 바램입니다.
ここに記された内容が韓国か日本、両国どちらかに多少なりともお助けにならばと思います。
저의 작업 환경은 다음과 같습니다.
自分の作業環境は以下の様になっております。
Mobile Device
LG Optimus LTE2, LGT locked model
Developing machine
HP Pavilion, dv7-6c95dx, windows 7 home premium (US)
2008 Macbook Pro 15' early, OSX Lion (KO)
2006 MacPro 1,1 5GB memory, 2.66 dual xeon x2 (JA)
API
Eclipse JUNO (Classic) + Android SDK 4.1 (API16) + Android NDK r8
VT enabled with (HP Pavilion)
취업예정관계상 한글 및 일본어로 작성합니다
このブログは僕個人の就職活動の一環として記録したアンドロイド入門過程日誌です。
就職先の都合の関係上、韓国語および日本語で作成いたします。
이곳에 기록된 내용이 한국이나 일본, 양측 어느쪽에라도 조금이나마 도움이 되었으면 하는 바램입니다.
ここに記された内容が韓国か日本、両国どちらかに多少なりともお助けにならばと思います。
저의 작업 환경은 다음과 같습니다.
自分の作業環境は以下の様になっております。
Mobile Device
LG Optimus LTE2, LGT locked model
Developing machine
HP Pavilion, dv7-6c95dx, windows 7 home premium (US)
2008 Macbook Pro 15' early, OSX Lion (KO)
2006 MacPro 1,1 5GB memory, 2.66 dual xeon x2 (JA)
API
Eclipse JUNO (Classic) + Android SDK 4.1 (API16) + Android NDK r8
VT enabled with (HP Pavilion)
피드 구독하기:
글 (Atom)


