What is Java 3D and is it for me? | Chapter 1

By -
Hello Friends,
          This is my new requested tutorial from a facebook fan page for JAVA 3D Programming...
          Let's come to the point


 What is Java 3D and is it for me? | Chapter 1


1.1 Strengths
1.2 Weaknesses
1.3 System requirements (developerand end user)
1.4 Expected performance
1.5 Running the examples
1.6 Summary

         
Java 3D is an application programming interface (API) developed at Sun Microsystems for rendering interactive 3D graphics using the Java programming language. Java 3D is a client−side Java API. Other examples of Sun client−side APIs include the Abstract Windows Toolkit (AWT) and Java Foundation Classes (JFC/Swing), which are both Java class libraries for building applications with a Graphical User Interface (GUI). The client−side Java APIs are in contrast to Sun’s server−side APIs such as Enterprise Java−Beans (EJB) and the other components of Java 2 Enterprise Edition (J2EE).

          Making 3D graphics interactive is a long−standing problem, as evidenced by its long history of algorithms, APIs, and vendors. Sun is not a major player in the 3D graphics domain, although its hardware has long supported interactive 3D rendering. The dominant industry standard for interactive 3D graphics is OpenGL, created by Silicon Graphics (SGI). OpenGL was designed as a cross−platform rendering architecture and is supported by a variety of operating systems, graphics card vendors, and applications. The OpenGL API is written in the C programming language, and hence not directly callable from Java. A number of open source and independent programming efforts have provided simple Java wrappers over the OpenGL API that allow Java programmers to call OpenGL functions, which are then executed in native code that interacts with the rendering hardware. One of the most popular is GL4Java, which you can find at http://www.jausoft.com/gl4java/.
          
          However, there are few advantages to using a Java wrapper over OpenGL, as opposed to coding in C and calling OpenGL directly. Although programmers can use the more friendly Java APIs, they must incur the overhead of repeated calls through the Java Native Interface (JNI) to call the native OpenGL libraries.

          Java 3D relies on OpenGL or DirectX to perform native rendering, while the 3D scene description, application logic, and scene interactions reside in Java code. When Sun set out to design Java 3D, although they did not have the resources or industry backing to replace OpenGL, they wanted to leverage more of Java’s strengths as an object−oriented programming (OOP) language instead of merely delegating to a procedural language such as C. Whereas OpenGL’s level of description for a 3D scene consists of lists of points, lines, and triangles, Java 3D can describe a scene as collections of objects. By raising the level of description and abstraction, Sun not only applied OOP principles to the graphics domain, but also introduced scene optimizations that can compensate for the overhead of calling through JNI.

 See You In Next Tutorial BBye                   Next Tutorial

Comments

Post a Comment

Popular Posts

2.2.3 Drawing filled triangles | JAVA 3D Programming | Chapter 2

By -
Image
2.2.3 Drawing filled triangles Java 3D rendered the hand as an apparently solid object. We cannot see the triangles that compose the hand, and triangles closer to the viewer obscure the triangles further away.         You could implement similar functionality within MyJava3D in several ways: Hidden surface removal You could calculate which triangles are not visible and exclude them from rendering. This is typically performed by enforcing a winding order on the vertices that compose a triangle. Usually vertices are connected in a clockwise order. This allows the graphics engine to calculate a vector that is normal (perpendicular) to the face of the triangle. The triangle will not be displayed if its normal vector is pointing away from the viewer. This technique operates in object space—as it involves mathematical operations on the objects, faces, and edges of the 3D objects in the scene. It typically has a computational complexity of...
Keep reading

3.1.4 Java 2 development environment (optional) | JAVA 3D Programming | Chapter 3

By -
Image
3.1.4 Java 2 development environment (optional) Every developer has their favorite programmer’s editor, and an increasing number of Integrated Development Environments (IDEs) are available that support Java 2. They range from free to expensive, and have a wide variety of features. Some of the more popular IDEs for Java 2 development are: Kawa, Allaire ( http://www.allaire.com/ ) All the examples for this book were built using Kawa. Unfortunately, after Allaire was acquired by Macromedia, development of Kawa was discontinued. JBuilder, Borland ( http://www.inprise.com/jbuilder/ ) Emacs, GNU ( http://www.gnu.org/software/emacs/ ) Visual CaféWebGain ( http://www.webgain.com/Products/VisualCafe_Overview.html ) NetBeans ( http://www.netbeans.org ) Eclipse (Open Source, IBM) ( http://www.eclipse.org/ ) IntelliJ IDEA ( http://www.intellij.com/ ) Ok good luck, See you in next tutorial :)
Keep reading

4.7 Immediate mode vs. retained mode vs. mixed mode

By Vikash Kumar -
Image
Java 3D does not interact directly with system display hardware to produce the 3D rendering of a scene, but rather relies upon a lower level 3D graphics API: currently either OpenGL or DirectX. The designers of Java 3D have added several locations within the Java 3D rendering loop that application developers can hook into to directly render 3D primitives irrespective of the current scenegraph. Using Java 3D in retained mode does not exploit these capabilities. This is usually the recommended and most common mode for Java 3D. The application developer defines the scenegraph for the application, passes it to Java 3D, and Java 3D is responsible for rendering the scene. Java 3D also coordinates and carries out a lot of the chores related to user interaction. In complete contrast, using Java 3D in immediate mode does not exploit Java 3D’s scenegraph abilities at all, and the application developer assumes all responsibility for rendering and user interaction. Java 3D is merely be...
Keep reading

4.4 Elements of scenegraph design | JAVA 3D Programming | Chapter 4

By -
Image
Designing a good scenegraph structure may involve making trade−offs across several factors. The scenegraph should be easy to manipulate at runtime (you may want to dynamically attach and detach entire branches to switch them on or off) as well as easy to customize in the future. You may have to make compromises to get good performance to ensure that Java 3D can process your scenegraph efficiently. Object−oriented         Object orientation allows easy reuse of scenegraph branches. Ideally, each branch should define a component of the application that can be meaningfully used independently of the other scenegraph branches. You should imagine having to drop the scenegraph branch in question into another application. Compilable          This property is related to the goal of object orientation. If scenegraph branches can be reused within the scenegraph without modification of their appearance or relati...
Keep reading