Software hardware environments

Its main job is to allow communication between the different parts of a computer. The UI is what allows us to communicate with a computer by showing us information and giving us things to click. If we want to go on the Internet then by clicking on the Internet Explorer icon the OS will load the browser for us and show it on screen.

When you click inside the Internet Explorer window the OS tells the program, allowing it to then calculate what it should do next. When the program makes changes it then asks the OS to show these changes on the screen. This is introduced very simply at KS1 level through a series of tasks that will have your child perform basic functions on the computer, such as loading programs and using menus. At KS2 this learning will be taken further and the concept of the OS being a translator will be introduced more thoroughly.

An example of an OS learning activity at KS2 would be to have students stand up at the front of the class and be given a role. For example, one student could draw a picture, one student could provide pieces of paper, one student could be a communicator and one student could be a middleman for the other three.

They communicate with all the other members of the team components of the computer and deal with all requests and communication. In a computer they could be the mouse, receiving a request to start drawing on the screen.

In a computer this could be the screen. When the middleman asks whether there is paper available this could be the OS checking that there is nothing else on screen. This handles the input from the user and produces an output to the screen. Year 1 The basic parts of a computer are introduced and a definition of software is given.

Year 2 The difference between input and output devices are learned and the OS is explained graphically. Year 4 Processing devices will be linked to using the OS and students will learn about how parts of the computer communicate. First, by moving the user over significant distances, problems in orientation could result.

Next, moving objects quickly over great distances can be difficult moving an object from Los Angeles to New York would require that the user fly this distance or that the user have a point-and-click, put-me-there interface with a global map.

Finally, moving close to an object can destroy the spatial context in which that move operation is taking place. The second and third solutions are completely equivalent except when other participants or spectators are also in the environment. Perhaps the most basic interaction technique in any application is object selection.

Object selection can be implicit, as happens with many direct manipulation techniques on the desktop e. It is interesting to note that most two-dimensional user interface designers use the phrase "highlight the selected object," to mean "draw a marker, such as selection handles" on the selected object.

With VE systems, we have the ability to literally highlight the selected object. Most examples thus far have used three-dimensional extensions of two-dimensional highlighting techniques, rather than simply doing what the term implies; applying special lighting to the selected object. The following list offers some potentially useful selection techniques for use in three-dimensional computer-generated environments:. Pointing and ray casting. This allows selection of objects in clear view, but not those inside or behind other objects.

This is analogous to "swipe select" in traditional GUIs. Selections can be made on the picture plane with a rectangle or in an arbitrary space with a volume by "lassoing. Carrying this idea over to three dimensions requires a three-dimensional input device and perhaps a volume selector instead of a two-dimensional lasso.

Voice input for selection techniques is particularly important in three-dimensional environments. The question of how to manage naming is extremely important and difficult.

It forms a subset of the more general problem of naming objects by generalized attributes. Naming attributes.

Specifying a selection set by a common attribute or set of attributes "all red chairs with arms" is a technique that should be exploited. Since some attributes are spatial in nature, it is easy to see how these might be specified with a gesture as well as with voice, offering a fluid and powerful multimodal selection technique: all red chairs, shorter than this [user gestures with two hands] in that room [user looks over shoulder into adjoining room].

For more complex attribute specification, one can imagine attribute editors and sophisticated three-dimensional widgets for specifying attribute values and ranges for the selection set. Selection by example is another possibility: "select all of these [grabbing a chair]. It is important to provide the user with an opportunity to express "but not that one" as a qualification in any selection task. Of course, excluding objects is itself a selection task.

An important aspect of the selection process is the provision of feedback to the user confirming the action that has been taken. This is a more difficult problem in three dimensions, where we are faced with the graphic arts question of how to depict a selected object so that it appears unambiguously selected from an arbitrary viewing angle, under any lighting circumstances, regardless of the rendering of the object.

Another issue is that of extending the software to deal with two-handed input. Although manipulations with two hands are most natural for many tasks, adding a second pointing device into the programming loop significantly complicates the programmer's model of interaction and object behavior and so has been rarely seen in two-dimensional systems other than research prototypes.

In three-dimensional immersive environments, however, two-handed input becomes even more important, as. If an interface is poorly designed, it can lull the user into thinking that options are available when in fact they are not. For example, current immersive three-dimensional systems often depict models of human hands in the scene when the user's hands are being tracked.

Given the many kinds of actions that human hands are capable of, depicting human hands at all times might suggest to users that they are free to perform any action they wish—yet many of these actions may exceed the capabilities of the current system. One solution to this problem is to limit the operations that are possible with bare hands, specifying for more sophisticated operations the use of tools. A thoughtful design would depict tools that suggest their purpose, so that, like a carpenter with a toolbox, the user has an array of virtual tools with physical attributes that suggest certain uses.

Cutting tools might look like saws or knives, while attachment tools might look like staplers. This paradigm melds together issues of modality with voice, context, and command.

Interaction techniques and dialogue design have been extremely important research foci in the development of effective two-dimensional interfaces.

Until recently, the VE community has been occupied with getting any input to work, but it is now maturing to the point that finding common techniques across applications is appropriate. These common techniques are points of leverage: by encapsulating them in reusable software components, we can hope to build VE tools similar to the widget, icon, mouse, pointer WIMP application builders that are now widely in use for two-dimensional interfaces.

It should also be noted that the progress made in three-dimensional systems should feedback into two-dimensional systems. Visual scene navigation software provides the means for moving the user through the three-dimensional virtual world. There are many component parts to this software, including control device gesture interpretation gesture message from the input subsystem to movement processing , virtual camera viewpoint and view volume control, and hierarchical data structures for polygon flow minimization to the graphics pipeline.

In navigation, all act together in real time to produce the next frame in a continuous series of frames of coherent motion through the virtual world. The sections below provide a survey of currently developed navigation software and a discussion of special hierarchical data structures for polygon flow. Navigation is the problem of controlling the point and direction of view in the VE Robinett and Holoway, Using conventional computer graphics techniques, navigation can be reduced to the problem of determining a position and orientation transformation matrix in homogeneous graphics coordinates for the rendering of an object.

This transformation matrix can be usefully decomposed into the transformation due to the user's head motion and the transformation due to motions over long distance travel in a virtual vehicle.

There may also be several virtual vehicles concatenated together. The first layer of virtual world navigation is the most specific: the individual's viewpoint.

One locally controls one's position and direction of view via a head tracking device, which provides the computer with the position and orientation of the user's head. The next layer of navigation uses the metaphor of a virtual vehicle, which allows movement over distances in the VE greater than those distances allowed by the head-tracker alone.

The position and orientation of the virtual vehicle can be controlled in a variety of ways. In simulation applications, the vehicle is controlled in the same way that an actual simulated vehicle would be controlled. Examples that have been implemented are treadmills and bicycles and joysticks for flight or vehicle simulators. For more abstract applications, there have been several experimental approaches to controlling the vehicle. The most common is the point and fly technique, wherein the vehicle is controlled via a direct manipulation interface.

The user points a three-dimensional position and orientation tracker in the desired direction of flight and commands the environment to fly the user vehicle in that direction.

Other methods of controlling the vehicle are based on the observation that in VE one need not get from here to there through the intervening space.

Teleoperation is one obvious example, which often has the user specify a desired destination and then "teleports" the user there. Solutions have included portals that have fixed entry and exit locations, explicit specification of destination through numerical or label input, and the use of small three-dimensional maps of the environment to point at the desired destination.

Another method of controlling the vehicle is dynamic scaling, wherein the entire environment is scaled down so that the user can reach the desired destination, and then scaled up again around the destination indicated by the user.

All of these methods have disadvantages, including difficulty of control and orientation problems. There is a hierarchy of objects in the VE that may behave differently during navigation. Some objects are fixed in the environment and are acted on by both the user and the vehicle. Other objects, usually virtual. Still other objects, such as data displays, are always desired within the user's field of view and are not acted on by either the user or the vehicle.

These objects have been called variously world stable, vehicle stable , and head stable Fisher et al. Although most of the fundamental mathematics of navigation software are known, experimentation remains to be done. Hierarchical data structures for the minimization of polygon flow to the graphics pipeline are the back end of visual scene navigation. When we have generated a matrix representing the chosen view, we then need to send the scene description transformed by that matrix to the visual display.

One key method to get the visual scene updated in real time at interactive update rates is to minimize the total number of polygons sent to the graphics pipeline. Hierarchical data structures for polygon flow minimization are probably the least well understood aspect of graphics development. This is a very common misconception. Visual reality has been said to consist of 80 million polygons per picture Catmull et al.

The alternatives are to live with worlds of reduced complexity or to off-load some of the graphics work done in the pipeline onto the multiple CPUs of workstations. All polygon reduction must be accomplished in less time than it takes just to send the polygons through the pipeline.

The difficulty of polygon flow minimization depends on the composition of the virtual world. This problem has historically been approached on an application-specific basis, and there is as yet no general solution. Current solutions usually involve partitioning the polygon-defined world into volumes that can readily be checked for visibility by the virtual world.

There are many partitioning schemes—some of which work only if the world description does not change dynamically Airey et al. A second component of the polygon flow minimization effort is the pixel coverage of the object modeled. Once an object has been determined to be in view, the secondary question is how many pixels that object will cover. If the number of pixels covered by an object is small, then a reduced polygon count low-resolution version of that object can be rendered.

This results in additional software complexity, again software that must run in real time. Because the level-of-detail models are precomputed, the issue is greater dataset size rather than level selection which is nearly trivial. The current speed of z-buffers alone means we must carefully limit the polygons sent through the graphics pipeline. Other techniques that use the CPUs to minimize polygon flow to the pipeline are known for specific applications, but those techniques do not solve the problem in general.

In a classic paper, Clark presents a general approach for solving the polygon flow minimization problem by stressing the construction of a hierarchical data structure for the virtual world Figure The approach is to envision a world database for which a bounding volume is known for each drawn object.

The bounding volumes are organized hierarchically, in a tree that is used to rapidly discard large numbers of polygons. This is accomplished by testing the bounding volumes to determine whether they are contained or partially contained in the current orientation of the view volume. The process continues recursively until a node is reached for which nothing underneath it is in the view volume.

This part of the Clark paper provides a good start for anyone building a three-dimensional VE for which the total number of polygons is significantly larger than the hardware is capable of drawing. The second part of Clark's paper deals with the actual display of the polygons in the leaf nodes of the tree. The idea is to send only minimal descriptions of objects through the graphics pipeline minimal based on the expected final pixel coverage of the object.

In this approach, there will be multiple-resolution versions of each three-dimensional object and software for rapidly determining which resolution to draw.

The assumption of multiple-resolution versions of each three-dimensional object being available is a large one, with automatic methods for their generation remaining an open issue. Other discussions of this issue are found in DeHaemer and Zyda , Schroeder et al. Polygon flow minimization to the graphics pipeline is best understood by looking at specific solutions. Some of the more interesting work has been done by Brooks at the University of North Carolina at Chapel Hill with respect to architectural walkthrough Brooks, ; Airey et al.

The goal in those systems was to provide an interactive walkthrough capability for a planned new computer science building at the university that would offer visualization of the internal spaces of that building for the consideration of changes before construction. The walkthrough system had some basic tenets. The first was that the architectural model would be constructed by an architect and passed on to the walkthrough phase in a fixed form.

A display compiler would then be run on that database and a set of hierarchical data structures would be output to a file. The idea behind the display compiler was that the building model was fixed and that it was acceptable to spend some 45 minutes in computing a set of hierarchical data structures.

Once the data structures were computed, a display loop could then be entered, in which the viewpoint could be rapidly changed. The walkthrough system was rather successful, but it has the limitation that the world cannot be changed without rerunning the display compiler. Other walkthrough systems have similar limitations Teller and Sequin, ; Funkhouser et al. Real-time display of three-dimensional terrain is a well-researched area that originated in flight simulation.

Terrain displays are an interesting special case of the polygon flow minimization problem in that they are relatively well worked out and documented in the open literature Zyda et al. The basic idea is to take the terrain grid and generate a quadtree structure containing the terrain at various display resolutions.

The notion of the grid cell is used for reducing polygon flow by drawing. This strategy works well for ground-based visual displays; a more comprehensive algorithm is required for air views of such displays. Models that define the form, behavior, and appearance of objects are the core of any VE. A host of modeling problems are therefore central to the development of VE technology. An important technological challenge of multimodal VEs is to design and develop object representation, simulation, and rendering RSR techniques that support visual, haptic, and auditory interactions with the VE in real time.

There are two major approaches to the RSR process. First, a unified central representation may be employed that captures all the geometric, surface, and physical properties needed for physical simulation and rendering purposes. In principle, methods such as finite element modeling could be used as the basis for representing these properties and for physical simulation and rendering purposes. At the other extreme, separate, spatially and temporally coupled representations could be maintained that represent only those properties of an object relevant for simulating and rendering interactions in a single modality e.

The former approach is architecturally the most elegant and avoids issues of maintaining proper spatial and temporal correlation between the RSR processes for each modality. Practically, however, the latter approach may allow better matching between modality-specific representation, simulation, and rendering streams.

The abilities and limitations of the human user and the VE system for each of the modalities impose unique spatial e. For example, it is likely that the level of detail and consequently the nature of approximations in the RSR process will be different for each of the modalities. It is unclear, therefore, whether these modality-specific constraints can be met by systems based on a single essential or core representation and still operate in real time.

The overwhelming majority of VE-relevant RSR research and development to date has been on systems that are visually rendered e. The theoretical and practical issues associated with either of the two RSR approaches or variants in a multimodal context, however, have received minimal attention but are likely to become a major concern for VE system researchers and developers.

For example, geometric modeling is relevant to the generation of acoustic environments i. Novel applications such as the use of auditory displays for the understanding of scientific data e. In this section, we concentrate on the visual domain and examine the problems of constructing geometric models, the prospects for vision-based acquisition of real-world models, dynamic model matching for augmented reality, the simulation of basic physical behavior, and simulation of autonomous agents.

Parallel issues are involved in the other modalities and are discussed in Chapters 3 and 4. The need to build detailed three-dimensional geometric models arises in computer-aided design CAD , in mainstream computer graphics, and in various other fields. Geometric modeling is an active area of academic and industrial research in its own right, and a wide range of commercial modeling systems is available. Despite the wealth of available tools, modeling is generally regarded as an onerous task.

Among the many factors contributing to this perception are sluggish performance, awkward user interfaces, inflexibility, and the low level at which models must typically be specified. It is symptomatic of these difficulties that most leading academic labs, and many commercial animation houses such as Pixar and PDI , prefer to use in-house tools, or in some cases a patchwork of homegrown and commercial products.

From the standpoint of VE construction, geometric modeling is a vital enabling technology whose limitations may impede progress. As a practical matter, the VE research community will benefit from a shared open modeling environment, a modeling environment that includes physics. In order to understand this, we need to look at how three-dimensional geometric models are currently acquired. We do this by looking at how several VE efforts have reported their model acquisition process.

If one reads the work done for the walkthrough project at the University of North Carolina Airey et al. In the presentation of that paper, one of the problems discussed was that of ''getting the required data out of a CAD program written for other purposes. In particular, data related to the actual physics of the building were not present, and partitioning information useful to the real-time.

RB2 is a software development platform for designing and implementing real-time VEs. Development under RB2 is rapid and interactive, with behavior constraints and interactions that can be edited in real time.

RB2 has a considerable following in organizations that do not have sufficient resources to develop their own in-house VE expertise. RB2 is a turnkey system, whose geometric and physics file formats are proprietary. As a result, project researchers have developed an open format for storing these three-dimensional models Zyda et al.

Computer-aided design systems with retrofitted physics are beginning to be developed e. Many applications call for VEs that are replicas of real ones.

Rather than building such models by hand, it is advantageous to use visual or other sensors to acquire them automatically. Automatic acquisition of complex environment models such as factory environments is currently not practical but is a timely research issue.

Meanwhile, automatic or nearly automatic acquisition of geometric models is practical now in some cases, and partially automated interactive acquisition should be feasible in the near term Ohya et al. The most promising short-term approaches involve active sensing techniques. Scanning laser finders and light-stripe methods are both capable of producing range images that encode position and shape of surfaces that are visible from the point of measurement.

These active techniques offer the strong advantage that three-dimensional measurements may be made directly, without the indirect inferences that passively acquired images require.

Active techniques do, however, suffer from some. Surfaces that are nonreflective or obliquely viewed shiny surfaces may not return enough light to allow range measurements to be made. Noise is enough of a problem that data must generally be cleaned up by hand. A more basic problem is that a single range image contains information only about surfaces that were visible from a particular viewpoint.

To build a complete map of an environment, many such views may be required, and the problem of combining them into a coherent whole is still unsolved.

Among passive techniques, stereoscopic and motion-based methods, relying on images taken from varying viewpoints, are currently most practical. However, unlike active sensing methods, these rely on point-to-point matching of images in order to recover distance by triangulation. Many stereo algorithms have been developed, but none is yet robust enough to compete with active methods.

Methods that rely on information gleaned from static monocular views—edges, shading, texture, etc. For many purposes, far more is required of an environment model than just a map of objects' surface geometry.

If the user is to interact with the environment by picking things up and manipulating them, information about objects' structure, composition, attachment to other objects, and behavior is also needed. Unfortunately, current vision techniques do not even begin to address these deeper issues. The term augmented reality has come to refer to the use of transparent head-mounted displays that superimpose synthetic elements on a view of the real surroundings.

Unlike conventional heads-up displays in which the added elements bear no direct relation to the background, the synthetic objects in augmented reality are supposed to appear as part of the real environment. That is, as nearly as possible, they should interact with the observer and with real objects, as if they too were real. At one extreme, creating a full augmented-reality illusion requires a complete model of the real environment as well as the synthetic elements.

For instance, to place a synthetic object on a real table and make it appear to stay on the table as the observer moves through the environment, we would need to know just where the table sits in space and how the observer is moving. For full realism, enough information about scene illumination and surface properties to cast synthetic shadows onto real objects would be needed.

Furthermore, we would need enough information about three-dimensional scene structure to allow real objects to hide or be hidden by synthetic ones, as appropriate. Naturally, all of this would. This sort of mix of the real and synthetic has already been achieved in motion picture special effects, most notably, Industrial Light and Magic's effects in films such as The Abyss and Terminator 2. Some of these effects were produced by rendering three-dimensional models and creating a composite of the resulting images with live-action frames, as would be required in augmented reality.

However, the process was extremely slow and laborious, requiring manual intervention at every step. After scenes were shot, models of camera and object motions were extracted manually, using frame-by-frame manual measurement along with considerable trial and error. Each environment has its own unique purpose. Different organisations all have their own purposes and policies which dictate when and how each environment is used.

The development environment is used to build your application. This is where developers complete the majority of their work. Typically, the development environment is set up on local computers, and work is facilitated by a Git repository. Users and customers cannot access anything done in the development environment unless you show them.

The beta environment is used to test your application. Before your team releases from development to beta, they will usually copy what is currently on your production environment down to beta. Sample 1. Production Environment means a logical group of virtual or physical computers comprised within the Cloud Environment to which the Customer will be provided with access and use the purchased Cloud Application s in production and for its generally marketed purpose.

Hostile environment means a situation in which bullying among students is sufficiently severe or pervasive to alter the conditions of the school climate;. Operating Environment means, collectively, the platform, environment and conditions on, in or under which the Software is intended to be installed and operate, as set forth in the Statement of Work, including such structural, functional and other features, conditions and components as hardware, operating software and system architecture and configuration.

Environment means indoor air, ambient air, surface water, groundwater, drinking water, land surface, subsurface strata, and natural resources such as wetlands, flora and fauna. Least restrictive environment LRE means that to the maximum extent appropriate, children with disabilities, including children in public or private institutions or other care facilities, are educated with children who are not disabled, and that special classes, separate schooling or other removal of children with disabilities from the regular educational environment occurs only when the nature or severity of the disability is such that education in regular classes with the use of supplementary aids and services cannot be achieved satisfactorily.