Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×
Book Reviews Books Media

Computer Graphics With Java 218

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 Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Computer Graphics With Java

Comments Filter:
  • Probably a good read (Score:2, Interesting)

    by An Ominous Coward ( 13324 ) on Wednesday July 11, 2007 @03:23PM (#19828969)
    First of all, I've used Liang's introductory Java book in classes I've TAed, he is quite good.

    As for Java graphics programming itself, it's definitely a mixed bag, but in general more good than bad. Back in my undergraduate days I took two courses for Java graphics and Java game programming. If you're already familiar with the language, it's a great tool for learning the basics and mid-level game-oriented 2D and 3D programming. Java has a lot of great tools for all kinds of design, and the speed-issues are not a concern with JIT and APIs that take advantage of hardware acceleration. And Java's easy network programming lets you build some interesting projects.

    That said, people seriously thinking about futures in game development should be learning DirectX and C++ as soon as possible. OpenGL is great, and if you're doing cross-platform work it's obviously the right choice. But DirectX is the standard now; even Carmack hasn't been too hard on it lately. It's managed to make great strides while the OpenGL committee squabbled.
  • Yeah... (Score:3, Interesting)

    by Anrego ( 830717 ) on Wednesday July 11, 2007 @03:26PM (#19828999)
    Java is about the last language id use for anything involving graphics.

    I'm no Java hater, I think it owns when it comes to developing maintainable applications and deployment across multiple platforms, but lets be realistic, it's slow.

    One could argue that it still has merit in an academic sense, for teaching the basics of graphics programming, but even that is kind of flawed. You probably want to avoid OOP in general when it comes to the actual graphics component of an application, as it adds overhead. Not only is Java itself slow, but the way in which it approaches graphics is probably the worst way to approach it in any language performance wise.
  • Java 3d (Score:2, Interesting)

    by edxwelch ( 600979 ) on Wednesday July 11, 2007 @03:27PM (#19829017)
    There is an enormous amount of work done in the Java 3d api, unfortunately hardly anyone uses it - I counted only a handful of games made - most not really commercial quality. It's ironic that the mobile 3d version has had a lot more success, considering how limited mobile phones are.
  • Don't worry (Score:4, Interesting)

    by wawannem ( 591061 ) on Wednesday July 11, 2007 @03:38PM (#19829131) Homepage
    As a somewhat-successful professional software engineer, it has been my experience that this sort of programming is not as common as many students and/or civilians think. The majority of programming code is done on the business level... i.e. I need a report that will tell me how fribble relates to frabble, or we need a system that will track all of the incoming support requests on our jimble jamble product.

    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.
  • by Anonymous Coward on Wednesday July 11, 2007 @04:07PM (#19829501)
    You'd be wrong. First, clock ticks are cheap. An insanely fast computer can be bought for as little as $200-$300. You probably pay developer that for just over one day's work. If you can shave a week's worth of development time off of a project with 10 devs, then you can probably afford to double the hardware requirements. If you've got 10,000 employees waiting on this app, what do you think is more important: having your code run 10% faster, or having it available now? Installing an extra server can make up that speed difference, but nothing can recoup the lost productivity of those 10,000 people.

    Second, java is fast. The JIT is going to compile the code to native as soon as it starts running a lot. Maybe within the first few seconds of operation. A large-scale program is going to be running for a long time, and those brief moments lost to compiling at start-up aren't going to amount to much.

    A JIT compiled language can actually run faster than a natively compiled one. Why? For two reasons: compiled code is compiled for the lowest common denominator, and the JIT has more information available to it than a static compiler. The JIT can be smarter than a static compiler. It can see that some final variable has been set to a certain value or the isNetworkAvailable() function is always going to return the same value, and can optimize out all of the loops and branches around those statements, or just re-arrange them so that the preferred branch is always taken in speculation. It can see that it is running on a machine that has a certain SIMD instruction available, and can compile using that instruction.

    I recently upgraded to a 64 bit machine. I installed a 64 bit JVM, and all of my code ran as 64 bit. It Just Worked. No rewrite. No recompile. The JVM just compiled my java as 64 bit code as it ran. I got >2gb of heap space, and it is presumably using some those new native 64 bit instructions.
  • by Viol8 ( 599362 ) on Thursday July 12, 2007 @10:18AM (#19837523) Homepage

    "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"

    Well sorry , but that IS (amongst other things) what computer graphics is about. If you want to learn how to write a graphics program in Java, sure, get this book, but if you want to learn how computers do graphics you NEED to learn this low level stuff as well as going down even further to the hardware level. Any serious computer science course will teach this low level detail, only toy colleges would teach you one line library calls and pretend they're actually teaching you computer graphics.
    Its a bit like someone professing to teach about filesystems then not going any deeper than fopen()!

The absence of labels [in ECL] is probably a good thing. -- T. Cheatham