㈠ qt android 怎樣使用opengl
qt 可以通過QGLWidget運行opengl。QGLWidget繼承QWidget，能夠直接在裡面調用opengl的介面。這個在qt文檔里有具體說明，也有相關例子，所以不贅述了。但是無法在正式軟體裡面執行，為什麼？因為正式軟體是用QGraphicsScene這個場景類操作和操作一切item,而用QGraphicsView將其顯示出來，而每一個item都是QGraphicsItem的子類。QGLWidget並不是QGraphicsItem類，我曾經嘗試用普通的QWidget類那樣，通過proxy來加進QGraphicsItem，但是沒有成功。或許有方法，但是沒有找到。
於是我放棄了用QGLWidget來操作opengl的打算，尋找直接在QGraphicsItem中操作opengl的方法。通過查看文檔和示例代碼，找到了這個方法：
1 往qt工程文件里添加opengl以及對應的lib。
2 對QGraphicsView進行一個三維對話框的指定，代碼如下：
QGLWidget *widget = new QGLWidget(QGLFormat(QGL::SampleBuffers));
widget->makeCurrent();
QGraphicsView view;
view.setViewport(widget);
上述代碼告訴了 QGraphicsView 類當前繪制的對象是支持opengl的。於是所有的場景中的item都將繪制到widget 上。
3 寫一個QGraphicsItem的繼承類，特別要重寫paint函數。代碼如下：
void XXX::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget)
{
painter->beginNativePainting();
glColor3f(0.5,1.0,0.2);
glBegin(GL_TRIANGLES);
glVertex3f(100.0,100.0,-100.0);
glVertex3f(150.0, 100.0, -100.0);
glVertex3f(100.0, 150.0, -100.0);
glEnd();
painter->endNativePainting();
}
上面這個函數主要是用opengl介面繪制了一個三角形。記住，在opengl繪制之前一定要執行painter->beginNativePainting()以及painter->endNativePainting()這兩個語句。
QGraphicsScene、 QGraphicsView和QGraphicsItem的關系可以查閱相關文檔，也不贅述了。
不過我按照這個方式畫的三角形，怎麼也在窗口上顯示不出來，找了半天才發現問題在這個函數上QGraphicsItem::boundingRect()。這個函數是 干什麼用的呢？主要用來返回該item的初始化大小，這個大小不會輕易改變，後續的改變都可以通過矩陣來完成，但是初始大小是不變的。QGraphicsView通過這個矩形來判斷當前item是不是需要重繪，如果在重繪區外，則不調用重繪函數了。同時碰撞檢測之類，也可以用這個矩形來判斷。原來，item本身的矩陣外包框不對，所以才導致了重回不出來，改過來就正確了。
上面說的很潦草，具體怎麼改的步驟就不說了。要想正確的繪制，必須得弄清楚坐標系的關系，QGraphicsScene、QGraphicsView以及QGraphicsItem這三個坐標繫到底是什麼關系。我看了文檔，也自己進行了測試，但是感覺文檔和測試的結果有些出入。具體出入不說了。說一下自己得心的吧。
先說明：涉及到一切大小和長度，都是像素大小，至少我測試的結果是這樣的。
在建立QGraphicsScene對象的時候，有一個構造函數是矩形，這個矩形是什麼含義呢？經過測試，發現這個矩形並沒有指定彈出窗口的位置，比如，我把矩形的左上角點指定為-1000，-1000，顯示的位置和1000,1000是一樣的，而長度則正確指定了（當然，可能會有滾動條）。所以，這個矩形的左上角點並不是顯示的窗口的位置，而是它在邏輯上的左上角點。我們顯示一切item，都是以這個邏輯上的坐標系為准來繪制的。比如，左上角點是-1000，-1000，而item的位置在-500，-500，則這個-500，-500相當於在顯示窗口的左上角往下各加500個像素的坐標的位置。
那麼 QGraphicsItem的boundingRect是什麼意思呢？返回的是什麼大小？是以什麼坐標系顯示的大小？首先，這個大小肯定是以像素為單位的，其次，這個矩形的坐標是以QGraphicsScene的邏輯坐標為準的。當然這個大小是沒有任何矩陣疊加的大小。有了矩陣疊加後，實際的矩形可能會發生變化。假如在boundingRect中指定矩形的左上角為100，100，那麼最終體現的位置則是QGraphicsScene邏輯坐標100,100的位置，如果QGraphicsScene的左上角點已經指定為-1000，-1000，那麼這個位置實際上就是離窗口左上角點1100,1100的位置（由於有滾動條，所以也不一定是這個長度。）
那麼在QGraphicsItem的paint函數中進行了opengl繪制用的是什麼坐標呢？其實用的也是QGraphicsScene的邏輯坐標。如上面的例子，繪制的直角三角形直角頂點是0,0，那麼顯示的位置就是距離顯示窗口左上角點1000，1000的位置。不過opengl的所有繪制都是沒有矩陣疊加的基礎上，如果用矩陣疊加，則顯示的位置肯定和指定的有區別了。比如，我用setPos強制指定一個位置，這個位置將和opengl繪圖坐標相疊加，最後顯示到窗口上。我推測setPos其實是改變了矩陣，是一個平移矩陣。
㈡ android opengl製作地圖 繪制圖片的問題
是要自己開發地圖引擎，還是需要用地圖引擎類似的功能啊。。。如果是後者那麼android的Google Map API 就是基於OpenGL ES 的，如果是想自己開發地圖引擎，既然Google做了，所以說是可行的，至於感覺如何只有自己做過了才知道啊
㈢ android opengl技術主要有哪些應用
1. 一般應用app開發，用不到
2. 游戲開發等
㈣ 如何在Android上使用OpenGL ES 2.0繪制點
FrameBuffer對象的概念可以參見前面文章AndroidOpenGLES開發教程(23)：FrameBuffer。簡單的和2D圖像類比，FrameBuffer如果對應到二維圖形環境中，就是一個2D的內存數組空間，預設情況為屏幕的顯存，也可以創建Offscreen內存空間，此時FrameBuffer可以是一個二維數組，數組每個元素代表一個像素顏色。對於三維圖形來說，除了需要代表顏色的二維數組（ColorBuffer），還需要深度二維數組（DepthBuffer)或遮罩數組(StencilBuffer)，因此在OpenGL中的FrameBuffer為上述ColorBuffer,DepthBuffer,StencilBuffer的集合。如果手機具有GPU，其預設的FrameBuffer也是3D屏幕顯示區域。通過OpenglES擴展支持，應用程序也可以創建內存中的FrameBuffer對象（不用於屏幕顯示）。通過這種應用程序創建的FrameBuffer對象，OpenGL應用可以將圖像顯示輸出重新定向到這個非屏幕顯示用FrameBuffer對象中，類似於二維圖形繪制中常用的Offscreen技術。和預設的屏幕顯示FrameBuffer一樣，由應用程序創建的FrameBuffer對象也是由ColorBuffer,DepthBuffer和StencilBuffer(可選）的集合組成。這些Buffer在FrameBuffer對象中可以稱為FrameBuffer-attachable圖像，FrameBuffer定義了一些接入點(AttachmentPoint)可以用於連接（Attach）這些Buffer數組。OpenGLES定義了兩種FrameBuffer-attachable圖像，Texture和renderbuffer，簡單的可以將Texture理解為Colorbuffer或是2D圖像，renderbuffer對應於depthbuffer。
㈤ Android opengl es 2.0怎麼學習
OpenGLES是一個讓人崩潰的東西。在Andorid手機上做3D還就得用它。把我記的一些筆記分享在這里吧：
Android OpenGL ES簡介 20011-6-3
Android系統使用OpenGL的標准介面來支持3D圖形功能，android 3D圖形系統也分為java框架和本地代碼兩部分。
本地代碼主要實現的OpenGL介面的庫，在Java框架層，javax.microedition.khronos.opengles是java標準的OpenGL包，
android.opengl包提供了OpenGL系統和Android GUI系統之間的聯系。
Android的本地代碼位於frameworks/base/opengl下,
JNI代碼位於frameworks/base/core/com_google_android_gles_jni_GLImpl.cpp和frameworks/base/core/com_google_android_gles_jni_EGLImpl.cpp，
java類位於opengl/java/javax/microedition/khronos下
本地測試代碼位於frameworks/base/opengl/tests。包括angeles、fillrate等14個測試代碼，這些代碼都可以通過終端進行本地調用測試（模擬器中使用adb shell）。
OpenGL ES 1.x
固定管線操作，支持glVertexPointer()等函數，不支持GLSL。頭文件在ndk的GLES目錄下，庫文件是libGLESv1_CM.so。
OpenGL ES 2.x
可編程管線操作，不兼容1.x，不支持固定管線操作，例如glVertexPointer()等函數。支持GLSL(還必須用這個來編程)。頭文件在ndk的GLES2目錄下，庫文件是libGLESv2.so。
OpenGL ES學習 2011-6-30
OpenGL定義了自己的數據類型。應該堅持使用這些OpenGL的數據類型，從而保證可移植性和效率。
OpenGL ES 目前不支持64位數據類型。
OpenGL ES 只支持三邊形。
OpenGL ES 只支持gl開頭的函數，glu庫都不支持。
OpenGL ES 從 OpenGL中刪除的功能：
1. glBegin/glEnd
2. glArrayElement
3. 顯示列表
4. 求值器
5. 索引色模式
6. 自定義裁剪平面
7. glRect
8. 圖像處理(這個一般顯卡也沒有，FireGL/Quadro顯卡有)
9. 反饋緩沖
10. 選擇緩沖
11. 累積緩沖
12. 邊界標志
13. glPolygonMode
14. GL_QUADS,GL_QUAD_STRIP,GL_POLYGON
15. glPushAttrib,glPopAttrib,glPushClientAttrib,glPopClientAttrib
16. TEXTURE_1D、TEXTURE_3D、TEXTURE_RECT、TEXTURE_CUBE_MAP
17. GL_COMBINE
18. 自動紋理坐標生成
19. 紋理邊界
20. GL_CLAMP、GL_CLAMP_TO_BORDER
21. 消失紋理代表
22. 紋理LOD限定
23. 紋理偏好限定
24. 紋理自動壓縮、解壓縮
25. glDrawPixels,glPixelTransfer,glPixelZoom
26. glReadBuffer,glDrawBuffer,glCopyPixels
OpenGL ES 2.0 2011-10-9
2.0和1.1不兼容。
- 2.0使用的頭文件是ndk的include目錄下的GLES2目錄，有gl2.h,gl2ext.h,gl2platform.h，而1.1使用的是GLES目錄。
- 2.0使用的庫文件是ndk的lib目錄下的libGLESv2.so，而1.1使用的是libGLESv1_CM.so。
- 2.0中取消了很多1.1函數，例如glMatrixModel和glLoadIdentity等。
OpenGL著色語言（GLSL――OpenGL Shading Language）
- 使用2.0，必須學此語言。因為很多1.1的函數都被取消了。
san-angeles NDK OpenGL ES 1.1的例子程序 2012-3-8
San Angeles，查維基網路，是一個虛構的未來概念城市，位於南加州。常在電影中出現，來源自Los Angeles和San Diego.
該程序的演示效果是，觀察一個宏偉的城市，地面是鏡面有建築倒影，城市中有飛船飛過。前後有5、6個觀察點，而且鏡頭在每個觀察點不停的移動。
這個例子，用NDK(C++)調用OpenGL ES 1.1來繪制了San Angeles這個城市。基本上全部使用了NDK，Java程序只有1個。
用vc2005演示一下，目的通過跟蹤代碼了解一些細節。方法是：
- 將jni下所有的.h文件，以及demo.c,app-win32.c復制出來，放在一個專門的目錄下，然後改造成用OpenGL的而不是ES的。（或者乾脆刪除大段的繪制代碼，保證編譯通過）
首先分析Java代碼
- DemoActivity.java，這是唯一的Java文件，它主要需要下列4個jni的介面：
- private static native void nativeInit(); // 初始化
- private static native void nativeResize(int w, int h);
- private static native void nativeRender(); // 繪制1幀
- private static native void nativeDone();
其次分析C++代碼 app-android.c
- 首先，調用了importGLInit()，動態導入OpenGL的庫。
- 其次，調用了 appInit()，在內存中建立了平台無關的3D對象集合。建立方法是用一個數組，用類似畫圓拔高的方式產生諸多三角形。
- 然後，在每個時鍾周期中調用appRender()，細節是：
- prepareFrame(width, height); // 准備OpenGL ES繪制框架。其實就是清空顏色和深度緩沖，重置投影和模型矩陣。
- camTrack(); // 算好在當前時鍾周期，鏡頭的位置、朝向及焦距等。然後調用gluLookAt來實現。
- configureLightAndMaterial(); // 設置光源和材質
- drawModels(-1); // 先繪制倒影(其實就是將所有模型z軸倒過來畫)
- 第一個循環，是畫精緻的物體
- 第二個循環，是畫運動的物體
- drawGroundPlane(); // 再繪制鏡子一般的地面。在繪制前取消光照，打開混合，然後繪制。繪制後還原狀態。
- drawModels(1); // 再繪制所有模型
- drawFadeQuad(); // 最後繪制淡出框，用融合的方式畫一個遮住整個視口的2D框，融合系數和時間相關。
㈥ android opengl es畫動畫的時候老是出現抖動，不流暢是為什麼求高人給個android opengl動畫的例子。
天真了, 嘿嘿. 稍微說兩句, 1. 其實正是微軟造成了這種很亂(所謂的百花齊放)的局面, 出於商業的目的, 微軟會在別人制定好標准之後再搞一套自己的東西, 但是又常常搞不過專攻這一塊的領域. (舉例: 在資料庫上做SQL Server, 效率甚至低於開源的My SQL, 更不用說是Oracle了; 游戲領域的帝國時代, 和暴雪的差遠了; .net和C#框架是針對Java的, 但又沒實現跨平台, 徒有其型 ... 不勝枚舉). 2. 微軟的軟體的特點, 表面文章做的很好, 但是內部穩定性不行.(不能說沒有優勢, 在有些方面還是方便到客戶的, 但缺陷是長期的) Windows Vista像noodle的代碼, 到Word我每天必花時間解決它的莫名奇妙的毛病. Visual Studio也一樣, intellisense模塊會把你卡死, UTF-8的文件頭Bug拒絕修訂等等. 3. 微軟喜歡把簡單的問題復雜化, 各種軟體動輒幾個G幾十個G上來, 用戶每天日常用到的功能所佔的比例很低, 大量的計算機資源被消耗在了用戶從來用不到的地方. 而且因為很多沒必要的復雜, 用戶對它原理的了解會增加很多不必要的障礙. 總結: 微軟的軟體對初學者很方便, 這是一個事實. 它把大量的投入投在的這一塊. 但是當你學習深入了, 水平提高了, 你會發現微軟的軟體很不方便: 1. 會讓你白白浪費很多時間去學沒必要學的東西, 而且由於它對自己技術的壟斷, 有新的技術提出來, 你學的東西很快就淘汰. 還得從頭學. 2. 拿Visual Studio來說, 我用過VC6, VC2003和VC2005, 後面幾款由於失望沒再使用了. 到VC2005還沒有很方便的提供.h和對應文件名的.cpp簡單快速切換的基本功能(或者我沒找到, 菜單工具條里沒有).(其他開源的IDE都有, 而且很實用), 一大堆讓人看的頭暈的功能配置, 把有用的藏起來了. 3. 拿Win7來說, 前面我有個朋友區域網共享發生連不上的問題. 我在WinXP下有經驗, 就叫我幫忙解決, 我查了很多資料折騰了一整天, 因為變化太大, 沒有成功, 也不知道原因(反正就是有Win7特有的許可權問題, 而許可權點不亮, 用網上搜索到的所有方法試驗失效). 我在Linux上也做過配置, 經驗上來說Linux上第一次搞定這種問題會比Windows麻煩, 因為很多專有的配置命令, 但搞定了一次之後, 不會發生這樣情況, 而且就是搞不定, 一般都能找到原因.(開源的好處) 這幾年微軟處於中年期, 基本已經快開始走下坡路了. 它的技術是厲害, 裡面有很多牛人, 我也見過不少, 也很佩服(比如說James Larus, 我在國外的時候見過一面). 即使裡面的小員工也真的很強. 但我不覺得它還能壟斷, google反而是在上升期. 這不是具體技術的問題, 而是理念的問題. 以上僅代表個人觀點, 不針對任何組織和個人, 難免有偏頗之處, 請指正.
我是非常用心回答的，請加分
eyafhfsgkq5761672011-9-22 11:58:40
㈦ 求 android opengl es 2.0 的開發文檔 教程之類 或者例子（有注釋的java方面）分多多給
[email protected]， 給我發個郵箱地址吧， 給你發個教程，裡面有大量 3D開發的例子。我起步就看的這個。
《Android3D游戲開發技術詳解與典型案例》 60M大小。