J2ME Mobile 3D Graphics API(M3G)文档 一.简介

Overview

序言

 

 

 

这份文档包含了J2ME的Mobile 3D Graphics API (简称 “M3G”)的规范.这个规范由Java Community Process (“JCP”)在Java Specification Request 184 (“JSR-184”)下定义.这个规范是JCP合同期限的主体内容. (也就是 JSPA and/or IEPA).

 

 

 

Mobile 3D Graphics API是一个可选包.一个可选包可以配置在已经存在的J2ME配置上.一个J2ME的配置针对特殊垂直的行业和市场定义了设备类型规范集合的API.这个可选API的主要目标平台是J2ME/CLDC,象MIDP 1.0 or MIDP 2.0使用了这些配置.可是这些API依然能够能够在J2ME/CDC或者任何的通用Java平台所执行.

 

这些API的技术细节可以在包的纵览和独立的类说明中找到.尤其可以查看Graphics3D类.要知道这些API是怎么在实践中使用的可以参考在章节末尾MIDlets的范例.

背景

Mobile 3D Graphics API专家组的主要任务是为J2ME平台提供一组有效的3D图像API,特别是对CLDC/MIDP.这些API针对标准的只有非常有限的处理能力和内存和无硬件支持3D图像和浮点运算能力的设备的CLDC类设计.这些API已经定义在这类硬件上的可行的实现方法.

 

 

 

可是,这些API依然需要提高到一个高价位的设备来支持描述一个颜色显示,一个DSP,一个浮点单元甚至专门的3D图像硬件.

M 3G规范基于专家组通过的基本的需求和概述.每个需求的联系都展现在下面的概要后面的图里.

        •API必须支持保留模式(retained mode)存取(就是scene图像)

        •API必须支持近似于OpenGL即时模式(immediate mode)存取的特性.

        •API必须支持即时模式和保留模式存取的混和和匹配.

        •API必须具有面(meshes),材质(textures),整体场景图像(entire scene graphs)等等的导入.

•API必须有效的在OpenGL ES上执行.

        •API必须使用Java本地的浮点数据类型,不导入一个自定义的类型.

        •API必须有效的在无浮点的硬件上执行

        •API应该可以在真实的150KB大小的移动终端上运行.

        •API必须构造,所以垃圾回收要最少.

        •API必须与已经存在的Java APIs特别是MIDP兼容.

很多应用可以使用Mobile 3D Graphics API来实现,包括游戏,地图显示,用户界面,动画消息,产品可视化演示和屏保.这些应用每个都有不同的需求.有些需要简单的内容创作,有些需要高速多边形处理,也有些需要高质量的带有特殊效果的图片.

显而易见的是如此多的不同的宽光谱需求不可能使用一个背景图像API或一种即时模式API实现.另外拥有两个独立的API可以导致开发者混乱和内存空间的不充分利用.更适当的应该必须只有一个使用RI和TCK的可见的API,来使用统一的方法满足不同存取方式的需要.一个开发者可以根据手头任务的需要选择只使用一个或两个同时使用.

即时模式(或低层模式)部分API应该是没有修改的OpenGL的API的子集.更确切的说,低层特性应该与Khronos 的规范化的OpenGL ES兼容.在实现的定义规范中,场景图像(高层)部分必须建立再底层接口之上并且不能在渲染的时候绕开底层实现.这就保证了场景图像不包含不能直接通过底层接口实现的材质渲染.底层的执行可以随意的改变,甚至直接使用硬件加速.

很多情况下,在一些程序中使用这些效果比显示一个场景和播放一些使用3D模型建立的动画使用少的多.这就不需要很多Java编程.甚至实在更多的要求的情况下, 如果它能简单的导入对象和动画到一个midlet中可以很大程度的加快开发速度.因此,API必须提供导入不同数据类型的功能,比如材质,面,动画和场景层级.这些数据必须转化为二进制格式来压缩存储和传输.

大多数移动终端不支持硬件浮点运算.这些功能将在API中实现.所以API可以高效率的执行整型计算.即使这样,因为使用混和数值计算编程还是复杂和容易出错,无论是否可行API都应该使用浮点数值.混和数值计算不应该使用.同样,必须Java的浮点类型来替代一个自定义的浮点类型或转换浮点值为一个整型.这样做的结果就是API不能在CLDC 1.0上执行.

如所有针对MIDP的API一样,我们需要尽量压缩执行文件.这就需要能够在少于150kb的ROM空间中执行API,包括本地的图形引擎.Java类文件(ROM中的)和内容导入设备.为了最小化垃圾回收,API结构化生成,所以在使用的时候不需要重复的建立对象.

API必须完全从MIDP’s LCDUI中衍生,比如2D,3D图像可以从同一Canvas或Image高效的绘制.比如是否使用双缓冲或不应该使用MIDP程序托管.API应该能够与如AWT等的GUI API绑定.

 

大多数移动终端不支持硬件浮点运算.这些功能将在API中实现.所以API可以高效率的执行整型计算.即使这样,因为使用混和数值计算编程还是复杂和容易出错,无论是否可行API都应该使用浮点数值.混和数值计算不应该使用.同样,必须Java的浮点类型来替代一个自定义的浮点类型或转换浮点值为一个整型.这样做的结果就是API不能在CLDC 1.0上执行.

如所有针对MIDP的API一样,我们需要尽量压缩执行文件.这就需要能够在少于150kb的ROM空间中执行API,包括本地的图形引擎.Java类文件(ROM中的)和内容导入设备.为了最小化垃圾回收,API结构化生成,所以在使用的时候不需要重复的建立对象.

API必须完全从MIDP’s LCDUI中衍生,比如2D,3D图像可以从同一Canvas或Image高效的绘制.比如是否使用双缓冲或不应该使用MIDP程序托管.API应该能够与如AWT等的GUI API绑定.