×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Computer Graphics With Java

samzenpus posted more than 6 years ago | from the read-all-about-it dept.

Book Reviews 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

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

218 comments

One class I missed in school (0, Offtopic)

microbee (682094) | more than 6 years ago | (#19828853)

I didn't take this class back when I studied computer science. It was kinda boring at that time. But maybe time has changed now.

Don't worry (3, Interesting)

wawannem (591061) | more than 6 years ago | (#19829131)

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.

Re:Don't worry (1)

misleb (129952) | more than 6 years ago | (#19829345)

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.


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

-matthew

Friends... (-1, Troll)

Lord of Hyphens (975895) | more than 6 years ago | (#19828889)

...don't let friends code in Java.

Stop wasting time (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19829323)

Don't waste your time, man. Pick up a book on programming with DirectX, and use what the big boys use.

Re:Stop wasting time (1)

Jorgandar (450573) | more than 6 years ago | (#19830167)

That's funny...it seems the folks at runescape (www.runescape.com) have had plenty of success with their JAVA 3D game. They seem like a pretty big boy to me.

Runescape: "There are currently 208580 people playing!"

Anti-alasing not needed with interval rendering (1)

192939495969798999 (58312) | more than 6 years ago | (#19828895)

You don't need antialiasing if you are rendering with an interval engine like this one:
http://sunfishstudio.com/ [sunfishstudio.com]

Re:Anti-alasing not needed with interval rendering (0)

Anonymous Coward | more than 6 years ago | (#19829035)

sorry mate, we are talking about REAL-TIME computer graphics here, not animation for movies.... but the technology sounds pretty amazing. do you own any share in this company ? ;-)

Re:Anti-alasing not needed with interval rendering (0)

Anonymous Coward | more than 6 years ago | (#19829457)

Wow. A company has trivial examples of spheres and teapots. And they're 'patent pending'. Analytical evaluation has been there for ages. The methods they are saying 'suck' have been invented to speed up the rendering process. (sigh).

Re:Anti-alasing not needed with interval rendering (1)

bobstatesman (927692) | more than 6 years ago | (#19829689)

From http://sunfishstudio.com/software.htm [sunfishstudio.com]:

This patent-pending technology analytically renders NURBS and subdivision surfaces directly into perfectly anti-aliased pixels
Sounds like it does use anti-aliasing, although the way it's done does sound somewhat different from traditional anti-aliasing techniques (I haven't looked at it in detail). On a side note, it also sounds like there might be patent issues if anyone else decides to go with their approach.

Re:Anti-alasing not needed with interval rendering (1)

AKAImBatman (238306) | more than 6 years ago | (#19829817)

Our esteemed anonymous representative was trying to say that their method renders an antialiased scene by nature of the algorithm, not because an antialiasing routine was applied. In theory, this differs from traditional methods in that it makes the renderer simpler and takes fewer computations to achieve the desired result.

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 of anti-aliasing information over the downscaling methods. (e.g. anisotropic filtering and supersampling) It's hard to say without reading up on the rendering method they're using.

Quick guide to doing graphic work in Java: (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19828903)

Use C# instead.

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.)

For 3D work, you can usually skip this, since most 3D work uses floating point values, but you still have times when it would be really nice if Java supported unsigned types - which makes doing the same task in C# plain easier than in Java. (And this ignores speed and memory issues. C# makes inline assembly possible, Java makes it just plain slow.)

Re:Quick guide to doing graphic work in Java: (0)

Anonymous Coward | more than 6 years ago | (#19828957)

i inlined assemblied your mom last night

Re:Quick guide to doing graphic work in Java: (2, Insightful)

fruitbane (454488) | more than 6 years ago | (#19829071)

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.

Re:Quick guide to doing graphic work in Java: (2, Insightful)

Ailure (853833) | more than 6 years ago | (#19829085)

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. :/

Re:Quick guide to doing graphic work in Java: (1)

GodfatherofSoul (174979) | more than 6 years ago | (#19830379)

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: (5, Informative)

AKAImBatman (238306) | more than 6 years ago | (#19829107)

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:Quick guide to doing graphic work in Java: (1)

EEBaum (520514) | more than 6 years ago | (#19829271)

Except that, without unsigned values, Java won't let you, for example, say:

byte a = 0xFF;

Re:Quick guide to doing graphic work in Java: (3, Informative)

harmonica (29841) | more than 6 years ago | (#19829419)

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: (3, Informative)

AKAImBatman (238306) | more than 6 years ago | (#19829495)

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:Quick guide to doing graphic work in Java: (1, Troll)

CoughDropAddict (40792) | more than 6 years ago | (#19829593)

Wow, you Java apologists are hard-core. Your contention is that the lack of unsigned types is no problem at all because you can:
  • infer from context/documentation that *some* signed values are actually unsigned values in disguise
  • for such values, use bit shift instead of arithmetic shift
  • for such values, manually translate them if they are printed incorrectly on the console or in a debugger
Not only that, you're not even right. You miss the following problems:
  • you will have to devise your own strange and complicated ways to detect overflow
  • you will not be able to assign literal values outside the signed range of the data type (short x = 65535 does not compile)
  • Types will be converted incorrectly, as demonstrated in the following program:

    public class Test
    {
        public static void main(String args[])
        {
            short y = -32768; // 65535 in disguise!
            int x = y; // "incorrectly" converted to (int)-32768
            System.out.println(x);
        }
    }

Re:Quick guide to doing graphic work in Java: (1)

CoughDropAddict (40792) | more than 6 years ago | (#19829705)

Oops, got my twos complement wrong in the example -- it's been a while. But the point is still valid.

Re:Quick guide to doing graphic work in Java: (1)

teknopurge (199509) | more than 6 years ago | (#19830091)

No it's not.

why not use Short.reverseBytes(short) for your 2s-complement skills? ;)

Re:Quick guide to doing graphic work in Java: (0)

Anonymous Coward | more than 6 years ago | (#19829859)

Or maybe it really is -32768 and not 65535! Perhaps you should try: short x = (short)65535;

Java and unsigned types (1)

CustomDesigned (250089) | more than 6 years ago | (#19830121)

Your first three points are still valid (basically the one point that you have to manually keep track of which byte variables are really unsigned). However, your attempt to add more points is pathetic. For instance, "short a = (short)65535;" works just like "byte c = (byte)255;". Furthermore, Java actually *does* have an unsigned 16-bit type. It is called "char". As in "char a = 65535; int b = a;".

Re:Quick guide to doing graphic work in Java: (1)

AKAImBatman (238306) | more than 6 years ago | (#19830249)

infer from context/documentation that *some* signed values are actually unsigned values in disguise

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.

for such values, use bit shift instead of arithmetic shift

Killer isn't it? Adding that extra > sign.

for such values, manually translate them if they are printed incorrectly on the console or in a debugger

I don't know about you, but I like to see my bit-packed values in Hexadecimal. It's a heck of a lot easier to read than decimal. And what'dya'know? Java just happens to have a library for printing unsigned hexadecimal values [sun.com].

you will have to devise your own strange and complicated ways to detect overflow

Um, okaaaay. Would you like to explain to the class which overflow-detection scheme you can use in C/C++ that you can't use in Java? Remember, you've got the same bits in that 32-bit value. So unless you've got assembly hooks back to the processor to give you a heads up, I don't see how you could have a test in C that won't work in Java.

you will not be able to assign literal values outside the signed range of the data type (short x = 65535 does not compile)

First off, you're a very bad boy for using the decimal value 65535 when your real intent is obviously to fill all 16 bits with 1's. You should be using 0xFFFF for clarity instead. Secondly, the compiler thinks you're a bad boy for assigning an integer value to a short. You should have done this:

short x = (short)65535;

(Actually, you should have done "short x = (short)0xFFFF", but one point at a time.)

Thirdly, why are you doing such a thing? Java extends all bytes and shorts to integers for operations. This is a feature that gets around problems caused by newbs screwing up byte alignment with pointless attempts at saving memory. Your processor is a 32-bit computational machine. It's poor form (and poor performance) to make it pretend to be a 16-bit machine.

Types will be converted incorrectly, as demonstrated in the following program:

Oh noes! Casting rules!

As in, the rules you read when you learn how to program the language. Unsurprisingly, casts are signed. So if you don't want to cast a number (which you should never, ever, ever be doing with a bit-packed number anyway) you should be doing bitwise casts on them:

x = (0xFFFF & y);

See above for further ranting about why you are using a short for working storage rather than an integer.

Re:Quick guide to doing graphic work in Java: (0, Troll)

CastrTroy (595695) | more than 6 years ago | (#19829287)

I can't remember if it was a limitation on Java specifically, but the JPEG library I was using for image recognition in my univeristy robotics class didn't support multidimensional arrays for accessing pixels. So if you want the to access pixel i in row j of an image that's x * y pixels, you'd have to use image[j*x + i] (or something like that). Also figuring out where a particular pixel was located just based on it's index was equally cumbersome. From that moment on, I decided that working with graphics in Java was terrible.

Re:Quick guide to doing graphic work in Java: (0)

Anonymous Coward | more than 6 years ago | (#19829697)

Which was probably not a big deal, as I assume your current job at Burger King doesn't require this functionality that often.

Re:Quick guide to doing graphic work in Java: (1)

AKAImBatman (238306) | more than 6 years ago | (#19829703)

the JPEG library I was using for image recognition in my univeristy robotics class didn't support multidimensional arrays for accessing pixels.

That would be the specific library, not Java. Java has multidimensional arrays, though they are actually arrays within arrays. (ad infinitum)

So if you want the to access pixel i in row j of an image that's x * y pixels, you'd have to use image[j*x + i] (or something like that).

That is generally the fastest way to access image data. I don't know about you, but I've been using the formula (y * width + x) since before Java was even invented. (Actually, it was usually a high-performance variation that derived from the formula, but it was the same basic concept.) The formula is, and please take this with the utmost respect, an absolute requirement for anyone doing intricate graphics work.

FWIW, most programmers today never have to dive down to such a level. C/C++, Java, C#, Language of Choice(TM) all have libraries that abstract away low-level graphics operations. So unless you are writing a graphics library, you shouldn't need to deal with such things any longer.

Of course, in your case you were doing low-level graphics operations. If I were to hazard a guess, you were using the AWT Toolkit to load a JPG image, which you then extracted the pixel information from using a MemoryImageConsumer. (IIRC) Primitive stuff, intended for Applets. The BufferedImage and ImageIO libraries are much more useful these days.

Re:Quick guide to doing graphic work in Java: (1)

DrSkwid (118965) | more than 6 years ago | (#19829761)

Integers are for wimps.

Real graphics is done with floats.

Interesting (1)

Broken scope (973885) | more than 6 years ago | (#19828909)

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

Re:Interesting (0)

Anonymous Coward | more than 6 years ago | (#19828993)

You can access OpenGL via Java, which (depending on how you have things configured) can be hardware accelerated. The latest release of OpenGL supports shaders, so it's pretty competitive with other options.

Re:Interesting (1, Informative)

Anonymous Coward | more than 6 years ago | (#19829023)

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.

Re:Interesting (1)

fruitbane (454488) | more than 6 years ago | (#19829105)

>> Sadly, there's no way to use software rendering,
>> 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.

Certainly it can (0)

Anonymous Coward | more than 6 years ago | (#19829113)

Java3d is all translated into OpenGL calls, which are processed in hardware just like any other OpenGL calls. Java2D also uses some hardware help. Now that Java has been open-sourced, I expect we will see some JRE releases which take even more advantage of hardware.

Re:Interesting (5, Informative)

AKAImBatman (238306) | more than 6 years ago | (#19829243)

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?

why bother asking (2, Funny)

dj245 (732906) | more than 6 years ago | (#19828925)

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

Re:why bother asking (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#19829009)

Why do people insist on nitpicking every sentence in a summary?

In school, I built a basic 3d engine (0)

Anonymous Coward | more than 6 years ago | (#19828945)

out of lisp with some calls to C. I don't see why language would be a barrier for the basic stuff - computers nearly 8 years ago were fast enough to handle it.... we just started with the basic lineto function as well.

Breaks (0)

Anonymous Coward | more than 6 years ago | (#19828959)

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

Not anti-aliasing is a social faux-pas? Give me a break.

While I do like the fact that Java is... (0)

Anonymous Coward | more than 6 years ago | (#19828961)

... relatively easy to program with and that it probably does a great job handling the coding side. If I were making a large-scale program I still think it would be worth taking the time to do it in C++ or another direct compile language. This definitely will hit the mark in helping people make small web apps with great GUI's or web games, but when clock ticks are crucial, I think that Java's place is still very limited.

Re:While I do like the fact that Java is... (1, Interesting)

Anonymous Coward | more than 6 years ago | (#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.

Re:While I do like the fact that Java is... (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19829951)

Wow! I was just sitting here, reading a book and listening to some music and it started bleeping. I mean, it does that some times, but never that fast! I came running to the computer and found myself here...

Man, that Java Fanboy Detector went off the scale!

Re:While I do like the fact that Java is... (0)

Anonymous Coward | more than 6 years ago | (#19830081)

C/C++ meet Java.

You're his assembly language.

G'day sir!

Probably a good read (2, Interesting)

An Ominous Coward (13324) | more than 6 years ago | (#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.

Re:Probably a good read (0)

Anonymous Coward | more than 6 years ago | (#19829173)

We just ported a DirectX application to a Web Page using a signed Java Applet via Web Start and using JOGL to render the graphics.

Granted, it is not a photo-realistic application, but this type of display is far and above what the customer wants; the data is stationed on the web server, we are displaying it with an applet in their browser. It works though, and it works well and across all platforms and major browsers.

Re:Probably a good read (1)

An Ominous Coward (13324) | more than 6 years ago | (#19829435)

Cool. There's definitely tons of places where Java graphics is either the best choice or at least acceptable. Static or dynamic analysis, design tools, or any kind of scientific visualizers (molecule analysis, etc.) would be perfect for a Java-based systems. The reviewer mentions undergraduate classes though, and from my experience undergrads taking a computer graphics class are either already thinking "video games" or will best learn through a game-centric syllabus, keeping their interest with fun material they can relate to.

Re:Probably a good read (1)

fm6 (162816) | more than 6 years ago | (#19829391)

Anybody thinking about a future in game development should ask themselves whether they're just doing because it sounds like a fun way to make a living, or because they know that they have the makings of a world-class ubergenius game developer. So many people are studying game design (I was at an art school graduation ceremony; half the class had studied game design) that you have no hope of making a living at it unless you're the best of the best.

Re:Probably a good read (0)

Anonymous Coward | more than 6 years ago | (#19829797)

You do realize that Game Design and Game Development are two different things?

Granted, they both start with "de", but one is easy and hard to get into, the other is hard and easy to get into. You pick.

Re:Probably a good read (1)

FooBarWidget (556006) | more than 6 years ago | (#19829961)

"But DirectX is the standard now"

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

Java for the rest of your life... (5, Insightful)

SilentBob0727 (974090) | more than 6 years ago | (#19828975)

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.

Re:Java for the rest of your life... (1)

Applekid (993327) | more than 6 years ago | (#19829045)

Unfortunately, teaching computer graphics in Java3D locks the aspiring developer into the Java platform.

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 general.

Re:Java for the rest of your life... (1, Insightful)

Anonymous Coward | more than 6 years ago | (#19829155)

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

Despite the blindingly obvious conceptual holes that aren't supported in Java 3D like NURBS (http://en.wikipedia.org/wiki/NURBS).

Re:Java for the rest of your life... (1)

AKAImBatman (238306) | more than 6 years ago | (#19829339)

Re:Java for the rest of your life... (0)

Anonymous Coward | more than 6 years ago | (#19829581)

a) That's not Java 3D, nor is it part of the Java 3D spec; it's a library built on Java 3D
b) It's licensed as GPL; you might as well develop a computer graphics training class based upon proprietary software

*yawn* (0)

Anonymous Coward | more than 6 years ago | (#19828983)

"It's a cool way to do computer graphics at a higher level of abstraction than programming directly with OpenGL."

Wake me up when Java 3D contains native support for NURBS.

Linus is right (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#19828997)

I am with Linus on this one.
Unlike RMS he always makes his case intelligently. His contribution to FOSS is unmatched.
He deserves everyone's admiration. To hell with GPL v3

Yeah... (3, Interesting)

Anrego (830717) | more than 6 years ago | (#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.

Re:Yeah... (3, Insightful)

MBCook (132727) | more than 6 years ago | (#19829933)

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:Yeah... (1)

FooBarWidget (556006) | more than 6 years ago | (#19830051)

Java uses a lot of memory, on that I agree. Back in 1998, the JVM made the machine constantly swap, which makes it slow. Java GUIs also load slowly. Why that is I do not know, maybe because JIT compilation takes a bit of time.

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... (5, Informative)

Mithrandir (3459) | more than 6 years ago | (#19830169)

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.

The brilliance of JAVA (2, Insightful)

perlhacker14 (1056902) | more than 6 years ago | (#19829003)

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.

Re:The brilliance of JAVA (0)

Anonymous Coward | more than 6 years ago | (#19829127)

Linux is brilliant also.

*awaits moderation*

Re:The brilliance of JAVA (1)

Tim C (15259) | more than 6 years ago | (#19829839)

Repeat after me: Java is not an acronym.

Re:The brilliance of JAVA (1, Funny)

Anonymous Coward | more than 6 years ago | (#19830137)

you mean, Java Ain't No Acronym?

Re:Is the brilliance of JAVA due to JAVA? (1)

heroine (1220) | more than 6 years ago | (#19830187)

But how much of the billiance of Java due to the fact that it's Java and not the way a consortium defined the API layers? The Java APIs work because they were designed by consortiums spending many years in meetings around the world to define specs. The internet enabled more collaboration with the Java specs than any language before it, but these API's have to be implemented in C.

Java 3d (2, Interesting)

edxwelch (600979) | more than 6 years ago | (#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.

An alternative (1)

Bieeanda (961632) | more than 6 years ago | (#19829021)

M. Guzdial's "Introduction to Computing and Programming with Java: A Multimedia Approach" was used in an introductory Java course that I took during Intersession this year. It doesn't focus on creating graphics, or 3D objects (which I imagine would be pretty daunting for a lot of people), but rather bases its lessons around modifying already extant images and sound files, systematically teaching the student how various aspects of OOP work, and giving them an obvious 'real world' use for programming.

Re:An alternative (0)

Anonymous Coward | more than 6 years ago | (#19829301)

M. Guzdial
Is he a packie?

The trouble with scene graph APIs (2, Informative)

Animats (122034) | more than 6 years ago | (#19829059)

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:The trouble with scene graph APIs (1)

junkgui (69602) | more than 6 years ago | (#19829397)

There are some other options like Xith 3D [xith.org] that came out after Java 3D was abandoned and before it was open sourced... Java 3D feels very dead to me, so I wonder why so much gets written about it (in the form of books mostly). If I was interested in scene graph based 3d in Java, Java3D would be my last choice...

Re:The trouble with scene graph APIs (1)

ThosLives (686517) | more than 6 years ago | (#19829775)

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 Y and orientation N, I have to create an object X, create an object "Offset", create an object "Rotation", then link them all together. Nounifying verbs is equally troubling as verbifying nouns in this case. Just have the object X extend from PlaceableEntity with the interface setPosition and OrientableEntity with the interface setOrientation.

No goofy objects, just X.setPosition(x,y,z); X.setOrientation(xaxis,yaxis). Then you have a scene like Scene.drawObject(X) and you're all done.

(Is my understanding of draw graph wrong? I would hate to do Scene.addObject(X); Scene.addRotation(R), Scene.addTranslation(P); or some nonsense like that).

In my day... (4, Funny)

niceone (992278) | more than 6 years ago | (#19829083)

(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.

Re:In my day... (1)

iggymanz (596061) | more than 6 years ago | (#19829741)

you're lucky, you had electrons. In my day we had to use hot iron shards. and deflecting those with our bare butts really hurt.

Re:In my day... (1)

joe 155 (937621) | more than 6 years ago | (#19829769)

MAGNETS!

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:In my day... (1)

poot_rootbeer (188613) | more than 6 years ago | (#19830371)

we had to deflect the electron beams ourselves using little magnets we had dug out of the ground with our bare fingernails.

You had an electron BEAM?

We just had a single electron, bought secondhand, which we had to use over and over...

If all you have is a hammer... (0, Flamebait)

Anonymous Coward | more than 6 years ago | (#19829097)

I like Java, I really do. But bloody hell... there's fanboys, and there's Java fanboys.

Oh, but this is such a fantastic basket! No, really! You could just keep all your eggs in this one super-convenient basket. Oh, go on! Be just like me, won't you? Please? Please, oh please, oh please become another host mind for the Java meme! Please? Really, once you've got Java, you don't need to think about anything. You can just say "Java can do this", and you're done. Accept Java as your personal savior today and receive one extra refill pack absolutely free! If you pay by credit card, we'll even through in a signed pair of Air Jordans! Call today, and let Java start improving your life.

The worst of it is that it's not confined to powerless internet nerds. It's bled right through the industry and the universities. And why? Because it's a one-stop-shop? You mean like fucking Walmart?

did java improve jpg quality (1)

b17bmbr (608864) | more than 6 years ago | (#19829111)

silly problem but I had written a small java app to create thumbnails from images for the wife's photo website. the resizing made the thumbs look poor compared to Apple's ImageEvents. had to google an applescript to accomplish the thing. hopefully the image quality has gotten better. all I was doing was taking a 400x400 or so jpg and reducing it by 50%. nothing else. and they turned out either blurry or lost sharpness, etc. ImageEvents does the job alot better.

when I taught AP Comp Sci we did some graphics projects and yes, the 2D stuff is really cool. but I don't know whether java is ready for higher end stuff or even decent quality yet. hope it is, that'd be really nice.

Scaling, not compression (0)

Anonymous Coward | more than 6 years ago | (#19829185)

Was that really a JPEG compression problem?

Did you try to display the thumbnails before saving them, did they look bad already?

Try using the bilinear interpolation rendering hint. A search engine should find some sample code.

Re:did java improve jpg quality (0)

Anonymous Coward | more than 6 years ago | (#19829277)

So, because you don't know image processing algorithms it is the fault of the implementation language that your image manipulation sucks?

What algorithm did you do to reduce the 400x400 image to 50%? You do a javax Graphics2d system call? Or let me guess, you just removed every other pixel? How does this compare to the commercial product's algorithm, which you have no idea what it is doing?

Heres the point: if you know the image processing algorithm of 'ImageEvents' or whatever, then it would be trivial to implement in Java or whatever else.

The problem here is you have no clue.

[i hope i didn't get trolled]

Re:did java improve jpg quality (1)

furball (2853) | more than 6 years ago | (#19829315)

The default parameters for resizing are really bad for photo work. I got chewed out by a certain men's magazine when I wrote the system that turned humongous originals into web-friendly thumbnails. Upon research I found out that the parameters for that were all shitty and tweaked. And tweaked.

It got acceptable after a bit of work on my end.

Re:did java improve jpg quality (0)

Anonymous Coward | more than 6 years ago | (#19829453)

It's called INTERPOLATION you fucking newb.

Why Java? (0, Flamebait)

Gunark (227527) | more than 6 years ago | (#19829143)

There are many reasons to use Java, but nearly all of them have to do with the language's proliferation in the business/enterprise world. Why on earth would you choose Java as a language/platform for doing anything with graphics? If you want something Java-like, and you're interested in experimentation, for god's sake go with Proce55ing [wikipedia.org], which is much better suited for graphics work, both in terms of instant-gratification and supporting library/community. If you want a modern, high-level language, why not go with Ruby [wikipedia.org]? In evolutionary terms, compared to Ruby, Java is starting to look more and more like a dinosaur. And finally, if you want something that will get you extreme speed while maintaining conceptual abstraction, I'd strongly suggest looking into the weird and wacky world of OCaml [wikipedia.org].

Re:Why Java? (1)

MBCook (132727) | more than 6 years ago | (#19830053)

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 does every discussion even tangentially related to Java become a "Ruby r00lz!!!" discussion? I can think of many great reasons why someone might use Java. Libraries, familiarity, existing app, embedding (does Ruby have an equivelent of the applet that a large number of computers can run from a web page?).

Take it as a "If you must use Java, here is how it does graphics" if you want. The book is about graphics in Java. It's not called "How To Do Computer Graphics", "Making Wicked Fast Games", or "The Best Graphics Library Ever". It's about JAVA.

<hippy-voice>Why the hate, man? Just let it be........</hippy-voice>

WTF? (1)

nerdstrap (1071916) | more than 6 years ago | (#19829245)

Is this a commercial for the book? How many graphics libraries use web services? Serializing and deserializing a SOAP message is not fast enough! Java and C# are too slow for anything but a super computer (insert PS3 here) to render high level graphics at 60fps. Who approved this article?

Courses still low level (1)

cerelib (903469) | more than 6 years ago | (#19829247)

My university computer science graphics course was still pretty low level. We use OpenGL for 2D drawing primitives, but the assignments were: line drawing with anti-aliasing, 3D rendering, camera movement, adding light sources, and finally ray tracing. As I said before, we only got to use 2D drawing routines to project 3D data onto a 2D surface. Many people in the class complained because they thought the course would be using OpenGL 3D. Hell, most of the undergrads referred to OpenGL like it was a single library, not realizing that OpenGL is just an API that many companies reimplement to utilize specific hardware. Painfully obvious by questions like, "Well, how does OpenGL do it?"

Computer Graphics using COBOL (0, Troll)

GrEp (89884) | more than 6 years ago | (#19829303)

Seriously.. Just because you can put OpenGL bindings in a corporate fabricated language doesn't mean you should.

Porting to Cell DSPs (1)

Doc Ruby (173196) | more than 6 years ago | (#19829525)

I'd love to see someone port an open source Java class libary or VM's graphics library to render the graphics on the Cell microprocessor's SPE math processors, especially in PS3/Ubuntu [psubuntu.com].

Is there an open source Java OpenGL implementation? That would be a great package to see running on the Cell.

No mention of 'Processing'? (1)

delire (809063) | more than 6 years ago | (#19829771)

The Java API Processing [processing.org] is used fairly widely now for precisely this purpose, often taught in various UNIs as a platform for introducing computer graphics techniques and programming concepts more generally.

Processing is an open source programming language and environment for people who want to program images, animation, and interactions. It is used by students, artists, designers, researchers, and hobbyists for learning, prototyping, and production. It is created to teach fundamentals of computer programming within a visual context and to serve as a software sketchbook and professional production tool. Processing is developed by artists and designers as an alternative to proprietary software tools in the same domain.
It's certainly nothing that takes performant advantage of modern GPU's but is important nonetheless.

Every Java program is really 2 programs (1)

heroine (1220) | more than 6 years ago | (#19830007)

Everything Java does has to be done in C first. Until operating systems are written in Java, that's always going to be the case. OpenGL has been available in C for over 15 years, and by the time it was implemented in Java it wasn't a novelty anymore. Maybe there's some benefit to Java memory management in scene graphs, but all that functionality had to be written in C first before Java would run it.

slow? (0)

Anonymous Coward | more than 6 years ago | (#19830149)

Computer

.

Graphics

.

With

.

Java
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...