Slashdot Mirror
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.
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.
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."
Why must you ask rhetorical questions of me???
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
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.
Unfortunately, teaching computer graphics in Java3D locks the aspiring developer into the Java platform. At least with OpenGL, you're not locked into any particular programming platform and have more choices in that regard. That makes learning OpenGL easier as well, since you don't have to already be a Java developer to pick up OpenGL and can instead learn it in your favorite language. And, at this stage in the game, there are plenty of Object-Oriented APIs based on OpenGL available.
Life would be easier if I had the source code.
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 really is a brilliant achievement. It comes with nearly everything built in, and what is not included is easy to make. The simplicity of Graphics in JAVA is unsurpassed in any real language, and has huge capabilities. Even using OpenGL with JAVA is possible. This work is exactly what is needed to get more people using JAVA and revolutionary in the way of graphics. I still remember trying to draw a house with Assembly and C++ using only native libraries. JAVA makes life a lot easier, and graphics possible for all.
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.
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. The general consensus was "give us an OpenGL binding and get this turkey out of the way".
If you are programming portable code you want any non-Windows users to be able to run casually, Java is a better choice. The web consists of more than just Windows users, y'know.
(you knew it was coming) we had to deflect the electron beams ourselves using little magnets we had dug out of the ground with our bare fingernails.
ccalam - acoustic versions of new songs.
As far I know, Java uses 32 bit values internally as a minimum, so even if they got around adding a unsigned byte, it would technically be a 32 bit value in disguise. But I got to admit, the lack of unsigned byte is a huge annoyance when you program in java. :/
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.
Javascript + Nintendo DSi = DSiCade
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.
Java 1.4 added support for a direct-rendering scheme similar to DirectDraw. The primary difference is that surfaces are managed automatically by the JVM rather than being explicitly locked and unlocked.
JOGL introduced an official add-on for OpenGL support in Java, and was standardized under JSR-231. Several Java-based scenegraphs appeared shortly thereafter. The most popular are Xith3D and jMonkeyEngine.
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. It now supports the JOGL/JSR-231 standard.
Does that answer your question?
Javascript + Nintendo DSi = DSiCade
You have to do an explicit cast:
byte a = (byte)0xff;
That's a bit annoying, but hardly a giant pain in the ass.
byte a = (byte)0xFF;
This program will print out the correct result of -1: 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;
byte a = (byte)0xFF;
rgb |= a;
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.
Javascript + Nintendo DSi = DSiCade
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.
Life is complete only for brief intervals in between toys or projects -- John Dalton
Well, there may be a lot of people out there who like Java, but I'm not one of them. Java is the Cobol of the 21st century, it's OK for bureaucratic applications, when you need attributes like "traceability" and "auditability", but come on, graphics?
Get serious, folks! Java is about the last language one would use for computer graphics. It lacks the raw speed of C, it lacks the quick and dirty coding pace of Python. If I worked for Mastercard or Citigroup I would use Java, of course, but not for graphics!
FTA:
"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()!