DE19549870B4 - Creating representation of scene for display on graphical output - invoking object drawing sub-system with identification of object stored in memory, and identification of renderer for use in drawing object into scene - Google Patents

Abstract

The method for creating a representation of a scene for display on a graphical output device involves storing in memory a representation of an object, and invoking an object drawing sub-system with an identification of the object and an identification of a renderer to use for drawing the object. The object drawing sub-system uses the identified renderer to render the identified object into the scene. The object includes at least one sub-object, and the object drawing sub-system uses the identified renderer to draw each of the sub-objects into the scene for output to the graphical output device.

Description

Limited anther protection waiver

One Part of the disclosure of this patent contains material to which claim is raised to copyright protection. The copyright owner has no objections to the facsimile reproduction of the patent specification or the patent disclosure, as in the files or records the US Patent and Trademark Office appears, by any person, reserves but otherwise all other rights.

BACKGROUND

1. Field of the invention

The This invention relates to graphics processing systems and more particularly on software tools to assist graphics application developers.

2. Description of the Related Art

graphics rendering is the process of Calculation of a two-dimensional image (or part of an image) from three-dimensional geometric shapes. An object is here considered as three-dimensional, if its points by at least each three coordinates are specified (regardless of whether the object has a thickness in all three dimensions or not). A dresser is a tool that deploys graphics rendering operations supplied Performs requests. Some preparers are only software, others are exclusively Hardware and some are done using both (e.g. Software with hardware support acceleration). Hand over conditioner typically scenes in a buffer that follow the graphics output device is read, but it is in some Preparers possible, overwrite its two-dimensional output directly to the output device. A graphics rendering system (or subsystem) as used herein is, refers to all levels of processing between one Application program and a graphics output device. In many known systems, the graphics editing system is the same content with the dresser; that is, the Conditioner is directly through the application program without intermediate Processing layers called.

Graphics rendering systems typically have a direct command interface or a maintenance interface for the Application program. A real-time interface is a true process interface, in which the application program of each geometric element for the graphics rendering system every time specified when the image is to be processed. The processing system entertains no model database from scene to scene, even if the application program could do this. Real-time interfaces are highly attractive for editing scenes where the model changes with each frame, such as the Presentation of simulations, for previewing animation sequences or to read a series of models from a document. on the other hand requires a direct-command interface that handles the entire scene via process requirements at each frame is transmitted to the conditioner, resulting in a high data bandwidth between the application program and the conditioner leads. Also, the document format is for a model often a stream of drawing commands instead of the model itself, indicating its usefulness limited as a data exchange format. Real-time interfaces are also less conducive to creation a toolset replicating functionality of the application program, and they close usually a user interface toolset that objects in the Scene edited.

In a maintenance operating system, sometimes called a display list system, the graphics rendering system maintains a database representation of the three-dimensional model. At each frame, the rendering system crosses and records the database of the maintained model. This can be triggered by the application program by a single command to the graphics rendering system instead of a stream of paint commands describing the entire scene. As the model changes, the application program edits or updates the model database and again prompts the reconditioning system to render the scene. The advantage of a maintenance operating system include the reduced bandwidth between the application program and each hardware accelerator. The document format of the model database can also be easily used as a data exchange format since it is not just a list of processing instructions. The existence of an object database also provides an additional way to execute a user interface toolset and a functionality replica. Maintenance dressers can also recycle Information Buffers and can buffer information for optimizing a scene traversal. On the other hand, maintenance rendering systems have a greater overhead for editing the scene database, and they limit application programming by forcing the scene into a system-defined data structure, usually a hierarchy, so that many application programs are required to obtain a duplicate copy of the model in its own format ,

In the essay by Mark A. Tarlton and P. Nong Tarlton "A Framework for Dynamic Visual Applications, "Proceedings of the 1992 Symposium to Interactive 3D Graphics, Cambridge, MA, 1992, pp. 161-164, what incorporated herein by reference in the specification is a Maintenance processing system described, the an Alzweckdatenbanksystem executing, to organize the model instead of forcing the model into a single system hierarchy. Such a technique Trying to take advantage of the maintenance system without the disadvantages offer.

One However, such a high level scheme can not solve the model organization problem for all Solve applications and is not optimal for Visualization applications where the scene changes with each frame.

conventional Graphics rendering systems have several additional issues that affect their usefulness limit in one way or another. The following list describes some of the graphics rendering systems that are currently available.

GL ^TM : GL from Silicon Graphics is a real-time renderer used primarily for interactive graphics. GL is described in "Graphics Library Programming Guide", Silicon Graphics Computer Systems, 1991, incorporated herein by reference. Designed to interface with Silicon Graphics' IRIS rendering hardware, it offers no document format, no printer output, no modeling capability, or user interface tools. GL maintains simple display lists, which are essentially macros for a sequence of GL commands. The GL routines perform rendering operations by issuing commands to the IRIS hardware.

StarBase ^TM : StarBase from Hwelett-Packard's is a real-time system that is very similar to GL, sharing most of its features and disadvantages. StarBase is described in "Starbase Graphics Techniques", by Hewlett-Packard Company, 1991, incorporated herein by reference. For StarBase, numerous device drivers are available for outputting the rendered (that is, two-dimensional) scenes to different graphics output devices, ranging from plotters to highly complex 3-D graphics workstations.

RenderMan ^TM : RenderMan by Pixar is a real-time system designed primarily to support high-quality rendering. RenderMan is described in Steve Upstill, "The RenderMan Companion", Addison-Wesley, Reading, MA, 1990, incorporated herein by reference. As described in Tony Apodaca, "RenderMan Interface Specification Version 4.0 Beta," January 1992, incorporated herein by reference, newer versions of the RenderMan description provide new routines that bridge the existing RenderMan commands and allow the use of various renderers. The conditioner is specified with a single command prior to rendering the scene, and it affects the entire scene. See also Pixar: "Uick RenderMan Interface and Implementation Specification", 1992, incorporated herein by reference.

PHIGS: PHIGS is described in PHICS Committee, A. van Dam, chair, "PHIGS Functional Description, Revision 3.0 ", Computer Graphics, 22 (3), 1988, pages 125-218, which is hereby incorporated by reference is built in, and is a descendant from GKS-3D, described in International Standards Organization, "International Standard Information Processing Systems Computer Graphics - Graphical Kernel System for Three Dimensions (GKS-3D) Functional Description ", ISO Document No. 8805: 1988 (E), American National Standards Institute, New York, 1988, incorporated herein by reference. PHIGS was a committee-designed System for an interactive 3D graphics display. In PHIGS consists the entire Model database in a single hierarchy. application programmer have to a big Learn number editing and hierarchy manipulation commands to do this System to use effectively. PHIGS uses a single conditioner, which supports all edit types available in PHIGS are, and supported no alternative conditioner for Photorealism or other effects.

PEX: PEX is an attachment to the X-Windows system defined by a serial protocol (for transferring data between an application program and the X-Windows system) and a set of seman tic, which was originally derived from PHIGS. PEX has several available APIs, all of which maintain maintenance mode, real-time operation, and mixed mode function commands for drawing, changing states, and so on. PEX is described in "PEX Protocol Specification, Version 5.0PX Public Review Draft", September 14, 1990, Massachusetts Institute of Technology, incorporated herein by reference.

HOOPS ^™ : HOOPS by Ithaca Software is described by Garry Wiegand and Bob Covey, in "HOOPS Reference Manual, Version 3.0" Ithaca Software, 1991, incorporated herein by reference. It is a maintainer 3D graphics system that organizes the model into a hierarchy whose nodes are accessible through text strings, much in the same way as the documents in the UNIX document system are labeled. Like PHIGS, HOOPS supports a single conditioner. HOOPS, however, offers more extensive scene editing functionality than PHIGS.

DORÉ ^TM : DORÉ by Kubota is an example of a 3D graphics system with an object-related design. It is described in Dorè Programmer's Guide, Issue 5.0, Kubota Pacific Computer Inc., 1991, incorporated herein by reference. DORÈ has been designed so that scene data can be processed by many types of conditioners and not just by a single monolithic conditioner, as provided by PHIGS. However, conditioners can not be dynamically added to DORÈ because the rendering processes are built into the system. In DORÈ, the choice of conditioner is specified by entering the current preparation handle in the DORÈ "view object". DORÈ then causes the application program to attach the model to the view object before rendering. This restricts DORÈ to use only one conditioner at a time. There are other design considerations at DORÈ that also limit it to using only one conditioner at the same time; for example, there is only one set of global variables to maintain the rendering state.

DORÈ is one Maintenance operating system. To relieve a lot of the trouble which is associated with the editing of the model hierarchy and the dynamic databases and user interaction with dynamic To facilitate databases, DORÈ supports application callback objects, whereby an application program defines a function to call, if the callback object while the scene crossing is encountered.

Inventor ^TM : Inventor is an object-oriented 3D graphics user interaction tool set that sits on the GL graphics system. Like DORÈ, Inventor supports multiple renderers by having a conditioner-specific "rendering" method for each object type. Inventor is a maintenance operating system where the entire scene is in a "scene graph". Inventor has rendering objects that take a model as a parameter. The conditioner is selected by the rendering process used when drawing the model. The rendering process draws the entire model by traversing the model and invoking the appropriate rendering process for each object. The usual treatment process is the GL treatment plant. Inventor is described in Wernecke, "The Inventor Mentor", Addison-Wesley (1994), incorporated herein by reference.

Other publications essential to the present specification, all of which are incorporated herein by reference, are: Bergman, Fuchs and Grant, "Image Rendering by Adaptive Refinement", Computer Graphics, 20 (4), 1986, pages 29-37; Catmull, "Asubdivision Algorithm for Computer Display of Curved Surfaces", Ph.D. Thesis, Report UTEC-CSc-74-133, Computer Science Department, University of Utah, Salt Lake City, UT, December 1974; Chen, Rushmeier, Miller, and Turner, "A Progressive Multi-Pass Method for Global Illumination," Computer Graphics, 25 (4), 1991, pp. 165-174; Clark "The Geometry Engin: A VLSI Geometry System for Graphics", Computer Graphics, 16 (3), 1982, pages 127-133; Foley, van Dam, Feiner, and Hughes, "Computer Graphics: Principles and Practice," Addison-Wesley, Reading, MA, 1990; Haeberli and Akeley, "The Accumulation Buffer: Hardware Support for High-Quality Rendering", Computer Graphics, 24 (4), "A Scalable Hardware Render Accelerator using a Modified Scenline Algorithm", Computer Graphics, 26 (2), 1992, pages 241-248; Maillot, "Three Dimensional Homogeneous Clipping of Triangle Strips", Graphics Gems II, Academic Press, Inc., San Diego, CA, 1991, pp. 219-231; Newell, Newell, and Sancha, "A Solutation to the Hidden Surface Problem," Preceedings of the ACM National Conference, 1972, pp. 443-450; Potmesil and Hoffert, "FRAMES: Software Tools for Modeling, Rendering, and Animation of 3D Scences," Computer Graphics, 21 (4), 1987, pp. 85-93; Saito and Takahashi, "Comprehensible Rendering of 3-D Shapes", Computer Graphics, 24 (4), 1990, pages 197-206; Segal, Korobkin, van Widenfeld, Foran, and Haeberli, "Fast Shadows and Lighting Effects Using Texture Mapping," Computer Graphics, 26 (2), 1992, pp. 249-252; Sillion and Puech, "A General Two-Pass Method Integrating Specular and Diffuse Reflection", Computer Graphics, 23 (3), 1989, pp. 335-344; Snibbe, Herndon, Robbins, Conner and van Dam, "Using Deformations to Explore 3D Widget Design ", Computer Graphics, 26 (2), 1992, pp. 351-352; Strauss and Carey, "An Object-Oriented 3D Graphics Toolkit," Computer Graphics, 26 (2), 1992, pp. 341-349; Turkowski, "Design Considerations for an Object-Oriented [3D Graphics] Metafile," Proceedings of the Third Eurographics Workshop on Object-Oriented Graphics, Charnpery, Switzerland, October, 1992, pp. 163-169; Venolia, "Facile 3D Direct Manipulation", for publication in Proceedings of CHI '93, ACM / SIGCHI, Amsterdam, May, 1993; Venolia, "Automatic Alignment in Two and Three Dimensions", submitted to SIGGRAPH '93; and Wanger, "The Effect of Shadow Quality on the Preception of Spatial Relationships in Computer Generals Imagery," Proceedings of the 1992 Symposium on Interactive 3D Graphics, Cambridge, MA, 1992, page 3942.

In the patent US 5,181,162 A2 discloses a system for managing and creating documents, in which the documents are presented as a collection of logical components that can be combined and edited in the form of a page-organized layout. The components, also referred to as objects, contain texts, images, speech or graphic data. In addition, the components may also include data relating to appearance, relationship to other objects, or access restrictions. The system allows a viewer to view the contents and logical partitions of a publication, as well as thematically or otherwise, such as through the author or certain attributes, to collect related material. The patent further discloses management of the organization of the documents via logical and layout data structures by means of a database. A graphic rendering of a document for display on a graphics output device is not the subject of this patent.

The publication EP 0 534 446 A2 discloses a system for recognizing drawing objects that includes a method for approximating graphical objects and drawing objects, and for approximating positions on the approximated graphical object. The system enables you to capture the type, shape and exact position of a graphic in a drawing. This is also possible if the drawing contains superimposed graphics or the quality of the graphics has deteriorated due to frequent copying, which graphic may represent a line or a composite graphic. The disclosed system allows the separation of the captured graphics from the background as soon as a user indicates an approximately equal object or its approximate position. Other than the above systems is EP 0 534 446 not concerned with rendering objects for display on a graphics output device.

It is desirable to be able to model using a variety drawing different types of dresser. For example can be an application program that is an interactive editing of a allowed three-dimensional model, be beneficial by use a high speed wireframe conditioner low quality for drawing intermediate versions on a display and through Using a high-quality, slow Z buffer conditioner to draw the Final version on a printer. The interchangeability of conditioners however, is difficult at best using the above-described Treatment systems. In particular, some of the above processing systems support no more than a dresser, while those who do that, like for example DORÉ and Inventor, the chosen one Integrate conditioner into the system configuration. Accordingly There is a desire for a graphics editing system that is enhanced flexibility to use different conditioners for different purposes at the same time creates three-dimensional model.

One Another problem with the above treatment systems is that that she do not support more than one dresser who is active at the same time is. Simultaneous processing of a model is desirable in several situations, including simultaneous output an image to both a display device and a Printer. As another example, it is sometimes desirable to have two different views a model simultaneously on two different parts of the same To prepare display device. Simultaneous processing would be desirable mainly in real-time systems where an application program is an image by execution a sequence of commands to the rendering system. In such systems would be Many application programs are able to work more effectively in the commands for a preparer in the sequence for another conditioner be interspersed. earlier Systems excluded such interspersed command sequences.

Another problem with the above rendering systems is that those systems that supported more than one renderer required that all renderers support at least the same geometries. For example, the Inventor rendering system could only support preparers who were able to handle points, lines, and certain other predetermined shapes. Easier preparers could not be used with Inventor. More capable dressers could be used as long At least they support the full set of Inventor geometric primitives, but they could not be dynamically added. The application program had to be a priori informed about these conditioners. The above treatment systems did not allow "plug-in" processing of more or less capable processors with automatic detection and use of the conditioner features.

One Another problem with the above treatment systems is that that she Multithreading does not support well, especially not those the real-time and Unsupported mixed operating preparation. A multi-conditioner is one that is created that he several crossings a scene database requires. There are several reasons why a conditioner for several passes a scene database is designed. For example, not enough disk space be present to prepare the entire frame buffer, the with very high resolutions is processed. A conditioner can then insert the frame buffer into Strip parts and each strip over a separate pass through the scene database. As another example, if the image is passed to multiple devices, each with one other resolution (such as when a window overlaps two monitors or if an image is attached to both the screen and a high resolution printer is given), then the conditioner can each device in one hand over a separate pass. As another example, a conditioner, a progressive refinement executing, can several runs run the scene database, being continuously the final one Image is refined until the process by a user intervention is canceled or the image has the highest quality. Yet other examples include high quality rendering algorithms with use of bulk mail buffers, using a texture card to create of shading and lighting effects and with global lighting techniques in two passes.

In a maintenance operating system usually does not need the application program Know if the dresser requires more than one pass to complete the preparation. This is touching therefore, that the Application program just makes a call to the dresser cause the model to be processed and the conditioner can so many passes To run, as he needs before returning to the application program. In a real-time operating system or mixed operating system, on the other hand, plays the application program a role in traversing the model, directing several Calls to the dresser to do the only traversal. For one Multiple conditioner would the application program must therefore know how often the model traverses must become, to complete the scene. This would require that Application program has an intimate knowledge of the conditioner, and it would essentially very difficult to support interchangeable conditioners.

Yet Another problem with the above systems is that when preparing a three-dimensional model in a scene for display is available, a classic compromise is between the speed of the reprocessing process on the one hand and the quality on the other hand. For example, wireframe reprocessing works at a high speed, but produces a low-quality result, while a Ray tracker much longer Time needed to deliver the same model but deliver extremely high quality results can. An application program that is an interactive editing of a three-dimensional Model allows, thus, by using a Drahtmodellaufbereiters for drawing intermediate versions on a display device and by using a ray tracer for drawing the final version for use the edition.

The Interchangeability of preparers, however, is at best troublesome Use of the treatment systems described above. Furthermore Replacing one preparer with another offers only one coarse influence on the compromise between Speed and quality. It would be desirable, to allow an application program that sacrifices a bit of quality, to gain some speed and vice versa. It would be desirable, several stages in the compromise continuum between speed and quality to have a user or application program can choose exactly the desired position in compromise.

In the past, application programs have provided users with control of various casual parameters of the rendering process, and users have taken advantage of this control by selecting options that, as a side effect, affect the trade-off between speed and quality. For example, by temporarily turning off some lamps, the user can speed up the rendering process at the expense of quality. The same effect can be achieved by removing objects from the scene prior to rendering by making the output window smaller by switching from full to edge operation in a renderer that allows such selection and by setting a coarser image smoothing level. In some systems, the user has the parameters that affect the compromise between speed and quality, in a single dialog box where the user can make a choice for each of the influenceable parameters. This is a highly piecewise solution to the problem. Other application programs allow a user to select a rough quality for rendering, but usually the user chooses to have the program call a completely different renderer, or at least induce the renderer to use highly variant rendering techniques. A quality control mechanism is needed that allows an application program or user to select a desired point in the overall compromise between speed and rendering quality with relatively fine resolution in the compromise spectrum and without having to worry about individual rendering parameters.

It It is therefore an object of the present invention to provide a method for Creating a representation of a scene for display on a graphics output device indicate that there is a certain trade-off between reprocessing quality and reprocessing speed allows.

OVERVIEW OF THE INVENTION

All Examples given below and not by the scope of in the accompanying claims detected invention are not as embodiments or embodiments of the To regard invention.

According to the invention Roughly speaking, a graphics editing system is given that in maintenance mode, the construction and editing of a Model independent of the choice of the dresser. Application program calls to the rendering system for drawing an object not only the object to be drawn, but also the conditioner, the for execution is used. In one embodiment the conditioner is specified as part of a more inclusive "view object", specified by the API to the rendering system. To this Way, switching to another conditioner to egg ner during any time building or editing a model is a trivial task for the Application program.

According to one Another aspect of the invention is a graphics rendering system in which more than one conditioner is active at the same time can. In one embodiment this is achieved by the fact that the current state the preparation for each conditioner in a respective "view object" (or Objects) that specifies the application program when the rendering system is called to draw a three-dimensional object.

According to one Another aspect of the invention is a graphics rendering system indicated that on the support dynamically registered conditioner is expandable.

According to one Another aspect of the invention is a graphics rendering system which automatically detects if geometries do not pass through a chosen one Dresser supported and automatically make such geometries into multiple objects easier Geometry considered. Such an automatic decomposition can be performed recursively, until objects are reached, their geometries by the selected conditioner supports become.

According to one Another aspect of the invention is a graphics rendering system which allows an application program to provide real-time and maintenance calls to prepare a model without having to know how many passes the conditioner needs to complete the scene. In one embodiment causes the application program the rendering subsystem, the model too and the processing subsystem is a hallmark back (referred to herein as a new crossing indicator) indicating whether the preparation of the model is complete. If the indicator indicates that the Preparation not yet complete is, the application program can reprocess the rendering subsystem cause the model to be drawn. Preferably are the calls to the rendering subsystem within a loop in the application program, which is repeated until the new cross-reference indicator the completeness displays. The technology supports Real time and mixed operations because the loop has many May contain calls to the rendering subsystem, all through the application program will be executed while traversing the model itself. If the cross-reference indicator indicates that the processing is not yet Completely If the application program repeats the same sequence of calls, to effectively traverse the model again.

According to another aspect of the invention, calls to the application program specify the rendering system for drawing an object should perform not only the object to be drawn, but also the renderer of this. In this way, switching to another renderer at any time during the expansion or editing of a model becomes a trivial task for the application program. Because of the new crossing indicator, the application program does not have to make any additional concessions depending on whether the new conditioner has to execute multiple passes to complete a rendering.

According to one Another aspect of the invention is a graphics rendering system in which more than one conditioner is active at the same time can. In one embodiment This is done by saving the momentary state of the processing for each Conditioner in a corresponding "view object" (or Objects) that specifies the application program when the rendering system is called to a three-dimensional To draw object. Again the new crossing indicator avoids any need that the application program special concessions makes when one or more of the simultaneously active conditioner several passes needed to complete a preparation.

According to one Another aspect of the invention is a graphics rendering system indicated that on the support dynamically registered conditioner is expandable. Again exists because of the new crossing indicator no restriction that the newly registered conditioners are single or multi-pass conditioners.

According to one yet another aspect of the invention, a mechanism is provided which allows an application program or user to choose a desired one Point in a total compromise between Speed and quality of preparation with relatively fine resolution in the Select spectrum and without having to worry about individual preparation parameters have to. A graphics rendering system to accomplish this goal includes a spectrum or a collection of quality control data groups, each of which has several quality control type variables contains.

each contains the type variable a value consisting of several options in a corresponding tradeoff between the processing quality and select the editing speed. For example, anyone can the quality control data groups a quality control type variable included for "detail level"; those groups at the lower end of the quality spectrum can do those Variables set low have while at Data groups at the higher End of the spectrum this variable is set "high".

According to one Another aspect of the invention is a corresponding one of each quality control data groups quality Index assigned. An application program may thus have a point in the overall processing total between the processing speed and the quality only by selecting a Quality control index value choose. About that In addition, the application program may use the quality control index for a User accessible in such an intuitive way as through a pictogrammartigen "quality button". The quality button can have multiple positions, for example, from 0.0 to 1.0 range, each of which is a corresponding quality control data group equivalent. The mechanism thus allows the user a fine Control of processing compromise between processing speed and quality, without worrying about settings of the individual preparation parameters To take care of to have to.

BRIEF DESCRIPTION OF THE DRAWINGS

The Invention is related their special embodiments and reference is made to the drawings. In these

1 Fig. 10 is a simplified block diagram of a computer system embodying the present invention;

2 shows a software architecture using the invention;

3 Fig. 10 is a flow chart showing the overall flow of a program using the invention;

4 is a detail of step 308 in 3 ;

5 . 7 . 9 11 and 12 show object data structures in memory;

6 shows a class hierarchy used in an embodiment of the invention;

8th shows a model hierarchy provided by a sample program using the invention;

10 Fig. 10 is a flowchart showing the creation of a new object in memory;

13 Fig. 10 is a flowchart of an application program procedure for building a quality collection;

14 Fig. 10 is a flowchart of an application program procedure for obtaining a desired quality index;

15 is an illustration of a display picogram; and

16 Fig. 10 is a flowchart of an operation in a conditioner.

DETAILED DESCRIPTION

1 Figure 4 is a simplified block diagram of a computer system embodying the present invention. While certain types of computer architectures benefit more from the invention than others, the invention can be practiced in virtually any type of architecture. In the architecture of 1 are a CPU 102 , a store 104 , an I / O subsystem 106 all with a bus 108 connected. The CPU 102 gives signals over the bus 101 for reading and writing from and to the store 104 or to the I / O subsystem 106 to manipulate data in the manner described herein. The CUP outputs such signals in response to software instructions that they receive from the memory 104 receives. The I / O subsystem 106 may also be able to send signals over the bus 108 to leave to the store 104 in a specific embodiment. The system can also use a graphics coprocessor 110 included, that of the cpu 102 can take many of the memory-intensive tasks required to render an image. In such situations, the ad that appears in 1 With 114 is often controlled by the I / O subsystem 106. In other systems is a graphics accelerator 112 by bus 108 and the ad 114 connected. In this system, the display buffer is typically within the graphics accelerator 112 that does not just have special attributes (such as colors) on specific pixels of the display 114 can write, as by the CPU 102 demanded, but also more complicated primitives on the display 114 under the command of the CPU 102 can draw.

The invention is in the present embodiment in the form of a set of software tools, hereinafter referred to as Escher. These software tools include a set of software procedures and a set of header documents that define the variable names and data structures used by the procedures. Escher is supplied to an application program developer on a storage medium such as a magnetic or optical disk or disks. In one embodiment, the storage medium includes a source code for Escher, while in another embodiment, the storage medium includes a compiled object code for Escher. In yet another embodiment, the storage medium includes some source code and object code for Escher. The application developer compiles an application program with Escher and one or more renderers and stores the resulting object code on a storage medium. The combined object code will later be stored in memory 104 read in, either completely or in a superimposed manner, and from the CPU 102 executed.

It It should be noted that software and data, referred to herein as the "memory" in reality, completely or at any time partly in a secondary storage medium, such as a plate can lie. This situation could be, for example due to such architectures as superimposed execution or virtual memory occur. For simplicity, it is assumed here that all such software and data are "im Memory "too all possible times, even if they are to such Times actually temporarily are somewhere else.

2 shows the logical position of Escher in a software architecture. As you can see, the Escher procedures are 202 logical between an application program 204 and several preparers 206 . 208 and 210 arranged. That is, the application program 204 makes procedure calls to Escher procedures via an application program interface (API), and certain procedures within Escher (especially some primers of the call procedures 212 ) make procedure calls to the dresser 206 . 208 and 210 , The application program 204 specified when directing calls to the conditioner procedures 212 which dresser should use the conditioner call procedures. The conditioners in turn communicate with other hardware components 214 the platform, such as a display buffer, a graphics co-processor 110 if available and / or a graphic accelerator 112 , if available. The Escher procedures are in addition to the conditioner call procedures 212 also on installer procedures 216 , Quality control management procedures 217 , Modeling and Editing Procedures 218 , Image building and editing procedures 220 and some other types of procedures (not shown) that are not significant to the understanding of the invention.

3 FIG. 11 is a flowchart showing the overall flow of an exemplary program utilizing the invention. FIG. In one step 302 calls the application program 204 an Escher initialization procedure (not shown) which, among other things, includes one or more renderers using the dresser installation procedures 216 Installed. One of the benefits of Escher is that a variety of different types of conditioners can be installed, including conditioners that were not available at the time the application program was compiled.

In one step 303 the application program calls the quality control management procedures 217 from Escher to build one or more "quality collection objects", each of which may contain one or more "quality group objects". A quality group object is an object generated by the Escher system in accordance with a predetermined data structure that collects in a place a number of quality control criteria, the line style, the type of shading, the lighting, the detail level, the image smoothing level and so on.

In one step 304 the application program calls the screen layout / editing procedures 220 from Escher to build one or more "visual objects". A viewing object is an object created by the Escher system in accordance with a predetermined data structure that collects a number of visual criteria at one location, such as a camera position, illumination, hardware determination ("character context") into which preparing a two-dimensional image, as well as a selection of conditioners, among other things. step 304 may also be a call to an Escher procedure to select a quality group for use in the rendering process.

In one step 306 the application program makes calls to the model construction / editing procedures 218 by Escher to build one or more models. A model is represented in Escher as a hierarchy of one or more objects, each of which has a geometry (shape), a material attribute (describing the appearance or surface), a style (eg, filled surfaces, margins, or points only) Transformation (the relative position, orientation and size of the three-dimensional objects) with respect to an environment space or a group, (which contains only further objects in the next lower level of the hierarchy) describes. As used herein, a "model" can only form a single object, such as a geometry object, without any hierarchically defined sub-object.

In one step 308 the application program calls the conditioner call procedures 212 to allow Escher to render one or more models generated by the application program into one or more views defined by the application program. The driller calling procedure API 212 contain both real-time calls and maintenance calls. For the real-time calls for the application program only non-hierarchical data structures for processing too. The Escher system immediately routes the structures to the specified conditioner without caching any intermediate results. For material, stem, and transformation objects, the Escher system merely sets the current "state" of the view, thereby affecting the rendering of subsequently received geometries. For maintenance operation calls to the conditioning call procedures 212 This can be done by the application program 204 transmitted object can be a complete, hierarchically defined model; the conditioner call procedures 212 automatically traverse this model, make appropriate calls to the designated conditioner at appropriate points in the traversal.

Both real-time and maintenance calls specify the application program 204 for the conditioner call procedures 212 both the object to be called and a view object. The current "state" of the rendering always becomes within the data structure of the visual object so that the application program can concurrently render the same model more than one view by interspersing only calls specifying one view object and calls specifying another view object. These calls do not bother each other (unless, of course, both visual objects refer to the same drawing context). The two view objects could specify the same or different renderer, and the drawing context specified in the view objects may be specified for output to the same or different types of output devices (such as two different windows on a single display or one for the Display and for a printer). In addition, the application program can 204 Real-time and maintenance calls for the same view mix together, enabling the application developer to optimize the storage and / or traversal of different parts of a scene differently.

Some of these possibilities are illustrated in an exemplary flowchart that is incorporated in 4 is shown. In one step 402 the application program calls the conditioner call procedures 212 which specify a first model and a first visual object. In one step 404 the application program calls the conditioner call procedures specifying the first model and a second view object. In one step 406 the application program calls the conditioner call procedures specifying a second model and the first view object. In one step 408 the application program calls the conditioner renderer procedures specifying the second model and the second view object. In one step 410 the application program calls the conditioner call procedures specifying a third model and the first view object, and so on.

The independence of an Escher visual object (including the identification of the preparer) from the reprocessing model also creates tremendous flexibility in the flow of operations performed by the application program 204 be executed. For example, the conditioners do not need to be installed (step 302 ) until just before calls to the conditioner call procedures 212 (Step 308 ). Visual objects also need not be defined or completed (step 304 ) until a model is created (step 306 ). An application program can therefore build a model or a part of a model and allows a user to select the conditioner later. The selection of the conditioner may be made using, for example, a pop-up quick search window offering a number of pre-installed conditioners and also providing the user with an opportunity to install another conditioner at that time. The application program can then process the model (or models) using the selected conditioner, then edit the model or built new models, and / or change the choice of conditioners and reprocess the model (s), etc. Such flexibility is possible because the choice of the conditioner is not tied to the model when it is under construction, rather the application program specifies the conditioner in its calls to the conditioner call procedures 212 from Escher.

A simple application program 204 in C language is given in Annex A. In this example, the program first calls the Escher initialization routine, which installs both a wireframe builder and a Z-buffer renderer. Next, an application routine ExSetupQualityCollection () is called to set and initialize a quality collection object. This procedure will be described in more detail below.

When next If a visual object ("view") is generated, and become a special conditioner (the wireframe maker) assigned to the view. A camera object and a drawing context object are also assigned to the view object. ("Drawing sample") and adds a polygon object ("Polygon"), a Line object ("line"), a Transformation object ("transformation") and a Add sample object ("subgroup"). The application program adds then Toros object ("Toros", a Form of a geo-object) to the group object. Next will be set up a user-specified quality index for the visual object, and the model is traversed and recycled using of the conditioner specified in the view object. The in sight object specified conditioner is then placed in the Z-buffer conditioner changed, and the same model is redone using the in-sight object prepared conditioner.

Before proceeding, it is appropriate to explain some naming rules used in the C-language source code included in the present invention. In this description, names beginning with the Prefex Et (Escher type) data types are defined in the Escher source code. Names starting with the prefix Ec (Escher constant) are constants defined in the Escher source code. Names that begin with the prefix Er (Escher routine) are prefeed names that can be called by the application program. Names that start with the prefix egg (Escher-Intern) are names internal Escher procedures, which are called only by other Escher procedures. Many of them have counter-er procedures that are called by the application program and that essentially do nothing more than invoke the corresponding egg procedure. For this reason the Er and Ei procedure names used here interchangeably. Finally, names starting with the prefix Eg (Escher-Global) are global variables.

The Names of Escher routines begin with Egg or He, and follow them Sub-words, the with capital letters kick off. The shape of most Escher procedure names, like here is ErFoo.DoSomething, where Foo is the type of data The task that the function must work with is DoSomething and the operation the routine is to execute with this data type. For example the name of a procedure to create a new polygon object the ErPolygon.New. Other naming rules are mentioned when they occur.

The various primary steps of an application program, as in 3 will now be explained in more detail.

I. CONDITIONER INSTALLATION

The installation of Escher conditioners uses a generalized extension mechanism that is also used to install other extensions, such as shaders. Extensions for Macintosh executions are documents stored in mass storage in the hardware of 1 are stored, with a file branch and a resource branch. The file branch contains the code to be loaded by the Escher system, and the resource branch identifies the code fragments in the file branch.

If an application program 204 Using a Macintosh, call Escher's ErInitialize () call, then the Escher system queries all extension documents in an extension folder of the computer system. All documents that are found and that contain appropriate resource information are then treated as available for use by the application program. The extension document specifies an initialization routine that includes all necessary steps to "register" the services offered by the Escher system and a termination routine.

Escher extensions become a generalized object hierarchy in the Escher runtime environment loaded. Escher's object hierarchy has an "open" architecture that applies to every application allows to "plug in" a subclass at any of several levels in the hierarchy. Dresser are one of the object classes that can be subclassed.

A. Escher object system

An object in the Escher system is identified by two handles, namely an object class and an object. The object class is a pointer of type EtObjectClassPrivate, and the object type is a longword. Because the superclass of each subclass in the Escher class hierarchy has some behavior, Escher stores object privilege and object classes in a layered fashion. For example, a subclass of the conditioner class becomes abstract in the in 5 designed way. 5 shows an object "class" 502 which is a continuous range of memory-containing pointers of all processes associated with the conditioner, in this case a wireframe (WF) preparer. Since the wireframe conditioner is subclassed from the conditioner class, the conditioner class is subclassed by a "shared object" class, and the "shared object" class is underclassed from the generalized "object" class. The procedure tables 502 therefore first list those of the object class (area 504 ) associated procedures. These methods include, but are not limited to, placing the object, duplicating the object, and saving the object. All object class methods tables point to the same Escher procedures in these entries, unless those entries have been overwritten during initialization by one of the descending classes that in a particular procedure table 502 are shown. The class 502 next contains an area 506 containing pointers to a set of procedures that are appropriate for all objects in the "shared object" class. When it does, there is no "shared-object" procedure, so no space is allocated in this layer. In the area 506 follows an area 508 , which contains pointers to a set of procedures that are suitable for all Aufbe rider. There is no coating specifically for the wireframe reprocessor class because by convention in Escher design, leaf classes have their own process table.

The area 512 stores all data for a special case of class 12 , This area is in the same place organized as the area 502 , In particular, it first contains all the data that contains an object class in the area for each special case 514 are appropriate, followed by all the data for each special case of a shared object class in the range 516 are appropriate, followed by all the data for each special case of a conditioner object in the area 518 are suitable. Unlike the class data 502 contain the special case data 512 also an area 520 containing all the data suitable for a special case of a wireframe builder object. The object data in the area 514 contain only a pointer to the procedure tables 502 that are common to all special cases of wireframe dresser objects. The shared object data in the area 516 include a reference count, and the renderer object data in the range 518 and the wireframe maker data in the area 520 will be explained later.

In 5 For illustration purposes, a second special case of an object is also shown in the wireframe conditioner class. The second special case has all its data in the range 522 in the same format as the data of the first special case in the area 512 , The object data in the area 524 This data points to the same object class procedure table 502 as do the object data for the first special case. It should be noted that the second special case in 5 only specified to represent the relationship between classes and special case data in the Escher object mechanism. In particular, it is unlikely that more than one special case of a wireframe maker would ever co-exist in a single specialization of an application program, but this is not excluded.

It is now useful to describe the class hierarchy used in the Escher system. This hierarchy is extensive, and only those classes that are essential to the understanding of the invention will be discussed in 6 shown. Referring to 6 you can see that the EtObject class is the base class for all classes in the hierarchy. The EtSharedObject class is under-class, under EtObject, as are other classes that are not important here. Subclassed under the EtSharedObject class is an EtShapeObject class, an EtRendererObject class, an EtSetObject class, an EtDrawContext class, an EtViewObject class, an EtQualityCollection class, and an EtQualityGroupObject class. Subclassed under the EtShapeObject class, an EtStyleObject class is an EtTransformObject class, an EtCamera object class, an EtLightObject class, an EtGeometryObject class, an EtGroup class, and an EtShaderObject class, and is subclassed under the EdRendererObject class are a Z-buffer class and a wireframe class. Subclassed under the EtStyleObject class is a BackfacingStyle class, among others. Subclassed under the EtTrantormObject class are a rotation class, a scale class, and a translation class, among others, and not shown here. Subclassed under the EtGeometryObject class are classes for Line, Point, Polygon, Poly-Line, Toros, and Triangle as objects, among others. Subclassed under the EtGroup class are an EtLightGroup class, an EtInfoGroup class, and an EtDisplayGroup class, the last subclasses of which are EtOrderedGroup and EtListGroup. This class hierarchy describes the storage of procedure tables and special case data for each of the classes contained in the hierarchy. The classes at the ends of the hierarchy, that is, the "leaves" of the tree structures are known as "leaf" classes.

B: Registration of a conditioner

The base for the object subclassing at Escher is that Escher use its procedure table dynamically at system startup time of expansion mechanisms. Every object class in the system, including the conditioner object classes, is under the control of the ErInitialize procedure called by the application program is "registered" so that its functionality, if necessary available is. Since each extension is loaded, Escher receives the address of the initialization function of the Extension from the resource branch of the extension document. It then calls that function.

The following is a C-language initialization procedure, called ErWF.Register, used by the wireframe dresser extension.

When a class is registered, it provides procedures that determine the behavior of special cases of the class. The class provides these procedures to Escher through a Metahandeler. A metahandeler is a function that cards Escher process types to function pointers. Escher asks the Metahandeler function to give him a procedure of a certain type, and if the Metahandel knows the type of procedure, he provides his appropriate procedure. If the meta trader does not know the requested procedure type, he returns to zero. As can be seen, the first step of the ErWF register registers the new wireframe subclass by calling the remover class registering method ErRendererClass.Register with a Identification of the metaphor of wireframe builder ErWF.MetaHandler as argument.

The metal distributor of the wireframe conditioner is as follows:

Escher calls the Metahandel once each entry in his procedure table and requires each time the identification of another wireframe method.

The Contains the EtRendererObject class a procedure table for the preparation of geometric shapes. Every dresser must have a procedure to render at least three basic geometry types: point, Line and triangle. The conditioner can also process for processing provide more complex geometry types. After registering a Metahändlers hopes the above wireframe procedure, the ErWF.Register therefore the Preparer class procedure ErRendererClass. OverrideGeometrylTypeDrawMethod to set up the geometry drawing methods he supports. As you can see, the wireframe builder registers procedures for preparing geometries of the type Polygon, Triangle, Line, Polyline (sequence of connected lines) and points, among others.

The ErWF.Register procedure overrides also some transformation methods and attribute setting methods in a procedure table of the preparation class.

you can see that through the object mechanism of Escher new conditioner in the enterprise in The Escher system can be installed by merely accessing Subclasses are made under the EtRendererObject class.

II. CONSTRUCTION OF A SIGHT OBJECT

A. Data Structures

As noted, a view object is a data structure that includes, among other things, camera information, lighting information, traversal or state information, as well as an indication of a selection of conditioners. Each view object is a special case of the class EtViewObject, which, as in 6 is a subclass of the EtSharedObject class, which in turn is a subclass under the EtObject class. Accordingly, following the format of 5 , a visual object the format of 7 In the storage room. Especially an area of memory 702 is determined to contain pointers to methods of the EtViewObject class, and this range 702 contains pointer 704 on object method and pointer 706 on shared object method. The EtViewObject class is a leaf class, so in accordance with the Escher Rule, the class omits a procedure table specific to view object methods. It should also be noted that there are no shared object methods in the present embodiment as well.

The structure also contains special case data for the view object in the area 710 of the memory. This area contains special case data relevant to the object class in a part 712 are specific (to the object class 702 shows), special case data relevant to the shared object class in a part 714 are specific (containing a reference count) and special case data for the view object class in a part 716 are specific. The view object data is a data structure of the type EtViewPrivate, which is described as follows:

As you can see contains a visual object includes a pointer (* rendererClass) the procedures of a just chosen Preparer, a pointer (* renderer) to the special case data the current dresser, a drawing context object, a camera object, lighting objects (lights), multiple shader objects and a quality group object.

The EtRendererPrivate structure is defined as follows:

These Contains structure Pointer to a series of piles showing the current state specify a traversal. As described in more detail below These state stacks are encountered each time Escher's traverser becomes a "group" object in a model opens and traversing the next level the hierarchy begins. These stacks will be restored to their previous state raised when the crosser does his job at all lower levels completed the model hierarchy and a "group" object closes.

The EtRendererClass data structure is defined as follows:

It be reminded that the Initialization procedure of the wireframe renderer described above became a metal trader Escher can call for certain procedures of the treatment class to overwrite. Escher puts those through the Metahandel returned pointer in the EtRendererClass structure fields above for the corresponding ones Procedures are defined. It should also be remembered that the initialization procedure of the wireframe renderer overwrites some methods, in particular certain geometry character methods using an EtRendererClass OverrideGeometryTypeDraw method. These Procedure writes the pointer to the specified conditioner procedure in the procedure table pointed to by * geometryDrawMethods In order to thereby override error procedures, the Eschersystem originally were set during initialization. The EtMethodTable data structure is just a list of pointers; for * geometryDrawMethods shows each entry in the table refers to the procedure for processing a according to the geometry type beispielswei se point, line, triangle etc. The correspondence between places in this table and geometry types is set during compilation.

Another field in the EtRendererClass data structure that should be mentioned is the geometry DrawMethods field. This field contains a pointer to a procedure that Escher will call, if he has been requested, a geometry type. Drawing that the current dresser does not support (that is, the geometryDrawMethods procedure table entry for the geometry is NULL). This procedure breaks the specified geometry into similar geometries, as explained in more detail below. In the present embodiment, the decomposition procedure can not be turned off. However, in another embodiment of the invention, a conditioner may disable this decomposition process to optimize the process.

The EtQualityGroupObject structure is described below.

B. Procedures

The method for building a visual object in step 304 ( 3 ) is essentially the method of writing desired information into the view object data structure. The exemplary application program in Appendix A is used to explain the method.

1. Create a visual object

To Initialization and setup of a quality collection generates the application program a new view object by calling view = ErView_New (). These Procedure only creates a new special case of an object in the EtRendererClass and fills it with error data.

2. Adjust the conditioner

One Conditioner can be attached to a view object by using an Escher procedure ErView_SetRenderer is called and enter the view object and the conditioner object become. This call increases the reference count of the entered conditioner. If a dresser object already is set, then its reference count is decreased.

One Dresser can also be set by conditioner type, without that he first a special case of a conditioner object must have received. In this In case the application program calls the Escher routine ErView_SetRendererByType on, and this is the procedure used by the sample program in Appendix A. The ones specified by this procedure Parameters are the visual object and the type determination, which is a four-character code that designates a conditioner type (for example, wireframe or Z-buffer). The Escher procedure ErView_SetRendererByType determines which conditioner of the specified type has been registered, and when such a preparer has been registered, becomes one Pointer to the conditioner special data in the corresponding entry of the specified visual object.

3. Adjust the camera

In front to adjust the camera must be Camera object created and initialized. The program example in Annex A. this by writing the camera perspective types in a suitable perspectiveData data structure and assigns it to a camera object using the Escher procedure ErViewAngleAspectCamera_NewData. Once a camera object is received, it can be assigned to the view object enter the view object by calling ErView_SetCamera and the camera object. This call increases the reference count of the entered camera object. When the camera object is already entered was his reference count reduced. The program example in Appendix A then uses the camera object using the Escher function ErObject_Dispose as the camera object no longer needed separately becomes.

4. Setting the drawing context

In front The setting of the drawing context requires a drawing context object be generated and initialized. In the program example in Appendix A will do this by setting up a suitable data structure PixmapData accomplished and by entering into the Escher procedure ErPixmapDrawContext_NewData. The drawing context object is then used to the view object of the call ErView_SetDrawContext mapped using the Call ErView_SetDrawContext and enter the view object and the drawing context object. The application program example in Appendix A then sets the drawing context object by passing to the Escher function ErObject_Dispose.

Another Properties of the view can also in similar Be specified such as lighting and shading

5. Selection of the processing quality level

This will be described in more detail below.

you can recognize that the Construction and editing of a visual object completely separated of building and editing another visual object, so that more than a visual object (including those who specify the same or different conditioner) without mutual interference can coexist.

III. CONSTRUCTION OF A MODEL

The Modeling method used by Escher understands One best from a comparison of modeling patterns, the be used on two existing products by Apple Computers are offered: QuickDraw and QuckDraw GX. QuickDraw GX is in Apple Computer's "QuickDraw GX Programmer's Overview "(1994) which is incorporated herein by reference. Both QuickDraw and QuickDraw GX perform two-dimensional graphics processing instead of three-dimensional processing. The two-dimensional Graphics system QuickDraw has a process interface and a global graphics state, the color, the transfer method and the transfer pattern of her defined shapes defined. When the design drawing routines QuickDraw draws the shape from QuickDraw according to the variable in her graphic state. An application program can change the graphics state by manipulating other calls to QuickDraw.

QuickDraw GX differs from QuickDraw in that instead of a process interface with a system supportive Graphics state shapes are represented as objects, all Contain information necessary to draw them. It There is no system-based Graphics state. Because shapes are objects, QuickDraw GX can benefit deliver, work with such figures, what QuickDraw does not can because the routines of QuickDraw only images into a pixel map to draw. QuickDraw GX provides functionality to work on shapes, as well as "hit" exam and geometric overlap.

Of the The main data type in QuickDraw GX is a "shape" that contains the geometry and others Includes drawing information. Figures are drawn over a "sight gate", that the figures in "visual device" coordinates transformed. When a figure is typed in to draw with QuickDraw GX then the figure is drawn through every sight gate that attached to the figure is. A vision gate may overlap multiple vision devices, in which case the shape on each viewing device with their correct resolution is drawn. QuickDraw GX shapes can be used in hierarchies by using organized the "image shape" become. Every figure has a "type" who is hers which indicates whether it is a line, a polygon, a Curve, etc. is. Access to design takes place via a process interface and handle.

The Designing procedure of QuickDraw GX can be to any Time to be called to draw a figure. The order of figures that are drawn on top of each other depends on the order in which they are drawn. Between the drawing commands if no status information is retained, except for internal caching information, because every shape has all the information in it includes, necessary to draw this figure, including vision gate, Visual device, color, transfer mode and drawing style.

The Escher's system is remarkably different from QuickDraw and QuickDraw GX due to the nature of the three-dimensional rendering algorithms and the typically larger data volumes that necessary to describe a three-dimensional model.

Escher shapes do not contain all the information needed to draw them. Rather, Escher maintains a "state" that provides additional information about how a shape is to be rendered, as well as the original QuickDraw maintains a drawing state for the foreground color at the graphics port. Escher's state mechanism allows the construction of hierarchical models that specify information, such as color or drawing style, that are dragged by shapes at lower levels of the hierarchy. The mechanism provides increased flexibility in leading a model to be used multiple times in a scene, but with varying attributes, without re-specifying the geometry. Escher also differs from QuickDraw GX in that the drawing area for the up It is specified by Escher before preparation of the image by attachment to a visual object and not by attachment to any shape, as is the case with QuickDraw GX.

Escher returns several data types for the inclusion of Geometry and appearance in a model hierarchy. The general Data type classes are geometry "attribute set", style, Transformation and group. It is beneficial to look in several To separate data types in this way because of the typical complexity of three-dimensional Models. Even simple three-dimensional shapes can be hundreds or require thousands of geometric figures to a realism to create a matching image. To be a realistic looking Shape of any complexity to produce, such as a room in a house, can be hundreds and thousands or millions of geometrical shapes required be. When dealing with models of this size it is often beneficial a simple appearance characteristic of a large group geometric shapes to save space and to simplify the design and editing of such a model. The above data types facilitate this task.

In the QuickDraw GX model hierarchies, transformations of a "figurative" are considered concatenated with those of the shapes that comprise them. This makes a reference to the same shape more than once and uses transformation transformations to move or transform the shape without having a second copy of it in memory. Such concatenation is achieved with QuickDraw GX via a state mechanism that preserves a record of "instant transformation transformation" as it traverses a model hierarchy. QuickDraw GX image hierarchies are traversed from top to bottom, left to right. When traversing shapes further down the hierarchy, transformation transformations are concatenated with the current transformation transformation. After all shapes have been drawn within a picture frame, the traverse returns to the previous frame, if any, and resumes traversing its shapes. This is called "downward traversal". On returning from a traversal, the current transformation transformation is reset to what it was before the imagery was entered. This mechanism can be thought of as a stack of conversions that is pressed and poked during traversal. When the primitive is completed, the current cast is NULL:
Escher provides a similar traversal mechanism, although because of the increased complexity of three-dimensional models, more than just a transformational transformation is carried. Appearances and styles are also included.

While QuickDraw GX does not have a "running transformation transformation" when the QuickDraw GX system is not traversing a picture, Escher allows an application program to put the current state on its own and take it off. In fact, application programs can maintain Escher shapes in an application-specific hierarchical data structure, if desired, and through careful sequencing of Escher procedure calls 202 simulate a system hierarchy. This feature is extremely advantageous for application programs that use complex application-specific hierarchical data structures, such as animation systems, or when porting an existing application program that already has its own data structures. The known PHIGS system and other maintenance operating systems require that the entire model be in a single hierarchy, and GL handles each object independently. An application program can set the state, draw a number of independent geometric objects, and then have the Escher system reprocess a model built and stored in the Escher system data structure, then draw several independent geometric objects, and so on.

8th FIG. 12 is a graphical representation of a simple model hierarchy constructed by the exemplary application program in Appendix A. FIG. It contains two levels, the first (basic) level that is enclosed by the "group" called the EtDisplayGroupObject, and the second, which is enclosed by the "subgroup" called the EtDisplayGroupObject. Each EtDisplayGroupObject can be thought of as a node in the hierarchy. For each node, style objects, geometry objects, transformation objects, and other group objects (as in 8th ), as well as shader objects and attribute set objects.

Escher supports two types of EtDisplayGroupObject, namely those in the subclasses EtOrderedGroup and EtListGroup. Objects attached to an example in the EtListGroup class have no order except for the order in which they were added to the group. If, during the traversal, Escher encounters a list group object, any object in the list is processed ("executed") in the sequence in which it was originally added to the group. Referring to 8th , as soon as the In this sequence, Escher runs backfacingStyle, then polygon, line, then transform, then subGroup in this episode, because this was the result with which they were added to group. The editing state changes caused by backfacingStyle are thus also applied to polygon and line, while the changes to the edit state caused by transform apply only to the objects in subGroup. The Escher API contains calls that allow the application program to add objects to the top of the list, to the bottom of the list, or to items already in the list.

One Group object of subclass EtOrderedGroup is similar to one List group object except that the traverser is the object sorted that added to the group is, in dependence of the type before running become. In particular, objects are executed in the following sequence: transformation objects, Style objects, attribute set objects, shaders, geometries, and additional Groups.

For both Types group objects becomes when a subgroup is opened the then running condition of the conditioner entrained. objects in the subgroup can any characteristic of the state for subsequently executed objects in the subgroup (or in subgroups of the subgroup) the return however, the state becomes the parent group in that state made before entering the Durchquerers in the subgroup prevailed.

group objects also have a "state" that gives them although this is not confused with the "state" of the pass-through may be. The state of a group is just a collection of Indicators that define aspects of how to handle the group is. Most of the characteristics are for the understanding of the present invention not important, but it may be helpful to mark one of these to understand, namely "in-line". For modeling applications It can sometimes be useful Be a set of materials or styles together in a bundle Group, which is used in a model several times can. If such a bundle using normal hang-up and take-off of a traversal state however, these objects do not have the wished Influence on the model because the group picks up the condition after going through executed the truss is. Accordingly, the application program may have the "in-line" flag of the group object to thereby specify that entry in the group and leaving the group are not there, the Condition of the Durchquerers put on or take off. The Escher API provides procedure calls for setting, clearing and getting the current one Value of this mark.

A. Data Structures

As In the procedure for building a view it is helpful to have certain Describe data structures before describing the Escher procedures that call an application program to build a model can.

In the example application program in Appendix A, the groups group and subGroup are ordered display group objects. You have a type EtDisplayGroup that is in the class hierarchy of 6 has a class predecessor of EtGroupObject, EtShapeObject, EtSharedObject, and finally EtObject. Accordingly, they are in memory with data structures like in 9 shown, represented. In particular, the ordered display group class method table is in a block of memory 902 and sample data for group and subGroup are in blocks 904 respectively. 906 contain. The ordered display group class 902 starts with the area 908 that contains pointers to object methods, similar to the scope 504 in 5 , The area 908 follows range 910 which contains pointers to all methods specific to shared objects (none exist in the present embodiment). This is followed by an area 912 , which contains pointers to all gestalt object methods, and this is followed by an area 914 containing pointers to the procedures that are specific to group objects. The latter data structure, EtGroutClass, has the following type definition:

As can be seen, entries for pointers to various methods are included, including a method of adding an object to the end of the group (add), and methods of adding an object to a specific location within the list of objects already in a group are assigned (addBefore and addAfter) By area 914 Contains the ordered adgroup class procedure table 902 Pointer to the procedures for ad groups in one area 916 are specific. This data structure EtDisplayGroupClass is defined as follows:

The Methods in the EtDisplayGroupClass are not essential to the understanding of the invention, it should be noted, however, that the Class no pointing to any drawing method contains. The Digit explained These methods are in a view object instead of a group object identified so that they through a conditioner can be made ineffective. Every drawing process, that in the class for an object would be identified Become part of the model to be built, would be interwoven with the model itself be and would be difficult to change if an application program wishes to process the model using another conditioner. Such an arrangement would It also makes it difficult to have more than one dresser at a time to activate, as previously described.

Again referring to the process table 902 as typical of the design of the Escher system with respect to leaf classes in the class hierarchy ( 6 ), the table does not contain any procedures that are specific to ordered display groups.

The data structure of the example data for subGroup is the same as that for group, so only the data structure for group is described. As with the data structure for the example data block 512 in 5 starts block 904 with object data in the area 920 , especially a pointer to the ordered display group class block 902 , This is followed by an area 922 containing the shared object data, especially a reference count. This is followed by an area 924 which contains the Gestalt object data (which are also very short). The gestalt object data area 924 follows an area 926 that contains the object data for group objects, none of which are present in this example.

The area 926 follows an area 928 containing the sample data for display group objects. Such data includes only the "state" flags described above. The area 928 follows an area 930 containing the data specific to an example of an ordered display group object. This data has a format defined as follows, where EtDLList is a type definition for a double-linked list:

As you can see contains the area 930 Pointer to six double-linked lists, one for each of the object types that can be added to an ad group object. For completeness, note that if group is a list display group instead of an ordered display group, the only difference is the structure of the area 930 is. In particular, the area would be 930 that had a structure defined as EtListDisplayGroupPrivate, have only one pointer to a single double-linked list for all the objects added to the display group.

In addition to the EtListDisplayGroupObject structure, the sample application program in Appendix A uses an EtStyleObject data structure, an EtGeometryOject data structure, and an EtTransformObject data structure. These structures all refer to classes of objects that, like EtGroupObject, are under-classed by the EtShapeObject class (see 6 ). As with other objects described here, they each refer to a procedure table 902 9 and contain private sample data, such as area 904 or 906 in 9 , These three classes are each subclassed from the same main class (EtShapeObject) as EtGroupObject (see 6 ), and therefore, the first three layers of both the class data and the example data are of the same structure as in FIG 9 shown. The leaf class (BackfacingStyle) currently used in the example program in the EtStyleObject class is a subclass of the EtStyleObject, so the fourth and last layers of class methods for that object contain pointers to the methods specific to style objects. The fourth layer of sample data contains private data suitable for all style objects, if any, and the fifth and last layers contain data suitable for backward facing style objects.

Similarly, the translate class that is really used in the sample program in the EtTransformObject class is a subclass of the EtTransformObject class (see 6 ) that the fourth and last layers of the class methods for the transformation object include pointer methods that are specific to transformation objects. The fourth layer of the example data for the transformation object contains data specific to transformation objects, the fifth and last layers contain data specific to translation transformation objects.

The sample program creates three objects (polygon, line, torus) that are geor- omy objects, and all of them are in leaf classes, subclasses of the EtGroupObject ( 6 ). Thus, the fourth and fifth layers of the class method table for each of these objects contain pointers to methods that are specific to geometry objects. The fourth layer of example data for each of these objects contains data specific to each geometry object, and the fifth and last layers of example data for each of these objects contain data specific to polygon, line, and torus objects, respectively.

While at Escher attribute sets (which contain attributes such as diffuse color) surface appearance characteristics Styles include a conditioner, such as a geometric one To draw shape. For example, a polygon can be used as a Completely completed Shape, or only with its edges. One Another example is that surfaces are gentle or with a faceted appearance. One another example, which is a backward-looking style object (subclass of EtStyleObject) determines whether shapes created by pointing the camera away, displaying it or not. EcBackfacingStyle_RemoveBackfacing, the characteristic used in the example program in Appendix A. becomes, indicates that shapes, which point away from the camera, are not drawn. The private data for a backward-looking Contains style object a longword that contains a constant that indicates whether both front as well as rear facing surfaces are to draw, whether after rear facing surfaces are to be removed or whether surfaces facing the back, the do not have two-sided attributes, be typed with their normal ones should, so that they always pointing against the camera. An application program specified Style characteristics in a model by creating a suitable one Style object and adding it to a desired one Position in a group object of the model.

For geometry objects contain the private data in the last layer of sample data Information necessary to describe a specific geometry. For example, private data specifies in the last layer of a polygon object, the number of corners, the corners, and certain Attributes that are not relevant here. The private data in the last layer of a line object contain the locations of the two endpoints the line as well as some attribute data, and the private data in the last layer of a torus object contain an origin, an orientation, a major radius and a minor radius as well some attribute data.

A transform object allows the coordinate system containing geometric shapes to be changed so that it becomes possible to arrange and orient objects in space. Transfor mations are useful, do not change the geometric representation of objects (the corners or other data describing the shape), rather they are applied as matrices during rendering and "move" an object temporarily in space. This allows for a single object to be accessed multiple times with different transformations in a model, providing the ability to place an object at many different locations within a scene. An application program specifies transformation by generating a suitable transformation object from a subclass of the class EtTransformObject ( 6 ) and by adding it at a suitable location in a suitable group in a model. A transformation specified by an application program is maintained in the specified form until the time of rendering, at which point Escher converts the transformation to a temporary matrix that is applied to subsequent objects of the group. Matrixes are pre-multiplied to vectors of an object. Escher transforms pre-multiply the current transformation matrix; therefore, application programs specify transforms to be concatenated in reverse order. This is consistent with the application of matrices in a hierarchy. That is, matrices specified at the top of the hierarchy are applied last, and matrices specified just before an object are applied first.

applies, and matrices that are just specified in front of an object applied first.

Escher supports several different types of transformations, each of which is much Escher specified by using an object of a corresponding subclass of EtTransformObject. Three such subclass are in 6 represented (Rotate, Scale and Translate). The Escher API provides procedures for creating and arranging transformation objects, drawing them in real time, setting their contents to new data, obtaining the private data of a transformation object, writing a transformation object to a document, etc. The private data in the lowest layer of Example data for a translation transformation object, which is the blade class used in the example program in Appendix A, specifies the x, y, and z coordinates of the translation.

B. Procedures

1. ErOrderedDisplyGroup_New ()

Referring to Annexes A and 8th The example application program starts building the model of the group 802 by first creating the reordered group group object using the ErOrderedDisplayGroup_New () procedure. Escherobject creation mechanism is a recursive mechanism generally used in the flowchart of FIG 10 is shown. It should be noted that the class method table for the ordered display group class was created during initialization after registration of the ordered display group class, so that only one block of example data must be created and initialized in the new object mechanism.

Referring to 10 Call first in the step 1002 the "new" procedure of the leaf class its parent class "new" procedure with: (a) the static variable which, if the leaf class was registered, points to the top of the process table of that leaf class, and (b) the size of the private data structure the leaf class. In one step 1004 then the "new" procedure of each higher class calls the "new" procedure of its corresponding parent class: (a) the object class pointer passes over it, and (b) the size needed for all descending classes, plus the size needed for the private data structure of the current class. In one step 1006 executes the "new" procedure of last parent class (EiObject_New ()): (a) allocates memory space for the private data structures needed for its own private data plus the private data for all descending classes. this space then contains the entire block of sample data for the newly created object. Then (b) it initializes its own private data structure (by writing the object class pointer passed to it into the top of the newly allocated memory block), and (c) returns to its caller (which is the next-class "new" procedure), wherein a pointer is returned to the newly allocated memory block. In one step 1008 then executes the "new" procedure of the lower class: (a) calls its own access procedure to get a pointer to its own private data structure of the current class within the newly allocated example data block; (b) Initializes your own private data structure; and (c) returns to its caller (which is the next lower class "new" procedure), returning a pointer to the newly allocated memory block. The "new" procedure of the leaf class does the same, with the exception that the caller is typically the application program instead of a "new" procedure of a subclass.

A few examples of Escher's "new" procedures show better how this is achieved. The "new" procedure for an ordered display group object, which is the routine called by the application program, looks like this:

As As you can see, this routine first calls the "new" procedure of its parent class on EiDisplayGroup_New () with the pointer to the ordered display group class procedure tables EgOrderedDisplayGroupClass and the size of the private data structure EtOrderDisplayGroupPrivate, which in the next layer of sample data for the just created object needed become. When this procedure returns, the block has been allocated by example data and are higher levels initialized. After a certain error check, the procedure receives EiDisplayGroup_New () a pointer (ordered) to the ordered display group private data structure of the assigned block and initializes all of the double-connected ones Lists to zero. The procedure then returns to the application program back, wherein the pointer is returned to the newly created sample data block.

The "new" procedure of the display group class is as follows:

As As you can see, this procedure first calls the "new" procedure EiGroup_New of it own root class, sets the pointer to the object class and a data size that given by the size of private data size is needed by the parent class will, plus the storage space size that for the Private data of the objects in the group class (EtDisplayGroupPrivate) needed becomes. After error checking EiDisplayGroup_New () places a pointer groupPrivate on the private data of the group object and initializes it. The procedure then returns back to its caller EiDisplayGroup_New ().

The "new" procedure in the EtGroupObject class is as follows:

The The above procedure follows the same plan as the "new" procedures for the display group class and the ordered display group class, with the difference that none private data specifically for the class EiGroup_New () exists. Thus, the initializes Procedure EiGroup_New () does not have any private data, and the Data size, the to the "new" procedure passes the parent class EiShapeObject, is the same as the data size, the from the "new" procedure the display group class is passed to EiGroup_New ().

The procedures continue until the "new" procedure of the EtObject class. It can be seen that Escher the same recursive mechanism used to create objects in each class of the class hierarchy. In addition, it can be seen that Escher uses similar recursive techniques to perform the functions of a large number of Escher API calls.

2. ErGroup AddObject ()

again Referring to the exemplary application program in Appendix A, after the creation of a reordered display group object group, the program generates a backward pointing Style object and adds add it to the group. This part of the sample program is not important for the understanding of the invention, rather, is included for purposes of illustration only, the existence such object can be added to a group.

Next, the example program creates a polygon polygon object using the Escher procedure ErPolygon_New (). This procedure is similar to the "new" procedures discussed above with respect to the creation of an ordered display object and need not be described again. The sample program then adds polygon to group using the Escher API call ErGroup_AddObject (). The latter procedure is as follows:

As you can see, receive this procedure takes as arguments the object to be added to the group and the group to add this is. After some accounting operations, the procedure calls EiGroup_AcceptObject () On, an Escher procedure to determine if the specified object is of a type that is added to the specified group object type can. For example, if the specified object is a light object is, it can not be added to an ordered display group. In the present case, the result is valid because a polygon becomes a Object added to EtOrderDisplayGroup can be.

procedure contains then a pointer groupClass to the EtGroupObject class procedure table for the special ordered ad group object by calling the procedure "get Subclass method "the Root class EtShapeObject from EtGroupObject. The procedure then calls the procedure "adder object", on which is shown in this process table, and then returns to Application program back.

The pointer in the procedure table to the "add object" procedure for the particular group object was written there during initialization when the class EtOrderedGroup registered itself. The specified procedure "Add object" is as follows:

Referring On top of this procedure you can see that you first get the "get" procedure of the ordered ad group class used to specify a pointer groupData to the private data of the ordered display group object. The procedure then gets the type of specified object to be added (the one geometry object is), and after some error checking it calls EiOrdererdDisplayGroup_GetObjectList () to add a pointer to theList on the special double-linked list of the ordered display group object for geometry objects. The procedure calls EiGroupPosition_New () to get a new list "position" object and calls EiDLList_InsertNodeLast () to get the new "Position" object at the end of the double-linked list. The procedure then returns back to its caller EiGroup_AddObject ().

to completion It should be noted that the Procedure for adding an object to a list display group object very similar to that to add of an object to an ordered display group object is with the Exception that only a double-threaded list in a list display group object is available. It is therefore unnecessary to determine one of six lists to which the object is to be added. It be also noted that in addition to an object addition procedure Escher's API too Contains procedures to add an object behind a specified position in the list of Group, to be added an object in front of a specified location in a list of Group, to remove an object from a specified position in a list of the group for forward and backward through a list the group, as well as other procedures.

3. ErObject_Dispose ()

To Add of an object to the group sets the example program in Appendix A. Polygon object because it is no longer needed in the application program (apart from his presence in the model just created). As far as the application program is concerned, the polygon object has been removed. In fact, delete however, the Escher procedure ErObject_Dispose () at this time uses the polygon object not and clears not the allocation to the storage space. Since polygon is a shared Object is reduced, instead Escher only the reference count in the shared object private data for the polygon object. The reference count was set to 1 when polygon was created, and became 1 elevated, added as a group has been. The call of ErObject_Dispose () by the application program only reduces the reference count from 2 to 1. If the countdown is the reference count reduced to 0, clears Escher really the object and deletes also the allocation of the storage space.

4. New line object

The Example program in Attachment A next creates a new line object line, adds add it to the ordered display group object group and then "have" that Line object line. The Escher procedure calls to execute the same are similar those described above with reference to the polygon polygon object were and do not need to be repeated again.

5. Addition of a transformation object

To Include a style object and two geometry objects in the ordered one Display group group creates the example program in Appendix A a translation transformation object and adds add it to the group. The transformation object transform is passed through Calling the Escher procedure ErTranslateTransform_New () generates the similar in a recursive way ErOrderedDisplayGroup_New () works as described above. The subsequent calls to the example program of ErGroupAddObject (group, Transform) work as described above. It should be noted that though the sample program transforms the transformation object to the ordered one Adds display group object, After two geometry objects have already been added, the nature of one ordered display group to be executed Calls transformation objects before geometry objects. Escher poses this characteristic by arranging the transformation object in a separate double-linked list within the parent Display group object group for transformations only and by placing the geometry objects in a double-connected one List exclusively for Geometry objects. When processing, crosses as described above Escher the transformation object list before adding the geometry object list crosses.

6. Generation and addition of subgroup

After adding the transformation object to the ordered ad group object group, the sample program in Appendix A creates a new ordered subGroup display group by calling ErOrderedDisplayGroup_New (). This procedure is described above. The sample program then adds subGroup to the previously created display object group using the ErgoRup_AddObject () Escher procedure, also described above. The example program now has the in 8th generated hierarchy generated. The example program then generates a new geometry object, specifically a torus geometry object torus, using an Escher procedure ErTorus_New (), which operates similarly to the ErPolygon_New () described above. It then adds torus to subGroup using ErGroup_AddObject () and drops both torus and subGroup using ErObject_Dispose (). At this point, the entire, in 8th Model shown has been constructed and the sample program moves to the step 308 ( 3 ) to prepare the model for viewing.

IV Preparation of the model to the views

Escher does the rendering of objects to a view between calls to ErView-StartRendering () and ErView_EndRendering (). These procedures merely initialize relevant data structures prior to rendering (including dropping an initial state to a traversal stack) and purifying various accounting information after rendering. They also include calls to the dresser's own start and end procedures so that the dresser can do the same. The preparer's start and end procedures have been specified for Escher at registration of the conditioner and are identified in appropriate process tables. In particular, the conditioner's finishing procedure by the conditioner's metal dealer was a function of a call with the constant EcMethodType_EndRenderer returned.

Escher supports Multiple reprocessing, where the Escher model more than once which calls appropriate conditioner procedures each time become. Escher indicates that one retracing is required by a status indicator EcViewStatus_ReTraverse reset by procedure ErView_EndRendering () becomes. When the application program calls ErView_EndRendering (), then this procedure again calls the final processing procedure of the Dresser on. In the case of the wireframe conditioner this is Procedure named ErWF-End (). The conditioner is the retransmission indicator to the Escher procedure ErView_EndRendering (), which in turn selbiges to the application program as EcViewStatus_ReTraverse. The preferred technique for the executive program Therefore, it is the model drawing calls into a dispatch loop which is repeated as many times as ErView.EndRendering () the EcViewStatus-ReTranvers returns. This is the format used in the sample program in Appendix A. becomes.

It It should be noted that the Calls to ErView.StartRendering () and ErView_EndRendering () Use View Object View as an argument. An application program can call this procedure in each sequence, with different ones View objects are specified as long as the call to ErView_EndRendering () for a specific view object to the call to ErView_StartRendering () for the same The view object follows and all drawing calls to that view between. It is also an error, ErView_StartRendering () twice for to invoke a special view object without ErView_EndRendering () for it To throw a view object in between and there is an error, ErView_EndReridering () for a call specific view object without first ErView_StartRendering () for this To have a view object called. Different view objects can however, specify the same conditioner if desired the example data for the most different view objects are separated. The exemplary one Application program in appendix makes only a very simple blow with two processing of the model, in particular by complete processing of the model using the previously defined visual object, which specifies the wireframe conditioner, then the choice of conditioner changes in the visual object, to point to a Z-buffer conditioner, and the model still once to the same, now changed To prepare a visual object.

Between Calling ErView_StartRendering () and ErView_EndRendering () can an application program calls to either real-time Escher drawing procedures or Escher drawing procedures for maintenance operation, or both, judge. The real-time routines take data structures (such as a polygon data structure) as a parameter during maintenance operation routines Take objects (for example, an EtGeometryObject) as a parameter. Real-time routines do not trawl any model with, while some maintenance routines, such as ErDisplayGroup_Draw () have a traversal of a model.

A. Traversing a model

Accordingly, the exemplary application program in Appendix A makes a simple call to the conditioner call procedures 212 from Escher ( 2 ), in particular a call to ErDisplayGroup_Draw (). The application program picks up the model for rendering (represented by the ordered display group object group, which forms the root node of the model hierarchy) and the view in which the model is to be rendered (by picking up the view object). The application program could at this point also make additional calls to conditioner call procedures 212 by Escher to prepare additional objects (including additional models) in the same view. The ErDisplayGroup_Draw () procedure is as follows:

Referring to the above procedure, after a certain error checking determined the procedure first, that group an ordered display group is transferred by group to the Escher procedure EiDisplayGroup_GetTypeIndex () becomes. You get then a pointer func on the drawing process, what the ordered Adgroup class that is during initialization with the class method table end display group for ordered display group objects has been registered. If the "in-line" flag for the object group is set, then the program calls the procedure that by func, group picks up and the visual object, to which the group is to be prepared.

If the "in-line" mark for the Object group is not set, then "puts" the procedure EiDisplayGroup_Draw () the traversal state before the procedure is called, the is identified by func, and then "overrides" the traversal state.

In one embodiment, the state of the traversal is represented as the current position in a stack that can be overlaid or detached, and which at each level contains a concatenation of all the transformation arrays before that level of current style characteristics, the current shutdown characteristics, and the current attribute sets , Every time the traversing state A new level is created and all of this information is copied from the previous level to the current level of the stack. Moreover, in this embodiment, the concatenation of the transformation matrices takes place by actually performing each matrix pre-multiplication when the transformation object is encountered in the traversal.

In a preferred embodiment however, the current transformation, the current style characteristics, the running attribute sets and the current shading characteristics in multiple stacks stored, with each of them "filed" only when necessary. A major "state" stack entertains a record at each level, from that of the compound Stacking is to be lifted when the overall traversing state lifted from this level. For example, the current one Transformation state using multiple component stacks represents such as a running "place-to-far" matrix stack, an inverse one Matrix stack, etc. Instead of calculating these matrices at each Stopping the overall traversal state only becomes the consequence of transformation matrices the last calculated matrix to the current position in the traversal of the model. The current calculation will not be executed if not and not until such a thing is really needed. In this way will be a big one Number of matrix calculations avoided.

It It should be noted that in Maintenance company Escher drops and takes off as required while crossing the model. In real-time operation, the application program Also call Escherablege- and -hebhebroutinen, so that by careful Full taxation of calls the application program its own Traversing his own model database.

Returning to EiDisplayGroup_Draw (), the procedure indicated by func is EiView_OrdererdDisplayGroup (), which is as follows:

As can be seen, the above procedure calls a generalized display group list drawing function EiDisplayGroupList_Draw () six times, each time introducing a reference to another of the six double-linked lists in the private data of the ordered display group object group. In particular, the procedure calls the list-drawing procedure with reference first to the list of transformations, then to the list of styles, and then to the list of attribute sets, then to the list of shaders, then to the list of geometries in the group, and then with a pointer to the list of subgroups in the group. Each time, the list-drawing procedure procedure also introduces a reference to the special procedure that records the type of objects that are on the list. If for example, the list. from transforms to EiDisplayGroupList_Draw (), then a reference to the Escher procedure EiTransform_Draw () is also passed. As another example, if the list of geometries passes to EiDisplayGroupList_Draw (), then a handover to the Escher procedure EiGeometry_Draw () also takes place.

you recognizes that when group a list display group object instead of an ordered display group object would be, only a call to EiDisplayGroupList_Draw () would be made. This Call would enter a reference to a single list of objects to group attach, and a reference to a procedure that is both the type of each object, as found on the list, determined, and would the Call up a suitable Escher drawing procedure for this type.

The generalized list-drawing procedure is as follows:

As As you can see, this procedure only revolves around all objects on the double-linked list specified by the caller or, and convicted for each of these objects, the object for the drawing procedure, which is given by the Caller is specified.

Some the Escher object drawing procedures specified by the list-drawing procedure will be called, are now described. To simplify the However, they are described in a different order than the description explains in which they are called when an ordered display group is processed.

B. Drawing Subgroup Objects Display group object

Escher traverses the model in a recursive manner, and for that reason is the Escher procedure, the ErView-OrderedDisplayGroup () to the List drawing procedure for Passes group objects, that are found in the group group group, quite simply EiDisplayGroup_Draw (). This procedure is explained above.

C. Drawing geometry objects in one Display group object

The Escher procedure that identifies ErView-OrderedDisplayGroup () for the geometric object list-drawing routine is EiGeometry_Draw (), which is as follows:

As can be seen, the above procedure only performs certain error checks and then calls the geometry drawing method registered by the geometry class. This procedure is common to all geometry objects, and is as follows:

These Routine receives after error checking first a pointer func to the procedure that the preparer is running View registered four geometry objects of the kind to be processed has (in this case polygons). If func is zero, then finds a decomposition of the geometry object in one described here Way instead. In the present case, however, the wireframe builder ErWF_Geometry_Polygon () registered as the procedure for processing polygon objects. (See the discussion above with reference to ErWF_Register (). This procedure is given in Appendix B.

D. Drawing geometry objects that require a decomposition.

The previous section described how Escher made a geometry project in one in the situation where the renderer of the view has a routine specific to the type of geometry object (ie, polygon). The dresser to be used with Escher must at least support routine that can process points, lines, and triangles and also support routines that handle higher level geometries. In one aspect of the invention, the preparer does not need to support all geometry types that Escher supports in building a model. Rather, Escher automatically determines the absence of a rendering process for a particular geometry type and breaks the geometry down into less complex parts. She then leads them back to the conditioner in this less complex form.

Of the Wire Modeler of the present invention supports polygon objects, however for Purposes of explanation Now suppose that he it does not. This representation is hypothetical also because the wireframe rendering process for rendering triangles, which as you will see, is the geometry, decomposed into the Escher polygon, the same wire model run procedure is the recycled polygons. That is, the conditioner procedure ErWF_Geometry_Polygon () takes either a triangle or a polygon as an argument, determine what it is, and prepare it of the same code. Nevertheless, the hypothesis of explanation serves the cutting technology of Escher.

1. At the Escher initialization called procedures

The procedure at initialization for registering a conditioner has been previously described. Classes and subclasses also register themselves during initialization. For example, the polygon class initially registers by calling the following function:

These Routine creates the class method table for an object in the leaf class Polygon. As with other generation routines, previously described The block of memory is allocated and used Layer technique initialized, the class registration procedure each class first the Size that for your own procedure tables is required, the class registration procedure of their parent class. The class polygon is a class of leaves, So that the Size of her Procedure table is zero. Added polygon above the class every procedure. The size of her own procedure table and recursively call the class registration procedure of their parent class. The last registration procedure of the root class has memory for the entire block of procedure tables, initializes the own part with pointers to their error procedures and returns to Calling the class registration procedure of the subclass back.

On the way back to the original one Caller initializes the class registration procedure of each class their own procedure table with their own error procedures. Furthermore For example, the class registration procedure of each class may provide procedures for Specify inefficiencies of their parent, but only at Option of the parent class. This is accomplished when the class registration procedure the parent class is called, a meta trader and for some classes a virtual one Metahändler are specified as arguments to the call. These Metahandelers can through the class registration procedure of the parent class is called, if desired is specified, specifying a type of procedure and, if called, the trader returns a pointer to the procedure that required is the error method of the specified type of the parent class to render ineffective. If a class does not have a procedure for disabling the error method of the special type of the parent class, The Metahandel returns Zero back.

In the case of the polygon class registration procedure, only one meta-dealer is identified for the class registration procedure of the parent class. The Metahandeler is as follows:

From special relevance to the present discussion should be noted that if after a geometry decomposition procedure asked, the Metahandel one, namely EiPolygon_Decompose. This procedure is described below.

The class registration procedure for the parent class of the polygon class, EtGeometryObject, is as follows:

As As you can see, this procedure calls the class registration procedure their own parent class EiShapeClass_Register () on, specified a metal trader and a virtual metals dealer. After the recursion returns to the above procedure, the process continues Initialize its own procedure table with pointers to Error procedures. It receives these pointers using an Escher procedure EiObjectClassData_GetMethod (), the among other things Metahändler asks the subclass to specify the pointer for each desired method. One of the procedures that prompt the procedure from the Meta dealer of Polygon class is required, is a decomposition method, and, as before highlighted, the method that identifies it is EiPolygon_Decompose ().

It deserves to be emphasized that in Escher the decomposition process identified in the class procedure tables for each geometry type is not for every dresser. The decomposition methods are therefore part of the not included as part of the view, to which it is recycled or as part of the dresser. One recognises, that at another embodiment It may be allowed a preparer, the decomposition process for geometry, which he can not draw directly, to invalidate. In still a further embodiment can the decomposer methods of the conditioner subclass instead of the Added geometry subclass be.

A description of the geometry class meta-merchant is not material to the understanding of the invention, however, the virtual meta-dealer of the geometry class is described below:

From special relevance is that when called by the class registration procedure of the EtShapeObject class, it returns a pointer to EiGeometry_Draw () as an object drawing procedure.

2. Procedures called during processing become

Again reference is made to EiGeometry_DrawMethod () described above. If the conditioner has not registered a procedure for drawing geometries such as are offered to the procedure assumed to be illustrative with respect to polygons for purposes of illustration, then this routine passes the geometry, as previously mentioned at EiGeometry_Decompose (). This procedure is as follows:

As can be seen, after some error checking, this procedure merely passes the geometry object to the method identified by its method table for a decomposition procedure. For polygons, this method was previously registered, as described above, as EiPolygon_Decompose, which is constructed as follows:

The above procedure uses an Escher procedure EiPolygon_Triangulate () to break up the polygon into a bunch of triangles. In a embodiment could the triangulation procedure will generate a new EtGroupObject to for all to apply new triangles. However, a level of error checking and recursion short-circuit, because it is already known that all Objects within the group are geometric objects, sets the triangulation procedure however, preferably all new triangles in an object of class EtGeometryBundle. A geometry bunch is a purely internal geometry object that is just a list of May contain geometries.

The The above procedure can be either in real time or in sustain mode work. In real-time operation it calls the triangulation procedure with a label that instructs the triangulation procedure, not to store the result of the decomposition, but rather it's easy to draw. In the maintenance mode calls the above procedure is the triangulation procedure with a flag which indicates that the Disassembly, as well as with reference to a field, in which it is to be kept. In the above procedure that is Field in which the triangulation procedure relates to the resulting Geometry bundle object enrolls, polyPriv-> decomposition, then pass the above procedure to EiGeometry_Draw ().

EiGeometry_Draw () has been explained above, and in the manner described above, after error checking, merely calls the method identified in the method table of the geometry object passed to it to draw that type of geometry. Usually these procedures are registered by the preparer, however, geometry objects are not public. Dressers do not register any routines to draw these objects. Instead, the process table includes a pointer to Escher's geometry kernel error-locating procedure as follows:

As As you can see, this procedure only goes through the list the geometry objects in the geometry object that is fed to it and passes each of them turn to EiGeometry_Draw (). These are all triangles, so EiGeometry_Draw () the preparer's triangle drawing procedure for each triangle in the decomposition calls.

E. Drawing transformation objects in a display group object

The Escher procedure, which identifies EiView_OrderedDisplayGroup () for the transformation object list-drawing routine, is EiTransform_Draw () as follows:

As can be seen, the above procedure merely calls the transform drawing method for the EtTransformObject class. This procedure is common to all transformation objects and is as follows:

This routine, after error checking, first gets a pointer to the procedure that has the process table of the renderer of the current view for executing transformation objects of the type to be executed (in this case, translations). Escher's error procedure for executing translation transformations is as follows:

V. Administration and use of quality collections

A. Data Structures

A quality collection object is a data structure that is a linked list of quality groups contains objects. A quality collection object is an example of the class EtQualityCollectionObject, as in 6 is a subclass of the EtSharedObject class, which in turn is a subclass under the EtObject class. Accordingly, following the format of 5 a quality collection object the format in memory stored in 11 is shown. In particular, an area of the memory 1102 It is intended to include pointers to the methods of the EtQualityCollectionObject class, and this range 1102 contains pointer 1104 on object method and pointer 1106 on shared object methods (none of which are present). The EtQualityCollectionObject is a leaf class, so the class omits a procedure table specific to the quality collection object methods. This structure also contains sample data for the quality collection object in the storage area 1110 , This area contains sample data specific to the object class in one part 1112 (on the object class 1102 showing), example data specific to the sub-object class, in one part 1114 (containing a reference count) and example data specific to the quality collection object class in a part 1116 , The quality collection object data is a data structure of type EtQualityCollectionPrivate that starts a linked list of quality group objects.

A quality group object is a data structure that contains a set of quality control type variables, each of which has a value that is less than two or more. chooses more options in a compromise between rendering quality and rendering speed. Each quality group object is an example of the class EtQualityGroup object, as in 6 shown is a subclass of the EtSharedObject class. A quality group object has the in 12 shown format. In particular, an area of the memory 1202 contains pointers to methods of class EtQualityGroupObject, and this range 1202 contains pointer 1204 on object method and pointer 1206 on shared object methods (none of which are present). The structure also contains sample data for quality group object in the area 1210 of the memory. This area contains sample data specific to the object class in one part 1212 (on the object class 1202 showing), example data specific to the shared object class, in one part 1214 (Containing a reference count), and example data specific to the quality group feature class in a part 1216 , The quality group object data is a data structure of type EtQualityGroupObjectPrivate that contains the fields listed in Table I. TABLE I EtQualityGroupObjectPrivate field data type quality Index interval Pointer to EtQualityGroupObjectPrivate preceding in collection pointer Pointer to EtQualityGroupObjectPrivate following in collection pointer List of quality type entries structure

As you can see contains apart from the linked list pointers for other quality group objects in the quality collection object the quality group object a field for storing a quality index value corresponding to the specific Group is assigned. In one embodiment, in the quality index of Type interval and can range from 0.0 to 1.0, but in others embodiments can the quality index value for example, be an integer. It should be noted that in the presently described embodiment the quality index value although in a field in the quality group object is stored, in another embodiment of a special quality group associated quality index but can simply be a calculated value, such as n / N, where n is the position of the special quality group in the connected List of the collection and N the total number of quality groups in the collection are. In yet another embodiment, the quality index is the one of a special quality group is assigned, only n, with the special quality group the n quality group is in a collection list of quality groups. Many other Techniques can in different embodiments used to produce a quality index value of a corresponding quality group assigned.

Referring again to Table 1, each quality group object also contains a list of quality type entries. The quality type entries are a set of variables, each one of which Contains value that selects from at least two options in a respective compromise between rendering quality and rendering speed. For one embodiment, Table II gives the various quality control variables and the various options available for that parameter. TABLE II QUALITY TYPE PARAMETERS field options line style on off shaders out, fast, one lighting out, fast, one level of detail on off calculate shadows on off calculate transparency out, fast, one calculate reflections on off remove back on off interpolation flat, gouroud, phong progressive refinement on off Smoothing level flat (0.0 to 1.0) beam depth integer

you recognizes that different embodiments may contain a different set of parameters in each quality group and / or different options for can have any parameter in the table.

B. Procedures for setting up a quality collection

Referring to Appendix A, the example application program sets up a quality collection by calling an ExSetupQualityCollection (& qualityCollection) procedure. This procedure, which is part of the application program, uses procedures specified by Escher to build a collection of quality groups in a desired manner. 13 Figure 10 is a flow chart of an ExSetupQualityCollection () procedure that sets up a quality collection having four quality groups with quality indices 0.2, 0.4, 0.6, and 0.8, respectively.

Referring to 13 creates in one step 1302 the routine initially a new quality collection object. This is achieved with a call to an Escher procedure ErQualityCollectionObject_New (), which allocates space and initializes the data structures in the same way as described above with reference to FIG 10 is described. ErQualityCollectionObject_New () returns a pointer to the new quality collection object, which is the procedure of 13 stores in a variable QualityCollection.

In one step 1304 generates the procedure from 13 a new quality group object using an Escher routine ErQualityGroup_New (qualityIndex), where qualityIndex = 0.2. This routine allocates space for the new quality group object using the technique of 10 and initializes the quality index field of the quality group to 0.2.

In of the presently described embodiment sets the call the procedure ErQualityGroupObject_New () the quality index for the new group permanent. If the group object later becomes a quality collection added will put the Escher procedure doing this (described below) the new group in the linked list of the collection in the appropriate Episode, by the quality index the quality group is determined. If the quality index the to be added Group the quality index of a group already in the collection is doubled an error returned.

In a further embodiment he does not take ErQualityGroupObject_New () argument, but initializes it the quality index field the new group to a zero value. Escher routines are for the application program provided the quality index following the group as desired.

Returning to 13 After creating the first new quality group, the application program sets the parameters in the first group as in the step 1306 desired. In the presently described embodiment, each of the quality type parameters listed in Table II above is mapped to a single 4-character type code of type EtQualityType. To enable future improvements, application programs do not read and write the parameter values directly, but do so only through certain Escher routines. In addition, application programs can use the Escher routines to determine which quality parameters are supported by the specific version of Escher. Quality type codes are registered with Apple Computer, Inc., are available to application program developers and are useful for subsequent development by Escher.

The Escher routines given in Table III are used by the application program to manage the content of a quality group. TABLE III QUALITY GROUP MAINTENANCE ROUTINES Escher routine Comments EtStatus ErQualityGroup_GetFirstType (EtQualityGroupObject quality Group, EtQualityType * qualityType); Returns 4-character names of the first "type" in the specified quality group. Return the value qualityType. EtSatus ErQualityGroup_GetNextType (EtQualityGroupObject qualityGroup, EtQualityType * quality Type); Returns 4-character names of the next "type" in the specified quality group. EtStatus ErQualityGroup_GetTypeData (EtQlityGroupObject qualityGroup, EtQualityTypequalityType, void * data); Receives the group value for quality type qualityType (for example, Image Smoothing Level). Data is returned in structure "data". Returns errors if group has no entry for the specified quality type. EtStatus EtQualityGroup_SetTypeData (ErQualityGroupObject qualityGroup, EtQualityType qualityType void * data); Sets the value for quality type qualityType to the specified quality group. Returns errors if the group has no entry for the specified quality type. EtStatus ErQualityGroup_GetQualityIndex (EtQualityGroupObject qualityGroup, float * qualityIndex); Receives the quality index value associated with the quality group specified in qualityGroup and returns the value in qualityIndex.

The Routine for maintaining quality index, the one of a special quality group is assigned as an independent routine because the quality index value not one of the quality types using ErQualityGroup_GetTypeData () and Er QualityGroup_SetTypeData () available are. In a further embodiment however, the index value associated with a particular quality group may as one of the quality types which are accessible using these routines.

In step 1308 adds the procedure from 13 the first quality control group object to the quality collection object that was created in step 1302 was generated added. This is achieved using an Escher procedure ErQualityCollection_AddGroup (), which is one of several quality collection maintenance procedures described in Table IV. TABLE IV QUALITY SAMPLING MAINTENANCE ROUTINES Escher routine Comments EtStatus ErQualityCollection_GetFirstGroup (EtQualityCollectionObject qualityCollection, EtQualityGroupObject * qualityGroup); Returns a pointer to the first quality group in the specified quality collection in quality group. EtStatus ErQualityCollection_GetNextGroup (EtQualityCollectionObject qualityCollection, EtQualityGroupObject * qualityGroup); Returns a pointer to the next quality group in the specified quality collection in quality group. EtStatus ErQualityCollection_AddGroup (EtQualityCollectionObject qualityCollection, EtQualityGroupObject * qualityGroup); Adds the specified quality group to the specified quality collection. Automatically sorts the new quality group into the list associated with the quality collection according to the quality index. Returns an error if the quality index of the new quality group is already assigned to another group in the collection. EtStatus ErQualityCollection_DeleteGroup (EtQualityCollectionObject qualityCollection, EtQualityGroupObject * qualityGroup); Deletes the specified quality group from the specified quality collection. Since quality groups are shared objects, this procedure only reduces the reference count, currently deleting the object and clearing the memory allocation only if the resulting reference count is zero.

As you can see, adds the routine ErQualityCollection_AddGroup () the new quality group automatically to collection in sorted order in accordance with the quality index added. If the quality index the new group already assigned to another group in the collection is, an error is returned. In another embodiment can the Escher routines, however, write to take account of the possibility that two or more quality groups the same quality index in a single quality collection to have. Also, as previously mentioned, other embodiments possible, where the application program is the quality index that a group like required is assigned, can change. If in such an embodiment the quality index already a group in one or more quality collection objects is assigned, one recognizes that certain Accounting features may be accomplished Need to become, around every affected quality collection in sorted order and / or duplicate quality indices in the same quality collection to handle.

Referring to 3 After adding the first quality group object to the quality collection object, the procedure creates a second new quality group object in the step 310 , this time using a quality index of 0.4. In step 312 The procedure sets the parameters in the second quality group object as desired and in the step 1314 It adds the second quality group object to the quality object in the manner described above.

In the steps 1316 . 1318 and 1320 a third quality group object with a quality index of 0.6 is generated, modified as desired, and added to the quality group object. In the same way, in the steps 1322 . 1324 and 1326 generates a fourth new quality group object using a quality index of 0.8, the parameters are set appropriately in the fourth quality group object, and it is added to the quality collection object in the manner described above. This completes the application program procedure ExSetupQualityCollection () (step 1328 ).

It will be appreciated that in another embodiment, rather than requiring each application program to build its quality collection, the Escher routines may provide a procedure merely for providing error quality collection. Such an error quality collection can be predefined to contain four or five quality groups, each filled with quality type values, so that the overall progress from the quality group with the lowest quality index to the quality group with the highest The quality index is followed by a monotonously increasing overall quality and a monotonically decreasing overall speed in the overall quality / speed compromise spectrum.

you recognizes further that for the treatment some pictures a first quality group, the first set of quality type values has, with a higher quality and a lower speed than this with a second group giving a second set of quality type values has, that would be the case while another picture with lower quality and higher speed with the first quality group could be processed and with higher quality and low speed with the second quality group. Preparations that are carried out with different conditioners can also be executed in reverse order. Because of these possibilities to lead Escher routines no arbitrary Conception of which permutations of quality type values lower or higher quality indices should be assigned. The application program is free, every desired Set of quality type values in a given quality group to build, without consideration on the quality index value, of such a quality group assigned. It is understood that in another embodiment such a relationship actually created can be.

C. Procedures for Selecting and Maintaining a Quality Group

An advantage of having multiple quality groups in a collection, each associated with a corresponding quality index value, is that an application program can prompt a user to select a desired point in the tradeoff between rendering quality and speed using an intuitively appropriate mechanism. Referring back to the example program in Appendix A, the application program does this using an application program routine ExGetDesiredQualityIndex (). 14 Fig. 10 is a flow chart showing the major steps in such a procedure. Referring to 14 shows the procedure in one step 1402 a quality button pictogram. Such a pictogram is in 15 As you can see, it looks like a button. It has a pointer pointing straight to a quality index value of 0.0, and the user can press on the point of the needle and rotate the needle around the circle to select any desired quality index between 0.0 and almost 1.0. In one embodiment, the available positions of the button are stepless, allowing the user to select a quality index with the full fineness of the binary register in which it is stored. In another embodiment, only discrete values can be selected.

Returning to 14 takes in step 1404 the procedure selects the user selected quality index. In step 1406 the desired quality index is returned to the call routine.

The conditioner is informed of the selected quality group by appending the quality group to either the renderer object in one embodiment or the view object in one embodiment. In the presently described embodiment, it is appended to the viewing object. Escher supplies in Table V the routines for selecting and maintaining a quality group object. TABLE V ROUTINES FOR SELECTING AND OBTAINING QUALITY GROUPS Escher routine Comments EtStatus ErView_SelectQualityGroup (EtViewObject view, EtQualityCollectionObject qualityCollection, float desiredQualityIndex); Selects a quality group from a specified quality collection depending on the quality index, which is in desiredQualityIndex. If the specified quality index does not match the index associated with any quality group in the quality collection, this routine selects the quality group with the closest quality index. EtStatus ErView_GetQualityGroup (EtViewObject view, EtQualityGroupObject * qualityGroup); In qualityGroup, returns a pointer to the quality group object currently selected in the specified view object. This procedure can be used by the application program to manage single values in a quality group. This procedure or the like can also be used by a preparer as a prelude to obtaining the individual quality type values, depending on what he sets up his reprocessing procedures.

The Exemplary application program in Appendix A. uses the Escher Routine ErView_SelectQualityGroup () to set the quality group for the view object select their quality index with that matches or closest to him comes specified by the Be user. It should be noted that others embodiments other rounding functions for can use the situation where the desired quality Index does not agree with that the one of the quality groups in the quality collection assigned. In the present embodiment, the quality collection with the nearest one Quality index value selected; if the quality indices, the second quality groups in the same way from the desired quality index are different, then the group with the higher quality index selected. In another embodiment will be the desired Quality index always rounded up and in yet another embodiment becomes the desired quality index always rounded.

D. conditioner procedures

Any preparer called to render a shape of a particular view will do so depending on the individual values of the quality types in the quality group currently associated with the view object. Different preparers may choose to address different quality type parameters and ignore others. 16 FIG. 10 is a flow chart of pertinent aspects of a procedure ErRT_Geometry_Triangle () of a ray painter builder for rendering a triangle.

Referring to 16 uses the procedure in step 1602 the above Escher procedure ErView_GetQualityGroup () or a similar one to get a pointer to the quality group currently assigned to the view. In step 1604 the procedure gets the data for the triangle that is to be rendered to the view. In the steps 1606 . 1608 and 1610 The procedure looks for values of two different quality type parameters in the current quality group to determine which variation of the triangulation procedure should be used. Especially in the step 1606 the procedure obtains the value for the quality type parameter "compute reflections" using the Escher procedure ErQualityGroup_GetTypeData (). If the value is "on", which is a choice of higher quality / lower speed, then the controller goes to step 1608 above. However, if "calculate reflections" is "off", control goes to step 1610 above.

step 1608 Next, determine the value of the quality type parameter "calculate shadows" in the current quality group. If "compute shadow" is "on", then prepare in one step 1612 the Perform the triangle using the "Jet depth" quality type parameter value using Reflections and Using Shadows. If "compute shadow" is "off" then the procedure will prepare the triangle using the specified beam depth, but using reflections but without shadow (step 1614 ).

If "calculate reflections" was "off", then do in step 1610 a determination similar to the step 1608 , If "compute shadow" is "on", then prepare in step 1616 the procedure reveals the triangle using the specified beam depth, but calculating shadows without calculating reflections. If "calculate shadows" in step 1610 Is "on", then prepare the procedure in step 1618 '' the triangle using the specified beam depth, but without calculating any shadows or reflections.

It can be seen that, for simplicity, the conditioner procedure in FIG 16 only to the "ray depth", "compute reflections" and "compute shadows" - quality type parameter in the current quality group object responds. However, other conditioners may respond to much more of the quality type parameters, as may be appropriate for the particular type of conditioner.

ANHANG B ErWF Geometry Polygon()

The foregoing description of preferred embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise embodiments shown. Obviously, many modifications and variations can be made by practitioners of this field. The embodiments have been chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling other persons skilled in the art to understand the invention for numerous embodiments and numerous modifications as intended for the particular intended purpose are suitable. The scope of the invention should be determined by the following claims and their equivalents. ANNEX A EXEMPLARY APPLICATION PROGRAM

APPENDIX B ErWF Geometry Polygon ()

Claims (10)

Method for creating a representation of a Scene that is displayable on a graphics device comprising the steps: Providing a representation of a first object; Deliver of several quality control data groups, each of several quality control type variables have each value of a type variable, the among a plurality of options in a compromise between the processing quality and select the editing speed; Select one chosen the quality control data groups for a Object drawing subsystem; and Invoke the object drawing subsystem for processing the first object in the scene; the Object drawing subsystem matches the first object in the scene with the values in each of the type variables in the selected quality control data group edited. The method of claim 1, wherein the first object is a model that contains multiple subobjects. The method of claim 1, wherein the step of providing a plurality of quality control data groups comprises the steps of: providing a plurality of preliminary quality data control groups each having a plurality of quality control type variables; and calling a value setting procedure with an indication of a desired one of the quality type control variables, a desired one of the quality control data groups and a desired value for writing into the desired variable in the desired group, the value setting procedure setting the desired value in encrypts the desired variable in the desired group. The method of claim 1, wherein the step of Delivery of several quality tax groups the following steps include: Deliver a preliminary one Variety of quality data control groups; and invoking a data group addition procedure to add one desired new quality data control groups to the provisional Variety of quality data control groups. The method of claim 4, wherein each of the quality data control groups in the provisional Variety of quality data control groups has assigned a different respective index value, and wherein the Step of delivering multiple quality data control groups continues the step of assigning a desired new index value the desired new quality control data group having the desired new one Index value is different from the index values that each of the quality control data groups in the provisional Variety of quality control data groups assigned. The method of claim 1, wherein each of the quality control data groups the variety of quality control data groups each assigned an index value, the step being the Selection of a selected one the quality control data groups the step of calling a data group selection procedure with a desired Includes index value, and wherein the data group selection procedure is the selected one of Quality control data groups in dependence of the desired one Selects index value. The method of claim 6, wherein the data group selection procedure the selected one the quality control data groups as one of the quality control data groups in the variety of quality control data groups selects their associated Index value the desired Index value closest is. The method of claim 1, wherein a first of the Quality control type variables contains a value, who chooses whether (a) shaders are calculated by a high quality method should; (b) Shaders by a high-speed method or (c) shaders should not be calculated should. The method of claim 1, wherein a first of the Quaiitätssteuertypvariablen contains a value, who selects a level of detail, the object drawing subsystem uses the first object in the To process the scene. The method of claim 1, wherein the plurality of quality type variables includes at least two of the group consisting of: (a) a line style variable containing a value indicating whether the object drawing subsystem inputs or removes the first object into the scene with line styles to process; (b) a shader variable containing a value indicating whether the object drawing subsystem is to render the first object into the scene with shaders off, fast or on; (c) a lighting variable containing a value indicating whether the object drawing subsystem is to render the first object into the scene with illumination off, fast or on; (d) a detail level variable containing a value indicating whether the object drawing subsystem is to render the first object into or out of the detail level scene; (e) a shadow calculation variable containing a value indicating whether the object drawing subsystem is to compute shadows when rendering the first object into the scene; (f) a transparency calculation variable containing a value indicating whether the object drawing subsystem should calculate transparency when the first object is rendered in the scene; (g) a reflection calculation variable containing a value indicating whether the object drawing subsystem should calculate reflections when rendering the first object into the scene; (h) a reverse use removal variable containing a value indicating whether the object drawing subsystem is to render the first object into the scene with elimination of the return action on or off; (i) an interpolation variable containing a value indicating whether the object drawing subsystem is to render the first object into the flat, Gouraud or Phong interpolation scene; (j) a progressive refinement variable containing a value indicating whether or not the object drawing subsystem is to render the first object into or out of the progressive refinement scene; (k) an image smoothing level variable containing a value indicating an image smoothing level with which the object drawing subsystem is to render the first object into the scene; and (l) a beam depth variable containing a. Contains value indicating a beam depth with which the object drawing system is to process the first object in this scene.