Hero's Tale

3D Graphics Team Page


Contents


Preface

This page will serve to show the current status of the 3D graphics portion of the Hero's Tale game. The primary goal of this group is to design and implement the graphical aspects of the Main Viewer window.

Comments about this page are always welcome. Mail may be sent to the java games mailing list and/or the author, Jonathan Korein.


Requirements

This list of requirements is based partially on items from Trevor's Project Description and Deliverables Specification documents.


Current Design and Implementation Issues

Their are obviously many design issues which need be tackled. Rather than delay the publication of this page until I have sorted out preliminary thoughts on all of them, I will present a few which I think need to be presented to the team members promptly.

The desirability of using 3D graphics, taken together with the need for portability and smooth animation, raises a red flag to anyone who has tried to achieve these goals. This will be a difficult set of requirements to meet. I would like to start a discussion by proposing a list of possibilities, along with what I see as the pros and cons of each.

Here is a list of some possible methods of rendering the main viewer window.

 

Home-Bred Java 3D Engine

In this scenario, we create our own java 3D engine and use it for all rendering.

Pros

This is the most portable of all solutions, at least to the extent that java is a reasonably portable language. It enables us to use any constraints we impose on the geometry of our objects to our advantage (ie. environments could be implemented as BSP trees, etc.). In addition, it is always nice to have source code to as much of a system as possible.

Cons

Despite the fact that we can use constraints, this solution may not be able to meet the fundamental speed and attractiveness requirement. At least one attempt to create a simple 3D engine in java reports that texture mapping proved to be prohibitively inefficient. There is a brief discussion of this in "Cutting-Edge Java Game Programming", by Neil Bartlett, Steve Simkin, and Chris Stranc. The specific project mentioned in that book is a Wolfenstein-3D clone called Fred. (That section also includes an interesting discussion on the trade-offs involved with synchronizing displays.) Essentially, their experience was that it was difficult to use java to emulate the tight native loops (often coded in assembly language) that are typically used to achieve real-time texture mapping.

A related disadvantage is the inability of this scheme to take advantage of any specialized hardware a user machine might have. It is always nice to run as fast as possible on a given machine, and 3D graphics hardware is on the verge of becoming commonplace.

 

Home-Bred Java 2D Engine

One option, mentioned in Trevor's spec, is to just scrap 3D, and render the main viewer fully in 2D. Objects and the environment could be rendered in 3D offline, but the main viewer display would just manipulate and animate bitmaps.

Pros

This has the same advantages as the home-bred java 3D engine. If we used pre-rendered 3D graphics, it would allow us to use objects of arbitrary complexity.

Cons

While a 2D view can look very nice, it will limit some features 3D would easily accomodate: perspective, zoom, etc. Going fully 2D also decreases the ability to accomodate a wider variety of views in future versions of the game. All 2D pictures have to be pre-packaged, so some things (ie. displaying a character prone) which are accomplished trivially in 3D can be difficult in 2D. It should be noted that going with a hybrid solution, such as a 3D environment and 2D objects, would also incur some of the disadvantages associated with the full 2D system.

 

Java 3D

There is a Java3D API due out sometime early this year. We could use it to render the main viewer.

Pros

A standard java API could eventually garner widespread support; this therefore may be a portable solution. Ideally this support would be free and integrated with java interpretters in such way as to be fast and use available hardware.

Cons

We would have to wait for the API came out and have at least preliminary support before we could consider using it. It is also not definite that widespread support would develop once it does come out.

 

VRML 2.0

VRML 2.0 has many procedural capabilities, both within the file format itself and in terms of hooks to java. It might be possible to implement the main viewer using it.

Pros

VRML already has wide acceptance, and many companies are developing VRML browser plug-ins. Because of this, there is a good chance of achieving portability, reasonable speed, and 3D hardware utilization by using VRML.

Cons

It may be difficult to find a VRML browser that meets all our needs and is a good game environment. The fact that we would be constrained to work with someone else's browser is also a minus. It might be awkward integrating the rest of the game and the VRML environment.

 

Liquid Reality API

Liquid Reality is a VRML based java API.

Pros

DimensionX has ported Liquid Reality to many platforms, so it (in theory) could provide a fast, portable 3D API for the main viewer.

Cons

We would have to negotiate with them to see if they would let us have development tools and run-time licenses for free in exchange for the marketing benefit we could provide.

 

Spacecraft API

InWorld VR is about to release a proprietary java 3D API. The current version is not native and does not support texture mapping. A version which will support texture mapping and which will run natively on systems supporting Direct3D, OpenGL, CosmoGL, and Live3D is supposed to come out by the end of the year.

Pros

The current API is cheap ($50) and may be used for the game as long as it is freeware. In the long run, the native plug-ins may give speed on machines with the required software support, while allowing a slower (and/or graphically plainer) version to run on other machines. It might be possible to get off the ground quickly with this API while continuing to evaluate it and other products over a longer period of time.

Cons

The current API is probably not adequate, so we are counting on a version which does not yet exist and whose delivery time is unspecified.

 

Native Graphic Libraries

If the program is implemented as a plug-in, the possibility of using native graphics libraries exist.

Pros

Native graphics libraries tend to offer the best performance and take greatest advantage of client graphics hardware.

Cons

This would force the plug-in methodology. We would have to decide on an intermediate level graphics interface and then implement it in terms of a native library for each platform.

 

Discussion

At the current time I am not inclined to recommend any one of the above alternatives above another. I consider them all reasonable proposals. My intent is to get feedback from members of the project, and from the 3D graphics team in particular, about their feelings about the various suggestions. Once this feedback is in hand it should help determine our next step. Most likely the proposals that get the most favorable response will require some furthur investigation to determine their feasibility.

It should also be mentioned that the above suggestions are hardly exhaustive. In particular, Trevor mentioned the possibility that OrbixWeb might be useful. I am not familiar enough with it to evaluate how it could be of use, but if anyone is aware of any methodology that would help us meet our goals I would encourage you to bring it up.

Due to the uncertain nature of the main veiwer graphics implementation, it may be desirable to encapsulate object geometry representations, rendering methods, and collision detectection methods so that other aspects of the game can proceed independently of these.


Team Members

Last Updated 1/27/97