Java Media prominent at Siggraph97

Siggraph, the annual meeting of the members of the Graphics Special Interest Group of the Association for Computing Machinery (ACM), draws attendees from around the world and from a variety of backgrounds and interests. Organized originally by engineers and scientists, the Siggraph conference has expanded its scope over the years as computer graphics have moved from academia to mainstream usage. A variety of activities and events — from content creation courses to art galleries and everything in between — brought a crowd of over 48,000 artists, animators, scientists, engineers, designers, and graphics devotees of all sorts to Siggraph97.

With the sweltering L.A. heat from August 3 to 8, attending all of the announcements, meetings, and other Java-related events proved to be a full-time, exhausting undertaking. If the prominence of Java at this year’s conference serves as any sort of foreshadowing for next year’s, you can expect to see a wide variety of Java-based solutions at Siggraph98 in Orlando, FL, next July.

A lot of ground was covered in Java Media over the six days of the conference. Given that much of the audience at Siggraph is involved in three-dimensional graphics, a large part of JavaSoft’s effort was spent on evangelizing the Java 3D API. Expect to see a more technical article that compares the newly specified Java 3D API with OpenGL and VRML in an upcoming issue of JavaWorld.

JavaSoft made a major press release during Siggraph announcing the 1.0 Java 3D specification release as well as early access releases of the Java Media Player and Java 2D APIs and the Java Sound Engine. See the Resources at the end of this article for more information on this JavaSoft announcement and other Java-related activity at Siggraph.

The Java 3D course

JavaSoft hosted a full-day introductory course on the new Java 3D API. This followed the release of the Java 3D 1.0 specification to the public by just four days. (Does anyone get the idea that JavaSoft was rushing to meet a deadline?) Though JavaSoft showed demos running on both Solaris and Windows NT machines, currently there are no publicly available implementations.

The course was noteworthy in part because it was aimed squarely at graphics programmers and others who might not already be intimately familiar with the Java language and runtime. This tactic struck pay dirt for JavaSoft: Throughout the entire day of the course, the meeting hall remained near its capacity of 750 people.

The first part of the class centered on the general benefits of Java that we have all come to know and love from Sun’s marketing activities — namely, “Write once, run anywhere,” and so on. It also included a brief introduction to the Java 3D API and its basic structure.

The other major sections of the course included:

• The Java 3D API — A detailed discussion of the major objects and methods.

• Unique Features of the Java 3D API — A discussion of the design center of the API and its inherent strengths and weaknesses.

• Applying the Java 3D API — A case study presented by a speaker from Intel showing how Java 3D can be used to build compelling 3D games and environments.

Fundamentally, Java 3D is a graphics runtime that uses a Java-based scene graph, or a hierarchical set of relationships between objects in a three-dimensional scene, to render 3D graphics. As a higher-level API, Java 3D has been designed to be a common subset of all 3D graphics API functionality available in several major pre-existing 3D APIs. This gives Java 3D implementors flexibility in implementing on top of well-established APIs.

JavaSoft’s current Windows and Solaris implementations of Java 3D in turn use OpenGL as their interface into machine-specific functionality. JavaSoft also anticipates possibly providing implementations of Java 3D built on top of Direct3D for Win32 and QuickDraw3D for MacOS at some point in the future.

The emphasis on its runtime nature was constantly pointed out by JavaSoft personnel, largely in response to questions by Virtual Reality Modeling Language (VRML) supporters. Whereas VRML is predominantly a file format for 3D scene graphs, Henry Sowizral of JavaSoft explained that Java 3D is a runtime API and system for building and using scene graphs in Java. He illustrated this point with an example showing that though one might write a computer-aided design (CAD) program using Java 3D, this program might output models into VRML for use on the Web or for importation into other modeling or CAD packages.

There are many other differences between Java 3D and VRML. Nonetheless, the basic concern that most people seemed to have was that Java 3D was an attempt to preempt the pre-existing and widely deployed Web standard of VRML. The tension came to a head when someone asked point blank which of the two they should use if they had deadlines to meet this year and needed to employ a 3D graphics project that used Java to manage the scene. The answer from JavaSoft’s featured Java 3D speaker: “Don’t even think about using Java 3D in a product this year.”

An interesting way to hedge your bets did emerge, however. JavaSoft has already built a VRML 1.0 and 2.0 loader to read in VRML files and build up Java 3D scene graphs from them. Indeed, most of the really compelling content that was demonstrated running in Java 3D was actually authored by others in VRML and then read in by JavaSoft using their loader. JavaSoft has made no public commitments to ship its VRML loader, but a source at JavaSoft agreed that it would make good sense to provide this tool in some form for content creators to use to import their VRML content into the Java 3D runtime. Because of this, building content in VRML seems to be the safe approach — whether or not you ultimately decide to move that content into the Java 3D runtime.

Java 3D and Java Media “SIG”

The questions got more intricate at a JavaSoft-hosted Java Media birds-of-a-feather session. (Such sessions are called SIGs instead of BOFs at Siggraph.) JavaSoft used this forum as an opportunity to also introduce attendees to several other Java Media APIs, with presentations on Java 2D, Java Advanced Imaging, Java Media Players, and Java Sound.

Some of the interoperability between the various Java Media APIs was discussed, with questions such as “Can I render from Java 3D into a Java 2D frame buffer?,” but the majority of attendees seemed to be most interested in discussing Java 3D. Developers and content providers sought answers to the tougher questions that had not been asked — or answered to their satisfaction — during the preceding Java 3D course.

Some of the notable points that emerged from this SIG:

• Java 3D will be a premium extension to the Java Platform. This means that people implementing Java runtimes will have to pay a separate licensing fee above and beyond the cost of the Core Java Platform. There will be no user fees.

• Java 3D’s focus is on providing fast rendering. As such, its rendering engine optimizes for speed rather than quality. Because of this, building a high-end modeling, animation, and rendering package such as Alias-Wavefront’s PowerAnimator or SoftImage’s SoftImage 3D in Java 3D 1.0 does not make sense. Building Java 3D-based games, however, might make good sense.

• No Java 3D objects are currently Java beans. JavaSoft expects that once it works out granularity issues (such as what sub-portion of a scene graph makes sense to have as a bean), Java 3D bean objects will be available. Branch groups are probably the right level at which to make this distinction.

• JavaSoft is working on support for Java programs to ascertain at runtime whether a given Java Media API is implemented on a given machine, and if so, what version of the API is available. The chief architect for the Java Media APIs, Brent Browning, stated that as a whole, the APIs have proven there is a strong need for such a version mechanism.

There was more technical detail given on the basic structure of the Java 3D scene graph. JavaSoft explained the rationale behind some of the major trade-offs it had made in the Java 3D design. This information will be given in greater detail in a separate, more technical article on Java 3D to appear in a future issue of JavaWorld.

“What 3D API for Java should I use and why?”

A lot of tension had built up throughout the week as to which 3D API to use in Java 3D. Two days after the Java 3D course and Java Media SIG, a very well-attended panel session with representatives from Mitra, JavaSoft, Silicon Graphics Inc. (SGI), and Microsoft discussed choices for 3D graphics in Java. These representatives supported VRML, Java 3D, Java bindings to OpenGL, and Direct3D related technologies, respectively.

Each company introduced its favored technology and then what amounted to its defense of that technology’s strengths in this space. Of note: Many audience members pointed out that Microsoft’s technology was the only one of the above that was strictly tied to Win32. In fact, some called on Microsoft to scrap its plans entirely and support OpenGL (in lieu of Direct3D), Java 3D, and related Java extension APIs. Microsoft responded that it would provide “whatever its customers asked for,” but that so far they were not asking for OpenGL or Java 3D. Many attendees probably wondered if they, as customers, did not count.

Mitra pointed out that whereas the other technology models were oriented toward programmers and so might be too heavyweight for many content creators, VRML has been designed to allow for creation of content by non-programmers. This was followed by some debate as to which model was best for most people, with the obvious conclusion being that no one tool is best for every situation, but that open, widely available, cross-platform solutions are the best choice for most.

Many in the audience welcomed the announcement by Silicon Graphics that it would be providing Java bindings to the OpenGL Scene Graph. OpenGL is a widely known and implemented standard for 3D graphics, with implementations already available on all of the major versions of Unix, Windows, and MacOS. SGI promised bindings for both its IRIX operating system and Win32 (Windows 95 and NT). With the weight of SGI in the OpenGL Consortium, it is rather likely that many OpenGL licenses will at some point provide implementations of the OpenGL Scene Graph with Java bindings.

The consensus from the crowd was that open, cross-platform standards, like VRML and OpenGL, were preferable to closed technologies. To the extent Java 3D is implemented on a variety of platforms and the API creation process is seen as open, Java 3D also may be one of the technologies that developers and content creators choose to implement or use in their tools. However, widespread cross-platform support is by no means guaranteed for Java 3D, as Microsoft and Silicon Graphics both stated during the panel that they currently have no intentions of licensing and implementing the Java 3D API. Leaving Java 3D as a premium extension may prove to be the quickest way to insure its demise.

Panel discusses Internet sound

Several panelists, both engineers and musicians, convened in the early morning hours of the last day of the conference to discuss sound on the Web. The one thing every one could immediately agree on was that sound is a tremendously powerful means of communication that is vastly underutilized online.

JavaSoft indicated it hopes to dramatically improve the experience of Java Platform users with the introduction of the Java Sound Engine as a Core Platform component beginning with the next post-1.1 major platform revision. In place of the sub-standard, 8-bit muLaw support in the current Java 1.1 Platform, there will be a 16-bit CD quality sound engine. As demonstrated at the last JavaOne in April ’97, the sound engine will be able to play a variety of common audio formats, as well as MIDI. It will use a fast and efficient software synthesis engine based almost entirely on technology from JavaSoft’s Java Sound partner Headspace.

A separate Sound API will follow the release of the Sound Engine support. The Sound API will be a standard extension. It will give programmers the hooks they need to interact with the Sound Engine. If JavaSoft delivers as promised, sound in Java will be superb by the time next year’s Siggraph occurs: It’s possible that this engine and API, in their ubiquity in browsers and Java Platforms everywhere, may help to solve some of the problems discussed during this panel session.

The Sun Exhibit and Java in unexpected places

Sun demonstrated running versions of many of the Java Media APIs at its Siggraph pavilion booth. Java 3D was shown running on both Solaris and NT, with a mock-up, space shoot-em-up game that illustrated the speed of the system. Behind closed doors, JavaSoft was showing complete Java Platform 1.2-based demos of programs based on Java 2D, Java Sound, Java Media Players, and other Java Media and Communications technologies. The demos were hands-off and rather scripted, but they did demonstrate that the suite of multimedia and communication APIs is still developing nicely.

Another valuable tidbit picked up from behind closed doors: Java 2D will become part of the Core Java Platform with the next major post-1.1 release. As Adobe was the key partner with JavaSoft on developing this API, I would expect that one will be able to write plug-ins for Adobe programs such as Photoshop in Java fairly soon. Get ready, plug-in writers of the world: Opportunity for cross platform plug-ins may soon be coming your way!

Time spent walking around the pavilion was also rewarded with interesting demos from other companies selling Java-based solutions. Several companies were using Java at one level or another, some in great depth and breadth, the others mostly experimenting with the technologies to decide how to take advantage of them in their graphics and media products. What follows are a few snapshots from the show floor.

Skunk Technologies unveiled their Entao Visual Chat system that uses 100 percent Java to create an avatar-based chat application. The system involves links from your Web site to their chat servers. In addition, a group of researchers from Waseda University in Japan showed an experimental 3D graphics system that uses musical instrument output as input to drive VRML scenes. Java provides the glue that connects the system’s internals together and the network communication and processing power that drives the whole thing.

Most intriguing to me was an big-screen presentation dedicated to Java given by a British company named Quantel. Quantel makes proprietary image manipulation equipment for video, film, and print editing production. The fascinating thing is, the company launched its developers program in preparation for its upcoming release of Java on Quantel. By embedding a Java virtual machine in its system, Quantel suddenly has made the full power of its system available to any programmer to build upon and add to. Java is allowing Quantel to rapidly move away from a previously closed model and into a newly open one, enabling the growth of a network of developers and, Quantel hopes, extending and increasing its own success. If all goes as planned, it could turn out to be a true testament to the power of open systems and no doubt would become a great case study for JavaSoft.

Conclusions

Java Media as a whole is still a work in progress, but the APIs are maturing. Graphics engineers, programmers, and users are beginning to take notice and explore the possibilities of Java-based media manipulation and distribution. Rapid, well-tested deployment of reliable implementations based on openly developed specs seems to be the quickest and most successful approach that JavaSoft can use to insure Java Media’s success. Time, and next year’s Siggraph, will tell if it has been successful.