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 amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Anti-alasing not needed with interval rendering (Score:2)
http://sunfishstudio.com/ [sunfishstudio.com]
Re: (Score:2)
Are they using interval arithmetic in the renderer? I'm not sure how novel that would be as I used it in a ray tracer in a previous company pre-1990. Of course, they may have added some new way of using it.
As for Java graphics, I have heard on the grapevine that it can make it rather challenging to get anywhere near the native performance of the rendering hardware.
Re: (Score:2)
In reality, the possibility exists that their claims could be overblown as there are a variety of anti-aliasing routines for 3D rendering. They may be advertising the direct computation
Interesting (Score:2)
Re:Interesting (Score:5, Informative)
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: (Score:2, Informative)
Re: (Score:2)
>> but the usefulness of that is arguable.
I guess that depends. Most computers using even embedded video chipsets have some form of OpenGL or DirectX 3D hardware acceleration, even if it sucks, but there are some embedded-style devices that might support Java that may lack 3D acceleration or a common 3D library. In those cases it would be nice to have some kind of built-in software rendering default.
why bother asking (Score:3, Funny)
Why must you ask rhetorical questions of me???
Re: (Score:2, Funny)
Probably a good read (Score:2, Interesting)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You're right, there's a lot more to games development than graphics. I can tolerate weak graphics (up to a point) but I want to scream when NPCs can't find their way around simple obstacles. Also, human factors is a lot more important than eye candy, as the success of the Wii has demonstrated.
But a lot of people associate game design with graphics. Which is why this thread drifted from Java graphics to game design. And why all those art school grads spent a lot of time
Re: (Score:2)
This statement means nothing to me. If OpenGL fulfills your need then why should one use DirectX? Just because it is "the standard"? If a bike fulfills all my traveling needs, then why should I use a car instead of a bike even if the car is "the standard"?
Re: (Score:2)
I think the point was that OpenGL and DirectX were pretty much the same thing once upon a time, but whilst MS kept on adding more and more good stuff, the OpenGL committee argued over what they might add, and as a result ended up adding very little. Committees - pah.
Re: (Score:2)
I already said the bike *fulfills all my needs*. I don't need 20 times faster, the supermarket is only 3 minutes away by bike. Riding the car is not more comfortable, that's totally subjective. I don't care about the car radio, I have an MP3 player. Since when do I have to wear a helmet to ride a bike?
I'd even dare to say that the bike is better. Riding a bike is better for o
Re: (Score:2)
If you want to build games for yourself than you can use whatever you want.
Re: (Score:2)
Java for the rest of your life... (Score:5, Insightful)
Re: (Score:2)
I'd say that if one's education in computer graphics ends with the first book one picks up, they deserve to be locked up. In a mental institution preferably.
Aside from the obvious idea of using this book to teach graphics to those who are already on friendly-terms with Java, it still teaches graphics. While the examples and code are in Java, a reader would (hopefully) learn good practices for graphics in
Re: (Score:2)
Re: (Score:2)
And that's a problem because... ?
That's a fair enough point, though it *is* more than sufficient for the presented purposes of teaching. It's not like a serious 3D developer is going to do his work in Java3D. While you *can* do this, you'll have to work around a number of its shortcomings. A much better
Yeah... (Score:3, Interesting)
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.
Re:Yeah... (Score:4, Insightful)
Java is not always slow, and if you wanted to use JOGL you'll get pretty decent performance.
That said, the mistake that everyone seems to make is that you either do no graphics, or you are trying to recreate Doom 3. You're right that no one in their right mind is going to try to make the next Doom 3 in Java any time soon. But what if I just want to experiment with some simple 3D graphics? What if I want to make a neat little graph in my already existing Java program? What if I want to print fancy stuff from Java (which just gives you a canvas and makes you do the drawing).
You can experiment, do simple things, there are lots of reasons to go with Java for a small project. Maybe you want to make it an applet so it's easy to put in a browser.
PS: I'm working with Java3D right now, and I find it very interesting. I've done OpenGL before, but I've never used a scenography library, so there is an interesting learning experience there.
Re: (Score:2)
Re: (Score:2)
But slow as in raw CPU speed? Is that really so? The Sun JVM has supported JIT compilation for 10+ years now. Also, are the possible overheads introduced by Java significant compared to the time needed for the GPU to render the graphics?
Re:Yeah... (Score:5, Informative)
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: (Score:2)
I like Java, but the fact is that every end-user GUI desktop application I have ever seen written in Java is perceptibly slower than similar apps written in compiled languages, at least in terms of GUI rendering and responsiveness. It's seldom enough to be a problem, but it's there, and anyone can see it.
Claiming that Java is across the board as fast or faster than native code has probably done more to damage its reputation than anything else. It's like those absurd anti-marijuana ads that claim al
Re: (Score:2)
Java is a compiled language. Its main gui(JFC/Swing) is slower than native guis because it is designed as a cross-platform system; the Java language itself is not a problem, and is definitely not slow.
Re: (Score:2)
Hmm, moments ago we were talking about 3D graphics, and now suddenly it's desktop applications and GUI toolkits?
I don't think I've seen anyone make this claim.
Nice attempt to re-frame the d
Re: (Score:2, Funny)
Military work on the side? I may have a few jobs for you,my neigbour is really beginning to piss me off.
Re:Yeah... (Score:5, Informative)
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: (Score:2)
Not entirely certain what you mean here, but have you seen ? It defines a bunch of standard types like int8_t, uint8_t (sized integers), int_least8_t (smallest type containing at least that number of bits), int_fast8_t (fastest type containing at least that number of bits), intptr_t (type containing enough bits t
Re: (Score:2)
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."
For a guy demanding proof you might actually tell us about these examples you "have plenty of".
Re: (Score:2)
Re: (Score:2)
Yeah, I mean it's not like you could write a 3D FPS in Java and get performance comparable to C [bytonic.de], is it?
Re: (Score:2)
I used to say that, and I'm still wary of OO performance hits.
But suppose you want to draw each object in a list. They are aliens, projectiles, etc., so they get different drawing functions. The obvious choices are:
The brilliance of JAVA (Score:2, Insightful)
Re: (Score:2)
Re:Is the brilliance of JAVA due to JAVA? (Score:2)
Re: (Score:2)
Java is
Re: (Score:2)
LOLOLOLOL!!!
Ummm, what you're talking about is Java's classes , which is a class library, not a language. You can create similar class libraries in C++ or even assembler and they'd have the same advantages. That's why people write class libraries. I'd argue that OS X's Cocoa frameworks are much easier to understand and use than Java's, and no doubt there are plenty others out there equally good or better. Maybe before you embarras
Java 3d (Score:2, Interesting)
Re: (Score:2)
The trouble with scene graph APIs (Score:3, Informative)
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: (Score:2)
Scene graphs do sound a little off the wall to me, based on the description in the review.
When I think about 3D rendering, I think about modeling things as physical objects, with their shape, location, and orientation. Now, I can see the action of "rotate the object" or "place the object" being a function, but I really don't understand the concept of putting verb information in an object (which I consider to be a noun).
It seriously makes my head hurt to think that in order to draw an object X at location
Re: (Score:2)
Scene graphs do sound a little off the wall to me, based on the description in the review.
Scene graphs are a very useful concept. The problem is that they're more useful for handling object behavior than drawing. Game engines have elaborate scene graphs, used by the game system to decide what's near what and what to do about it, the collision detection system to keep things from going through walls, and the physics engine. So if you're doing something that has automated behavior, the scene graph is
In my day... (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Deflect the electron beams with magnets you say? back in my day we had to guide each one with our hands - and always ensure that our hands maintained a refractive index of 0 or less to not spoil the illusion. Magnets? we'd have killed for magnets!
Re: (Score:2)
Re: (Score:2)
You had an electron BEAM?
We just had a single electron, bought secondhand, which we had to use over and over...
did java improve jpg quality (Score:2)
when I taught AP Comp Sci we did som
Re: (Score:2)
It got acceptable after a bit of work on my end.
Courses still low level (Score:2)
Porting to Cell DSPs (Score:2)
Is there an open source Java OpenGL implementation? That would be a great package to see running on the Cell.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The PS3 in game mode uses both the SPEs and the RSX, and has the same amount of memory, but has excellent graphics.
No mention of 'Processing'? (Score:2)
Every Java program is really 2 programs (Score:2)
Shaders! (Score:2)
Computer Science is not about APIs! (Score:2)
Many universities these days are turning out "programmers" rather than "computer scientists" -- they can get stuff done, provided the tools are available to them, but God help you if you ever ask one to cr
This isn't learning about computer graphics (Score:3, Interesting)
"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()!
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
As far I know,...
From what I just read, that's shorter than the distance to your coffee grinder.
Re:Quick guide to doing graphic work in Java: (Score:5, Informative)
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: (Score:2)
byte a = 0xFF;
Re:Quick guide to doing graphic work in Java: (Score:4, Informative)
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: (Score:4, Informative)
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.
Re: (Score:2, Troll)
Not only that, you're not even right. You miss the following problems:
Re: (Score:2)
Java and unsigned types (Score:2)
Re: (Score:2)
Which can be read as "some of the weird and obnoxious problem you'll run into have non-obvious workarounds."
Furthermore, Java actually *does* have an unsigned 16-bit type. It is called "char"
Whatever, repeat the same criticism for "byte."
Re: (Score:2)
Well, yeah. If the documentation says, "This method expects a bit-packed value in ARGB format" you had better pass it a value in ARGB format. That's true whether you're working in Java or C/C++. I pity the fool who doesn't read his documentation.
Killer isn't it? Adding that extra > sign.
Re: (Score:2)
Bit-packed, huh? You must really like bitwise operations. A sane language would let you express it as a struct with four members. But keep working around Java's quirks; it's no skin off my back.
Killer isn't it? Adding that extra > sign.
The amount of work has absolutely nothing to do with it. It's not much work to walk around the mines in a mine field.
Um, okaaaay
Re: (Score:2)
Source: http://www-128.ibm.com/developerworks/power/librar y/pa-ctypes3/index.html [ibm.com]
I especially like the line: "Amon
Re: (Score:2)
3. Division. The shortest implementation of unsigned division using signed types I could knock together in a few minutes is
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Real graphics is done with floats.
Re: (Score:2)
Re: (Score:2)
That would be the specific library, not Java. Java has multidimensional arrays, though they are actually arrays within arrays. (ad infinitum)
That is generally the fastest way to access image data. I don't know about you, but I've be
Don't worry (Score:4, Interesting)
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.
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
Especially nowadays where a lot of game companies simply license various engines that do most of the hard/interesting work for you. But I guess you coudl always get a job with the people who develop the engines
Re: (Score:3, Informative)
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 gr
Re: (Score:2)
Re: (Score:2)
Why does everyone here seem to assume I have to be making Doom 3? First, why does a graphics project have to be new? Why can't I add some graphics to my existing Java app? Porting the whole thing to Ruby then doesn't make much sense. Java is a modern, high-level language, and it is much more well known that Ruby. If you went through school more before one or two years ago (and probably up to now) chances are if you were taught one of Ruby and Java it was almost certainly Java.
Java isn't perfect, by why doe
Enterprise does not exclude graphics... (Score:2)
... although I sometimes have a hard time convincing IT consultants of this -- What? You want your data in a GRAPH? Are you SERIOUS? -- Good, annotated, interactive plots can be enormously helpful to make sense of numeric data, which is what a lot of business programming is about, regardless of whether you are an investment banker or a pharmaceutical researcher.
If such features are absent from some business software, it is not because users would not find them useful; it is because many business programme
Re: (Score:2)
Because object orientation is a natural fit for 3D graphics, and because I won't willingly do anything in a language so primitive that it lacks automatic memory management.
...which is based on Java.
Because it's 10-100x slower than Java?
I us
Re: (Score:2)
In addition, Runescape is WAY older than WOW.
Why (-1, troll)? (Score:3, Insightful)
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 J
Re: (Score:2)
Re: (Score:2)
I agree. Whether a corporation invented the language should be the deciding factor in whether it's used for OpenGL. That's why I would never use C or C++ for calling OpenGL, but Perl would be a perfectly good choice.
Re: (Score:2)
Say that again? C and C++ are standards-based languages with no official working implementation. That's definitely not "corporate-made", in the sense of Java (or C# for that matter).