The GTC demonstration program in action.
Sebastien Loisel
All trademarks are properties of their respective owners. This includes, but is not limited to: Voodoo is a trademark of 3dfx Interactive, GeForce is a trademark of NVidia, Linux is a trademark of Linus Torvalds, RealPlayer is a trademark of RealNetworks, Java is a trademark of Sun Microsystems, 3d Studio Max is a trademark of Kinetix, Windows is a trademark of Microsoft. All other trademarks properties of their respective owners.
GTC is a set of tools to help Internet content providers distribute 3d and multimedia interactive content to their customers. It consists of a server-side library, which is run on the content provider's machine, and a client-side viewer, which is run on the customer's computer. Like many streaming media solutions now (e.g., RealPlayer or Vivo), the viewer receives a stream from a server. The viewer takes that stream and displays it appropriately to the customer. Unlike other streaming media solutions, the customer can interact with the stream. Mouse clicks and other types of events can be sent back to the server for further processing. In addition, the streaming media consists of 3d data and sound, which is unlike other existing streaming technologies.
Throughout this document, ``server'' shall refer to the computer(s) running the GTC library software on the company, merchant or content provider's machine, while ``client'' shall refer to the viewer, which runs on the customer's machine. The term ``shopping cart'' refers any variant of the well known electronic shopping cart systems used to sell products online. Also note that GTC is presently in an alpha state (more on this below).
GTC stands for ``Game Tool Chest'', however the applicability of the tools has extended beyond games and for that reason, it is possible that there will be a name change. The GTC web site location can be found in the references section.
Here I give three examples. The first two illustrate a subtle but important nuance of how the GTC library can be used on the server. This nuance will be explained in the latter sections. The third example is a currently available demonstration program that is distributed with the GTC tools.
An office furniture store wishes to let their corporate clients furnish a virtual room, and with the click of a button, that all selected furniture be added to the client's shopping cart. The best way to do this is to give the client a virtual room in which to place furniture. The customer can move around the room and appreciate it from various points of view. If the customer is not satisfied with the placement of a particular item, with the click of a mouse button the item can be moved around the room to a better location.
This method of using GTC I call ``peer-to-peer'', since each client requires a completely different stream of information.
A fictitious fashion company E-Fashion wants to promote its new line of clothes for young adults. It chooses one of the new virtual models. (For example, www.elite-illusion2k.com has a fashion model that does not really exist, it is a 3d computer object, much like the characters of the movie Toy Story or the T-Rex in Jurassic Park.) What would be best in this case is for the clients to be able to interact in some ways with the model (call her Valery). Perhaps she can give a fashion show by walking up and down a virtual catwalk, wearing the various products offered by E-Fashion. With the click of a button on Valery's skirt, the skirt is added to the customer's shopping cart. Several customers can watch the fashion show simultaneously and they can talk to each other (with actual voice, using a microphone).
This method of using GTC I call ``multicast'' because all clients receive essentially the same bit stream.
This was the original goal of GTC. As such, GTC is very well tuned to these applications. At the moment, my demonstration application, which I use to develop and debug GTC, is a space fighting game. Players get to pilot a space fighter, flying freely around in space. Players can shoot and destroy each other. I aim to also be able to implement games of other types, such as Quake (a ``first person shooter'') or Ultima Online (a ``persistent virtual world'' for a ``computer role-playing game''). Screenshots of the space fighting game are available on the GTC web site, though they are a bit dark at the moment, simply due to the way in which the artist created the 3d models.
The space shooter uses a multicast method, meaning that all clients receive more or less the same bit stream.
The GTC demonstration program in action.
The merchant needs to install the GTC library on his machine. Furthermore, a certain amount of programming is required to create the interactive content. At the moment, this programming must be done in C though my next priority is to add scripting features. The way this will be done ensures that all languages supporting CORBA (for instance, Perl, Python, Java) will be usable as scripting languages for GTC. It should be expected that the server will require significantly more computing power than is needed for static content or even certain dynamic content.
In order to generate an illusion of continuous movement, the viewer must display anywhere from ten to one hundred images per second. A movie theater uses 24 images per second, while an American television uses 60 images per second. Many of the streaming solutions available today cope with lower frame rates and/or very blurry images, but this is not the way of the next wave of Internet streaming media.
Since we are talking about streaming media here, each frame has to be sent from the server, which means that the server must be generating 10 to 100 new images per second. Depending on the type of application, a single stream of 100 images per second could be generated and sent to all clients (this may be appropriate for the fashion show example). However, in certain other applications (for instance, in the furniture store example), this is not possible. Which means that for each connected client, the server will have to generate from 10 to 100 new images per second. The GTC library is optimized for this work, so this is not as bad as serving 100 dynamically generated pages per second per client, however it will certainly impose more server load than is currently common on the Internet.
As an example, running the GTC library on my machine and generating 100 images per second results in no perceptible degradation in my other compute intensive tasks.
One of the most limiting factor in today's Internet is the very low bandwidth (data carrying capacity) of 56K modems. Audio-video streams of the type served by RealNetworks barely squeeze through. Because of the nature of 3d data, bandwidth requirements for GTC are somewhat greater. However, higher bandwidth pipes to the customers homes are being implemented very rapidly; examples include DSL and Cable modem but other alternatives exist. I personally am using a Cable modem as I write this and the fees are 40$ per month. These types of Internet connection offer over 100 times as much bandwidth as a 56K modem. Under these circumstances, GTC will use negligible bandwidth for most applications.
I am currently developing a test application along with GTC to ensure that all is working properly. Consequently, I have some sample data which illustrates the bandwidth requirements. This is the information I've gathered from my demo application:
The customer will need to install the GTC viewer software. At the moment, the viewer software functions only under Linux though a Windows port is easily at hand, using a well tested and widely used third party library called SDL (see the references section). This port is high on my agenda of priorities.
In addition, the customer will require to have a hardware accelerated OpenGL implementation. This similar to what is required to play Quake 3 or any of the other modern 3d games. While these setups are not very common yet, they are becoming much more so very fast (an acceptable solution is to get a Voodoo 2 graphics adapter which goes for 55$ on PriceWatch (see references) at the moment, roughly the same price as any other graphics card).
A high speed Internet connection is also heavily recommended. These are not much more expensive than the more conventional phone line Internet connections at the moment and it is expected that the price difference will soon vanish.
The GTC viewer uses a very large amount of CPU power on the client side. Rendering 3d images is probably the most CPU intensive thing people do with their PC nowadays.
One issue is that many hardware accelerated OpenGL implementations available on PC's today (including the Voodoo 2 but excluding the Voodoo 3, 75$ on PriceWatch right now) do not allow for 3d in a window.
Most cheap 3d cards available at this moment do not allow for 3d in a window. That is, in order to benefit from the 3d card's accelerated features, the 3d application must take control over the entire screen. All other windows disappear and are replaced by the one 3d application (in this case, the GTC viewer). This renders certain things (such as having a 3d application embedded in a small corner of a web page) completely impossible. It also complicates creating a GUI interface for the GTC viewer. More modern 3d cards, such as the Voodoo 3 or the NVidia GeForce, allow for 3d in a window. That is, a 3d application can display the 3d world inside a normal window in either Windows or Linux, without disturbing other applications on the screen.
While GTC has reached an interesting demonstration stage, it is not yet ready for the limelight. I estimate that I would need approximately one month of full time work to make it a complete solution. The following is a list of what remains to be done:
At the moment, I am able to play a demo game that uses GTC. I can fly in space and shoot other ships. Many people can play at the same time, distributed anywhere in the world. This means that the GTC library is right now capable of reproducing a 3d environment on all the clients. Further, the GTC library is capable of handling the required simulations aspect on the game server. Some collision detection is also implemented.
One of the important problem of 3d interactive applications is to accurately respond to user input. In a more physically correct 3d simulation, if the user pushes on a 3d objects, he expects it to move away. In a game, if the player shoots a spaceship, he expects it to be destroyed. Detecting when objects in a 3d world collide is not an easy task. GTC provides you with assistance in making that determination. The server can take any action in response to collisions of objects in the 3d world.
In addition, sophisticated tools are required to create the 3d content. These tools require enormous efforts from large companies to develop. For this reason, I propose to leverage existing tools, such as 3d Studio Max for creating 3d objects. At the moment, GTC has certain limited ability to use 3d objects created with 3d Studio Max.
I estimate that GTC requires about a month of my full time work to be ready for a public beta (which, according to some companies, is enough to make a first public release). I will not be working on GTC until mid-march, my Master's thesis requires my attention. I hope to give GTC the attention it deserves during Spring and Summer.
I apologize if this section is more technical than the rest.
The only other working implementation that I know about is VRML, which was used a few years ago by NASA to allow the public to visit a virtual representation of the landing site of the Mars Rover. VRML is a format for 3d interactive scenes. VRML is not appropriate for multi-user interactive 3d applications, facilities for communicating back to the server are not well implemented. For one reason or another, VRML never became popular.
MPEG-4 attempts to address some of these issues, leaving room for upstream (client to server) communication (for user feedback). However, there are still several problems. For one, the upstream communication protocol is not specified in MPEG-4. In addition, no MPEG-4 implementation currently exists. Also, there is some infighting amongst those responsible for writing the MPEG-4 standard; those who are responsible for VRML are trying to get the MPEG group to change their scene format to one that more closely matches the newer VRML standard, called X3D. Lastly, there is no well defined server-side API for writing 3d interactive applications, only the bit content of the streams is defined in the MPEG-4 specification.
This document was generated using the LaTeX2HTML translator Version 99.2beta6 (1.42)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 gtc.tex
The translation was initiated by Sebastien Loisel on 2000-01-22