Overview
Preface
This document contains a specification for J2ME Mobile 3D Graphics API ("M3G"). This specification is defined by Java Community Process 184 ("JSR-184") in Java Specification Request 184 ("JSR-184"). This specification is JCP The main content of the contract period. (I.e., JSPA and / OR IEPA).
Mobile 3D Graphics API is an optional package. An optional package can be configured on the already existing J2ME configuration. A J2ME configured for special vertical industries and market defines the API of the device type specification collection. This optional API is mainly The target platform is J2ME / CLDC, like MIDP 1.0 or MIDP 2.0 uses these configurations. However, these APIs are still capable of executing at J2ME / CDC or any general Java platform.
The technical details of these APIs can be found in the overview of the package. Especially you can view the Graphics3D class. To know how these APIs can be used in the practice of MIDlets at the end of the chapter.
background
The main task of the Mobile 3D Graphics API expert group is to provide a set of valid 3D images APIs for the J2ME platform, especially for CLDC / MIDP. These APIs are only very limited for standards for standards and memory and no hardware support 3D images and floats. The CLDC class design of point operability equipment. These APIs have defined a feasible implementation method on such hardware.
However, these APIs still need to increase a high-priced device to support a color display, a DSP, a floating point unit, or even a special 3D image hardware.
M
The 3G specification is based on the basic needs and outlines adopted by the expert group. The links of each need are shown in the drawings below.
• The API must support retention mode (the Scene image)
• The API must support the characteristics of approximately IMMEDIATE MODE.
• The API must support instant mode and retention mode access mix and match.
• The API must have an introduction of face (Meshes), material, and Entire Scene graphs, and the like.
• The API must be effectively executed on OpenGL ES.
• The API must use Java local floating point data types, not importing a custom type.
• The API must be effectively performed on a floating-point hardware
• The API should be able to run on a real 150KB size mobile terminal.
• The API must be constructed, so the garbage collection is minimal.
• The API must be compatible with the already existing Java APIS, especially MIDP.
Many applications can be implemented using the Mobile 3D Graphics API, including games, map display, user interface, animation, product visualization presentation and screen saver. These applications have different needs. Some need simple content creation, some need high-speed polygons Processing, there are also some high quality pictures with special effects.
Obviously, such a different wide spectral demand cannot be implemented using a background image API or an instant mode API. Also have two independent APIs can cause the developer's chaos and memory space insufficient use. More appropriate There must be only one accessible API using RI and TCK to meet the needs of different access modes. A developer can choose to use only one or two simultaneously according to the needs of the hand task. Instant mode (or low-level mode) The partial API should be a subset of the OpenGL API. More specifically, low-level features should be compatible with KHRONS standardized OpenGL ES. In the implementation specification, the scene image (high layer) section must establish a re-underlying interface Above and cannot be achieved around the bottom layer when rendering. This ensures that the scene image does not include material rendering that cannot be implemented directly through the underlying interface. The underlying execution can change, and even directly use hardware acceleration. Many cases, Some programs use these effects than displaying a scene and play some animation that uses 3D models. This doesn't require a lot of Java programming. Even more requirements, if it can simply import objects and Animated to a MIDLET to speed up the development speed. So, the API must provide features that import different data types, such as materials, faces, animations, and scene levels. These data must be converted to binary formats to compress storage and transfer.
Most mobile terminals do not support hardware floating point operations. These functions will be implemented in the API. So the API can perform integer calculations at high efficiency. Even though, because the use mix value calculation programming or complex and easy error, whether or not the API is The floating point value should be used. Mix numerical calculations should not be used. Similarly, the floating point type of Java must replace a custom floating point type or a conversion floating point value is an integer. The result is that the API cannot be in CLDC 1.0 Move. Like all APIs for MIDP, we need to compress the execution file as much as possible. This requires an API to be executed in a ROM space less than 150KB, including a local graphics engine .java class file (ROM) and content import Equipment. In order to minimize garbage collection, API structure is generated, so it is not necessary to repeat the establishment of objects when used.
The API must be derived from the MIDP's LCDUI, such as 2D, 3D images can be drawn from the same CANVAS or Image. For example, if you use dual buffers or should not use the MIDP program hosting. API should be able to bind to the GUI API such as AWT.
Most mobile terminals do not support hardware floating point operations. These functions will be implemented in the API. So the API can perform integer calculations at high efficiency. Even though, because the use mix value calculation programming or complex and easy error, whether or not the API is The floating point value should be used. Mix numerical calculations should not be used. Similarly, the floating point type of Java must replace a custom floating point type or a conversion floating point value is an integer. The result is that the API cannot be in CLDC 1.0 Decrease.
As all of the APIs for MIDP, we need to compress the execution file as much as possible. This requires an API that can be executed in a ROM space less than 150KB, including a local graphics engine .java class file (ROM) and content import device. In order to Minimize garbage collection, API structured generation, so you don't need repeated establishment of objects when you are using.
The API must be derived from the MIDP's LCDUI, such as 2D, 3D images can be drawn from the same CANVAS or Image. For example, if you use dual buffers or should not use the MIDP program hosting. API should be able to bind to the GUI API such as AWT.
