|
JSR-184 Public Review Draft - Apr. 30, 2003. | ||||||||||
PREV NEXT | FRAMES NO FRAMES |
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.
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.
Date
|
Version
|
Description
|
---|---|---|
11-Sept-2002
|
EG Draft 1
|
Based on the 2nd Expert Group meeting
|
20-Sept-2002
|
EG Draft 2
|
|
31-Oct-2002
|
EG Draft 3
|
For review in the 3rd EG meeting
|
15-Nov-2002
|
EG Draft 4
|
Based on the 3rd EG meeting
|
29-Nov-2002
|
EG Draft 5
|
|
17-Dec-2002
|
EG Draft 6
|
|
16-Jan-2003
|
EG Draft 7
|
For review in the 4th EG meeting
|
31-Jan-2003 | EG Draft 8 | Updated as per EG meeting resolutions. |
14-Feb-2003 | EG Draft 9 | First Community Review candidate. |
19-Feb-2003 | EG Draft 10 | Community Review specification. |
11-Apr-2003 | EG Draft 11 | Updated according to Community Review feedback. |
30-Apr-2003 | EG Draft 12 | Public Review specification. |
Nokia (Specification Lead)
Aplix Corporation
ARM
Bandai Networks
Cingular Wireless
Cellon France
France Telecom
Fuetrek
HI Corporation
Hybrid Graphics
In-Fusio
Insignia Solutions
Intel
Intergrafx
MathEngine
Motorola
Research In Motion
Siemens
Sony Ericsson Mobile Communications
Sun Microsystems, Inc.
Superscape
Symbian
Texas Instruments Inc.
3d4W
Vodafone
Zucotto Wireless
Fredrik Kekäläinen (Fathammer)
Mika Tammenkoski (Sumea)
Term
|
Definition
|
---|---|
MUST
|
The associated definition is an absolute requirement
of this specification.
|
MUST NOT
|
The definition is an absolute prohibition of this
specification.
|
SHOULD
|
Indicates a recommended practice. There may exist
valid reasons in particular circumstances to ignore this recommendation,
but the full implications must be understood and carefully weighed before
choosing a different course.
|
SHOULD NOT
|
Indicates a non-recommended practice. There may
exist valid reasons in particular circumstances when the particular behavior
is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior described
with this label.
|
MAY
|
Indicates that an item is truly optional.
|
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.
- The API must support retained mode access (that is, a scene graph).
- The API must support immediate mode access, with features similar to OpenGL.
- The API must support mixing and matching of immediate and retained mode access.
- The API must not include optional parts (that is, all methods must be implemented).
- The API must have importers for meshes, textures, entire scene graphs, etc.
- The API must be efficiently implementable on top of OpenGL ES.
- The API must use the native float data type of CLDC 1.1, not introduce a custom type.
- The API must be efficiently implementable without floating point hardware.
- The API should be implementable within 100 kB on a real mobile terminal.
- The API must be structured so that garbage collection is minimized.
- The API must be interoperable with related Java APIs, especially with MIDP.
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.
|
JSR-184 Public Review Draft - Apr. 30, 2003. | ||||||||||
PREV NEXT | FRAMES NO FRAMES |