Technology evaluation on 3D interactive graphic development, all the pros and cons related J2ME, M3G, OpenGL, Blender

1. J2ME/J2EE


Java Platform, Micro Edition, or Java ME, is a Java platform designed for mobile devices and embedded systems. Target devices range from industrial controls to mobile phones and set-top boxes. Java ME was formerly known as Java 2 Platform, Micro Edition (J2ME).

As of 2008, all Java ME platforms are currently restricted to JRE 1.3 features and use that version of the class file format (internally known as version 47.0). Should Sun ever declare a new round of Java ME configuration versions that support the later class file formats and language features, such as those corresponding JRE 1.5 or 1.6 (notably, generics), it will entail extra work on the part of all platform vendors to update their JREs.

Java ME devices implement a profile. The most common of these are the Mobile Information Device Profile aimed at mobile devices, such as cell phones, and the Personal Profile aimed at consumer products and embedded devices like Set-top boxes and PDAs. Profiles are subsets of configurations, of which there are currently two: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC).

Connected Limited Device Configuration

The Connected Limited Device Configuration (CLDC) contains a strict subset of the Java-class libraries, and is the minimum amount needed for a Java Virtual Machine to operate. CLDC is basically used to classify myriad devices into a fixed configuration.

A configuration provides the most basic set of libraries and virtual-machine features that must be present in each implementation of a J2ME environment. When coupled with one or more profiles, the Connected Limited Device Configuration gives developers a solid Java platform for creating applications for consumer and embedded devices.

Mobile Information Device Profile

Designed for mobile phones, the Mobile Information Device Profile includes a GUI API, and MIDP 2.0 includes a basic 2D gaming API. Applications written for this profile are called MIDlets. Almost all new cell phones come with a MIDP implementation, and it is now the de facto standard for downloadable cell phone games. However, many cellphones can run only those MIDlets that have been approved by the carrier, especially in North America.

JSR 271: Mobile Information Device Profile 3 will specify the 3rd generation Mobile Information Device Profile (MIDP3), expanding upon the functionality in all areas as well as improving interoperability across devices. A key design goal of MIDP3 will be backward compatibility with MIDP2 content.

Information Module Profile

The Information Device Profile (IMP) is a profile for embedded, "headless" devices such as vending machines, industrial embedded applications, security systems, and similar devices with either simple or no display and with some limited network connectivity.

Originally introduced by Siemens Mobile and Nokia as JSR -195, IMP 1.0 is a strict subset of MIDP 1.0 except that it doesn't include user interface APIs — in other words, it doesn't include support for the Java package javax.microedition.lcdui. JSR-228, also known as IMP-NG, is IMP's next generation that is based on MIDP 2.0, leveraging MIDP 2.0's new security and networking types and APIs, and other APIs such as PushRegistry and platformRequest(), but again it doesn't include UI APIs, nor the game API.

Connected Device Configuration

The Connected Device Configuration is a subset of Java SE, containing almost all the libraries that are not GUI related. It is richer than CLDC.

Foundation Profile

The Foundation Profile is a Java ME Connected Device Configuration (CDC) profile. This profile is intended to be used by devices requiring a complete implementation of the Java virtual machine up to and including the entire Java Platform, Standard Edition API. Typical implementations will use some subset of that API set depending on the additional profiles supported. This document describes the facilities that the Foundation Profile provides to the device and other profiles that use it. This specification was developed under the Java Community Process.

Personal Basis Profile

The Personal Basis Profile extends the Foundation Profile to include lightweight GUI support in the form of an AWT subset. This is the platform that BD-J is built upon.

Personal Profile

The Personal Profile is an extension of the Personal Basis Profile, and includes a more comprehensive AWT subset and adds applet support.

Mobile 3D Graphics for J2ME

JSR is the first Java-specific standard for three-dimensional graphics on mobile devices. The JSR's 26-member expert group includes all the major players in the mobile arena, including Sun Microsystems, Sony Ericsson, Symbian, Motorola, ARM, Cingular Wireless, and specification lead Nokia. The API takes the form of an optional package expected to be used with MIDP and version 1.1 of the Connected Limited Device Configuration (CLDC). It defines low- and high-level programming interfaces that bring efficient, interactive 3D graphics to devices with little memory and processing power, and with no hardware support for 3D graphics or floating-point operations. As new phones with diverse functionality appear, however, the API can scale up to higher-end devices that have color displays, 3D graphics hardware, and support for floating-point operations.


Application areas that will benefit from a 3D graphics API include games, map visualization, user interfaces, animated messages, and screen savers. Each of these areas requires simple content creation, some require high polygon throughput, and others require high-quality still images with special effects. To meet this wide spectrum of needs, the API supports both high-level and low-level graphics features, with a footprint of only 150 KB. In the high-level implementation (called retained mode), the developer works with scene graphs, and the world renders itself based on the positions of virtual cameras and lights. The low-level access (immediate mode) allows applications to draw objects directly. You can use either mode, or both at the same time, depending on the task at hand.

The features of immediate mode are aligned with Open GL ES standardization by Khronos. OpenGL ES (from "OpenGL for Embedded Systems") is a low-level, lightweight API for advanced embedded graphics using well-defined subset profiles of OpenGL. It provides a low-level interface between applications and hardware or software graphics engines. This standard makes it easy and inexpensive to offer a variety of advanced 3D graphics and games across all major mobile and embedded platforms. Because OpenGL ES is based on OpenGL, no new technologies are needed, which ensures synergy with, and a migration path to, the most widely adopted cross-platform graphics API, full OpenGL.

Mobile 3D Graphics API

The Mobile 3D Graphics API for J2ME is defined in the package javax.microedition.m3g, which provides an easy-to-use API for rendering 3D graphics in retained mode and immediate mode.

In addition to the APIs, the package defines a scene graph structure and a corresponding file format for managing and deploying 3D content efficiently, along with all other necessary data: meshes, scene hierarchies, material properties, textures, animation keyframes, and so on. This data is written to a file using content-creation tools and loaded into the API through the Loaderclass. The most important class is Graphics3D, because all rendering is done there. The World class serves as the root of the scene graph structure. Object3D is the base class of all objects that can be rendered or loaded from a file, as well as the place where animations are applied.

Requirements

1. The API must support both retained-mode access (scene graphs) and immediate-mode access (the OpenGL ES subset or similar), and allow mixing and matching of the two modes in a unified way.

2. The API must have no optional parts; all methods must be implemented.

3. To reduce the amount of programming required, the API must include importers for certain key data types, including meshes, textures, and scene graphs.

4. Data must be encoded in a binary format for compact storage and transmission.

5. It must be possible to implement the API efficiently on top of OpenGL ES, without floating-point hardware.

6. The API must use the float data type of the Java programming language, not introduce a custom type.

7. Because using integer arithmetic is difficult and error-prone, floating-point values should be used wherever feasible.

8. The ROM and RAM footprint must be small; the API should be implemental within 150KB on a real mobile terminal.

9. The API must provide minimal garbage collection.

10. The API must interoperate properly with other Java APIs, especially MIDP.

2. M3G (Mobile 3D Graphics API)


M3G is defined to write Java programs that produce 3D graphics. It extends the capabilities of the Java and the object oriented interface consists of 30 classes that can be used to draw complex animated three-dimensional scenes.

Versions: 1.1 and the latest 2.0

M3G provides two ways for developers to draw 3D graphics: immediate mode and retained mode.

In immediate mode, graphics commands are issued directly into the graphics pipeline and the rendering engine executes them immediately. When using this method, the developer must write code that specifically tells the rendering engine what to draw for each animation frame. A camera and set of lights is also associated with the scene, but is not necessarily part of it. In immediate mode it is possible to display single objects, as well as entire scenes (or worlds, with a camera, lights, and background as parts of the scene).

Retained mode always uses a scene graphic that links all geometric objects in the 3D world in a tree structure, and also specifies the camera, lights, and background. Higher-level information about each object — such as its geometric structure, position, and appearance — is retained from frame to frame.

Pros and cons:

1. M3G is a high level 3D API that allows us to get results quickly.

2. With only a few lines of code you can import a scene and animate it.

3. It runs quite slow on a lot of mobile phones (floating point unit).

4. To increase the performance need to optimize the code.

5. Mascot Capsule runs faster, but isn’t as widely supported (fixed point calculations).

3. OpenGL (Open Graphics Library)


OpenGL is a standard specification defining a cross-language, cross-platform API for writing applications that produce 2D and 3D computer graphics. The interface consists of over 250 different function calls which can be used to draw complex three-dimensional scenes from simple primitives.

Versions: 2.0, 2.1, 3.0 and 3.1

OpenGL serves two main purposes:

1. To hide the complexities of interfacing with different 3D accelerators, by presenting the programmer with a single, uniform API.

2. To hide the differing capabilities of hardware platforms, by requiring that all implementations support the full OpenGL feature set (using software emulation if necessary).


Java OpenGL

Core OpenGL API and GLU library calls are available from Java through a thin wrapper looking very much as the original OpenGL.

JOGL differs from some other Java OpenGL wrapper libraries in that it merely exposes the procedural OpenGL API via methods on a few classes, rather than attempting to map OpenGL functionality onto the object-oriented programming paradigm. Indeed, the majority of the JOGL code is auto generated from the OpenGL C header files via a conversion tool named Gluegen, which was programmed specifically to facilitate the creation of JOGL.

Pros and cons:

1. The straightforward mapping of the OpenGL C API to Java methods makes conversion of existing C applications and example code much simpler.

2. The thin layer of abstraction provided by JOGL makes runtime execution quite efficient.

3. The procedural and state machine nature of OpenGL is inconsistent with the typical method of programming under Java, which is bothersome to many programmers.

4. It is more difficult to code compared to higher-level abstraction libraries like Java3D, because most of the code is auto generated.



4. Blender

Blender is used form modeling, UV unwrapping, texturing, rigging, water simulations, skinning, animating, rendering, particle and other simulations, non-linear editing, compositing, and creating interactive 3D applications. Blender is available for several operating systems, including Linux, Mac OS X, and Microsoft windows, along with other operating systems. Blender has a robust feature set similar in scope and depth to other high-end 3D software such as Softimage, Cinema 4D, 3ds Max, Lightware and Maya. These features include advanced simulation tools such as rigid body, fluid, cloth and softbody dynamics, modifier based modeling tools, powerful character animation tools, a node based material and compositing system and Python for embedded scripting.

Versions: 2.49

Pros and cons:

1. Versatile internal rendering capabilities and integration with YafRay, a free software ray tracer.

2. Keyframed animation tools including inverse kinematics, armature (skeletal), hook, curve and lattice-based deformations, shape keys (morphing), non-linear animation, constraints, vertex weighting, soft body dynamics including mesh collision detection, LBM fluid dynamics, Bullet rigid body dynamics, particle based hair, and a particle system with collision detection.

3. Modifiers to apply non-destructive effects.

4. Python scripts for tool creation and prototyping, game logic, importing and exporting from other formats such as OBJ, FBX, DXF, COLLADA, task automation and custom tools.

5. Basic non-linear video/audio editing and compositing capabilities.

6. Game Blender, a sub-project, offers interactivity features such as collision detection, dynamics engine, and programmable logic. It also allows the creation of stand-alone, real-time applications ranging from architectural visualization to video game construction.

7. A fully integrated node based compositor within the rendering pipeline.

8. Blender has had a reputation as being difficult to learn for users accustomed to other 3D graphics software.