Computer Graphics With Java

Michael Grady writes "Computer graphics has become an indispensable part of mainstream computing and the undergraduate course in computer graphics programming is often one of the most popular courses in the curriculum. In the early days, such courses dealt with low level implementation details and algorithms such as converting lines to pixels, filling rectangles, view clipping and anti-aliasing. When OpenGL arrived on the scene, it was welcomed as an efficient and powerful, procedure-oriented library that kept many of the low level details out of sight. The sort of projects that could be tackled in an introductory course became much more impressive. That was back in the 90's. Is there a way to build a course covering the basic computer graphics concepts and techniques which takes advantage of object orientation and higher levels of abstraction? I believe the authors of Computer Graphics using Java have found a way." Read below for Michael's review

Computer Graphics Using Java 2D and 3D
author	Hong Zhang and Y. Daniel Liang
pages	462
publisher	Pearson Prentice Hall
rating	8
reviewer	Michael Grady
ISBN	0-13-035118-0
summary	Introduction to computer graphics concepts and techniques using Java 2D and 3D

Their strategy is to teach by example using the comprehensive, high level interfaces provided by Java 2D and Java 3D. Their examples are often well chosen and fun. The programming exercises are entertaining and appropriate.

About one third of the book is devoted to 2D graphics and covers the usual topics: coordinate systems, modeling, constructive area geometry, color models, affine transformations, compositing, splines, clipping, fonts, raster images, animation and image processing. As anyone who has worked in this area knows, Java 2D provides a beautifully designed set of classes for high quality 2D graphics and imaging. This part of the book could also serve as an excellent introduction for any programmer who wants to begin exploring its functionality.

Where the book really shines is in the examples. My favorite 2D examples include:An interactive demo of the RGB Color model which also illustrates constructive area geometry. An efficient rendering of the Mandelbrot set as a raster image. An elegant analog clock that shows how to use the Timer class in animation. An interactive demo of the common 2D affine transformations.

Surprisingly, none of the code uses anti-aliasing, even though Java 2D does a great job smoothing rough edges. In computer graphics circles, this is a faux pas — a violation of accepted, although unwritten, social rules, and points must be deducted for this omission. But if you add the required one line of code, most of the examples look pretty good.

The last two thirds of the book are devoted to 3D graphics programming, which reflects a common emphasis in the course at the undergraduate level. Coverage includes scene graphs, the rendering pipeline, 3D modeling, affine and projective transformations, illumination and reflection models, texture mapping, adaptive rendering, animation and interactivity, as well as object oriented graphics concepts such as behavior dynamics.

Java 3D provides a high level, object oriented framework for 3D graphics programming, with about 360 classes. For those who are used to programming with OpenGL, the Java 3D mindset may require a bit of indoctrination. It's based on the concept of a scene graph, and makes a lot of sense from an object oriented programming viewpoint.

Basically, a scene graph is a data structure for organizing the objects of a scene. We mean objects in the object oriented sense. Java 3D objects may be responsible for geometric, transformation, illumination, shading or behavioral data. The nodes of the scene graph represent objects and the edges represent a necessary connection. For example, a transformation node may be connected to a node representing a cube. The corresponding transformation object defines how the cube should be rotated, scaled, etc. In traversing the graph from its root, the Java 3D rendering engine finds all the information required to render the scene. It's a cool way to do computer graphics at a higher level of abstraction than programming directly with OpenGL.

Once again, many of the examples are excellent for an introductory text. My favorite 3D examples include: The classic spinning dodecahedron. This example shows that setting up the scene geometry is pleasantly intuitive in Java 3D. The ease of computing the normal vectors of all plane surfaces using the NormalGenerator class is a good illustration of the power of object oriented programming. Transformations, lighting and material properties are handled by dedicated classes. An interactive illustration of the common 3D affine transformations showing the effect of modifying transformation matrices. The mirror image of rotating 3D text that demonstrates the effect of composing transformations. How to generate a torus mesh. The canonical Utah Teapot.

Once again,the code does not use anti-aliasing, even where it is badly needed.

One of the benefits of using the Java platform is the extensive support for networking, multithreading, multimedia, database access and web services. For the most part, none of these benefits are exploited in the text. But that is probably the subject for a second course in computer graphics using Java.

All in all, it's clear that the authors are excellent teachers. This shows in their effective use of the teaching-by-example style. As stated in the preface, the authors intended their book for students and computer professionals who want to learn basic computer graphics concepts and techniques and who want to get started in programming with the Java 2D and 3D APIs. I believe they have succeeded in this goal, and if you are in this group of readers, I can confidently recommend their book.

---

You can purchase Computer Graphics Using Java 2D and 3D from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Re:Interesting

[Anonymous Coward]

Hardware rendering (with something close to java's innate portability) requires projects which bridge java and opengl, such as jogl.

However, the "official" java3d api (https://java3d.dev.java.net/) is coming along quite well -- it will identify directx/opengl on the platform it is running on and utilize it. Sadly, there's no way to use software rendering, but the usefulness of that is arguable.

The trouble with scene graph APIs

[Animats]

Historically, scene graph APIs haven't been too useful. There are successful drawing APIs, like OpenGL, and game engines, but the in-between middleware hasn't been that useful. SGI Inventor, later Open Inventor, was the classic in that space, and it's not used much any more.

Java 3D is abandonware. Sun wrote it, badly, and it's now a "community source project", meaning Sun doesn't support it any more. I used it in its early days and wasn't impressed. The Java3D collision detection system was both badly designed and badly implemented. [tufts.edu] The general consensus was "give us an OpenGL binding [j3d.org] and get this turkey out of the way".

Re:Quick guide to doing graphic work in Java:

[AKAImBatman]

And before anyone marks this as a troll, C# supports unsigned values. Java does not. Since RGB color spaces are frequently represented as unsigned values between 0 and the maximum word size (usually 8-bit) this makes working with computer graphics in Java either a giant pain in the ass, or a word size larger than the permitted range. (For example, using shorts instead of bytes.)

Do you even understand how signed values work? Signed and unsigned are the exact same thing, save for two major exceptions:

1. Sign-preserving operations. The only one I can think of off the top of my head is a signed right shift. (>>) Use a bitwise shift instead. (>>>)

2. When the result of computations are printed out. An unsigned value is printed as a larger positive number while a signed value is given a negative sign and inverted if the first bit is a 1, before being printed out.

Java has a very sophisticated graphics library. (see: java.awt.image.BufferedImage) It uses 32-bit ARGB values. Somehow, the sign doesn't seem to cause a problem. :-/

Re:Interesting

[AKAImBatman]

I've always been under the Impression that Java can't use hardware rendering, wouldn't that restrict usage for more intense applications?

Java 1.4 added support for a direct-rendering scheme [sun.com] similar to DirectDraw. The primary difference is that surfaces are managed automatically by the JVM rather than being explicitly locked and unlocked.

JOGL [java.net] introduced an official add-on for OpenGL support in Java, and was standardized under JSR-231 [jcp.org]. Several Java-based scenegraphs appeared shortly thereafter. The most popular are Xith3D [xith.org] and jMonkeyEngine [jmonkeyengine.com].

Java3D has been an official add-on since about '98 (IIRC), but it was less useful because it hid access to OpenGL behind its scenegraph. As a result, it was discontinued shortly after the introduction of JOGL, only to be brought back as a Sun Open Source Project [java.net]. It now supports the JOGL/JSR-231 standard.

Does that answer your question?

Re:Quick guide to doing graphic work in Java:

[harmonica]

You have to do an explicit cast:

byte a = (byte)0xff;

That's a bit annoying, but hardly a giant pain in the ass.

Re:Quick guide to doing graphic work in Java:

[AKAImBatman]

That's because you're specifying a 32-bit int value for an 8-bit byte variable. Try this instead:

byte a = (byte)0xFF;

This program will print out the correct result of -1:

public class TestSign
{
  public static void main(String[] args)
  {
    byte a = (byte)0xFF;
 
    System.out.println("Byte = "+a);
  }
}

If you want to upconvert it to an int, don't cast it. Casting is a sign extended operation. Instead, you can OR the value. e.g.:

byte rgb = 0xFF0000; //Red
byte a = (byte)0xFF;

rgb |= a; //Purple

Java makes you work a bit more at it, but it's nothing major. In most circumstances you *should* be using bitwise operations anyway. There are very few situations where you need to add an unsigned byte to a signed integer. (Most of them caused by a false sense of optimization or memory economy.) In those cases you use a (0xFF & a) operation to cast the byte without sign extending it.

Re:Yeah...

[Mithrandir]

Please provide proof of your assertions.

I have plenty of examples for you where our Java code is not only faster than competitors written in C or C++, but the margin of speed differences are double or greater. This is implementing open standards development work, so we're all playing on the same page, not comparing different game engines or so forth. In fact, our scene graph APIs are more than twice as fast as Java3D for the same content and typically 10+% faster than native-code based scenegraphs like OpenSceneGraph. Take a look at the j3d.org site or anything involving Xj3D.

Java is more than fast enough for full graphics. FWIW, I do high end scientific, medical visualisation and a fair amount of military work on the side. The places where highly optimised code for the task at hand is the order of the day.

Re:Interesting

[Mithrandir]

You're almost correct on the surface management side. For the most part, the JVM does manage it, but there are times where you have to do explicit management, and there are API calls to do this as part of the JAWT bridge library. One of the libraries I work heavily with is JOGL, and specifically the SWT port of JOGL, so I'm (unfortunately) more than a little aware of the surface locking protocols that one needs to go through. However, the only people that ever have to worry about this are those of us that implement native heavyweight renderers, such as JOGL. There's a lot of platform-specific surface locking going on under the covers - X11 code locks and unlocks surfaces at different times to Win32 or OSX, for example. You need to lock the surface for doing things like context management. makeCurrent() can't just be made at any random time, even though JOGL lets you do that, there's a whole raft of code under the covers that takes care of all the timing issues involved that you normally would have to deal with in a native code version of the same thing.

Re:Yeah...

[UnknownSoldier]

> Please provide proof of your assertions.

Having implemented (a working subset of) OpenGL on the Wii, there is no way I'd want to interface it with Java anytime soon. There is a reason _doubles_ are banned in our game engine. One PS2 they are emulated in software, and provide no extra benefit aside from taking up more space, and being slower. If you can guarantee that no doubles will be used throughout Java, then maybe I would agree with you.

Does your Java implementation let you align your data types (such as vector3f) to 16 byte alignment?

Does your Java implementation provide an assembly or fast version of Vector, Matrix, Quaternions types?

> our Java code is not only faster than competitors written in C or C++

1. A better algorithm written in a slower language can beat a poor algorithm in a faster language, so unless you know what algorithms they are using, its an apples to oranges comparison.

2. Let me guess, you're not running on consoles. Even something as simple as virtual functions will kill your CPU cache on these machines. On PC boxes, you have faster CPUs, and far more memory to take advantage of.

> our scene graph APIs are more than twice as fast as Java3D for the same content and typically 10+% faster than native-code based scenegraphs like OpenSceneGraph.

Scene Graphs are over rated, and demonstrates someone hasn't thought the rendering problem through. (i.e. Tell me, how does your scene graph handle objects with transparency?) Stuffing everything into one big generic container is one way to kill performance, instead of using specialized containers.

> Java is more than fast enough for full graphics.

It depends on your platform. Let me know when you have a fast Java platform for PS2 or Wii, let alone enough memory left over, and your frame rate isn't killed by the garbage collector.

Since the native sce*() or GX*() calls on the PS2 and Wii, respectively, are C only, you're going to have a hard time calling them from Java. Java has it's place, but not on consoles. If you got time & money to burn getting this to work, feel free to go ahead. For better or worse, we're stuck with C++ development on consoles.

If I was developing strictly on PCs, then yeah, Java has a lot of advantages -- one that I can throw more hardware at the problem. But soon as one hits the "embedded" market, its disadvantages demand serious consideration.

--
How long do we have to wait before C/C++ gets rids of this short, long, double crap? (Is it really that hard to have a stardard pragma that disables up-casting, standardized syntax for alignment?)

Re:Don't worry

[mypalmike]

As a student I really thought I would get the opportunity to write games, but after seeing the development process at a software publisher specializing in gaming, I realized that the programmers spend more time dealing with things like physics and optimization and leave a lot up to graphics artists.

That was not my experience in 10 years of professional game programming. Every project I worked on required a significant amount of graphics programming. In some cases, there were one or two guys who did the graphics programming full time. In others, almost everyone contributed some graphics code. And even if you end up doing mostly audio, AI, or physics, the math you'll learn in a 3D graphics class is very useful.