2.1 Please describe the proposed Specification:

This proposal specifies a lightweight, interactive 3D graphics API, which sits alongside J2ME and MIDP as an optional package.

The API shall be flexible enough for a wide range of applications, including games, animated messages, screen savers, custom user
interfaces, product visualization, and so on. It shall not be limited to any particular type of application. It shall also be simple
enough to use to make rapid development of compelling 3D applications feasible.

The API is targeted at CLDC class devices that typically have very little processing power and memory, and no hardware support for
3D graphics or floating point math. The API shall be defined such that implementations on that kind of hardware are feasible.
However, the API shall also scale up to higher-end devices featuring a color display, a DSP, a floating point unit, or even specialized
3D graphics hardware. The API may therefore support features that are not strictly necessary on the very low-end platforms.

The target platform of this API is J2ME/CLDC. The API is proposed to be an optional package to be used together with several J2ME
profiles, in particular MIDP.

Additionally, we should restrain the size such that the burden on the target platform for inclusion of the smallest conforming
subset should be of the order of 100K of ROM/Flash space for a well-optimised implementation.

2.3 What need of the Java community will be addressed by the proposed specification?

The specification brings support for 3D graphics to J2ME. Synthetically coded content, such as 3D graphics, has properties that
enable attractive services and applications to be constructed that can overcome the limitations of the current mobile networks.

Interactive content on mobile devices includes games, navigation aids, messaging and custom user interfaces. All of these can be
addressed using an interactive 3D API. The API shall be designed to supply interactive 3D rendering capabilities to applications in a
way that is efficient in processor power required, in overall code size, and in working memory footprint. It shall provide these
capabilities in a manner which makes content development natural and easy for MIDP developers.

2.4 Why isn't this need met by existing specifications?

Current proposals for integration of 3D into a Java environment are unsuitable for constrained devices due to ROM footprint, RAM
size, or processor power requirements. They cannot be adopted as such for embedded devices. Instead, one must either design a
new API for the embedded environment, or modify a subset of an existing API.

Specific ongoing JSRs in the J2ME arena which are related include:

JSR-134 - Gaming API is designed and optimised for gaming, targeting the CDC platform. While 3D is useful for games, it is
not useful only for games and thus we view JSR-134 as complementary, not competing. By concentrating on interactive 3D
graphics only, rather than on game-specific mechanisms, we hope to keep this JSR small, focussed, and independent of the
feature set implemented in JSR-134.

JSR-135 - Mobile Media API is a high-level control API for different media types, and it does not address interactive 3D
graphics. We feel that although high-level playback control of 3D content could be provided by JSR-135 in the future, that
specification is not suitable for providing core 3D graphics functionality. Therefore, a separate JSR is needed.

Outside the J2ME arena, the following JSRs are related:

JSR-148 - 3D Media Utilities addresses volumetric imaging and 3D vector math. The volumetric imaging part of the JSR are
not relevant to this JSR, because lightweight 3D content will be represented as polygonal data rather than volumetric data.
The vector math package of JSR-148 should be used at least as a reference if similar functionality is to be defined within
the proposed JSR. However, on the target platform the vector operations will in practice be mostly embedded within the
implementation?s native code, for speed reasons.

JSR-912 - Java 3D is very large by J2ME standards. It is unclear whether even a ?cut down? version of JSR-912 would
perform efficiently on the smallest platforms, given the design assumptions made for Java 3D.

2.5 Please give a short description of the underlying technology or technologies:

Mobile devices may feature a great variety of graphical capabilities. Some of the target devices may only have a black & white
display at 96x64 resolution, while others may feature a 320x240 display with 16-bit colors. In the future, even higher resolutions
and color depths are expected. Similarly, processor speeds may range from tens to hundreds of MHz. The API should accommodate
such differences, and be able to take full advantage of increasing capabilities and special hardware, such as 3D accelerators.

The main requirements for the API are:

Enable the use of 3D graphics on a variety of different applications

Do not assume the existence of relatively high-end hardware capabilities

Do not impose arbitrary limits on the size or complexity of 3D content

Support sophisticated features also on low-end platforms

Maintain low ROM and RAM footprint

To achieve sufficient generality without burdening the developer with drawing individual pixels, the API needs to be at least at the
abstraction level of drawing static 3D objects on command. It is useful if the API would also take care of issues like building and
maintaining a scene hierarchy, performing occlusion culling, animating the objects in the scene, and selecting the viewpoint,
because a higher level of abstraction eases application development, decreases application size, and increases the amount of
processing done in native code vs. Java code. The relatively lower level of abstraction has been proven successful by, for example,
SGI's OpenGL and Microsoft's Direct3D, while high abstraction level APIs have been used in OpenInventor, Java3D, and several
game engines (e.g., ID's Quake). Yet another successful approach has been a combination of a file format and a player, like VRML in
3D and Macromedia's Flash in 2D.

All 3D rendering is expected to be done in native code for speed and space reasons. Implementations may utilize hardware
acceleration on platforms where it is available. Implementations written in Java are possible, but most likely not practical without
using 3D hardware.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

TBD

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No, although the proposed implementation will be dependent on the specific profile implementations, such as MIDP, to transfer
pixel arrays to the screen.

2.8 Are there any security issues that cannot be addressed by the current security model?

None known or anticipated.

2.9 Are there any internationalization or localization issues?

None known or anticipated.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No.

2.11 Please describe the anticipated schedule for the development of this
specification.

The specification is expected to be finalized during Q4/2002.

2.12 Please describe the anticipated working model for the Expert Group working on developing this
specification.

It is up to the expert group to work out the details, but we are proposing to have 2-3 face-to-face meetings in the process and conference calls when needed. A kickoff meeting should be targeted hopefully for June before the summer holidays to get the work going.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

In addition to the JSRs mentioned in Section 2.4, the following references may be applicable: