Latest Entries »

Sunday, July 12, 2009

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.

Saturday, July 11, 2009

Integrating JSF, Hibernate and Spring

Hello Folks,This post describes the steps to configure Spring Hibernate JSF application. Integration of these three technologies makes a solid framework for web application development.
Creating the application with out IDE:Download the jars for JSF (Ex: Icefaces).Download the jars for Hibernate library.
Download the jars for Spring Library.
Jar's need are
ant-1.6.5.jar, ant-antlr-1.6.5.jar, ant-junit-1.6.5.jar, ant-launcher-1.6.5.jar, ant-swing-1.6.5.jar, antlr-2.7.6.jar, asm-attrs.jar, asm.jar, c3po-0.9.1.jar, cglib-2.1.3.jar, checkstyle-all.jar, cleanimports.jar, commons-beanutils-1.7.0.jar, commons-codec-1.3.jar, commons-collections-2.1.1.jar, commons-collections-3.1.1.jar, commons.digester-1.6.jar, commons-el-1.0.jar, commons-fileupload-1.0.jar, commons-lang-2.1.jar, commons-logging-1.0.4.jar, commons-validator-1.3.1.jar, concurrent-1.3.2.jar, connector.jar, dom4j-1.6.1.jar, ehcache-1.2.3.jar, hibernate3.jar, jass.jar, jacc-1_0-fr.jar, javassist.jar, jaxen-1.1-beta-7.jar, jdbc2_0-stdext.jar, jgroups-2.2.8.jar, jstl-1.1.0.jar, jta.jar, junit-3.8.1.jar, log4j-1.2.11.jar, myfaces-api-1.1.5.jar, myfaces-impl-1.1.5.jar, mysql-connector-java-3.0.16-ga-bin.jar, mysqlconnector-java-3.1.6-bin.jar, oro-2.0.8.jar, oscache-2.1.jar, proxool-0.8.3.jar, spring.jar, swarmcache-1.0rc2.jar, syndiag2.jar, tomahawk-1.1.6.jar, versioncheck.jar, xerces-2.6.2.jar, xml-apis.jar



















Now create the web application and copy all the above lib files under the WEB-INF folder.

Creating the web project with the MyEclipse IDE:Create New Web Application, add JSF capabilities (you can add different kind of flavours of JSF to your application Ex: Icefaces, Richfaces). Now add the spring capabilities and hibernate capabilities.
Create hibernate POJO's and DAO's classes (Hibernate Annotaions library is required to build POJO's & DAO's). Register all the POJO & DAO classes in the spring application contect file, to create hibernate POJO & DAO classes select the MyEclipse Hibernate Prespective. Add the database driver and connect to the database using DB browser. Navigate to the database-->tables, select all the tables and right click go to hibernate reverse engineering option. MyEclipse will take you to the several screens, here you need to select create POJO and create DAO options which will generate POJO & DAO classes.Register all the POJO & DAO classes in the applicationContext.xml file
Sample Code :












Add this spring context file in web.xml




At this point our web application got the relationship between the spring and hibernate and we registered them in web.xml. Now the tedious part of the application is to integrate this part with the JSF.

To integrate JSF and Spring , Spring API provides a variable resolver called DelegatingVariableResolver (but dude it work's only with JSF1.1 and it is not compatible with JSF1.2)




If we create one custom funtion works as DelegatingVariableResolver, then our application will be independent of spring API.


Sample Code:
import javax.faces.context.Facescontext;
import javax.servlet.ServletContext;

import org.springframework.context.ApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;

public class ServiceFinder {

public static object findBean(String beanName) {
FacesContext context = FacesContext.getCurrentInstance();

ServletContext servletContext = (ServletContext)context.getExternalContext().getContext();
ApplicationContext appContext = WebApplicationContextUtils.getWebApplicationContext(servletContext);

Object o = appContext.getBean(beanName);

return o;
}
}










And call this funtion in your managed bean like :

ProductionDAO productionDAO = (ProductionDAO) ServiceFinder
.findBean("ProductionDAO");

This completes the integration part of JSF, HIbernate and Spring.

Application Architechture:

Web application consists of 3 layers
1. Presentaion Layer
2. Business Layer
3. Data Access Layer


In our application the presentation layer, business layer and data access layer are physically located on the same JEE server. The different layers of the application are isolated from each other and connected through well defined interfaces.








Presentation Layer

JSF is used to build the presentation layer of the application. JFS allows us to create rich gui for web application. It resolves the technical challenges of creating rich gui web application. In this layer we have jsp pages and JSF components. All the request to the web server are passes through faces servlet.

Business Layer

The POJO classes and classes to process the business logic are used to create the Business Layer. The POJO classes with the help of spring framework creates an ideal solution to implement the Business Layer.

Data Access Layer

The data access layer handles all the logic to save and retrieve the data from data base. Hibernate O/R mapping tools is an ideal solution for enterprise application of any size. Hibernate handles all the logic to store and retrieve POJO objects. It also handles resource management and transaction management activities.