Comp 145 – UNC Chapel Hill
Contract II
Project 12
3D Widget for the inTouch System
Submitted to :
Prof. Ming Lin
and
Prof. Greg Welch
February 13, 2001
______Ming Lin (Client)
______Mark Foskey (Technical Director)
______Joohi Lee (Quality Assurance)
______Bryan Crumpler (Librarian)
______Derek Hartman (Producer)
Preface
This document shall establish the final contractual agreement between Comp 145-Team 12 and client Prof. Ming Lin. This document serves to define the features of the TouchUI widget for inTouch and to delineate the duties and responsibilities of Team 12 as necessary for completing the GUI and other product requirements. This contract is binding and shall go into effect after 5pm, Thursday February 15, 2001.
Document Change History
2-14-01
1. Preface revision
2. User & System level requirements, and V&V revised for clarity
3. Goals modified to indicate client priority rather than team priority
2-12-01
1. Title page changed to reflect Contract 2; Blank added for client's signature.
2. Added section 5 (V&V). Moved schedule to section 6.
3. Redrew figure 2. Adjusted section 3 to model figure 2.
Glossary
The Team: is heretofore defined as Comp145 Team 12, inclusive of Mark Foskey, Derek Hartman, Joohi Lee, and Bryan Crumpler
inTouch: is the interactive modeling system that allows user to paint and morph
geometric objects using the Phantom Tracker for haptic feedback.
TouchUI: is defined as the widget (or GUI) for inTouch
User Definition: The User for the 3D-Haptic TouchUI shall be defined on two sub-levels for which the User level requirements in themselves shall be defined. They are the General User, and the System Programmer.
* General User Definition: The General User shall be defined as the artist, or general user of the inTouch modeling system.
* System Programmer Definition: The System Programmer shall be defined as one who wishes to plug in additional features to the TouchUI widget and customize their own tools for the purposes of enhancing the widget.
Toolbox: The Toolbox shall be defined as the subset of functions (painting/modeling tools, or API) containing the necessary functions or operations to interact with or use the inTouch system or the TouchUI widget.
1. Introduction
1.1 Goal
The goal of the team is to provide a natural and intuitive painting and modeling environment for inTouch. An integral part of the goal is completing and extending the current 2D user-interface for inTouch.
1.2 The inTouch System
In 1999, Arthur Gregory, Stephen Ehmann, and Ming Lin developed inTouch for generating 3D geometric models. The system has a number of distinctive features:
· Direct interaction in 3D with the model.
· Force feedback.
· Multiresolution model editing.
· Interactive 3D painting.
InTouch formed the basis for a paper [GEL00] presented at the IEEE VR2000 conference.
1.3 GUI Weaknesses
InTouch was written as a demonstration system, and the user interface, though serviceable, needs improvement. Various editing features are controlled from a toolbar, and the buttons are entirely 2D for a 3D system. Several of the graphical representations of the controls are unclear, and no haptic feedback is given to indicate selection of an option.
In addition to the system being minimally haptic, there are also problems user's have gauging the position of the tool. This is due to the insufficient depth cues such as stereo, or even more obvious visual cues such as shadows.
From a software engineering standpoint, the code also is not modular. This characteristic makes adding new features an unnecessarily difficult task.
To remedy some of these problems, Scott Cooper began to write a user interface toolkit in the Fall of 2000. Unfortunately there was insufficient time to complete the toolkit, and the team's job is to complete this toolkit and extend its capabilities.
[GEL00] Arthur D. Gregory, Stephen A. Ehmann, Ming C. Lin. inTouch: Interactive Multiresolution Modeling and 3D Painting with a Haptic Interface. Proceedings of IEEE Virtual Reality Conference 2000.
2. User-Level Requirement Specifications
Figure 1: User level hierarchy
The Software should provide a Toolbox/Menu for both the General User and System Programmer to use or modify TouchUI with ease. Learning time should be minimal, thus the following requirements are proposed as critical solutions for developing the widget inTouch.
2.1-A General User Requirement Definition:
2.1-A.1 The general users must have a distinct and well-defined Toolbox that interfaces between the users and TouchUI
2.1-A.2 The Toolbox must provide a means for allowing users to model and paint 3D objects in the system in an intuitive and natural manner. It should also provide a visual interface that suits a painting or modeling environment.
2.1-A.3 The software must provide a means for users to start and quit using inTouch
2.1-A.4 The software must provide a means for representing and accessing external files.
2.1-A.5 The software should provide a means of loading external files either as modeling primitives (Cone, Cylinder, Sphere, Cube) or previously saved work.
2.2-B System Programmer Requirement Definition:
2.2-B.1 The system must have a distinct and well-defined Toolbox or API that interfaces between the users and inTouch.
2.2-B.2 The software must provide a means for users to program modules offline and use them as added features to TouchUI.
2.2-B.3 The Toolbox should provide a means for allowing users to create and integrate UI components with TouchUI.
3. System-Level Requirement Specifications
General User
Figure 2. Detailed Top-Down Hierarchy of General User's Toolbox
3.1-A File Tools: The software shall have a menu modeled in either 2D, 3D, or Text Based for basic load operations
3.1-A.1 The menu should allow users to locate external files.
3.1-A.2 The menu should allow users to save files externally for future work.
3.1-A.3 The menu should allow users to open external files that have been previously saved
3.1-A.3.1 Each external file should be represented by a standard file extension such as *.tch *.itf or *ntc to represent an inTouch editable model
3.1-A.3.2 Each external file should be saved in one of but is not limited to said file formats for inTouch models.
3.1-A.3.3 Each saved file should be represented in their respective directory as a standard 2D icon if running on a GUI-based OS with iconizable thumbnails.
3.1-A.4 The menu should allow users to save their work as a flat 2D image in a standard format. (*.jpg, *.gif, *.ppm, *.tif, *.tga, *.pic, *.rgb, etc.)
3.1-A.5 The menu should allow users to load basic objects (a particular geometry) as their starting primitive
3.1-A.5.1 Loadable primitives must include a Sphere, and should also include a Cone, Cube, or Cylinder
3.1-A.5.2 Loadable primitives shall be geometrically modeled and haptic interaction must be geometrically based as a subdivision surface model
3.1-A.5.3 Loadable primitives should be physically modeled
3.2-B Editing Tools: The software shall provide users with options to edit the model.
3.2-B.1 The menu shall be equipped with a choice of stylus or brush or morphing tool that looks like painting apparatus
3.2-B.2 Should 3D tools or brushes be used, each should be represented as a virtual object to indicate the function the user wishes to use.
3.2-B.2.1 Each object in should be selectable at the users discretion
3.2-B.3 Should iconic menus be used, each function should be represented by a haptic button. The icon should also graphically represent the particular brush stroke or modeling function to be invoked upon the geometric solid.
3.2-B.4 The brush/stylus should be controlled by the user with the Phantom Force- feedback Tracker Device
3.2-B.5 Brush/Stylus-to-Model interaction must be haptic, although not necessarily physically modeled given the modeled object's geometric constraints.
3.3-C Painting Options: The user's painting experience should have the conveniences of electronic art software and standard painting packages, only enhanced to suit the needs of inTouch modeling.
3.3-C.1 Users shall be able to use the following functions to edit their models
3.3-C.1.1 Choose a color
3.3-C.1.2 Warp (Denting, Stretching, Adding Bumps, Flatten)
3.3-C.1.3 Translate
3.3-C.1.4 Rotate
3.3-C.1.4 Undo
3.3-C.2 Users should also be able to do the following:
3.3-C.2.1 Erase
3.3-C.2.2 Choose an editing stylus (Brush, pen, etc.)
3.3-C.2.3 Paint Bucket (immerse object as a single color)
3.3-C.2.4 Type/Imprint Text
3.3-C.2.5 Zoom
3.3-C.3 Users should be able to use texture to paint the model. Accordingly, the following functions should be provided.
3.3-C.3.1 Choosing a texture from a built-in texture library.
3.3-C.3.2 Importing textures from existing files
(*.jpg, *.gif, *.ppm, *.tif, *.tga, *.pic, *.rgb, etc.)
3.3-C.3.3 Choose how to apply the texture
3.3-C.3.3.1 Control the area to apply a texture
3.3-C.3.3.2 Control the direction of the texture
3.3-C.3.3.3 Magnify the texture
3.3-C.3.3.4 Minify the texture
3. 3-C.4 Users shall be able to re-paint the model. Users should be able to
choose the following options.
3.3-C.4.1 Replace existing colors with new ones
3.3-C.4.2 Control the ratio between new colors and previous colors
to give the effect of blending paint colors on the model.
3.4-D Modeling Options: The user shall be able to deform the model.
3.4-D.1 Users should be able to transform the widget in screen space and move it around to suit modeling needs (e.g. if the widget occludes the modeling view port).
3.4-D.2 Users should be able to hide the widget as an event-controlled response
3.4-D.2.1 Event controls should include double click-button down, or a short-cut command from the keyboard (i.e. Ctrl-H)
3.4-D.3 Users shall be able to push and pull with a stylus to deform the
model.
3.4-D.4 Users shall be able to choose the size of stylus
3.4-D.5 Users should be able to specify the area to be affected by the
deformation
3.4-D.6 Users should be able to control the viscosity of the model
3.4-D.7 Users should be able to specify whether to preserve the volume of
the model
3.4-D.8 Users should be able to reshape the model by denting, stretching,
flattening, or adding bumps.
System User
3.5 System Programmer Section
3.5.1 The system should provide a frame rate higher than the 5fps on which the inTouch currently runs
3.5.2 The system should consider following features for deformation of
the model.
3.5.2.1 The direction and magnitude of the force.
3.5.2.2 Size of the stylus.
3.5.2.2 Viscosity of the model.
3.5.2.3 Volume of the model.
3.5.2.4 Area upon which to impose a deformation.
4. Hardware and Software Resource Requirements
4.1 InTouch requires the following resources:
4.1.1 A six-degree-of-freedom (6-DOF) input device with at least 3-DOF haptic feedback.
4.1.2 A computer, or combination of tightly coupled computers, sufficient to interface between the display device and the input device.
4.1.3 A display device capable of displaying in stereo, if desired.
5. Validation and Verification
5.1 Strategy
5.1.1 General plans:
Each component of the UI will be tested based upon its independent set of requirements before integration into TouchUI. These tests shall be referred to as a "Component Test." After each function of the UI passes a component test, it will be integrated into TouchUI. Next, inTouch will be tested with these changes. The modularity of the code and independence of each component should allow for integration into the entire system upon completion. User experiments shall follow after every component is successfully integrated.
5.1.2 Requirements: Followings are requirements for each component.
5.1.2.1 Menu: when the user selects a button, the system shall provide visual feedback. Selection should also provide haptic feedback.
The appearance of the tool should be changed upon selection
5.1.2.2 Modeling features:
Modeling functions shall deform the model as described in 3.4-D.
Modeling functions should not freeze the system.
5.1.2.3 Stereo and head tracking:
The system shall generate stereoptic images.
The images should be updated to reflect the changes in position of the user. Perspective distortion should be eliminated from all positions of the user.
The system should be able to switch between mono and stereo.
5.1.2.4 Shadow: The shadow of the tool should project onto the model.
5.2 Test Cases
5.2.1 Test case A: Various phantom positions
5.2.1.1 Menu shall remain unchanged if the phantom is below or above buttons. It shall give feedback only if the phantom is within a certain distance from buttons.
5.2.1.2 The shadow of the stylus should project onto the model.
The direction of the shadow should be appropriate with respect to the users viewing direction and the light direction.
5.2.2 Test case B: Menu test
5.2.2.1 Modeling or painting options shall be toggled on upon selection by the user. The selection shall be indicated by change of color, appearing beveled or embossed, and shall toggle the appropriate modeling function for painting and deforming the model.
5.2.2.2 Submenus shall appear if necessary.
5.2.3 Test case C: Serious deformation
5.2.3.1 Should users attempt to extremely deform the model, the action shall not show any significant delay in frame-rate. Furthermore, the system should not crash.
5.2.4 Test case D: Invalid area of deformation
5.2.4.1 Attempt to deform the model outside of the area specified for deformation.
5.2.5 Test case E: Head Tracking stability
5.2.5.1 Head Tracked Stereo shall work reasonably all the time considering the hardware constraints. Projections of the scene show move smoothly and without significant latency.
5.2.6 Test case F: User Experiment
5.2.6.1 Users should be able to use the system without any help so as to verify the intuitiveness of TouchUI.
Note: Test cases enumerated above are not in chronological order. Each case except test case F will be tested when corresponding components are completed. User Experiment (Test case f) will take place when entire system is completed.
6. Preliminary Schedule (Task Budgeting)
Development Items
6.1 Major phases
6.1.1 Phase I: Rework current implemented code ("Scott's code") into a running UI application. New features: ridge tool button, undo button redesign, stereo, shaded buttons for toggling selections, appearance of tools.
6.1.2 Phase II: Add new features to inTouch: Head tracking, explicit choice of deformation area.
6.1.3 Phase III: Accelerate rendering and add shadows
6.2 Tasks and dependencies
6.2.1 Understand the current system architecture. (How to integrate TUI with inTouch)
6.2.2 Achieve runnable copy of Scott's code
(Dependencies: 5.2.1)
6.2.3 Button Work