Project: The Watson Game - Binghamton



Project: The Watson Game

Function: Web Based Client

Subsystem: X3D

Author: Jonathan Sneed

Date: 5/6/05

1 Introduction 3

1.1 Goals and objectives 3

1.2 Statement of scope 3

1.3 Software context 3

1.4 Major constraints 3

2 Data design 3

2.1 Internal software data structure 3

2.2 Global data structure 4

2.3 Temporary data structure 4

2.4 Database descriptio 4

3 Architectural and component-level design 4

3.1 Program Structure 4

3.1.1 Architecture diagram 4

3.1.2 Alternatives 4

3.2 Description for Component n 4

3.2.1 Processing narrative (PSPEC) for component n 5

3.2.2 Component n interface description. 5

3.2.3 Component n processing detail 5

3.3 Software Interface Description 5

3.3.1 External machine interfaces 5

3.3.2 External system interfaces 6

3.3.3 Human interface 6

4 User interface design 6

4.1 Description of the user interface 6

4.1.1 Screen images 6

4.1.2 Objects and actions 6

4.2 Interface design rules 6

4.3 Components available 6

4.4 UIDS description 7

5 Restrictions, limitations, and constraints 7

6 Testing Issues 7

6.1 Classes of tests 7

6.2 Expected software response 7

6.3 Performance bounds 7

6.4 Identification of critical components 7

7 Appendices 8

7.1 Requirements traceability matrix 8

7.2 Packaging and installation issues 8

7.3 Design metrics to be used 8

7.4 Supplementary information (as required) 8

SOFTWARE DESIGN SPECIFICATION

Introduction

The investigation of an X3D client was new task in the development of the Watson Adventure Game (WAG). X3D is an Open Standards XML-enabled 3D file format to enable real-time communication of 3D data across all applications and network applications (Append 1). It has a rich set of features for use in engineering and scientific visualization, CAD and Architecture, Medical visualization, Training and simulation, multimedia, entertainment, educational, and more. This Design Document will help answer the question whether or not an X3D client would be feasible. To do this I have created a prototype of the 3D world in X3D from existing auto generated Virtual Reality Modeling Language (VRML) code.

1 Goals and objectives

The goal of this project is to investigate whether or not X3D would be a suitable choice for a web based client of the WAG. Our main objective is to make the WAG more accessible by running in a web browser.

2 Statement of scope

The software that was used in the development of a web based client is the converted VRML world, myWatson1.wrl, provided by Brent Rood and the newly created X3D model, myWatson2.x3d.

3 Software context

The WAG is a game simulation for prospective Watson Students of Binghamton University. The game is developed in Senior Seminar taught by Dick Steflik. Every semester students improve the WAG, and this semester one of our objectives was to make the WAG more accessible to users by making it available on an Internet browser.

4 Major constraints

The AccuTrans3d Software that was needed to convert VRML code to X3D code had minimum system requirements of 512 MB of RAM. My local machine only has 256 MB of RAM so the conversion software could only be used in N-7 of the Engineering building.

Data design

The X3D file rendered is an X3D world. There are no data structures in myWatson2.x3d just geometric co-ordinates.

1 Internal software data structure

No internal data structures.

2 Global data structure

No internal data structures.

3 Temporary data structure

Files created for interim use are described.

4 Database description

No database

Architectural and component-level design

The X3D world rendered is composed of geometry coordinates of objects in that world. There is collision detection for the student walking through the WAG. The WAG is going to run in a browser. Any application running in a browser would generally run slower then off a local machine considering if the two systems had the same specifications. Executing the 3D world in the browser was twice as slow then running it on a local machine. The frame-rates were a lot slower and considering that it was only the 3D World and not all the components the speed of the WAG will get worse.

1 Program Structure

The first thing defined in the X3D code is 6 initial viewpoints in which the model can be observed (top, bottom, right left, front, back). The browser plug-in then allows you to tweak these viewpoints with a “seek” tool located at the top. Then all the shapes in the 3D world are defined next to create all of the real life objects in the Engineering building. The plug in that I used is called Octaga (Append 2). I used this plug-in because it had tools that better help me experiment with the viewpoints, namely this “seek” tool.

1 Architecture diagram

Figure 1 below shows how an X3D application runs in a browser.

Figure 1

See Append 3

[pic]

2 Alternatives

Our alternative is to distribute the game on compact disc. This alternative would prevent us to achieve our objective in making the WAG more assessable.

2 Description for Component n

For the prototype of the WAG world there is only one software component, the myWatson2.x3d. This component is the world in which users will walk thru. There is no server integration. Server scripts in X3D use ECMAscripts, which are not always easily converted from VRML’s JavaScript’s. According to an experiment by Don Brutzman at Naval Postgraduate School 10-20% of trivial scripts need manual intervention for them to work (Append 4). An understanding of X3D and ECMAscripts is needed for script conversions.

1 Processing narrative (PSPEC) for component n

The X3D code is interpreted by the browser with a X3D plug-in (See Figure 1).

2 Component n interface description.

MyWatson2.x3d consist of 6 viewpoints defined at the beginning of the file and 283 3D objects. Every object is taken from 1 of 21 picture files and its attributes are described in myWatson2.x3d.

3 Component n processing detail

The X3D world is a text file that is interpreted by the browser and then rendered into the respective 3D world.

1 Interface description

The interface of the 3D world is the same it is just running on a different platform.

2 Algorithmic model (e.g., PDL)

No algorithmic model

3 Restrictions/limitations

The user would need a hi speed connection to run the game at a satisfactory speed.

4 Local data structures

No local data structures

5 Performance issues3.2.3.6 Design constraints

The frame-rate is twice as slow on the browser then on the console.

3 Software Interface Description

See 3.2.2.

1 External machine interfaces

No external machine interfaces.

2 External system interfaces

Interfaces to other systems, products, or networks are described.

3 Human interface

The human can see the engineering building.

User interface design

A description of the user interface design of the software is presented.

1 Description of the user interface

A detailed description of user interface including screen images or prototype is presented.

1 Screen images

2 Objects and actions

All screen objects are taken from picture files and are listed below

Doors – drs1, drs2, hldr

Floors – flrs1, flrs2, flrs3

Glass – gls, gls1

Wall Props – prps, prps2, prps3

Wall poster – pstr1, pstr2, sns1

Straighaways – strs1, strs2

Tiles – tls

Walls – whtwll, wlls1, wlls2

Window – wnd1

2 Interface design rules

The interface design can be broken down into two parts, viewpoints and objects.

An example of one of the 6 viewpoints is defined below

An example of one of the 283 objects is defined below

3 Components available

All 3D objects can be classified as X3D “scene components”.

4 UIDS description

See 4.1

Restrictions, limitations, and constraints

See 1.4

Testing Issues

When running the game in an X3D web browser, a main concern was speed. Along with a speed test, I also noted the file size of the converted code. I tested the time it took to get to the first door on the left from the initial starting point. It took 4 seconds using the consolidated code base from last semester. Using X3D’s Octaga plug-in it took 9 seconds. The file size of the original VRML file is 2.54 MB and the converted X3D file is 1.47 MB.

1 Classes of tests

Black Box testing was conducted, because the code was not measured, strictly the performance of the code on the new platform.

2 Expected software response

I expect the web-based version to run slower then the machine loaded application, even if it is just the 3D world.

3 Performance bounds

The X3D version has to run at a satisfactory speed. A frame-rate closer to the machine loaded version. There is an unnoticeable performance speed difference between the VRML and X3D versions of the WAG world.

4 Identification of critical components

See 3.2.2.

Appendices

1. All language specification for X3D can be found at

.

2. Octaga plug-in



3. Figure 1 was taken from

4. Don Brutzman at the Naval Postgraduate School conducted testing on X3D script conversion.

1 Requirements traceability matrix

| | | | | | | | | |

|Unique |Requirement |Software Reqs. Spec/|Design |Program |Test |Test Case(s) |Expected Test|Remarks |

|Number | |Functional Req. Doc.|Spec. |Module |Spec. | |Verification | |

| | | | |

| | | | | | | | | |

|1 | |See 3 | |MyWatson2.x3d |Speed |See 6 |( |X3D file size smaller then|

| | | |See 3.1 | |File Size | | |VRML world. Performance |

| |Create prototype of WAG | | | | | | |is unnoticeable from VRML,|

| |Wolrd in X3D | | | | | | |but slower then console |

| | | | | | | | |application. |

2 Packaging and installation issues

The X3D world was loaded onto the subversion server under the web client group in an x3d folder. The file name is entitled myWatson2.x3d. Also the 21 picture files for the X3D world have been loaded in the same folder. Simply open a browser with an Octaga or any X3D plug in to run the file.

3 Design metrics to be used

I downloaded AccuTrans3d with is a conversion for 3D languages. It auto generated the X3D code and examples of the generated code can be found at 4.2.

4 Supplementary information (as required)

As stated in the introduction, the question is whether or not it would be feasible to run the WAG in a browser so it came be more assessable. The 3D world of the engineering building has been rendered. There still lies a problem with scripts and converting them. Because the WAG is interacts with a server the challenge lays here. Converting scripts from VRML to X3D is a non-trivial task and only one with a good understanding of X3D and VRML may accomplish this task.

As of right now the VRML scripts are not even converted because of the Java sandbox issue described in Brent Rood’s Design Document. We might be getting ahead of ourselves in looking into X3D. If somewhere in the future there is an industry shift to X3D and our web-client game is in VRML there should be no problem because X3D is backward compatible. All one must do is include a profile statement such as “”. X3D has 4 profiles to choose from starting with the most inclusive of functionality: Full, Immersive, Interactive, and Interchange. X3D does have some advantages over VRML like its newly added components. These components include Geometry, Environment, Animation, Appearance, Sensors, Structure and others. An example of a new feature from VRML is multitexturing. Multitexturing is the ability to bind two textures or a light effect on a texture together. I by no means want to sell the WAG short, but for our needs it doesn’t seem like it worth our time and effort to peruse development in X3D.

However, X3D’s greatest feature has not been released yet. A binary compression and encryption is still under development and is set to be released in 2006. This compression will boost speeds up to 300-500% and the file sizes will be even smaller. Only then it seems that X3D would be worth developing. With increase performance speeds the WAG can run in a browser in a more similar manner as the local machine WAG.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download