## Chapter 9

## Working With Mobile 3D Graphics

This chapter provides a brief overview of working with 3D graphics content.

## 9.1 JSR 184 Overview

JSR 184 is a specification that defines the Mobile 3D Graphics (M3G) API for 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 have been 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:

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.

## 9.2 Immediate Mode

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.

## 9.3 Retained Mode

Most applications, particularly games, will 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.

## 9.4 Trading Quality for Speed

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 accomodate 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.

## 9.5 Creating Mobile 3D Graphics Content

Most mobile 3D applications will 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 will be considerably simplified.

| J2ME Wireless Toolkit User's Guide J2ME Wireless Toolkit 2.2

Copyright © 2004 Sun Microsystems, Inc. All rights reserved. Use is subject to the license terms.