Forgot your password?
typodupeerror
Book Reviews Books Media

Computer Graphics With Java 218

Posted by samzenpus
from the read-all-about-it dept.
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.
This discussion has been archived. No new comments can be posted.

Computer Graphics With Java

Comments Filter:
  • You don't need antialiasing if you are rendering with an interval engine like this one:
    http://sunfishstudio.com/ [sunfishstudio.com]
    • by N Monkey (313423)

      You don't need antialiasing if you are rendering with an interval engine like this one:
      http://sunfishstudio.com/ [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.

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

      by AKAImBatman (238306) * <<akaimbatman> <at> <gmail.com>> on Wednesday July 11, 2007 @03:47PM (#19829243) Homepage Journal

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

      Java 1.4 added support for a direct-rendering scheme [sun.com] similar to DirectDraw. The primary difference is that surfaces are managed automatically by the JVM rather than being explicitly locked and unlocked.

      JOGL [java.net] introduced an official add-on for OpenGL support in Java, and was standardized under JSR-231 [jcp.org]. Several Java-based scenegraphs appeared shortly thereafter. The most popular are Xith3D [xith.org] and jMonkeyEngine [jmonkeyengine.com].

      Java3D has been an official add-on since about '98 (IIRC), but it was less useful because it hid access to OpenGL behind its scenegraph. As a result, it was discontinued shortly after the introduction of JOGL, only to be brought back as a Sun Open Source Project [java.net]. It now supports the JOGL/JSR-231 standard.

      Does that answer your question?
      • Re: (Score:2, Informative)

        by Mithrandir (3459)
        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
  • by dj245 (732906) on Wednesday July 11, 2007 @03:21PM (#19828925) Homepage
    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???
  • 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
    • by fm6 (162816)
      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.
      • by cecille (583022)
        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
        • by fm6 (162816)
          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
    • "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"?
      • by gbjbaanb (229885)
        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.
        • "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 o
      • by krelian (525362)
        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.
  • by SilentBob0727 (974090) on Wednesday July 11, 2007 @03:24PM (#19828975) Homepage
    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.
    • by Applekid (993327)
      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
  • Yeah... (Score:3, Interesting)

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

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

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

      by MBCook (132727) <foobarsoft@foobarsoft.com> on Wednesday July 11, 2007 @04:35PM (#19829933) Homepage

      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.

      • by fbjon (692006)
        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.
    • 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... (Score:5, Informative)

      by Mithrandir (3459) on Wednesday July 11, 2007 @04:49PM (#19830169) Homepage
      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.
      • 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 al
        • by Laser Lou (230648)
          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.

        • by metamatic (202216)

          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 d

      • Re: (Score:2, Funny)

        by Luxifer (725957)

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

        by UnknownSoldier (67820) on Wednesday July 11, 2007 @07:01PM (#19832009)
        > 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?)

        • by david.given (6740)

          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 t

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

    • by kaffiene (38781)
      Java is not slow. And if you're writing a game, you'll use the hardware for the 3D rendering anyway.
    • by metamatic (202216)

      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 [bytonic.de], is it?
    • by crucini (98210)

      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 ea
  • 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 possib
    • by Tim C (15259)
      Repeat after me: Java is not an acronym.
    • 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.

    • by krelian (525362)
      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.
    • by GrahamCox (741991)
      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 embarras
  • Java 3d (Score:2, Interesting)

    by edxwelch (600979)
    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.
  • by Animats (122034) on Wednesday July 11, 2007 @03:30PM (#19829059) Homepage

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

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

    • by ThosLives (686517)

      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

      • by Animats (122034)

        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

  • by niceone (992278) * on Wednesday July 11, 2007 @03:32PM (#19829083) Journal
    (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.
    • by iggymanz (596061)
      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.
    • by joe 155 (937621)
      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!
    • 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...
  • 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 som
    • by furball (2853)
      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.
  • 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 sing
  • I'd love to see someone port an open source Java class libary or VM's graphics library to render the graphics on the Cell microprocessor's SPE math processors, especially in PS3/Ubuntu [psubuntu.com].

    Is there an open source Java OpenGL implementation? That would be a great package to see running on the Cell.
  • The Java API Processing [processing.org] is used fairly widely now for precisely this purpose, often taught in various UNIs as a platform for introducing computer graphics techniques and programming concepts more generally.

    Processing is an open source programming language and environment for people who want to program images, animation, and interactions. It is used by students, artists, designers, researchers, and hobbyists for learning, prototyping, and production. It is created to teach fundamentals of computer programmin

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

  • 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®. Th
  • 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 cr
  • by Viol8 (599362) on Thursday July 12, 2007 @10:18AM (#19837523)
    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()!

Philogyny recapitulates erogeny; erogeny recapitulates philogyny.

Working...