Overview  Package  Class  Use  Tree  Deprecated  Index  Help 
JSR-184 Public Review Draft - Apr. 30, 2003.
 PREV   NEXT FRAMES    NO FRAMES    

Mobile 3D Graphics API (JSR-184)

This document contains the Public Review draft (EG Draft 12) of the JSR184 Mobile 3D Graphics API for J2ME.

See:
          Description

Packages
javax.microedition.m3d This package contains the whole Mobile 3D Graphics API (M3D), comprising about 250 methods in about 30 classes.

 

This document contains the Public Review draft (EG Draft 12) of the JSR184 Mobile 3D Graphics API for J2ME.

Preface

This specification defines the JSR-184 Mobile 3D Graphics API for J2ME. This specification is a work in progress and is subject to changes before the final specification. The Public Review specification is intended to provide people outside of the Java Community with access to the specification in development and an opportunity to provide comments to the Expert Group. This specification indicates the direction the Expert Group is intending to take but any part of the document may change before the final specification. This document and all associated documents are subject to the terms of the JCP agreements (i.e. JSPA and/or IEPA).

The Mobile 3D Graphics API is an optional package. An optional package can be adopted to existing J2ME profiles. A profile of J2ME defines device-type-specific sets of APIs for a particular vertical market or industry. The main target platform of this optional API is J2ME/CLDC, used with profiles such as MIDP 1.0 or MIDP 2.0.

Introduction

The objective of the JSR-184 Expert Group is to provide an efficient 3D Graphics API suitable for the J2ME platform, in particular CLDC/MIDP. The API is targeted at CLDC class of devices that typically have very little processing power and memory, and no hardware support for 3D graphics or floating point math. The API has been defined such that implementations on that kind of hardware are feasible. However, the API also scales up to higher-end devices featuring a color display, a DSP, a floating point unit, or even specialized 3D graphics hardware.

Where to start reading

Technical details of the API can be found in the package overview and the individual class descriptions; see especially the Graphics3D class. To see how the API is used in practice, refer to the example MIDlets at the end of the Package overview.

Background

The JSR-184 specification is based on the requirements, summarized below, that were agreed on by the Expert Group. The motivation for each requirement is presented in the paragraphs following the summary. Several applications were identified for the Mobile 3D Graphics API, including games, map visualization, user interfaces, animated messages, product visualization, and screen savers. Each of these have different needs: some require simple content creation, some require high polygon throughput, yet others require high quality still images with special effects.

It is clear that such a wide spectrum of different needs cannot be fulfilled by a scene graph API alone, nor an immediate mode API alone. It is also clear that having two separate APIs would lead to developer confusion and sub-optimal usage of precious memory space. Rather, there must be only one indivisible API, with only one RI and TCK, that covers both types of access in a unified way. A developer should be able to use either one, or both at the same time, depending on the task at hand.

The immediate mode (or low-level) part of the API should be a subset of OpenGL with no added functionality. That is, the low-level features should be compatible with OpenGL ES, which is being standardized by Khronos. For the Reference Implementation, the scene graph (or high-level) part must be built on top of the low-level interface, and shall never bypass it when rendering. This ensures that the scene graph does not include rendering features that cannot be implemented directly with the low-level interface. The low-level implementation may then be changed freely, or even accelerated with dedicated hardware.

In many cases, there is little else to an application than displaying a scene and playing back some animation created in a 3D modeling tool. This should not require much Java programming. Even in more demanding cases, it greatly speeds up development if it is easy to import objects and animations into a midlet. Therefore, the API must provide importer functions for different data types, such as textures, meshes, animations, and scene hierarchies. The data must be encoded in a binary format for compact storage and transmission.

Most mobile terminals do not have hardware support for floating point processing. This should be reflected in the API, so that it can be efficiently implemented using integer arithmetic. However, programming geometry with fixed point mathematics is difficult and error prone, so some floating point support must be available. Therefore, this API requires CLDC 1.1 to be implemented.

Like all MIDP APIs, we need to strive for as compact an implementation as possible. It should be possible to implement the API in less than 100 kB of ROM space, including the native graphics engine, Java bindings, and content importing facilities. To minimize garbage collection, the API should be structured so that using it does not require repetitive creation of objects.

The API must be tightly integrated with MIDP, such that 2D and 3D graphics can be efficiently rendered on the same Canvas or Image, for example. Also, the decision of whether to use double buffering or not should be delegated to the MIDP implementation.

 Overview  Package  Class  Use  Tree  Deprecated  Index  Help 
JSR-184 Public Review Draft - Apr. 30, 2003.
 PREV   NEXT FRAMES    NO FRAMES    
Copyright © 2003 Nokia Corporation. See the Copyright Notice for details.