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.

Comments

One class I missed in school

[microbee]

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.

Re:One class I missed in school

[R00BYtheN00BY]

im a big fag wow nice -1 score n00b

Friends...

[Lord of Hyphens]

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

Anti-alasing not needed with interval rendering

[192939495969798999]

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

Re:Anti-alasing not needed with interval rendering

[Anonymous Coward]

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

[Anonymous Coward]

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

[bobstatesman]

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

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

[AKAImBatman]

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.

Re:Anti-alasing not needed with interval rendering

[N Monkey]

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

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.

Quick guide to doing graphic work in Java:

[Anonymous Coward]

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:

[Anonymous Coward]

i inlined assemblied your mom last night

Re:Quick guide to doing graphic work in Java:

[fruitbane]

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:

[Ailure]

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:

[AKAImBatman]

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

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

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

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

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

Re:Quick guide to doing graphic work in Java:

[EEBaum]

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:

[CastrTroy]

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:

[harmonica]

You have to do an explicit cast:

byte a = (byte)0xff;

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

Re:Quick guide to doing graphic work in Java:

[AKAImBatman]

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

byte a = (byte)0xFF;

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

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

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

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

rgb |= a; //Purple

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

Re:Quick guide to doing graphic work in Java:

[CoughDropAddict]

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:

[Anonymous Coward]

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:

[AKAImBatman]

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:

[CoughDropAddict]

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:

[DrSkwid]

Integers are for wimps.

Real graphics is done with floats.

Re:Quick guide to doing graphic work in Java:

[Anonymous Coward]

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

Re:Quick guide to doing graphic work in Java:

[teknopurge]

No it's not.

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

Re:Quick guide to doing graphic work in Java:

[AKAImBatman]

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.

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:

[GodfatherofSoul]

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:

[pjt33]

You missed a major exception:
3. Division. The shortest implementation of unsigned division using signed types I could knock together in a few minutes is

public static int div_unsigned(int a, int b) {
if (b<0) {
//The unsigned b is >=0x80000000. Result is 0 or 1.
return (a>=0 || a<b)?0:1;
}
else if (a<0) {
//a==0x80000000+(a&0x7fffffff)
//Account for (a&0x7fffffff)
int div=(a&0x7fffffff)/b;
int rem=(a&0x7fffffff)%b;
//Account for 0x80000000
div+=0x7fffffff/b;
rem+=1+0x7fffffff%b;
//Cumulative remainder might exceed.
return div+rem/b;
}
//Both represent themselves.
else return a/b;
}

Re:Quick guide to doing graphic work in Java:

[PaneerParantha]

The web consists of more than just Windows users,

What do you mean?

Microsoft invented the internet. Everyone knows that.

Re:Quick guide to doing graphic work in Java:

[AKAImBatman]

It's simpler to use longs, but good point. However, I do question the criticality of division in this case. In the decade I've been doing graphics in Java I've never found this to be a problem. Most of your working values are smaller than an integer, and you don't do math on bit-packed values. The values where sign matters (e.g. coordinates) *should* actually support negative values. I did up a couple of 2D rendering engines in Java 1.1 and 1.3 back when Java Applet gaming was still hot. It just wasn't an issue.

The truth is that the signed/unsigned whining by the AC is exactly that: whining. Computer Graphics *is* a mathematically intense field, but the rendering part of it is all just bitmapped data. And as any programmer worth his salt knows, there are plenty of ways to skin bitmapped data. ;-)

Re:Quick guide to doing graphic work in Java:

[Goaway]

To add to the list of problems: Comparisons work differently for signed and unsigned types.

Re:Quick guide to doing graphic work in Java:

[Anonymous Coward]

this makes working with computer graphics in Java either a giant pain in the ass

Pffft... I do all my graphics programming in COBOL, and I like it.

Re:Quick guide to doing graphic work in Java:

[kaffiene]

None of that is required to work with OpenGL in Java, of course.

Re:Quick guide to doing graphic work in Java:

[CoughDropAddict]

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.

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

#include <stdio.h>
 
int main()
{
    unsigned char a = 100, b, c;
    printf("Enter an integer to add to 100: ");
    scanf("%hhu", &b);
    c = a + b;
    if(c < a)
        printf("Sorry, the result overflowed!\n");
    else
        printf("The result is %hhu\n", c);
}

This doesn't work for Java, because the faux-unsigned byte you would be storing in c will wrap around in "normal" circumstances. You will have to do two checks instead of one in this case. Again, not a huge amount of work, but a minefield.

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.

On the contrary, my intent was to mimic a situation like this:

struct ARGB
{
    char a, r, g, b;
}color = {255, 255, 255, 255};

I really did mean 65535.

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:

Oh right. You're bit-packing again to deal with shortcomings of your language. As you were.

Re:Quick guide to doing graphic work in Java:

[icepick72]

C# is available on other platforms such as Linux through the Mono project, for example this article titled C# and .NET Without Microsoft. Also since the introduction of Silverlight Microsoft can allow other OS' to run a subset of .NET code -- maybe even coded in C# -- through a browser plug-in. You've fallen into the trap of thinking C# = Windows which is not true. Do some reading of these links and you'll be amazed what C# really is. Also as an EMCA specification it's not likely to be tied to a platform any more than any other international standard.

Re:Quick guide to doing graphic work in Java:

[josephdrivein]

Why every time someone speaks of portable code they refer to Java?
Isn't python just as portable?

Re:Quick guide to doing graphic work in Java:

[Knetzar]

The idea behind java is to prevent you from trying to do things like save memory by making items that are not fully portable. In C/C++ the size of short and int and ever char are not defined and the spec does not require integers to be represented by 2's compliment. For those reasons you should be using well defined sizes that are portable and not chars if you want to save the extra few bytes.

Source: http://www-128.ibm.com/developerworks/power/librar y/pa-ctypes3/index.html
I especially like the line: "Among the more interesting are 60-bit systems (CDC Cyber) which are only addressable by full words; on such a system, char is 60 bits."

If you want to be lazy and not have a full class, then in java you can just create a byte array to represent ARGB, "byte[] argb = new byte[4];" since it doesn't waste much space (I think it takes 8 bytes, 4 for the data, and 4 for the length, but that depends on the implementation).

Or, you can wrap an int (that is defined as exactly 32 bits in Java) in a class and keep all the bitwise operations that you fear hidden as implementation details and nice helper functions can be used, such as "byte getA(); void setA(byte A);" That way people don't have to worry about the inner implementation. You could even have constructors that build the ARGB object from Strings, ints, byte arrays, and other ways.

Re:Quick guide to doing graphic work in Java:

[fruitbane]

I still have doubts that the Macintosh, for example, will receive C# support. It may be an EMCA specification, but it's development is still controlled by Microsoft, and Microsoft has a habit of poorly supporting their products on any platform other than their own. Java already has a proven track record and receives support on all platforms, including cell phones. I'm sure C# is a wonderful language, but I'm not sure it'll ever be able to claim all that.

Re:Quick guide to doing graphic work in Java:

[Anonymous Coward]

byte rgb = 0xFF0000; //Red

you meant int here I guess...

Re:Quick guide to doing graphic work in Java:

[AKAImBatman]

Yes I did. Sorry, another one of my brain farts.

Re:Quick guide to doing graphic work in Java:

[try_anything]

The formula is, and please take this with the utmost respect, an absolute requirement for anyone doing intricate graphics work.

You shouldn't have to look at it and type it out every time. Talk about a massive violation of Don't Repeat Yourself! All that extra typing will surely cause a few bugs, and God help you if you ever have to change the orientation of the array.

C++ handles this pretty well by letting you express it as image(i, j). The translation to image.data[j*x + i] inlines easily, and you can templatize your image class to turn bounds checking on and off on individual instances at compile time. Some people would prefer to express it as image[i,j] which C++ doesn't allow, but surely image(i,j) (which I prefer anyway) is an acceptable compromise.

Interesting

[Broken scope]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

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

Re:Interesting

[fruitbane]

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

Re:Interesting

[AKAImBatman]

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

Java 1.4 added support for a direct-rendering scheme 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?

Re:Interesting

[Mithrandir]

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

why bother asking

[dj245]

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

[Anonymous Coward]

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

Re:why bother asking

[medge_42]

What's the point of rhetorical questions?

In school, I built a basic 3d engine

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

C/C++ meet Java.

You're his assembly language.

G'day sir!

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

[Anonymous Coward]

"A JIT compiled language can actually run faster than a natively compiled one."

But in practice, it never does.

Java and Game Programming - Still to SLow.

[deweycheetham]

High Performance it ain't. There are better ways.

Probably a good read

[An Ominous Coward]

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

[Anonymous Coward]

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

[fm6]

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

[An Ominous Coward]

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

[Anonymous Coward]

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

[FooBarWidget]

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

Re:Probably a good read

[cecille]

Depends on what you are doing. Not all aspects of game development even require much knowledge of graphics or any type of degree in game design/development. I had a game company make me an offer a while back because my grad work included some work in CI and they were looking for algorithms people to develop new path planning algorithms for their sports games. It's not anything I would have ever thought to get into, but they were convinced that I would fit right in. My boyfriend was just about green with envy, especially considering I have absolutely zero interest in the type of games they make and he would spend 23.5 hours of the day gaming if he could.

Re:Probably a good read

[gbjbaanb]

because the car goes 20 times faster, is way more comfortable, has lots of extra features, and doesn't require you to wear a helmet?

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:Probably a good read

[FooBarWidget]

"because the car goes 20 times faster, is way more comfortable, has lots of extra features, and doesn't require you to wear a helmet?"

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 one's health and better for the environment.

Since the bike already fulfills all my needs, the car doesn't add any value. Given all this, why in the world should I use a car? "Everybody else does it" is not a reason.

Re:Probably a good read

[fm6]

What's CI? Never mind, I get this gist.

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 acquiring game design skills few of them will ever use.

Re:Probably a good read

[An Ominous Coward]

As I said, that advice is for people intending to work in game development. Basically all the development houses use DirectX. "DirectX is the standard now" should mean something to you, if you're intending to market your skills or market to the largest installed base. But yes, if OpenGL works for your particular need, use it. The other responder to your post misunderstood my point as well. DirectX didn't surpass OpenGL while the committee squabbled, DirectX -caught up- with OpenGL. In terms of technology, both are pretty damn great right now. The focus on DirectX is for business, not technical, reasons. If a student doesn't want to work for a place like EA (and really, who would?), intending to go off and do his or her own thing, OpenGL's great. It obviously worked for those iD folks.

Re:Probably a good read

[krelian]

His statement was reflecting the fact that virtually all game studios are developing with DirectX today and if you want to get in the industry some day and make money you should invest your time in DirectX and not Java game programming.

If you want to build games for yourself than you can use whatever you want.

Re:Probably a good read

[Chosen Reject]

You are absolutely correct. All those companies making games for the Wii, DS, PSP, PS3, PS2, Mac and Linux are using DirectX. I mean, no game developer in their right mind would ever bother to learn OpenGL.

Re:Probably a good read

[samkass]

DirectX won't help you for many of the top selling consoles right now (PS2, PS3, Wii, and all handhelds). And there are even a growing number of MacOS X and Linux development houses. It's true knowing DirectX is valuable, but knowing ONLY DirectX is awfully limiting.

Re:Probably a good read

[Anonymous Coward]

Since when do I have to wear a helmet to ride a bike?

Oh I don't know, you know, those awful nagging things like traffic laws...or well, that brain compression you're looking at if that bad car pulls out in front of you...but let me foresee your analysis on that..."the bike is better because I can swerve away and not hit anything! in fact, on a bike I'm invincible!"

Re:Probably a good read

[Millenniumman]

20x faster? Is that assuming a Bugatti Veyron and a tricycle?

Java for the rest of your life...

[SilentBob0727]

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

[Applekid]

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

[Anonymous Coward]

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

[AKAImBatman]

Could have fooled me.

Re:Java for the rest of your life...

[Anonymous Coward]

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

Re:Java for the rest of your life...

[AKAImBatman]

a) That's not Java 3D, nor is it part of the Java 3D spec; it's a library built on Java 3D

And that's a problem because... ?

b) It's licensed as GPL; you might as well develop a computer graphics training class based upon proprietary software

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 idea is to look into working directly with OpenGL through JOGL, or look into one of the many other scenegraphs available for Java.

*yawn*

[Anonymous Coward]

"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

[Anonymous Coward]

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

[Anrego]

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

[MBCook]

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

[FooBarWidget]

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

[matfud]

Nasa just released a java (jogl) version of world wind (well an SDK for obtaining and rendering the data). Thought it might interest you.

http://worldwind.arc.nasa.gov/java/index.html

matfud

Re:Yeah...

[Mithrandir]

Please provide proof of your assertions.

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

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

Re:Yeah...

[Anonymous Coward]

If you're using the CPU to render graphics with OpenGL, you have already failed.

Or you don't have any OpenGL capable hardware.

Re:Yeah...

[Angst Badger]

Whatever.

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 all sorts of serious, permanent brain damage will happen the moment you smoke a joint. It's baloney, and it makes you question the reliability of the source. (To be fair, I don't think anyone has used Java safely and then gone on to disregard the warnings about heroin, but there have been incidents of Ruby use.)

It would be more productive to emphasize Java's many benefits than to deny the existence of the performance hit that comes along with some of them. As a trivial example, take array bounds checking. It makes code safer and more reliable, but there is simply no way to check every array reference for validity every time it's used without chewing up CPU cycles. Instead of denying the undeniable, why not point out that the relatively minor performance hit is more than amply compensated for by greater reliability?

Java is a pretty good language with a lot of strengths and some weaknesses. It is not, however, the second coming.

Re:Yeah...

[Laser Lou]

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.

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

[Mithrandir]

It still shows that you're living a fairly long way in the Java past. Java has not had internal bounds checking every array access since the advent of the Hotspot JVMs. Most of the array access checks are optimised away either by the compiler or by the JIT compilation from the hotspot, particularly in places where it matters like tight for loops. Random access are still checked some of the time, but anything that is performance critical, those checks are discarded by the JVM well before they become a performance issue.

I'm not acknowledging any performance hits at the UI level because, quite frankly, none of our users or our clients see them. In fact, many of our clients are surprised that the code has been written in Java. Sure, anyone can code a crappy UI, and with Swing it's incredibly easy to do so (in fact, seems to be the default way that it's implemented), but with a very small amount of attention to detail, they perform just as good as any other language. With some of the Java 6 work where it is using OpenGL under the covers for all the 2D rendering, it is a heck of a lot faster too than a lot of the Vista crap that we've seen.

Where we have seen performance hits in the past is in very heavy array/pointer access code such as that used in image decoding. In fact we wrote our own native code wrappers to get around this problem. However, starting with Java 5 and now 6, the supplied JVM image decoding is even faster than our light wrappers around libjpeg/libpng etc.

Re:Yeah...

[Anonymous Coward]

but anything that is performance critical, those checks are discarded by the JVM well before they become a performance issue.

so what you're saying is that Java doesn't have all those nice, safe features that people expect from it. Oh, no, it turns out its faster than assembler when it wants to be. The JIT takes exactly zero time to compile code, and will out-optimise any static compiler every day.

it is a heck of a lot faster too than a lot of the Vista crap that we've seen.

and again we see the root of the mindless pro-Java advocacy : its not MS, so it must be the best thing ever. Muppet.

Re:Yeah...

[Luxifer]

I do high end scientific, medical visualisation and a fair amount of military work on the side.

Military work on the side? I may have a few jobs for you,my neigbour is really beginning to piss me off.

Re:Yeah...

[UnknownSoldier]

> Please provide proof of your assertions.

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

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

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

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

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

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

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

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

> Java is more than fast enough for full graphics.

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

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

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

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

Re:Yeah...

[ClosedSource]

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

For a guy demanding proof you might actually tell us about these examples you "have plenty of".

Re:Yeah...

[kaffiene]

Java is not slow. And if you're writing a game, you'll use the hardware for the 3D rendering anyway.

Re:Yeah...

[metamatic]

Java is about the last language id use for anything involving graphics

Yeah, I mean it's not like you could write a 3D FPS in Java and get performance comparable to C, is it?

Re:Yeah...

[metamatic]

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

Hmm, moments ago we were talking about 3D graphics, and now suddenly it's desktop applications and GUI toolkits?

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.

I don't think I've seen anyone make this claim.

Nice attempt to re-frame the debate, though.

Re:Yeah...

[Anonymous Coward]

Here are a couple of links to brilliant Java-JOGL Web-Startable apps

NASA WorldWind Java Developers Kit (very google-earth like)
http://worldwind.arc.nasa.gov/java/index.html

Jake 2
Quake II port to Java with online references comparing frame rates to original Id C-code
http://bytonic.de/html/jake2.html

I have tested both of these on Linux and Windows with no problems.
-tve

Re:Yeah...

[Mithrandir]

Perhaps you didn't fully read my post explaining what some of those examples are?

Re:Yeah...

[Tony-A]

Nope.
His code is faster because he knows what he's doing.
What matters and what doesn't is not usually very apparent.
Fortran is compiled, right?
Bet most of the time is spent INTERPRETING format statements.
It's not really pro-Java. I'd bet his stuff would be fast in COBOL.

Re:Yeah...

[crucini]

You probably want to avoid OOP in general when it comes to the actual graphics component of an application, as it adds overhead.

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:

1. switch(thing->opcode) { // effectively a linear search
   
2. Use a function pointer in the object itself. Problem is, if there are 20 methods, there are 20 pointers in each object.
   
3. Use a "class pointer" in the object - pointing to a dispatch table for that class. This is what C++ does if you use its virtual dispatch.
   

Is #3, with its double-indirection, significantly slower than #2? Probably not. Drawing should comprise many steps. So C++, with its "OO", is merely formalizing a dispatch system that most C programmers would find reasonable.

Re:Yeah...

[david.given]

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

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 to store a pointer without data loss), etc? All incredibly useful, and actually in the C standard, too.

Re:Yeah...

[fbjon]

Indeed, I just tried out the World Wind and Quake2 web start things, and they're practically flying along. Of course, those are not that complex, but then again it's running on an Intel 82865G, which I suspect is not so hot on performance. In other words, Java apparently works beautifully for these tasks.

Re:Yeah...

[ClosedSource]

I guess I was looking for benchmarks or specific applications that could be compared side-by-side. Simply stating that your performance is better isn't proof.

Re:Yeah...

[ClosedSource]

When comparing languages either for features or speed the only reasonable approach is to include any standard libraries in the analysis. Otherwise you end up with conclusions like "C is a bad language because you can't do I/O with it". So, yes, it's understandable that there are cross-platform compromises in Java that any language would have, but that doesn't make your GUI applications run any faster.

Re:Yeah...

[edxwelch]

In java you can use floats or fixed point integers if you want.
I would strongly advise against the fixed point though - it makes debugging a nightmare.
It's interesting that mobile phones provide java acceleration hardware. Sony ericcson phones have jazelle which allows decient performance on 3d games, even though the processor is only a 200mhz ARM, probably a lot less than the Wii

The brilliance of JAVA

[perlhacker14]

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

[Anonymous Coward]

Linux is brilliant also.

*awaits moderation*

Re:The brilliance of JAVA

[Tim C]

Repeat after me: Java is not an acronym.

Re:The brilliance of JAVA

[Anonymous Coward]

you mean, Java Ain't No Acronym?

Re:The brilliance of JAVA

[z0I!)]

So it is an acronym then?

Re:The brilliance of JAVA

[krelian]

I can replace Java (or in your case JAVA) with .Net and it will still be true if not truer.

Java is .Net's stepfather though.

Re:The brilliance of JAVA

[GrahamCox]

The simplicity of Graphics in JAVA is unsurpassed in any real language

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 embarrass yourself further (come back and read your comment in ten years time and cringe!) you ought to expose yourself to a few more environments.

Java 3d

[edxwelch]

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.

Re:Java 3d

[Mithrandir]

One of the reasons why you don't see Java3D in games is that it has some serious internal architecture issues. The absolute primary one that killed it for our customers is that If you use a behaviour to set a transform and a geometry (vertex) change in the same frame, the geometry update appear rendered one frame before the transform takes effect. When we've pressed them about that, the Sun engineers have never seen this as a critical problem! Now, try writing a high-performance game in an environment that acts like that.

Re:Java 3d

[ClosedSource]

I think Java from start to finish was designed primary by MOR IT developers who are used to a lot of resources and have little or no experience in real-time or embedded environments.

Re:Java 3d

[LizardKing]

You do realise that Java grew out of Oak, which was a language and runtime environment for programming set-top boxes? There's also J2ME, which I have used to implement applications on handheld devices such as scanners.

Re:Java 3d

[ClosedSource]

"You do realise that Java grew out of Oak, which was a language and runtime environment for programming set-top boxes?"

Absolutely. I consider the business failure of Oak-based set-top boxes to be evidence that Gosling et al didn't know much about embedded systems. What embedded systems had they developed that would give them insight into how to create a language for one?

"There's also J2ME, which I have used to implement applications on handheld devices such as scanners."

It's true that now that vasts amounts of memory are available at low prices, it's practical for developers to use J2ME or Windows CE as the basis for embedded systems that don't have hard real-time requirements.

An alternative

[Bieeanda]

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

[Anonymous Coward]

M. Guzdial

Is he a packie?

The trouble with scene graph APIs

[Animats]

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

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

Re:The trouble with scene graph APIs

[junkgui]

There are some other options like Xith 3D 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

[ThosLives]

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

Re:The trouble with scene graph APIs

[Animats]

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 the representation of the world.

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.

Even in OpenGL you do something like that. Think about what happens when you move a character with subparts, like arms. Rendering is a tree operation with 4x4 rotation matrices at the nodes. If you have a scene graph for behavior purposes, you have enough info around to drive a rendering system like OpenGL. You don't need a second scene graph in the graphics system. It just gets in the way.

There is information that stays within the graphics system, like textures and drawing geometry, and OpenGL has display lists for retaining that info. It's important to use those, because you can send that info to the graphics card and leave it there, which is a big performance win. But that's not a full scene graph; it's graphic detail associated with scene graph nodes.

In my day...

[niceone]

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

[iggymanz]

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

[joe 155]

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

[poot_rootbeer]

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

Re:In my day...

[rleibman]

You little Maxwell Daemon you.

Re:In my day...

[Kehvarl]

Fingernails?! I nmy day we would have killed for fingernails, but the guys with the nails also had the big sticks.

Next book

[Anonymous Coward]

Stay tuned for his next book: Implementing Databases using LISP.

Re:Next book

[teknopurge]

mod parent funny.

If all you have is a hammer...

[Anonymous Coward]

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

[b17bmbr]

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.

Re:did java improve jpg quality

[Anonymous Coward]

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

[furball]

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

[Anonymous Coward]

It's called INTERPOLATION you fucking newb.

Re:did java improve jpg quality

[AKAImBatman]

Last time I ran across that issue, I cheated. Since the server was headless and you can't resize images in Java on a truly headless machine (it's a problem with the JVM requiring X11 libraries in the path), I just wrote my own Bilinear Scaling routine. The results were nice in comparison to the nearest neighbor results we had been getting out of the default libs. Of course, no one had tuned the original code, so a lot of improvement would have been possible. It just made more sense to use a custom routine considering that headless support was a serious issue.

In case anyone else ever needs it, here's the routine in its entirety:

public static BufferedImage createHeadlessBufferedImage(BufferedImage image, int type, int width, int height)
        {
                if (type == ImageUtils.IMAGE_PNG && hasAlpha(image)) {
                        type = BufferedImage.TYPE_INT_ARGB;
                }
                else {
                        type = BufferedImage.TYPE_INT_RGB;
                }

                BufferedImage bi = new BufferedImage(width, height, type);

                for(int y=0; y < height; y++)
                {
                        for(int x=0; x < width; x++)
                        {
                                bi.setRGB(x, y, image.getRGB(x * image.getWidth() / width, y * image.getHeight() / height));
                        }
                }

                return bi;
        }

Re:did java improve jpg quality

[AKAImBatman]

Doh! That was the wrong routine. I need to remember to take out my old, unused routines from source files. THAT is the nearest neighbor. THIS is the Bilinear. Sorry 'bout that:


public static BufferedImage createHeadlessSmoothBufferedImage(BufferedImage source, int type, int width, int height)
{
        if (type == ImageUtils.IMAGE_PNG && hasAlpha(source)) {
                type = BufferedImage.TYPE_INT_ARGB;
        }
        else {
                type = BufferedImage.TYPE_INT_RGB;
        }

        BufferedImage dest = new BufferedImage(width, height, type);

        int sourcex;
        int sourcey;

        double scalex = (double)width / source.getWidth();
        double scaley = (double)height / source.getHeight();

        int x1;
        int y1;

        double xdiff;
        double ydiff;

        int rgb;
        int rgb1;
        int rgb2;

        for(int y=0; y < height; y++)
        {
                sourcey = y * source.getHeight() / dest.getHeight();
                ydiff = scale(y, scaley) - sourcey;

                for(int x=0; x < width; x++)
                {
                        sourcex = x * source.getWidth() / dest.getWidth();
                        xdiff = scale(x, scalex) - sourcex;

                        x1 = Math.min(source.getWidth()-1, sourcex+1);
                        y1 = Math.min(source.getHeight()-1, sourcey+1);

                        rgb1 = getRGBInterpolation(source.getRGB(sourcex, sourcey), source.getRGB(x1, sourcey), xdiff);
                        rgb2 = getRGBInterpolation(source.getRGB(sourcex, y1), source.getRGB(x1, y1), xdiff);

                        rgb = getRGBInterpolation(rgb1, rgb2, ydiff);

                        dest.setRGB(x, y, rgb);
                }
        }

        return dest;
}

Re:did java improve jpg quality

[AKAImBatman]

And here are the supporting methods:


        private static double scale(int point, double scale)
        {
                return point/scale;
        }

        private static int getRGBInterpolation(int value1, int value2, double distance)
        {
                int alpha1 = (value1 & 0xFF000000) >>> 24;
                int red1 = (value1 & 0x00FF0000) >> 16;
                int green1 = (value1 & 0x0000FF00) >> 8;
                int blue1 = (value1 & 0x000000FF);

                int alpha2 = (value2 & 0xFF000000) >>> 24;
                int red2 = (value2 & 0x00FF0000) >> 16;
                int green2 = (value2 & 0x0000FF00) >> 8;
                int blue2 = (value2 & 0x000000FF);

                int rgb = ((int)(alpha1 * (1.0-distance) + alpha2 * distance) << 24) |
                                    ((int)(red1 * (1.0-distance) + red2 * distance) << 16) |
                                    ((int)(green1 * (1.0-distance) + green2 * distance) << 8) |
                                    (int)(blue1 * (1.0-distance) + blue2 * distance);

                return rgb;
          }

Certainly it can

[Anonymous Coward]

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.

Don't worry

[wawannem]

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

[raftpeople]

I used to program in jimble jamble, some think I still do.

Re:Don't worry

[misleb]

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

Re:Don't worry

[Constantine XVI]

Doesn't that go by the more common name of VB6?

Re:Don't worry

[mypalmike]

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

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

Re:Don't worry

[demallien2]

And tools. They write a lot of tools - the apps that the graphics artists use to create the games. Those level designers that are available for FPS games exist because they were orignally written to be used in-house by the publisher of the game to create the game itself.

Actually, most good programmers spend a large chunk of their time writing tools. Why would I generate the glue code between my VM and the native system by hand? It's boring, repetitive and very error prone. Far better to write a tool that generates the C code that implements the glue. Or why beat myself up trying to get make to handle my very complex build environment - write a tool to do the build instead, that accepts an input more inline with my company's Config Management policies.

The vast majority of things that we do as programmers are either highly repetitive, or highly error prone - far better to have the computer do it in these cases. The obvious result is that we should be trying to automate as much of our work as possible by writing tools. Games programmers are no different.

Why Java?

[Gunark]

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

Re:Why Java?

[MBCook]

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>

Re:Why Java?

[Harry Coin]

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, which is much better suited for graphics work, both in terms of instant-gratification and supporting library/community.

Perhaps Processing is "Java-like" because it's written in Java? Maybe you should ask the Processing dev team why they chose Java to produce their graphics? I admit that it looks like it simplifies experimentation, but it's a bad example to use to claim that Java does graphics poorly.

Re:Why Java?

[Anonymous Coward]

It's not called ... "Making Wicked Fast Games"

Are you implying that Java is not fast?

Re:Why Java?

[metamatic]

Why on earth would you choose Java as a language/platform for doing anything with graphics?

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.

If you want something Java-like, and you're interested in experimentation, for god's sake go with Processing

...which is based on Java.

If you want a modern, high-level language, why not go with Ruby

Because it's 10-100x slower than Java?

I use Ruby most weeks, but not for 3D graphics.

I'm not a big fan of Java, but it has OO, performance to rival C (no, really), it runs on every platform I care about, and it's commonplace enough that I can be confident it'll still be around in 10 years.

Re:Why Java?

[Anonymous Coward]

All of the current Ruby implementations are far too slow and have an absolutely horrible threading model. At least suggest Python so you don't lose all of your credibility...

Scaling, not compression

[Anonymous Coward]

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.

WTF?

[nerdstrap]

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

[cerelib]

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

[GrEp]

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

Re:Computer Graphics using COBOL

[adrianmonk]

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

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:Computer Graphics using COBOL

[IntergalacticWalrus]

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.

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

Re:Computer Graphics using COBOL

[Anonymous Coward]

For C++, you mean "no working implementation."

Re:Computer Graphics using COBOL

[adrianmonk]

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

Sure C and C++ are corporate-made. They were both created by AT&T / Bell Labs. They have gone on to later be turned into standardized languages, but Java has open standard as well.

Also, does Java have an official implementation? As far as I know, it has the JLS and a number of JCP standards. And Sun does offer a compiler and a JVM, but I am aware of nothing that makes that the official implementation.

Stop wasting time

[Anonymous Coward]

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

[Jorgandar]

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

Re:Stop wasting time

[Anonymous Coward]

208,000 playing. lol.

2 years ago, Blizzard announced there were a few users of WoW. Like, 180,000 concurrent users in the game's first weekend.

Re:Stop wasting time

[badzilla]

My kids actually play Runescape and doing their tech support is not much fun. Game seems to have tolerably acceptable graphics although nothing to shout about. But what a memory hog and CPU burner (literally! leave it on the "exit game y/n" flaming torch screen for a while and watch the temperature go through the roof.)

Re:Stop wasting time

[Jorgandar]

Runescape is run by a small group while blizzard is a rather large one with deep pockets and an army of developers and graphics designers. Obviously bliz games will have nicer graphics and whatever. But the point is, a java-based game can still not only survive, but thrive. 200,000 concurrent players means probablly well over a million active players. That's nothing to poo-poo on. I call that success.

Porting to Cell DSPs

[Doc Ruby]

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.

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

Re:Porting to Cell DSPs

[Mithrandir]

There's official bindings to OpenGL with Java. That's called JSR-231, better known as JOGL. There's not software implementation of OGL in Java that I'm aware of.

At the InfoViz conference last year there was a company displaying a PCI-Express card that had 4 or 8 cell processors on it and a library to play with it. They had Java bindings to that, so you could something like what you want. They had an extremely impressive realtime mesh-extraction from volumetric data demo that they were running. Unfortunately I don't remember the name of the company right now, but that card had very serious potential to be a vector supercomputer in a box for the high-end sciviz crowd.

Re:Porting to Cell DSPs

[Doc Ruby]

I really wish you could remember the name of the company. The only companies making Cell products that I know of are IBM, Toshiba, Mercury, and Sony (and Terrasoft was releasing custom clusters of PS3s). A Java library that runs on more than just the Cell PPC, especially on multiple parallel Cells, would be compelling. And if the product has died, or the company making it, that orphaned library could be a good candidate for opening its source, if it was previously proprietary.

Re:Porting to Cell DSPs

[kabz]

Start saving: http://www.linuxdevices.com/news/NS6832279023.html

Re:Porting to Cell DSPs

[Doc Ruby]

Yeah, but that was Mercury's intro pricing, before the PS3 was even released, a year ago. The Cell itself costs only <$100 apiece, and the rest of the HW to support it on a blade is probably under $50. A real multi-Cell blade, like an 8-way one, should cost under $1000. And it should have as much RAM as possible, at best 32GB per 8-SPE Cell, plus probably another 4GB or so for the PPE, for 260GB, which is probably $10K. That kind of monster is well worth $11K, and even a 100GB one, with 4x2x10Gb-e on a PCI-e bus is well worth $5K. Hell, it's probably as fast as a $5M machine running on some other CPU. A $40K machine with 64 Cells, 1TB RAM, all on PCI-e plus a bank of 32x2x10Gb-e ports is probably one of the faster supercomputers, which would cost well over $50M. And suck godwaful (regulated) power, an air-conditioned room, and a faculty of PhDs to design, assemble and run each one. Those Cell machines could roll off assembly lines by the thousands.

Re:Porting to Cell DSPs

[AKAImBatman]

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

I presume you're looking for a software implementation? If so, then you might try this:

http://www.cmlab.csie.ntu.edu.tw/~robin/JavaGL/

I've never used it, so I can't vouch for it, but it's supposedly a software implementation of the OpenGL API and renderer in Java.

No mention of 'Processing'?

[delire]

The Java API Processing 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.

Mainframes

[myowntrueself]

See, this is why we still need mainframes.

Re:Mainframes

[Broken scope]

Um we still have them. My dad works for IBM and helps people get switched over to them.

Re:Mainframes

[Anonymous Coward]

Who said we didn't?

Oh. You're one of those assholes who deliberately misinterprets other people's posts in order to "correct" them.

Every Java program is really 2 programs

[heroine]

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.

Re:Every Java program is really 2 programs

[Anonymous Coward]

true. and you could say the same for any language running on an OS that was not written in said language. you could even make that claim for programs written in C itself, since they rely on functionality from the kernel.

Java and unsigned types

[CustomDesigned]

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:Java and unsigned types

[CoughDropAddict]

However, your attempt to add more points is pathetic. For instance, "short a = (short)65535;" works just like "byte c = (byte)255;"

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:Java and unsigned types

[Anonymous Coward]

Which can be read as "some of the weird and obnoxious problem you'll run into have non-obvious workarounds."

or perhaps you need to learn that the world is not a 32 bit computer? You have only succeeded proving that you do not know how to write machine portable code. Its engineers like you who are keeping us in the 32bit dark ages. All languages have their quirks, perhaps you should take the time to actually learn to deal with Java's quirks, just the way you did with 2-complement math. Java doesn't work exactly the way C/C++ did when you learned in school or 21 days, but it does work, perhaps you should learn something new.

slow?

[Anonymous Coward]

Computer

.

Graphics

.

With

.

Java

Re:Is the brilliance of JAVA due to JAVA?

[heroine]

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.

compare results

[Organic Brain Damage]

Runescape in Java,

WOW and EQ2 and EVE in ...C/C++?

Which games look better? Based on the current crop of games, it does not look like Java has arrived as a tool for making 3d games.

Re:compare results

[kaffiene]

The developers of Runescape and Blizzard have slightly different levels of resourcing. Is it possible, do you think, that that might JUST MAYBE have a little bit to do with the difference in the comparison?

In addition, Runescape is WAY older than WOW.

Re:compare results

[Metaleks]

That's not fair. To say that Java can only go as far as Runescape, while other languages such as C++ are clearly better (WoW, EQ2) is just plain dumb. You're comparing a game thats played in a BROWSER to a game thats played in FULL SCREEN. The game played in the browser (Runescape) is hampered by the browser itself. Performance becomes an issue. That, and Runescape is really old, so comparing a new game with it is stupid. That would be like me comparing a brand new Porche to a beat down '82 pickup.

Runescape cannot utilize full system resources like it's full screen C++ counterparts can. It has nothing to do with Runescape being made in Java. Remember, runescape is NOT the pinnacle of Java graphics.

Re:compare results

[Dungbeetle]

EVE online was not written in C/C++ - it was done using stackless Python.

Re:compare results

[Dungbeetle]

Yikes, forget one word and you change the whole context.
The above should say "not only written", instead of "not written".

[Grumbles about editing desires]

Re:compare results

[AKAImBatman]

If you're going to make unfair comparisons, at least get your competition right:

http://www.wurmonline.com/

Shaders!

[Jerry Talton]

I've taught introductory computer graphics courses at both Stanford and the University of California, Santa-Cruz, and by far the most important change that needs to be made to the "traditional" curriculum is the introduction of the programmable pipeline. Far more so than the chosen language or API, teaching shaders forces students to understand the mathematics that lies at the heart of the graphics pipeline while simultaneously endowing them with the tools they need to create Really Cool Projects®. The prevailing mentality seems to be that asking students to handle lighting and transformations directly in an introductory setting is too difficult, but my experience has been that this is not at all the case.

For those that are interested, I have SIGCSE paper on the subject available here.

Re:Shaders!

[deweycheetham]

Hey wait a second, Shader are cool stuff but not in the first salvo of class. If you want to turn these kids on, you need to show them stuff like how to make their own games. There are tones of graphic libraries to help in the Shader Area. Then they can show their buddies how cool they are, and nature will take it course from there in terms of motivation.

However, +1 point for "Shady" self promoting post. (Sorry couldn't resist)

Enterprise does not exclude graphics...

[Mutatis Mutandis]

... 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 programmers lack the skills to create them.

It is true that Java lacks a convenient plotting library in its standard, but it has a decent set of basic tools in the J2SDK, so it isn't that difficult to write a simple one. Making it interactive is a bit trickier, of course. Simple plotting libraries are of course available for download, although the few I have studied were a bit too simple.

Using script languages for such purposes sounds risky to me. Some ten years ago, when I heard that the team I was planning to visit had only Macs, I did hastily write a data conversion / plotting tool in Tcl/Tk to take with me, so that I could still access and use my data --- I didn't fancy porting a FORTRAN/C++ application from Unix to Mac OS on the spot! It worked, but it was terribly slow on anything over a thousand data points or so.

Java was much better, and it allowed me to share my data with co-workers over the internet in the form of interactive graphs; in the late 90s that was quite a novelty for us... And an object-oriented language is enormously beneficial for such purposes, in my humble opinion, because that is the right way to assemble a data graph -- as a set of data objects, annotation objects, and interactive anchors.

I still regret that MS moved away from the concept of the original MS Graph, which basically treated data sets as objects to be rendered, to the array-based model of Excel, which I find much less practical, and is riddled with inconveniences and a few significant bugs. Call me eccentric.

ARE YOU NUTS

[Anonymous Coward]

Do you guys actually do any programming?

Hey, I've got a great idea. Why not write an office suite in Java !!

Come back in a few years when you've had some experience.

plop

[Anonymous Coward]

java stinks like poop

Re:ARE YOU NUTS

[kaffiene]

Like this: http://product.thinkfree.com/ ??

Computer Science is not about APIs!

[ravyne]

A computer graphics course using any API (be it OpenGL, DirectX, or what-have-you) is like a data structures course that focuses solely on the STL (or your favorite language's equivalent); it has its place at a higher level but it is not a replacement for down-and-dirty, low-level study and implementation.

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 create that tool themselves. Pointers scare the hell out of them, they can't read declarations with more than 1 level of indirection, even simple concepts like recursion are beyond them (I once had an interviewer tell me that most people took 15 minutes to solve the recursion interview question which took me all of 60 seconds to solve and explain, and then they were wishy-washy when he challenged their solution, even if it was correct -- they had no confidence in their solution.)

Its a sad day when a CS student goes through "Computer Graphics I" and may have never studied (and implemented) the variety of line-drawing algorithms to experience first-hand their respective code complexity and performance, or who have never experienced the joy of drawing an ellipse using a purely-incremental algorithm using second-order derivatives.

Its an even sadder day when a CS student goes through "Data Structures" and may have never implemented a self-balancing binary tree, KD-trees, red-black trees, pooled memory allocators or skip-lists.

APIs come and go, but fundamentals are forever. I pity the poor programmer who "knows Direct3D" only to have it replaced by DirectRayTracer years down the line.

Not all is lost, as there still are many great CS schools that haven't forgotten about the fundamentals, but I think there are many who have unfortunately lost their way.

Re:Computer Science is not about APIs!

[Anonymous Coward]

I second the comment that only the fundementals endure. I've taught a senior computer graphics course at RPI for over 25 years. In that time, I've replaced the API several times. However, the math for 3D rotations is still the same. BTW most texts do that badly.

VJ material with JOGL

[rustcycle]

I recently completed my MS in CS, will post additional materials if anyone is interested. I used genetic algorithms to alter the look of JOGL generated visuals in my thesis "Aesthetic Emergence in Synesthetic Sculptures". Here are two batches, each with a few variations:

http://youtube.com/watch?v=F1xvnI96gFA
http://youtube.com/watch?v=XPylKUSEuuc

The wires 'weave' according to evolved vector fields - the finished product will use the vector fields in addition to 3D geometry from a Point Grey stereoscopic camera to sculpt the musicians in my band, with the animation modulated by MIDI events and other items.

Re:VJ material with JOGL

[bill_mcgonigle]

I used genetic algorithms to alter the look of JOGL generated visuals in my thesis "Aesthetic Emergence in Synesthetic Sculptures".

Could you elablorate on 'alter the look of JOGL generated visuals' or provide a link to your thesis?

I do a little bit of JOGL hacking and I'm not sure what that means (but the videos are cool!).

Probably a good view.

[Anonymous Coward]

"But a lot of people associate game design with graphics."

Not me. Oh wait!

Yeah, when Java's calling an assembly function.

[Anonymous Coward]

Yes, the assembly language that a java program is calling might be faster than the C version.

(rolls eyes)

You Java weenies just have to accept the fact Java failed because it's too slow.

Re:Yeah, when Java's calling an assembly function.

[Anonymous Coward]

Hey mother fucker as long as it pays my bills its not a failure.

Java? That's old-school...

[Anonymous Coward]

Java is so Web 1.0. Web 3.0 will be Computer Graphics with JavaScript.

Why (-1, troll)?

[mangu]

Friends don't let friends code in Java

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!

Re:Why (-1, troll)?

[Anonymous Coward]

Maybe because you can create performant, cross-platform applications like:

    http://www.banghowdy.com/
    http://tribaltrouble.com/
    http://sunflow.sourceforge.net/

...or that in five years it will be hard to find a widescreen, 3D capable cellphone that does not support being programmed in Java?

...or that the iPhone can run Java natively in hardware?
    http://blogs.zdnet.com/Burnette/?p=338

Re:Why (-1, troll)?

[John Betonschaar]

While there are definitely areas in which Java really sucks (specifically: UI programming) I think the 'Java lacks the speed of C' argument is getting really, *really* old. Granted, I would not choose Java for my next-generation DX10 graphics engine, because even in C++ it would *need* to stress top-end hardware to the maximum. But properly written Java code can be almost as efficient as C++ code, and in some cases even faster. A hardware accelerated 3D pipeline would actually fit Java pretty well, and could be plenty fast. Orders of magnitude faster than what's needed to introduce people to 3D programming.

You check some of the advanced XNA applications on the 360. These are coded in C#, which is pretty much comparable to Java in terms of performance (the C# VM is apperently pretty good, so it's probably a little faster). The example applications include a very good looking 'racing game' (XNA racer) which uses complex 3D models and textures and runs at a full 60fps, and it's not even using all three CPU cores of the 360.

Interpreted languages are not much slower than statically compiled languages todat...

Re:Why (-1, troll)?

[Anonymous Coward]

The .NET CLR is pretty primitive and slow compared to the JVM.

Java makes an excellent platform for games. It will replace C/C++ in the coming decade.

Will never happen...

[Anonymous Coward]

At least not with any conventionally-shaped VM.

When configured in useful fashion, the Cell SPUs can access at most about 128KB of memory.

Re:Will never happen...

[Doc Ruby]

No, PS3 Cell SPEs each have 256KB of local store, plus they each can DMA from each other, and from main memory another 256MB (or possibly nearly 512MB).

The PS3 in game mode uses both the SPEs and the RSX, and has the same amount of memory, but has excellent graphics.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Someone kicked their flux capacitor ?

[billcopc]

Is it just me, or does this book belong with all the other "great" Java books of 1998 ? I still have a very hard time understanding why people even bother with Java at all, but how many legitimate uses are there for Java graphics in this day and age ? They have widget toolkits that kinda sorta get the job done. I certainly don't want to see any new Java games, that's what Flash is for.

The thing is, computer graphics theory is pretty much universal. Once you learn the algorithms to draw your primitives, you can apply them just about anywhere. Does anyone need a book to draw a line in Visual Basic ? Well they're suckers if they do, because it works more or less the same way as C++, or Delphi, or even Javascript on a Canvas object. Java is in the same boat.

Re:Someone kicked their flux capacitor ?

[AKAImBatman]

Comparing Java to Flash won't win you any friends. Especially since you're assuming that Java == Applets. Why don't you go play some Java games instead?

http://www.puppygames.net/
http://www.wurmonline.com/
http://www.javaunlimited.net/games/db.php?min=0&so rt=5&order=1&screen=0&max=25 -- (Make sure you try Miners, Xero, and fuzetsu. Those are my favorites. Amazing that they fit in a mere 4K, isn't it?)

but why use java at all?

[Anonymous Coward]

The author noted database interactivity, networking abilities, etc. associated with java. However other languages possess the same abilities (if you doubt me, go read the Church-Turing thesis again). The thing that the other languages (such as for example C) have that java does not, is speed. Lots and lots and lots of speed. Java has none. No speed in java. Speeding up the computer doesn't speed up an interpreted language. Ramble on all you like about byte-code. Its still not compiled, and its still slow as hell. Java would be good for static bar charts and pie graphs, but for a 3-d animated anything-else, run like a banshee away from Java. I know the authors are trying to teach a course and show that 'see, java can do this too', and its like putting lipstick on a pig. The lipstick is shiny, but a pig is still a pig. If you are big on java, then you can use this reference to write a 10,000 line pie-graph program. You can call it call.draw-graph.start.new-graph()-scene.create-lin e()start.no-background() or something.

Creating thumbnails with Java - a field report

[Anonymous Coward]

I recently wrote up what I (believe to) know about the topic and what I'm still missing:

http://schmidt.devlib.org/java/creating-thumbnails -with-java.html

It's a bit long, but I appreciate comments, preferably by mail.

I'd like to know what you had to do to improve quality. Step-wise down-scaling (always to 50%, until thumbnail size is reached), do a blur filter first, anything else?

Re:Why

[Lord of Hyphens]

Try Computer Engineering - it's a bit of Electrical Engineering mixed with Computer Science with that C and assembly flavor. Minty!

It's not the execution speed that makes me stay away from Java -- it's that I like C so much more. Doesn't help that I despise the absurdly long function names (IOCCC parody)

This isn't learning about computer graphics

[Viol8]

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()!

Well gee, my Palm can't run Java very well...

[jotaeleemeese]

And I have an HP calculator that can't run Java neither.

Java is an adulterated piece of crapola, I am telling you ....