Slashdot Mirror
Computer Graphics With Java
Michael Grady writes "Computer graphics has become an
indispensable part of mainstream computing and the undergraduate
course in computer graphics programming is often one of the most
popular courses in the curriculum. In the early days, such courses dealt with low level
implementation details and algorithms such as converting lines to
pixels, filling rectangles, view clipping and anti-aliasing. When OpenGL arrived on the scene, it was welcomed as an efficient and
powerful, procedure-oriented library that kept many of the low level
details out of sight. The sort of projects that could be tackled in
an introductory course became much more impressive. That was back in the 90's. Is
there a way to build a course covering the basic computer graphics
concepts and techniques which takes advantage of object orientation
and higher levels of abstraction? I believe the authors of Computer
Graphics using Java have found a way." Read below for Michael's review
Computer Graphics Using Java 2D and 3D
author
Hong Zhang and Y. Daniel Liang
pages
462
publisher
Pearson Prentice Hall
rating
8
reviewer
Michael Grady
ISBN
0-13-035118-0
summary
Introduction to computer graphics concepts and techniques using Java 2D and 3D
Their strategy is to teach by example using the comprehensive, high level interfaces provided by Java 2D and Java 3D. Their examples are often well chosen and fun. The programming exercises are entertaining and appropriate.
About one third of the book is devoted to 2D graphics and covers the usual topics: coordinate systems, modeling, constructive area geometry, color models, affine transformations, compositing, splines, clipping, fonts, raster images, animation and image processing. As anyone who has worked in this area knows, Java 2D provides a beautifully designed set of classes for high quality 2D graphics and imaging. This part of the book could also serve as an excellent introduction for any programmer who wants to begin exploring its functionality.
Where the book really shines is in the examples. My favorite 2D examples include:An interactive demo of the RGB Color model which also illustrates constructive area geometry. An efficient rendering of the Mandelbrot set as a raster image. An elegant analog clock that shows how to use the Timer class in animation. An interactive demo of the common 2D affine transformations.
Surprisingly, none of the code uses anti-aliasing, even though Java 2D does a great job smoothing rough edges. In computer graphics circles, this is a faux pas — a violation of accepted, although unwritten, social rules, and points must be deducted for this omission. But if you add the required one line of code, most of the examples look pretty good.
The last two thirds of the book are devoted to 3D graphics programming, which reflects a common emphasis in the course at the undergraduate level. Coverage includes scene graphs, the rendering pipeline, 3D modeling, affine and projective transformations, illumination and reflection models, texture mapping, adaptive rendering, animation and interactivity, as well as object oriented graphics concepts such as behavior dynamics.
Java 3D provides a high level, object oriented framework for 3D graphics programming, with about 360 classes. For those who are used to programming with OpenGL, the Java 3D mindset may require a bit of indoctrination. It's based on the concept of a scene graph, and makes a lot of sense from an object oriented programming viewpoint.
Basically, a scene graph is a data structure for organizing the objects of a scene. We mean objects in the object oriented sense. Java 3D objects may be responsible for geometric, transformation, illumination, shading or behavioral data. The nodes of the scene graph represent objects and the edges represent a necessary connection. For example, a transformation node may be connected to a node representing a cube. The corresponding transformation object defines how the cube should be rotated, scaled, etc. In traversing the graph from its root, the Java 3D rendering engine finds all the information required to render the scene. It's a cool way to do computer graphics at a higher level of abstraction than programming directly with OpenGL.
Once again, many of the examples are excellent for an introductory text. My favorite 3D examples include: The classic spinning dodecahedron. This example shows that setting up the scene geometry is pleasantly intuitive in Java 3D. The ease of computing the normal vectors of all plane surfaces using the NormalGenerator class is a good illustration of the power of object oriented programming. Transformations, lighting and material properties are handled by dedicated classes. An interactive illustration of the common 3D affine transformations showing the effect of modifying transformation matrices. The mirror image of rotating 3D text that demonstrates the effect of composing transformations. How to generate a torus mesh. The canonical Utah Teapot.
Once again,the code does not use anti-aliasing, even where it is badly needed.
One of the benefits of using the Java platform is the extensive support for networking, multithreading, multimedia, database access and web services. For the most part, none of these benefits are exploited in the text. But that is probably the subject for a second course in computer graphics using Java.
All in all, it's clear that the authors are excellent teachers. This shows in their effective use of the teaching-by-example style. As stated in the preface, the authors intended their book for students and computer professionals who want to learn basic computer graphics concepts and techniques and who want to get started in programming with the Java 2D and 3D APIs. I believe they have succeeded in this goal, and if you are in this group of readers, I can confidently recommend their book.
You can purchase Computer Graphics Using Java 2D and 3D from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Their strategy is to teach by example using the comprehensive, high level interfaces provided by Java 2D and Java 3D. Their examples are often well chosen and fun. The programming exercises are entertaining and appropriate.
About one third of the book is devoted to 2D graphics and covers the usual topics: coordinate systems, modeling, constructive area geometry, color models, affine transformations, compositing, splines, clipping, fonts, raster images, animation and image processing. As anyone who has worked in this area knows, Java 2D provides a beautifully designed set of classes for high quality 2D graphics and imaging. This part of the book could also serve as an excellent introduction for any programmer who wants to begin exploring its functionality.
Where the book really shines is in the examples. My favorite 2D examples include:An interactive demo of the RGB Color model which also illustrates constructive area geometry. An efficient rendering of the Mandelbrot set as a raster image. An elegant analog clock that shows how to use the Timer class in animation. An interactive demo of the common 2D affine transformations.
Surprisingly, none of the code uses anti-aliasing, even though Java 2D does a great job smoothing rough edges. In computer graphics circles, this is a faux pas — a violation of accepted, although unwritten, social rules, and points must be deducted for this omission. But if you add the required one line of code, most of the examples look pretty good.
The last two thirds of the book are devoted to 3D graphics programming, which reflects a common emphasis in the course at the undergraduate level. Coverage includes scene graphs, the rendering pipeline, 3D modeling, affine and projective transformations, illumination and reflection models, texture mapping, adaptive rendering, animation and interactivity, as well as object oriented graphics concepts such as behavior dynamics.
Java 3D provides a high level, object oriented framework for 3D graphics programming, with about 360 classes. For those who are used to programming with OpenGL, the Java 3D mindset may require a bit of indoctrination. It's based on the concept of a scene graph, and makes a lot of sense from an object oriented programming viewpoint.
Basically, a scene graph is a data structure for organizing the objects of a scene. We mean objects in the object oriented sense. Java 3D objects may be responsible for geometric, transformation, illumination, shading or behavioral data. The nodes of the scene graph represent objects and the edges represent a necessary connection. For example, a transformation node may be connected to a node representing a cube. The corresponding transformation object defines how the cube should be rotated, scaled, etc. In traversing the graph from its root, the Java 3D rendering engine finds all the information required to render the scene. It's a cool way to do computer graphics at a higher level of abstraction than programming directly with OpenGL.
Once again, many of the examples are excellent for an introductory text. My favorite 3D examples include: The classic spinning dodecahedron. This example shows that setting up the scene geometry is pleasantly intuitive in Java 3D. The ease of computing the normal vectors of all plane surfaces using the NormalGenerator class is a good illustration of the power of object oriented programming. Transformations, lighting and material properties are handled by dedicated classes. An interactive illustration of the common 3D affine transformations showing the effect of modifying transformation matrices. The mirror image of rotating 3D text that demonstrates the effect of composing transformations. How to generate a torus mesh. The canonical Utah Teapot.
Once again,the code does not use anti-aliasing, even where it is badly needed.
One of the benefits of using the Java platform is the extensive support for networking, multithreading, multimedia, database access and web services. For the most part, none of these benefits are exploited in the text. But that is probably the subject for a second course in computer graphics using Java.
All in all, it's clear that the authors are excellent teachers. This shows in their effective use of the teaching-by-example style. As stated in the preface, the authors intended their book for students and computer professionals who want to learn basic computer graphics concepts and techniques and who want to get started in programming with the Java 2D and 3D APIs. I believe they have succeeded in this goal, and if you are in this group of readers, I can confidently recommend their book.
You can purchase Computer Graphics Using Java 2D and 3D from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
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.
You don't need antialiasing if you are rendering with an interval engine like this one:
http://sunfishstudio.com/
stuff |
I've always been under the Impression that Java can't use hardware rendering, wouldn't that restrict usage for more intense applications?
You mad
Is there a way to build a course covering the basic computer graphics concepts and techniques which takes advantage of object orientation and higher levels of abstraction? I believe the authors of Computer Graphics using Java have found a way."
Why must you ask rhetorical questions of me???
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
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.
i inlined assemblied your mom last night
> 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.
... 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.
High Performance it ain't. There are better ways.
First of all, I've used Liang's introductory Java book in classes I've TAed, he is quite good.
As for Java graphics programming itself, it's definitely a mixed bag, but in general more good than bad. Back in my undergraduate days I took two courses for Java graphics and Java game programming. If you're already familiar with the language, it's a great tool for learning the basics and mid-level game-oriented 2D and 3D programming. Java has a lot of great tools for all kinds of design, and the speed-issues are not a concern with JIT and APIs that take advantage of hardware acceleration. And Java's easy network programming lets you build some interesting projects.
That said, people seriously thinking about futures in game development should be learning DirectX and C++ as soon as possible. OpenGL is great, and if you're doing cross-platform work it's obviously the right choice. But DirectX is the standard now; even Carmack hasn't been too hard on it lately. It's managed to make great strides while the OpenGL committee squabbled.
Unfortunately, teaching computer graphics in Java3D locks the aspiring developer into the Java platform. At least with OpenGL, you're not locked into any particular programming platform and have more choices in that regard. That makes learning OpenGL easier as well, since you don't have to already be a Java developer to pick up OpenGL and can instead learn it in your favorite language. And, at this stage in the game, there are plenty of Object-Oriented APIs based on OpenGL available.
Life would be easier if I had the source code.
"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.
Java is about the last language id use for anything involving graphics.
I'm no Java hater, I think it owns when it comes to developing maintainable applications and deployment across multiple platforms, but lets be realistic, it's slow.
One could argue that it still has merit in an academic sense, for teaching the basics of graphics programming, but even that is kind of flawed. You probably want to avoid OOP in general when it comes to the actual graphics component of an application, as it adds overhead. Not only is Java itself slow, but the way in which it approaches graphics is probably the worst way to approach it in any language performance wise.
JAVA really is a brilliant achievement. It comes with nearly everything built in, and what is not included is easy to make. The simplicity of Graphics in JAVA is unsurpassed in any real language, and has huge capabilities. Even using OpenGL with JAVA is possible. This work is exactly what is needed to get more people using JAVA and revolutionary in the way of graphics. I still remember trying to draw a house with Assembly and C++ using only native libraries. JAVA makes life a lot easier, and graphics possible for all.
There is an enormous amount of work done in the Java 3d api, unfortunately hardly anyone uses it - I counted only a handful of games made - most not really commercial quality. It's ironic that the mobile 3d version has had a lot more success, considering how limited mobile phones are.
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.
Historically, scene graph APIs haven't been too useful. There are successful drawing APIs, like OpenGL, and game engines, but the in-between middleware hasn't been that useful. SGI Inventor, later Open Inventor, was the classic in that space, and it's not used much any more.
Java 3D is abandonware. Sun wrote it, badly, and it's now a "community source project", meaning Sun doesn't support it any more. I used it in its early days and wasn't impressed. The Java3D collision detection system was both badly designed and badly implemented. The general consensus was "give us an OpenGL binding and get this turkey out of the way".
If you are programming portable code you want any non-Windows users to be able to run casually, Java is a better choice. The web consists of more than just Windows users, y'know.
(you knew it was coming) we had to deflect the electron beams ourselves using little magnets we had dug out of the ground with our bare fingernails.
ccalam - acoustic versions of new songs.
As far I know, Java uses 32 bit values internally as a minimum, so even if they got around adding a unsigned byte, it would technically be a 32 bit value in disguise. But I got to admit, the lack of unsigned byte is a huge annoyance when you program in java. :/
Stay tuned for his next book: Implementing Databases using LISP.
I like Java, I really do. But bloody hell... there's fanboys, and there's Java fanboys.
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?
Do you even understand how signed values work? Signed and unsigned are the exact same thing, save for two major exceptions:
1. Sign-preserving operations. The only one I can think of off the top of my head is a signed right shift. (>>) Use a bitwise shift instead. (>>>)
2. When the result of computations are printed out. An unsigned value is printed as a larger positive number while a signed value is given a negative sign and inverted if the first bit is a 1, before being printed out.
Java has a very sophisticated graphics library. (see: java.awt.image.BufferedImage) It uses 32-bit ARGB values. Somehow, the sign doesn't seem to cause a problem.
Javascript + Nintendo DSi = DSiCade
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.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
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.
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.
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.
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.
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?
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?"
Except that, without unsigned values, Java won't let you, for example, say:
byte a = 0xFF;
-- I prefer the term "karma escort."
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Seriously.. Just because you can put OpenGL bindings in a corporate fabricated language doesn't mean you should.
bash-2.04$
bash-2.04$yes "Don't you hate dialup connections?"| write USERNAME
You have to do an explicit cast:
byte a = (byte)0xff;
That's a bit annoying, but hardly a giant pain in the ass.
byte a = (byte)0xFF;
This program will print out the correct result of -1: If you want to upconvert it to an int, don't cast it. Casting is a sign extended operation. Instead, you can OR the value. e.g.:
byte rgb = 0xFF0000;
byte a = (byte)0xFF;
rgb |= a;
Java makes you work a bit more at it, but it's nothing major. In most circumstances you *should* be using bitwise operations anyway. There are very few situations where you need to add an unsigned byte to a signed integer. (Most of them caused by a false sense of optimization or memory economy.) In those cases you use a (0xFF & a) operation to cast the byte without sign extending it.
Javascript + Nintendo DSi = DSiCade
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.
--
make install -not war
- 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:Which was probably not a big deal, as I assume your current job at Burger King doesn't require this functionality that often.
That would be the specific library, not Java. Java has multidimensional arrays, though they are actually arrays within arrays. (ad infinitum)
That is generally the fastest way to access image data. I don't know about you, but I've 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.
Javascript + Nintendo DSi = DSiCade
Oops, got my twos complement wrong in the example -- it's been a while. But the point is still valid.
Integers are for wimps.
Real graphics is done with floats.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
See, this is why we still need mainframes.
In the free world the media isn't government run; the government is media run.
Or maybe it really is -32768 and not 65535! Perhaps you should try: short x = (short)65535;
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.
No it's not.
;)
why not use Short.reverseBytes(short) for your 2s-complement skills?
Website Hosting
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;".
Computer
.
Graphics
.
With
.
Java
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!"
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.
Well, yeah. If the documentation says, "This method expects a bit-packed value in ARGB format" you had better pass it a value in ARGB format. That's true whether you're working in Java or C/C++. I pity the fool who doesn't read his documentation.
Killer isn't it? Adding that extra > sign.
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.
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.
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.
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.
Javascript + Nintendo DSi = DSiCade
As far I know,...
From what I just read, that's shorter than the distance to your coffee grinder.
I swear to God...I swear to God! That is NOT how you treat your human!
3. Division. The shortest implementation of unsigned division using signed types I could knock together in a few minutes is
What do you mean?
Microsoft invented the internet. Everyone knows that.
Runescape in Java,
...C/C++?
WOW and EQ2 and EVE in
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.
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.
Javascript + Nintendo DSi = DSiCade
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.
... 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.
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.
To add to the list of problems: Comparisons work differently for signed and unsigned types.
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.
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.
Like this: http://product.thinkfree.com/ ??
None of that is required to work with OpenGL in Java, of course.
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.
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.
Music for coding. Genetic algorithm driven visuals. http://www
"But a lot of people associate game design with graphics."
Not me. Oh wait!
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? 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.
Java is so Web 1.0. Web 3.0 will be Computer Graphics with JavaScript.
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!
At least not with any conventionally-shaped VM.
When configured in useful fashion, the Cell SPUs can access at most about 128KB of memory.
Comment removed based on user account deletion
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.
-Billco, Fnarg.com
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.
Why every time someone speaks of portable code they refer to Java?
Isn't python just as portable?
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.
r y/pa-ctypes3/index.html
Source: http://www-128.ibm.com/developerworks/power/libra
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.
I recently wrote up what I (believe to) know about the topic and what I'm still missing:
s -with-java.html
http://schmidt.devlib.org/java/creating-thumbnail
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?
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.)
"Don't belong. Never join. Think for yourself. Peace." V.Stone, Microsoft Corporation
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)
"I've spent my whole life figuring out crazy ways to do things. It'll work." -- Montgomery Scott, "Relics"
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.
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()!
And I have an HP calculator that can't run Java neither.
....
Java is an adulterated piece of crapola, I am telling you
IANAL but write like a drunk one.
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.
byte rgb = 0xFF0000; //Red
you meant int here I guess...
Hey mother fucker as long as it pays my bills its not a failure.
Yes I did. Sorry, another one of my brain farts.
Javascript + Nintendo DSi = DSiCade
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.