Abstract

Many useful applications in the field of virtual environments can be classed as static with a mobile observer; i.e. many images being generated of the same environment while an observer moves in position and orientation. Examples of such environments are: pilots in a simulator practising different landings at the same airport; an architect walking through and previewing a building before its construction; and a tank driver battling across an artificial rugged terrain to gain experience in a war scenarios. In such applications, great advantage can be taken of the static nature of the scene and many of the necessary calculations can be moved to the pre-processing stage. Using a hierarchical a priori structure--the Binary Space Partitioning tree--run-time requirements can be minimized significantly giving a vast head-start in the quest for real-time simulations.
In this project, we examine the BSP tree for removal of hidden surfaces. Depending on the users viewing point, the visible faces to the user of the object will be determined using the information present in BSP tree. The BSP tree has nodes which represents front and back polygons depending on the reference polygon (root polygon). We begin with some of the predetermined objects. Purpose

The main purpose of this document is to describe the requirements of a system which demonstrates the hidden surface removal algorithm using Binary Space Partitioning tree. This document also describes the possible output of the system, which is a static group of 3D polygons as seen from an arbitrary viewpoint. Scope This document deals with the implementation of hidden surface removal algorithm only and not the other algorithms such as solid modeling algorithm, shadow algorithm (multiple light sources) ,radiosity etc. which can also be implemented using BSP trees Definitions, Acronyms, Abbreviations BSP tree Binary Space Partitioning tree References

Binary Space Partioning Trees and Polygon Removal in Real Time 3D Rendering -Samuel Ranta-Eskola Computer Graphics , Principles and Practice James D Foley http://en.wikipedia.org
Requirements input and output requirements input1: the system will take the position of the view point from the user output1:it will generate the 3D object containing only visible lines and surfaces . Functional Requirements Determine the visible surfaces and lines from a given viewpoint and display them input:input1 output:output1 External Interface Requirements User Interface:we use the user interface of TurboC++ IDE Performance Constraints the time taken to display the object increases as the no. of lines in the original object increases and this must be taken into account

Design Constraints Hardware Constraints Any hardware that supports windows XP Software Constraints -Windows XP -TurboC++ Compiler or BorlandC Compiler Acceptance Criteria Before accepting the system, the developer must demonstrate that the system works for different type of solids
System Design Architecture Design Overview

System Overview The system performing hidden surface removal using BSP tree takes the coordinates of view point as input and displays the visible surfaces and lines accordingly. the user can specify different viewpoints and the system displays the corresponding lines and surfaces.

System Context The system context is clearly defined in the SRS. Basically, the user is the main source of information (who provide information about the view point . The object will be predefined of which different projections will be generated. Stakeholders of the Process Scheduling System The main stakeholder and his concerns are: Designer: The designer should have the complete idea of how he is implementing the hidden surface removal. He should be given highest priority that means he should be allowed to change the way of implementation i.e, sometimes it may be required that for complex objects such as a teapot , it is necessary to select a polygon as a root which can generate a balanced tree. Naive user: The user must have the basic knowledge and idea of how the projections will look from different viewpoints. The user should input values
which are correct and feasible. For instance any coordinate out of the 640X480 range is not valid. Such an input may lead to out of bound errors.

Scope This document describes the proposed architecture for the hidden surface removal using BSP tree. For architecture we consider only the component and connector view. Definitions and Acronyms As given in the SRS.

Architecture Design

As this is a batch processing system, the most natural style will be pipe and filter style. We use this style for the architecture of the system. This architecture has three filter components- one to input the view point information from the user , second filter checks the validity of the input. If any errors are detected , then user will be prompted for input again . The third filter displays the object as per the viewpoint with the help of the BSP which contains information about the object to be displayed.

Evaluating the Architecture Criteria Evaluation of the proposed Architecture Complex objects ( objects containing large number of surfaces and lines) Average as the number of lines increases time taken to generate the tree and hence the time to display the tree increases . However this can be countered to some extent by adding a function which can generate a balanced tree Good this can can accomplished satisfactorily by the above architecture Poor - The architecture is not designed with security in mind . All naive users can use the program.

Multiple objects

Provision of additional Securities(passwords, etc) )

Design DFD of the system The DFD of the system which describes the various inputs and outputs and the flow of data in the system is showm in the figures 1,2,3.The DFD gives an overall idea of how the system processes the data and satisfies the various constraints. Design Specifications We first specify these modules precisely, and then we analyse them using the information flow complexity metrics. Based on this analysis, the initial design is modified. Here we specify the interface of each of the functions precisely in the final design of the system.