 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 184: Mobile 3D Graphics API for J2METM
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: This proposed JSR will provide a scalable, small-footprint, interactive 3D API for use on mobile devices. Please direct comments on this JSR to the Spec Lead(s) Team
The following information has been updated from the original proposal. 2012.08.29: North Sixty-One has become the Co-Maintenance Lead. Maintenance Lead: Erkki Rysä E-Mail Address: jsr184 Telephone Number: - Fax Number: -
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Nokia Corporation Name of Contact Person: Kari Pulli E-Mail Address: kari.pulli@nokia.com Telephone Number: +358 7180 48975 Fax Number: +358 7180 52244 Specification Lead: Jyri Huopaniemi E-Mail Address: jyri.huopaniemi@nokia.com Telephone Number: +358 7180 37309 Fax Number: +358 7180 37133 Initial Expert Group Membership:
Supporting this JSR:
Section 2: Request
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. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)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:
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:
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:
3.2 Explanation of how these items might be used as a starting point for the work.These references include a general description of available 3D standards, tools and techniques. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
