| Sun Java Wireless Toolkit for CLDC User's Guide |    
|
| Sun Java Wireless Toolkit for CLDC User's Guide |
|
| C H A P T E R 9 |
|
Working With Mobile Graphics |
This chapter provides a brief overview of working with graphics content. The Sun JavaTM Wireless Toolkit for CLDC offers three APIs that provide comprehensive capabilities for interactive 2D and 3D graphics:
JSR 184 is a specification that defines the Mobile 3D Graphics (M3G) API for the J2ME. This API provides 3D functionality in a compact package that's appropriate for CLDC/MIDP devices. The API provides two methods for displaying 3D graphics content. The immediate mode API makes it possible for applications to directly create and manipulate 3D elements. Layered on top of this is a scene graph API, also called retained mode, that makes it possible to load and display entire 3D scenes that are designed ahead of time. Applications are free to use whichever approach is most appropriate or to use a combination of the retained mode and immediate mode APIs. The JSR 184 specification also defines a file format (.m3g) for scene graphs.
For more information, consult the JSR 184 specification at
http://jcp.org/en/jsr/detail?id=184.
JSR 184 provides a standard API for CLDC/MIDP devices, enabling a new generation of 3D applications. The immediate mode API, in turn, is compatible with OpenGL ES, a standard lightweight API for 3D graphics. See http://khronos.org/ for more information on OpenGL ES.
Immediate mode is appropriate for applications that generate 3D graphics content algorithmically, like scientific visualizations or statistical graphs. The application creates 3D objects and manipulates them directly.
For an example of immediate mode, see the Life3D MIDlet in the Demo3D example application.
Most applications, particularly games, use the retained mode or scene graph API. In this approach, a graphic designer or artist uses 3D modeling software to create a scene graph. The scene graph is saved in the JSR 184 file format. The scene graph file is bundled with the application. At runtime, the application uses the scene graph API to load and display the file.
Applications can manipulate parts of a loaded scene graph to animate characters or create other effects. The basic strategy is to do as much work as possible in the modeling software. At runtime, the application can grab and manipulate parts of the scene graph, which can also include paths for animation or other effects.
For an example of retained mode, see the retainedmode MIDlet in the Demo3D example application.
One of the challenges of MIDP development is the constrained environment of typical devices. Compared to desktop computers, MIDP devices have slow processors and little memory. These challenges extend into the arena of 3D graphics. To accommodate a wide variety of implementations, the JSR 184 specification provides various mechanisms to make the display of a 3D scene as efficient as possible.
One approach is scoping, a technique where you tell the 3D graphics implementation when objects are not going to interact with each other. For example, if you defined a scene graph for a house, you could use scoping to specify that the light in the basement doesn't affect the appearance of the bedroom on the second floor. Scoping makes the implementation's job easier by reducing the number of calculations required to show a scene.
In general, however, the best way to improve the rendering speed of 3D scenes is to make some compromises in quality. The Mobile 3D Graphics API includes rendering hints so that applications can suggest how the implementation can compromise quality to improve rendering speed.
Most mobile 3D applications use scene graphs in resource files to describe objects, scenes, and characters. Usually it is not programmers but graphic designers or artists who create the scene graphs, using standard 3D modeling tools.
Several vendors offer tools for authoring content and converting files to the JSR 184 format. Superscape (http://superscape.com/) is one such vendor.
Because it is relatively difficult to create and manipulate 3D graphics content in an application using the immediate mode API, most applications rely as much as possible on a scene graph file. By putting as much as possible into the scene graph file at design time, the application's job at runtime is considerably simplified.
Scalable Vector Graphics (SVG) is a standard defined by the World Wide Web Consortium. It is an XML grammar for describing rich, interactive 2D graphics.
The Sun JavaTM Wireless Toolkit for CLDC emulator support JSR 226, the Scalable 2D Vector Graphics API for J2ME. JSR 226 is a Java ME API to load, manipulate, render and play SVG content. SVG Tiny is an compact yet powerful XML format for describing rich, interactive, animated 2D content.
While it is possible to produce SVG content with a text editor, most people prefer to use an authoring tool. Here are three possibilities:
Java ME applications using SVG content can create graphical effects that adapt to the display resolution and form factor of the user's display.
SVG images can be animated in two ways. One is to use declarative animations. The other is to repeatedly modify the SVG image parameters (such as color or position), through API calls. Section A.21.3, Play SVG Animation illustrates declarative animation.
JSR 239 defines the Java programming language bindings for two APIs, OpenGL® for Embedded Systems (OpenGL® ES) and EGL. OpenGL® ES is a standard API for 3D graphics, a subset of OpenGL®, which is pervasive on desktop computers. EGL is a standard platform interface layer. Both OpenGL® ES and EGL are developed by the Khronos Group (http://khronos.org/opengles/).
While JSR 184 (which is object oriented) requires high level functionality, OpenGL® is a low level graphics library that is suited for accessing hardware accelerated 3D graphics. Explore the OpenGLESDemo sample project code.
| Sun Java Wireless Toolkit for CLDC User's Guide |
|
Copyright © 2007, Sun Microsystems, Inc. All Rights Reserved.