DE19581872B4

DE19581872B4 - Dreidimensionales Graphikaufbereitungssystem

Info

Publication number: DE19581872B4
Application number: DE19581872T
Authority: DE
Inventors: David Boulder Creek Jevans; Philip J. Boulder Creek Schneider
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 1994-12-22
Filing date: 1995-12-15
Publication date: 2006-11-16
Anticipated expiration: 2015-12-16
Also published as: JP4129039B2; GB9713246D0; GB2312818B; GB2312818A; JP2007257661A; WO1996019780A1; AU4471496A; JP2006079638A; JP4188962B2; JP3763079B2; GB2312818A8; JPH10511485A; DE19581872T1

Abstract

Verfahren zum Erschaffen visueller Bilder auf einer Mehrzahl von unterschiedlichen Graphikausgabevorrichtungen zur Verwendung mit einem Objektzeichnungsuntersystem, welches einen Aufbereiter verwendet, der für das Objektzeichnungsuntersystem angegeben wird, um ein Objekt, das dem Objektzeichnungsuntersystem angegeben wird, in eine dem Objektzeichnungsuntersystem angegebene Szene aufzubereiten, umfassend die Schritte:
Bereitstellen einer Darstellung eines Objekts in einem Speicher;
Aufrufen des Objektzeichnungsuntersystems ein erstes Mal mit einer Identifikation des Objekts, einer Identifikation einer ersten Szene und einer Identifikation eines ersten zu verwendenden Aufbereiters; und
Aufrufen des Objektzeichnungsuntersystems ein zweites Mal mit einer Identifikation des Objekts, einer Identifikation einer zweiten Szene und einer Identifikation eines zweiten zu verwendenden Aufbereiters; und
Ausgeben der ersten und zweiten Szenen auf verschiedene der Graphikausgabevorrichtungen.

Description

Ein Teil der Offenbarung dieser Patentschrift enthält Material, auf das Anspruch auf Urheberrechtschutz erhoben wird. Der Inhaber des Urheberrechts hat keine Einwendungen gegen die Facsimilereproduktion der Patentschrift oder der Patentoffenbarung, wie sie in den Akten oder Aufzeichnungen des US-Patent- und Markenamtes erscheint, durch irgendeine Person, behält sich aber im übrigen alle anderen Rechte vor.
HINTERGRUND
1. Gebiet der Erfindung
Die Erfindung bezieht auf Graphikaufbereitungssysteme und insbesondere auf Softwarewerkzeuge zur Unterstützung von Graphikanwendungsentwicklern.

2. Beschreibung der einschlägigen Technik

Graphikaufbereitung ist der Prozeß der Berechnung eines zweidimensionalen Bildes (oder Teil eines Bildes) aus dreidimensionalen geometrischen Formen. Ein Objekt wird hier als dreidimensional betrachtet, wenn seine Punkte durch wenigstens jeweils drei Koordinaten spezifiziert werden (gleichgültig, ob das Objekt in allen drei Dimensionen eine Dicke aufweist oder nicht). Ein Aufbereiter ist ein Werkzeug, das Graphikaufbereitungsvorgänge in Abhängigkeit von zugeführten Anforderungen ausführt. Manche Aufbereiter sind ausschließlich Software, andere sind ausschließlich Hardware und manche sind unter Verwendung von beidem ausgeführt (z. B. Software mit Hardwareunterstützung-Beschleunigung). Aufbereiter übergeben typischerweise Szenen in einen Puffer, der anschließend an die Graphikausgabevorrichtung ausgelesen wird, aber es ist bei manchen Aufbereitern möglich, ihre zweidimensionale Ausgabe direkt an die Ausgabevorrichtung zu überschreiben. Ein Graphikaufbereitungssystem (oder Subsystem), wie es hier verwendet wird, bezieht sich auf alle Verarbeitungsniveaus zwischen einem Anwendungsprogramm und einer Graphikausgabevorrichtung. In vielen bekannten Systemen ist das Graphikaufbereitungssystem inhaltsgleich mit dem Aufbereiter; das heißt, der Aufbereiter wird direkt durch das Anwendungsprogramm ohne zwischenliegende Verarbeitungslagen aufgerufen.

Graphikaufbereitungssysteme haben typischerweise eine Direktbefehlsschnittstelle oder eine Erhaltungsschnittstelle für das Anwendungsprogramm. Eine Echtzeitschnittstelle ist eine echte Verfahrensschnittstelle, in der das Anwendungsprogramm jedes geometrischen Elements für das Graphikaufbereitungssystem jedesmal spezifiziert, wenn das Bild aufzubereiten ist. Das Aufbereitungssystem unterhält keine Modelldatenbank von Szene zu Szene, auch wenn das Anwendungsprogramm dies tun könnte. Echtzeitschnittstellen sind hoch attraktiv für die Aufbereitung von Szenen, bei denen sich das Modell mit jedem Rahmen ändert, wie beispielsweise zur Darstellung von Simulationen, zur Vorausschau von Animationssequenzen oder zum Lesen einer Serie von Modellen aus einem Dokument. Andererseits erfordert eine Direktbefehlsschnittstelle, daß die gesamte Szene über Prozeßanforderungen bei jedem Rahmen an den Aufbereiter übertragen wird, was zu einer hohen Datenbandbreite zwischen dem Anwendungsprogramm und dem Aufbereiter führt. Auch ist das Dokumentenformat für ein Modell häufig ein Strom von Zeichenbefehlen anstelle das Modell selbst, was seine Nützlichkeit als Datenaustauschformat beschränkt. Echtzeitschnittstellen sind auch weniger förderlich bei der Schaffung einer einen Werkzeugsatz nachbildenden Funktionalität des Anwendungsprogramms, und sie schließen gewöhnlich einen Benutzerschnittstellenwerkzeugsatz aus, der Objekte in der Szene bearbeitet.

In einem Aufrechterhaltungsbetriebssystem, das manchmal Anzeigelistensystem genannt wird, hält das Graphikaufbereitungssystem eine Datenbankdarstellung des dreidimensionalen Modells aufrecht. Bei jedem Rahmen überquert das Aufbereitungssystem die Datenbank des aufrecht erhaltenen Modells und zeichnet es. Dieses kann durch einen einzigen Befehl an das Graphikaufbereitungssystem durch das Anwendungsprogramm ausgelöst werden anstelle durch einen Strom von Zeichenbefehlen, die die gesamte Szene beschreiben. Wenn sich das Modell ändert, editiert oder aktualisiert das Anwendungsprogramm die Modelldatenbank und fordert das Aufberei tungssystem erneut auf, die Szene aufzubereiten. Der Vorteil eines Aufrechterhaltungsbetriebssystems umfassen die verminderte Bandbreite zwischen dem Anwendungsprogramm und jedem Hardwarebeschleuniger. Das Dokumentenformat der Modelldatenbank kann auch einfach als Datenaustauschformat verwendet werden, da es nicht lediglich eine Liste von Verarbeitungsbefehlen ist. Die Existenz einer Objektdatenbank bietet auch einen zusätzlichen Weg zur Ausführung eines Benutzerschnittstellenwerkzeugsatzes und einer Funktionalitätsnachbildung. Aufrechterhaltungsaufbereiter können auch Aufbereitungsinformationen Puffern und können Information zur Optimierung einer Szenedurchquerung puffern. Andererseits haben Aufrechterhaltungsaufbereitungssysteme einen höheren Aufwand zur Editierung der Szenendatenbank, und sie beschränken Anwendungsprogrammgestaltungen dadurch, daß sie die Szene in eine systembestimmte Datenstruktur, üblicherweise eine Hierarchie, zwingen, so daß viele Anwendungsprogramme erforderlich werden, um eine Duplikatkopie des Modells in ihrem eigenen Format zu erhalten.

In dem Aufsatz von Mark A. Tarlton und P. Nong Tarlton "A Framework for Dynamic Visual Applications," Proceedings of the 1992 Symposium on Interactive 3D Graphics, Cambridge, MA, 1992, Seiten 161–164, was hier durch Bezugnahme in die Beschreibung eingebaut wird, ist ein Aufrechterhaltungsaufbereitungssystem beschrieben, das ein Alzweckdatenbanksystem ausführt, um das Modell zu organisieren, anstelle das Modell zu zwingen, in einer einzigen Systemhierarchie zu bleiben. Eine solche Technik versucht, die Vorteile des Aufrechterhaltungssystems ohne die Nachteile anzubieten.

Ein Schema so hohen Niveaus kann jedoch nicht das Modellorganisationsproblem für alle Anwendungen lösen und ist nicht optimal für Visualisierungsanwendungen, bei denen sich die Szene mit jedem Rahmen ändert.

Konventionelle Graphikaufbereitungssysteme weisen mehrere zusätzliche Probleme auf, die ihre Nützlichkeit in der einen oder anderen Art begrenzen. Die nachfolgende Liste beschreibt einige der Graphikaufbereitungssysteme, die gegenwärtig verfügbar sind.

GL^TM: GL von Silicon Graphics ist ein Echtzeitaufbereiter, der hauptsächlich für interaktive Graphik verwendet wird. GL ist in "Graphics Library Programming Guide", Silicon Graphics Computer Systems, 1991, beschrieben, was hier durch Bezugnahme eingebaut wird. Es war als Schnittstelle für die IRIS-Aufbereitungshardware von Silicon Graphics entworfen und bietet kein Dokumentenformat, keine Druckerausgabe, keine Modellierfähigkeit oder Benutzerschnittstellenwerkzeuge. GL unterhält einfache Anzeigelisten, die im wesentlichen Makros für eine Folge von GL-Befehlen sind. Die GL-Routinen führen Aufbereitungsvorgänge durch Abgabe von Befehlen an die IRIS-Hardware durch.

StarBase^TM: StarBase von Hwelett-Packard's ist ein Echtzeitsystem, das GL sehr ähnlich ist, die meisten seiner Merkmale und Nachteile teilt. StarBase ist in "Starbase Graphics Techniques", von Hewlett-Packard Company, 1991, beschrieben, was hier durch Bezugnahme eingebaut wird. Für StarBase sind zahlreiche Vorrichtungsdriver verfügbar zum Ausgeben der aufbereiteten (das heißt, zweidimensionalen) Szenen an unterschiedliche Graphikausgabevorrichtungen, die von Plottern bis zu hoch komplizierten 3-D-Graphikarbeitsstationen reichen.

RenderMan^TM: RenderMan von Pixar ist ein Echtzeitsystem, das hauptsächlich zur Unterstützung von Hochqualitätsaufbereitung entworfen ist. RenderMan ist beschrieben in Steve Upstill, "The RenderMan Companion", Addison-Wesley, Reading, MA, 1990, was hier durch Bezugnahme eingebaut wird. Wie in Tony Apodaca, "RenderMan Interface Specification Version 4.0 Beta", Januar 1992, hier durch Bezugnahme eingebaut, beschrieben ist, bieten neuere Versionen der RenderMan-Beschreibung neue Routinen, die die existierenden RenderMan-Befehle überbrücken und die Verwendung verschiedener Aufbereiter ermöglichen. Der Aufbereiter wird mit einem einzigen Befehl vor der Aufbereiten der Szene spezifiziert, und er beeinflußt die gesamte Szene. Siehe auch Pixar: "Uick RenderMan Interface und Implementation Specification", 1992, was hier durch Bezugnahme eingebaut wird.

PHIGS: PHIGS ist beschrieben in PHICS Committee, A. van Dam, chair, "PHIGS Functional Description, Revision 3,0", Computer Graphics, 22(3), 1988, Seiten 125–218, was hier durch Bezugnahme eingebaut wird, und ist ein Abkömmling von GKS-3D, beschrieben in International Standards Organization, "International Standard Infor mation Processing Systems Computer Graphics – Graphical Kernel System for Three Dimensions (GKS-3D) Functional Description", ISO Dokument Nr. 8805:1988(E), American National Standards Institute, New York, 1988, was hier durch Bezugnahme eingebaut wird. PHIGS war ein Kommittee-entworfenes System für eine interaktive 3D-Graphikanzeige. In PHIGS besteht die gesamte Modelldatenbank in einer einzigen Hierarchie. Anwendungsprogrammierer müssen eine große Zahl Editier- und Hierarchiemanipulationsbefehle lernen, um das System wirksam zu benutzen. PHIGS verwendet einen einzigen Aufbereiter, der alle Aufbereitungsarten unterstützt, die in PHIGS verfügbar angegeben sind, und unterstützt keine alternativen Aufbereiter für Photorealismus oder andere Effekte.

PEX: PEX ist ein Anhang zum X-Windows-Systems, definiert durch ein Serienprotokoll (zum Übertragen von Daten zwischen einem Anwendungsprogramm und dem X-Windows-System) und einen Satz Semantic, die ursprünglich von PHIGS abgeleitet war. PEX hat verschiedene verfügbare APIs, die alle den Aufrechterhaltungsbetrieb, den Echtzeitbetrieb und Gemischtbetriebs-Funktionsbefehle zum Zeichnen, Zustandsändern usw. unterhalten. PEX ist in "PEX Protocol Specification, Version 5.0P-X Public Review Draft", 14. September 1990, Massachusetts Institute of Technology beschrieben, was hier durch Bezugnahme eingebaut wird.

HOOPS^TM: HOOPS von Ithaca Software ist beschrieben von Garry Wiegand und Bob Covey, in "HOOPS Reference Manual, Version 3.0" Ithaca Software, 1991, was hier durch Bezugnahme eingebaut wird. Es ist ein 3D-Graphiksystem im Aufrechterhaltungsbetrieb, das das Modell in einer Hierarchie organisiert, deren Knoten durch Textstränge zugänglich sind, hauptsächlich in der gleichen Weise, wie die Dokumente im UNIX-Dokumentensystem bezeichnet sind. Wie PHIGS unterstützt HOOPS einen einzigen Aufbereiter. HOOPS bietet jedoch eine extensivere Szenen-Editierfunktionalität als PHIGS.

DORÉ^TM: DORÉ von Kubota ist ein Beispiel eines 3D-Graphiksystems mit einem objektbezognene Design. Es ist beschrieben in Dorè Programmer's Guide", Ausgabe 5.0, Kubota Pacific Computer Inc., 1991, was hier durch Bezugnahme eingebaut wird. DORÈ wurde so gestaltet, daß Szenendaten durch viele Arten von Aufbereitern aufbereitbar sind und nicht nur durch einen einzigen monolithischen Aufbereiter, wie bei PHIGS vorgesehen. Aufbereiter können jedoch zu DORÈ nicht dynamisch hinzugefügt werden, weil die Aufbereitungsverfahren in das System eingebaut sind. Bei DORÈ wird die Wahl der Aufbereiter durch Eingeben des gegenwärtigen Aufbereitungsstiels in das DORÈ-"Ansichtsobjekt" spezifiziert. DORÈ veranlaßt dann auch das Anwendungsprogramm, das Modell dem Ansichtsobjekt vor dem Aufbereiten anzuhängen. Dieses beschränkt DORÈ darauf, gleichzeitig nur einen Aufbereiter zu verwenden. Es gibt andere Design-Überlegungen bei DORÈ, die es ebenfalls darauf beschränken, gleichzeitig nur einen Aufbereiter zu verwenden; beispielsweise ist zur Aufrechterhaltung des Aufbereitungszustandes nur ein Satz globaler Variablen vorhanden.

DORÈ ist ein Aufrechterhaltungsbetriebssystem. Um viel von der Mühe zu erleichtern, die mit dem Editieren der Modellhierarchie einhergeht und um die dynamischen Datenbanken und die Benutzerinteraktion mit dynamischen Datenbanken zu erleichtern, unterstützt DORÈ Anwendungsrückrufobjekte, wodurch ein Anwendungsprogramm eine aufzurufende Funktion definiert, wenn das Rückrufobjekt während der Szenenüberquerung angetroffen wird.

Inventor^TM: Inventor ist ein objektgerichteter 3D-Graphikbenutzerinteraktionswerkzeugsatz, der auf dem GL-Graphiksystem sitzt. Wie DORÈ unterstützt Inventor mehrere Aufbereiter, indem es ein Aufbereiter-spezifisches "Aufbereitungs"-Verfahren für jeden Objekttyp aufweist. Inventor ist ein Aufrechterhaltungsbetriebssystem, bei dem die gesamte Szene in einem "Szenengraph" liegt. Inventor hat Aufbereitungsobjekte, die ein Modell als einen Parameter nehmen. Der Aufbereiter wird durch den Aufbereitungsvorgang ausgesucht, der beim Zeichnen des Modells verwendet wird. Der Aufbereitungsvorgang zeichnet das gesamte Modell durch Durchquerung des Modells und Aufrufen des geeigneten Aufbereitungsverfahrens für jedes Objekt. Der übliche Aufbereitungsvorgang ist der GL-Aufbereitungsbetrieb. Inventor ist beschrieben in Wernecke, "The Inventor Mentor", Addison-Wesley (1994), hier durch Bezugnahme eingebaut.

Andere für die vorliegende Beschreibung wesentliche Veröffentlichungen, die sämtlich durch Bezugnahme hier eingebaut werden, sind: Bergman, Fuchs und Grant, "Image Rendering by Adaptive Refinement", Computer Graphics, 20(4), 1986, Seiten 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, Dezember 1974; Chen, Rushmeier, Miller und Turner, "A Progressive Multi-Pass Method for Global Illumination", Computer Graphics, 25 (4), 1991, Seiten 165–174; Clark "The Geometry Engin: A VLSI Geometry System for Graphics", Computer Graphics, 16(3), 1982, Seiten 127–133; Foley, van Dam, Feiner, und Hughes, "Computer Graphics: Principles und Practice," Addison-Wesley, Reading, MA, 1990; Haeberli und 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, Seiten 241–248; Maillot, "Three-Dimensional Homogeneous Clipping of Triangle Strips", Graphics Gems II, Academic Press, Inc., San Diego, CA, 1991, Seiten 219–231; Newell, Newellund Sancha, " A Solutation to the Hidden Surface Problem", Preoceedings of the ACM National Conference, 1972, Seiten 443–450; Potmesil und Hoffert, "FRAMES: Software Tools for Modeling, Rendering, und Animation of 3D Scences", Computer Graphics, 21(4), 1987, Seiten 85–93; Saito und Takahashi, "Comprehensible Rendering of 3-D Shapes", Computer Graphics, 24(4), 1990, Seiten 197–206; Segal, Korobkin, van Widenfeld, Foran, und Haeberli, "Fast Shadows und Lighting Effects Using Texture Mapping", Computer Graphics, 26(2), 1992, Seiten 249–252; Sillion und Puech, "A General Two-Pass Method Integrating Specular und Diffuse Reflection", Computer Graphics, 23(3), 1989, Seiten 335–344; Snibbe, Herndon, Robbins, Conner und van Dam, "Using Deformations to Explore 3D Widget Design", Computer Graphics, 26(2), 1992, Seiten 351–352; Strauss und Carey, "An Object-Oriented 3D Graphics Toolkit, "Computer Graphics, 26(2), 1992, Seiten 341–349; Turkowski, "Design Considerations for an Object-Oriented [3D Graphics] Metafile", Proceedings of the Third Eurographics Workshop on Object-Oriented Graphics, Charnpery, Schweiz, Oktober, 1992, Seiten 163–169; Venolia, "Facile 3D Direct Manipulation", zur Veröffentlichung in Proceedings of CHI '93, ACM/SIGCHI, Amsterdam, May, 1993; Venolia, "Automatic Alignment in Two and Three Dimensions", übermittelt an SIGGRAPH '93; und Wanger, "The Effect of Shadow Quality on the Preception of Spatial Relationships in Computer Generate Imagery", Proceedings of the 1992 Symposium on Interactive 3D Graphics, Cambridge, MA, 1992, Seite 3942.

Es ist wünschenswert, in der Lage zu sein, ein Modell unter Verwendung einer Vielzahl unterschiedlicher Arten von Aufbereitern zu zeichnen. Beispielsweise kann ein Anwendungsprogramm, das ein interaktives Editieren eines dreidimensionalen Modells erlaubt, vorteilhaft sein durch Verwendung eines Hochgeschwindigkeits-Drahtmodellaufbereiters geringer Qualität zur Zeichnung von Zwischenversionen auf einer Anzeige und durch Verwendung eines hochwertigen, langsamen Z-Pufferaufbereiters zum Zeichnen der Endversion auf einem Drucker. Die Austauschbarkeit von Aufbereitern ist jedoch bestenfalls schwierig unter Verwendung der oben beschriebenen Aufbereitungssysteme. Insbesondere unterstützen einige der obigen Aufbereitungssysteme nicht mehr als einen Aufbereiter, während jene, die das tun, wie beispielsweise DORÉ und Inventor, den gewählten Aufbereiter in die Systemkonfiguration einbinden. Dementsprechend besteht ein Wunsch nach einem Graphikaufbereitungssystem, das gesteigerte Flexibilität zur Verwendung verschiedener Aufbereiter für verschiedene Zwecke am selben dreidimensionalen Modell schafft.

Ein weiteres Problem bei den obigen Aufbereitungssystemen besteht darin, daß sie nicht mehr als einen Aufbereiter unterstützen, der gleichzeitig aktiv ist. Gleichzeitiges Aufbereiten eines Modells ist wünschenswert in mehreren Situationen, einschließlich der simultanen Ausgabe eines Bildes sowohl zu einer Anzeigeeinrichtung als auch zu einem Drucker. Als weiteres Beispiel ist manchmal wünschenswert, zwei unterschiedliche Ansichten eines Modells gleichzeitig an zwei verschiedenen Teilen der selben Anzeigezeinrichtung aufzubereiten. Gleichzeitiges Aufbereiten wäre wünschenswert hauptsächlich bei Echtzeitsystemen, bei denen ein Anwendungsprogramm ein Bild durch Ausführung einer Folge von Befehlen an das Aufbereitungssystem zeichnet. In solchen Systemen wären viele Anwendungsprogramme in der Lage, wirksamer zu arbeiten, in dem Befehle für einen Aufbereiter in die Befehlsfolge für einen anderen Aufbereiter eingestreut werden. Frühere Systeme schlossen solche eingestreuten Befehlsfolgen aus.

Ein weiteres Problem bei den obigen Aufbereitungssystemen besteht darin, daß jene Systeme, die mehr als einen Aufbereiter unterstützten, verlangten, daß alle Aufbereiter wenigstens die selben Geometrien unterstützten. Beispielsweise konnte das Inventor-Aufbereitungssystem nur Aufbereiter unterstützen, die in der Lage waren, Punkte, Linien und gewisse andere vorbestimmte Formen zu bearbeiten. Einfachere Aufbereiter konnten mit Inventor nicht verwendet werden. Fähigere Aufbereiter konnten verwendet werden, so lange sie wenigstens den vollen Satz der geometrischen Grundelemente von Inventor unterstützen, sie konnten aber nicht dynamisch hinzugefügt werden. Das Anwendungsprogramm mußte über diese Aufbereiter a priori informiert sein. Die obigen Aufbereitungssysteme erlaubten keine "Einsteck"-Aufbereitung von mehr oder weniger fähigen Aufbereitern mit automatischer Ermittlung und Verwendung der Merkmale des Aufbereiters.

Ein weiteres Problem bei den obigen Aufbereitungssystemen besteht darin, daß sie Mehrfachaufbereitung nicht gut unterstützen, insbesondere nicht jene, die Echtzeit- und Mischbetriebsaufbereitung untrstützen. Ein Mehrfachaufbereiter ist ein solcher, der so geschaffen ist, daß er mehrere Überquerungen einer Szenendatenbank erfordert. Es gibt mehrere Gründe, warum ein Aufbereiter für mehrere Durchläufe einer Szenendatenbank entworfen ist. Beispielsweise kann nicht genügend Speicherplatz vorhanden sein, um den gesamten Rahmenpuffer aufzubereiten, der mit sehr hohen Auflösungen aufbereitet wird. Ein Aufbereiter kann dann den Rahmenpuffer in Streifenteilen und jeden Streifen über einen gesonderten Durchlauf durch die Szenendatenbank aufbereiten. Als anderes Beispiel, wenn das Bild an mehrere Vorrichtungen übergeben wird, jedes mit einer anderen Auflösung (wie wenn beispielsweise ein Fenster zwei Monitoren überlappt oder wenn ein Bild sowohl an den Schirm als auch an einem hoch auflösenden Drucker gegeben wird), dann kann der Aufbereiter jede Vorrichtung in einem gesonderten Durchlauf übergeben. Als weiteres Beispiel, ein Aufbereiter, der eine progressive Verfeinerung ausführt, kann mehrere Durchläufe der Szenendatenbank ausführen, wobei kontinuierlich das endgültige Bild verfeinert wird, bis der Vorgang durch einen Benutzereingriff abgebrochen wird oder das Bild die höchste Qualität hat. Noch andere Beispiele umfassen Hochqualitäts-Aufbereitungsalgorithmen mit Verwendung von Sammelpuffern, Verwendung einer Texturkardierung zur Erzeugung von Schattierungs- und Beleuchtungseffekten und mit Globalbeleuchtungstechniken in zwei Durchläufen.

In einem Aufrechterhaltungsbetriebssystem muß das Anwendungsprogramm gewöhnlich nicht wissen, ob der Aufbereiter mehr als einen Durchlauf erfordert, um die Aufbereitung abzuschließen. Dies rührt daher, daß das Anwendungsprogramm nur einen Aufruf ausführt, um den Aufbereiter zu veranlassen, das Modell aufzubereiten, und der Aufbereiter kann so viele Durchläufe ausführen, wie er benötigt, bevor er zum Anwendungsprogramm zurückkehrt. In einem Echtzeitbetriebssystem oder Mischbetriebssystem spielt andererseits das Anwendungsprogramm eine Rolle bei der Durchquerung des Modells und richtet dabei mehrere Aufrufe an den Aufbereiter, um die einzige Durchquerung auszuführen. Für einen Mehrfachaufbereiter würde das Anwendungsprogramm daher wissen müssen, wie oft das Modell durchquert werden muß, um die Szene zu vervollständigen. Dies würde erfordern, daß das Anwendungsprogramm eine innige Kenntnis vom Aufbereiter hat, und es würde im wesentlichen sehr schwierig, austauschbare Aufbereiter zu unterstützen.

Noch ein weiteres Problem bei den obigen Systemen besteht darin, das wenn ein dreidimensionales Modell in eine Szene zur Anzeige aufzubereiten ist, ein klassischer Kompromiß vorhanden ist zwischen der Geschwindigkeit des Aufbereitungsvorgangs einerseits und der Qualität des Ergebnisses andererseits. Beispielsweise arbeitet Drahtmodellaufbereitung mit hoher Geschwindigkeit, erzeugt aber ein Ergebnis geringer Qualität, während ein Strahlverfolger sehr viel längere Zeit benötigt, um dasselbe Modell zu liefern, jedoch Ergebnisse extrem hoher Qualität liefern kann. Ein Anwendungsprogramm, das ein interaktives Editieren eines dreidimensionalen Modells erlaubt, kann somit durch Verwendung eines Drahtmodellaufbereiters zur Zeichnung von Zwischenversionen auf einer Anzeigeeinrichtung und durch Verwendung eines Strahlverfolgungsaufbereiters zur Zeichnung der Endversion für die Ausgabe nutznießen.

Die Austauschbarkeit von Aufbereitern ist jedoch bestenfalls mühselig unter Verwendung der oben beschriebenen Aufbereitungssysteme. Darüber hinaus bietet der Ersatz eines Aufbereiters gegen einen anderen nur einen groben Einfluß auf den Kompromiß zwischen Geschwindigkeit und Qualität. Es wäre wünschenswert, ein Anwendungsprogramm zu erlauben, das ein wenig Qualität opfert, um ein wenig an Geschwindigkeit zu gewinnen und umgekehrt. Es wäre wünschenswert, mehrere Stufen in dem Kompromißkontinuum zwischen Geschwindigkeit und Qualität zu haben, damit ein Benutzer oder Anwendungsprogramm exakt die gewünschte Position im Kompromiß wählen kann.

In der Vergangenheit haben Anwendungsprogramme die Benutzer mit einer Steuerung verschiedener beiläufiger Parameter des Aufbereitungsverfahrens ausgestattet, und die Benutzer haben die Vorteile dieser Steuerung durch die Auswahl von Optionen ausgenutzt, die als Nebeneffekt den Kompromiß zwischen Geschwindigkeit und Qualität beeinflussen. Beispielsweise kann durch vorübergehendes Ausschalten mancher Lampen der Benutzer den Aufbereitungsvorgang auf Kosten der Qualität beschleunigen. Die gleiche Wirkung kann erreicht werden, indem Objekte aus der Szene vor dem Aufbereiten entfernt werden, indem man das Ausgabefenster kleiner macht durch Umschalten vom Vollbetrieb zum Randbetrieb bei einem Aufbereiter, der eine solche Auswahl zuläßt, und durch Einstellen eines gröberen Bildglättungspegels. In manchen Systemen stehen dem Benutzer die Parameter, die den Kompromiß zwischen Geschwindigkeit und Qualität beeinflussen, in einer einzigen Dialogbox zur Verfügung, in der der Benutzer eine Wahl für jeden der beeinflußbaren Parameter treffen kann. Dieses ist eine höchst stückweise Lösung für das Problem. Andere Anwendungsprogramme erlauben es einem Benutzer, eine Grobqualität für die Aufbereitung auszuwählen, gewöhnlich wirkt aber des Benutzers Wahl, daß das Programm einen vollständig anderen Aufbereiter aufruft, oder veranlaßt wenigstens den Aufbereiter, stark abweichende Aufbereitungsverfahren zu benutzen. Es wird ein Qualitätssteuermechanismus benötigt, der es einem Anwendungsprogramm oder Benutzer ermöglicht, einen gewünschten Punkt in dem Gesamtkompromiß zwischen Geschwindigkeit und Aufbereitungsqualität auszuwählen mit relativ feiner Auflösung im Kompromißspektrum und ohne sich um einzelne Aufbereitungsparameter kümmern zu müssen.

US 5,181,162 offenbart ein System, um visuelle Bilder auf einer Mehrzahl von Graphikausgabevorrichtungen darzustellen. Hierzu wird ein Objektzeichnungsuntersystem mit einer Identifikation eines Objekts aufgerufen, um das Objekt aufzubereiten und auf eine oder mehrere Graphikausgabevorrichtungen auszugeben. Das System gibt dem Benutzer auch eine Möglichkeit, ein Objekt nach seinen Wünschen anzuordnen und auf Graphikausgabevorrichtungen auszugeben. Das Objekt wird hierbei mit einer Szene verknüpft, um ein festes, für eine aktuelle Produktion bestimmtes visuelles Bild zu erschaffen. Erst nach der Verknüpfung von Objekt und Szene zu einem Ganzen wird ein Objektzeichnungsuntersystem mit einer Identifikation des Objekts, einer Identifikation der fest mit dem Objekt verknüpften Szene und einer Identifikation des zu verwendenden Aufbereiters aufgerufen. Eine Schwierigkeit tritt allerdings dann auf, wenn das erschaffene visuelle Bild auf verschiedene Graphikausgabevorrichtungen ausgebeben werden soll.

EP 0 534 446 A2 beschreibt ein System zum Erschaffen visueller Bilder auf einer Mehrzahl von Graphikausgabevorrichtungen, wobei ein Objekt durch einen ersten Aufbereiter auf einem Bildschirm und durch einen zweiten Aufbereiter auf einem Plotter ausgegeben wird. Hierbei werden digitalisierte Bilddaten mittels eines Programms zur Erkennung von Zeichnungen so vereinfacht, daß als relevant anzusehende Bilddaten auf einfach beschreibbare Linien reduziert werden und damit ein erforderlicher Speicherbedarf reduziert ist. Aufgrund dieser speziellen Ausrichtung ist die Verwendung auf einen Plotter als Graphikausgabevorrichtung beschränkt, womit das System relativ starr ist.

Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren zur Erschaffung visueller Bilder auf verschiedenen bzw. unterschiedlichen Graphikausgabevorrichtungen in einer flexiblen Weise bereitzustellen.

Diese Aufgabe wird gelöst durch die Bereitstellung eines Verfahrens zum Erschaffen visueller Bilder auf einer Mehrzahl von unterschiedlichen Graphikausgabevorrichtungen gemäß den beiliegenden Ansprüchen 1, 2 und 9, durch die Bereitstellung einer Vorrichtung zum Erzeugen einer auf jeweils unterschiedlichen Graphikausgabevorrichtungen anzeigbaren Szene gemäß den beiliegenden Ansprüchen 14 und 18 sowie durch die Bereitstellung eines ein solches Verfahren verkörpernden Computer lesbaren, Programmbefehle tragenden Mediums gemäß den beiliegenden Ansprüchen 19 und 20.

Gemäß der Erfindung wird grob gesagt, ein Graphikaufbereitungssystem angegeben, das im Aufrechterhaltungsbetrieb den Aufbau und die Editierung eines Modells unabhängig von der Wahl des Aufbereiters ermöglicht. Anwendungsprogrammaufrufe an das Aufbereitungssystem zum Zeichnen eines Objekts spezifizieren nicht nur das zu zeichnende Objekt, sondern auch den Aufbereiter, der für die Ausführung verwendet wird. In einer Ausführungsform wird der Aufbereiter als Teil eines mehr inklusiven "Ansichtsobjekts" spezifiziert, das dem Aufbereitungssystem durch den API angegeben wird. Auf diese Weise wird das Umschalten auf einen anderen Aufbereiter zu ei ner beliebigen Zeit während des Aufbaus oder Editierens eines Modells eine triviale Aufgabe für das Anwendungsprogramm.

Gemäß einer weiteren Ausführungsform der Erfindung wird ein Graphikaufbereitungssystem angegeben, in dem mehr als ein Aufbereiter gleichzeitig aktiv sein kann. In einer Ausführungsform wird dieses dadurch erreicht, daß der augenblickliche Zustand der Aufbereitung für jeden Aufbereiter in einem betreffenden "Ansichtsobjekt" (oder Objekten), das das Anwendungsprogramm spezifiziert, wenn das Aufbereitungssystem zum Zeichnen eines dreidimensionalen Objekts aufgerufen wird.

Gemäß einer weiteren Ausführungsform der Erfindung wird ein Graphikaufbereitungssystem angegeben, das auf die Unterstützung dynamisch registrierter Aufbereiter ausdehnbar ist.

Gemäß einer weiteren Ausführungsform der Erfindung wird ein Graphikaufbereitungssystem angegeben, das automatisch ermittelt, wenn Geometrien nicht durch einen gewählten Aufbereiter gestützt werden, und automatisch solche Geometrien in mehrere Objekte einfacherer Geometrie überlegt. Eine solche automatische Zerlegung kann rekursiv ausgeführt werden, bis Objekte erreicht sind, deren Geometrien durch den gewählten Aufbereiter unterstützt werden.

Gemäß einer weiteren Ausführungsform der Erfindung wird ein Graphikaufbereitungssystem angegeben, das es einem Anwendungsprogramm ermöglicht, Echtzeit- und Aufrechterhaltungsaufrufe zur Aufbereitung eines Modells auszuführen, ohne wissen zu müssen, wie viele Durchläufe der Aufbereiter benötigt, um die Szene zu vervollständigen. In einer Ausführungsform veranlaßt das Anwendungsprogramm das Aufbereitungs-Subsystem, das Modell zu zeichnen, und das Aufbereitungssubsystem stellt ein Kennzeichen zurück (hier als ein Neudurchquerungskennzeichen bezeichnet), das angibt, ob die Aufbereitung des Modells vollständig ist. Wenn das Kennzeichen angibt, daß die Aufbereitung noch nicht vollständig ist, kann das Anwendungsprogramm das Aufbereitungssubsystem erneut veranlassen, das Modell zu zeichnen. Vorzugsweise befinden sich die Aufrufe an das Aufbereitungssubsystem innerhalb einer Schleife im Anwendungsprogramm, die so oft wiederholt wird, bis das Neudurchquerungskennzeichen die Vollständigkeit anzeigt. Die Technik unterstützt Echt zeit- und Gemischtbetriebsaufbereitung, weil die Schleife viele Aufrufe an das Aufbereitungssubsystem enthalten kann, die sämtlich durch das Anwendungsprogramm beim Durchqueren des Modells selbst ausgeführt werden. Wenn das Neudurchquerungskennzeichen angibt, daß die Aufbereitung noch nicht vollständig ist, wiederholt das Anwendungsprogramm dieselbe Sequenz von Aufrufen, um dadurch das Modell wirksam erneut zu durchqueren.

Gemäß einer weiteren Ausführungsform der Erfindung spezifizieren Aufrufe des Anwendungsprogramms an das Aufbereitungssystem zum Zeichnen eines Objekts nicht nur das zu zeichnende Objekt, sondern auch den Aufbereiter der dieses ausführen soll. Auf diese Weise wird das Umschalten auf einen anderen Aufbereiter zu irgendeinem Zeitpunkt während des Ausbaus oder des Editierens eines Modells eine triviale Aufgabe für das Anwendungsprogramm. Wegen des Neudurchquerungskennzeichens muß das Anwendungsprogramm keinerlei zusätzliche Zugeständnisse in Abhängigkeit davon machen, ob der neue Aufbereiter mehrere Durchläufe zur Vervollständigung einer Aufbereitung ausführen muß.

Gemäß einer weiteren Ausführungsform der Erfindung wird ein Graphikaufbereitungssystem angegeben, in dem mehr als ein Aufbereiter gleichzeitig aktiv sein kann. In einer Ausführungsform wird dieses durch Speichern des Augenblickzustands der Aufbereitung für jeden Aufbereiter in einem entsprechenden "Ansichtsobjekt" (oder Objekten) erreicht, das das Anwendungsprogramm spezifiziert, wenn das Aufbereitungssystem dazu aufgerufen wird, ein dreidimensionales Objekt zu zeichnen. Wieder vermeidet das Neudurchquerungskennzeichen jegliche Notwendigkeit, das das Anwendungsprogramm spezielle Zugeständnisse macht, wenn einer oder mehrerer der gleichzeitig aktiven Aufbereiter mehrere Durchläufe benötigt, um eine Aufbereitung zu vervollständigen.

Gemäß einer weiteren Ausführungsform der Erfindung wird ein Graphikaufbereitungssystem angegeben, das auf die Unterstützung dynamisch registrierter Aufbereiter ausdehnbar ist. Wieder besteht wegen des Neudurchquerungskennzeichens keine Einschränkung, das die neu registrierten Aufbereiter Einzel- oder Mehrtachdurchlauf-Aufbereiter sind.

Gemäß einer noch weiteren Ausführungsform der Erfindung wird ein Mechanismus angegeben, der es einem Anwendungsprogramm oder Benutzer erlaubt, einen gewünschten Punkt in einem Gesamtkompromiß zwischen Geschwindigkeit und Aufbereitungsqualität mit relativ feiner Auflösung im Spektrum auszuwählen und ohne sich um einzelne Aufbereitungsparameter kümmern zu müssen. Ein Graphikaufbereitungssystem zur Erreichung dieses Ziels enthält ein Spektrum oder eine Sammlung von Qualitätssteuerdatengruppen, von denen jede mehrere Qualitätssteuertypvariablen enthält.

Jede der Typvariablen enthält einen Wert, der aus mehreren Optionen in einem entsprechenden Kompromiß zwischen der Aufbereitungsqualität und der Aufbereitungsgeschwindigkeit auswählt. Beispielsweise kann jede der Qualitätssteuerdatengruppen eine Qualitätssteuertypvariable für "Detailniveau" enthalten; jene Gruppen am unteren Ende des Qualitätsspektrums können jene Variablen "niedrig" gesetzt haben, während bei Datengruppen am höheren Ende des Spektrums diese Variable "hoch" gesetzt ist.

Gemäß einer weiteren Ausführungsform der Erfindung ist jeder Qualitätssteuerdatengruppen ein entsprechender Qualitätsindex zugeordnet. Ein Anwendungsprogramm kann somit einen Punkt im Aufbereitungsgesamtkompromiß zwischen der Aufbereitungsgeschwindigkeit und der Qualität lediglich durch Auswahl eines Qualitätssteuerindexwertes auswählen. Darüber hinaus kann das Anwendungsprogramm den Qualitätssteuerindex für einen Benutzer zugänglich machen, beispielsweise in solch einer intuitiven Form wie durch einen pictogrammartigen "Qualitätsknopf". Der Qualitätsknopf kann mehrere Stellungen haben, die beispielsweise von 0,0 bis 1,0 reichen, von denen jede einer entsprechenden Qualitätssteuerdatengruppe entspricht. Der Mechanismus erlaubt somit dem Benutzer eine feine Steuerung des Aufbereitungskompromisses zwischen Aufbereitungsgeschwindigkeit und Qualität, ohne sich um Einstellungen der einzelnen Aufbereitungsparameter kümmern zu müssen.

KÜRZE BESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung wird bezüglich ihrer speziellen Ausführungsformen beschrieben, und bezug wird auf die Zeichnungen genommen. In diesen
1 ist ein vereinfachtes Blockschaltbild eines Rechnersystems, das die vorliegende Erfindung ausbildet;
2 zeigt eine Softwarearchitektur, die die Erfindung verwendet;
3 ist ein Flußdiagramm, das den Gesamtablauf eines Programms zeigt, das die Erfindung verwendet;
4 ist ein Detail von Schritt 308 in 3;
5, 7, 9 11 und 12 zeigen Objektdatenstrukturen im Speicher;
6 zeigt eine Klassenhierarchie, die in einer Ausführungsform der Erfindung verwendet wird;
8 zeigt eine Modellhierarchie, die durch ein Beispielprogramm geschaffen wird, das die Erfindung verwendet;
10 ist ein Flußdiagramm, das die Schaffung eines neuen Objekts im Speicher zeigt;
13 ist ein Flußdiagramm einer Anwendungsprogrammprozedur zum Aufbau einer Qualitätssammlung;
14 ist ein Flußdiagramm einer Anwendungsprogrammprozedur zum Erzielen eines gewünschten Qualitätsindex;
15 ist eine Darstellung eines Anzeigepictogramms; und
16 ist ein Flußdiagramm eines Betriebsablaufs in einem Aufbereiter.
DETAILLIERTE BESCHREIBUNG
1 ist ein vereinfachtes Blockschaltbild eines Rechnersystems, das die vorliegende Erfindung ausbildet. Obgleich gewisse Arten von Rechnerarchitekturen von der Erfindung größeren Nutzen ziehen als andere, kann die Erfindung auf praktisch jede Art Architektur ausgeführt werden. In der Architektur von 1 sind eine CPU 102, ein Speicher 104, ein I/O-Subsystem 106 sämtlich mit einem Bus 108 verbunden. Die CPU 102 gibt Signale über den Bus 101 zum Lesen und Schreiben aus und in den Speicher 104 oder zum I/O-Subsystem 106, um Daten in der hier beschriebenen Weise zu manipulieren. Die CUP gibt solche Signale in Abhängigkeit von Softwarebefehlen ab, die sie vom Speicher 104 erhält. Das I/O-Subsystem 106 kann auch in der Lage sein, Signale über den Bus 108 abzugeben, um zum Speicher 104 in einer speziellen Ausführungsform zurückzugreifen. Das System kann auch einen Graphik-Koprozessor 110 enthalten, der der CPU 102 viele der speicherintensiven Aufgaben abnehmen kann, die erforderlich sind, um ein Bild aufzubereiten. In solchen Situationen wird die Anzeige, die in 1 mit 114 bezeichnet ist, häufig vom I/O-Subsystem 106 gesteuert. In anderen Systemen ist ein Graphikbeschleuniger 112 mit dem Bus 108 und der Anzeige 114 verbunden. In diesem Systemen befindet sich der Anzeigepuffer typischerweise innerhalb des Graphikbeschleunigers 112, der nicht nur spezielle Attribute (z. B. Farben) an speziellen Bildpunkten der Anzeige 114 schreiben kann, wie durch die CPU 102 gefordert, sondern auch kompliziertere Grundelemente auf der Anzeige 114 unter dem Befehl der CPU 102 zeichnen kann.
Die Erfindung ist in der vorliegenden Ausführungsform in Form eines Satzes von Softwarewerkzeugen aufgeführt, der nachfolgend als Escher bezeichnet wird. Diese Softwarewerkzeuge enthalten einen Satz von Softwareprozeduren und einen Satz von Kopfdokumenten, die die variablen Namen und Datenstrukturen definieren, die von den Prozeduren verwendet werden. Escher wird einem Anwendungsprogrammentwickler auf einem Speichermedium, wie beispielsweise einer magnetischen oder optischen Platte oder Platten zugeführt. In einer Ausführungsform enthält das Speichermedium einen Quellencode für Escher, während in einer anderen Ausführungsform das Speichermedium einen kompilierten Objektcode für Escher enthält. In noch einer anderen Ausführungsform enthält das Speichermedium etwas Quellencode und etwa Objektcode für Escher. Der Anwendungsentwickler kompiliert ein Anwendungsprogramm mit Escher und mit einem oder mehreren Aufbereitern und speichert den resultierenden Objektcode auf ein Speichermedium. Der kombinierte Objektcode wird später in den Speicher 104 eingelesen, entweder vollständig oder in überlagerter Art, und von der CPU 102 ausgeführt.
Es sei angemerkt, daß Software und Daten, die hier als dem "Speicher" bezeichnet werden, zu jedem beliebigen Zeitpunkt in Wirklichkeit vollständig oder zum Teil in einem Sekundärspeichermedium, wie beispielsweise einer Platte, liegen können. Diese Situation könnte beispielsweise aufgrund solcher Architekturen als überlagerte Ausführung oder virtueller Speicher auftreten. Zur Vereinfachung wird hier angenommen, daß all solche Software und Daten sich "im Speicher" zu allen in Frage kommenden Zeiten befinden, selbst wenn sie zu solchen Zeiten tatsächlich vorübergehend irgendwo anders sind.
2 zeigt die logische Position von Escher in einer Softwarearchitektur. Wie man sehen kann, sind die Escher-Prozeduren 202 logisch zwischen einem Anwendungsprogramm 204 und mehreren Aufbereitern 206, 208 und 210 angeordnet. Das heißt, das Anwendungsprogramm 204 macht Prozeduraufrufe an Escher-Prozeduren über eine Anwendungsprogrammschnittstelle (API), und gewissen Prozeduren innerhalb Escher (speziell gewisse Aufbereiter der Aufrufprozeduren 212) machen Prozeduraufrufe an die Aufbereiter 206, 208 und 210. Das Anwendungsprogramm 204 spezifiziert beim Richten von Aufrufen an die Aufbereiterprozeduren 212, welcher Aufbereiter die Aufbereiteraufrufprozeduren nutzen sollte. Die Aufbereiter wiederum kommunizieren mit anderen Hardware-Komponenten 214 der Plattform, wie beispielsweise einem Anzeigepufferspeicher, einem Graphikkoprozessor 110, falls vorhanden und/oder einen graphikbeschleuniger 112, falls vorhanden. Die Escher-Prozeduren enthalten zusätzlich zu den Aufbereiteraufrufprozeduren 212 auch Auf bereiterinstallationsprozeduren 216, Qualitätssteuermanagementprozeduren 217, Modellerrichtungs- und Editierprozeduren 218, Bildaufbau- und -Editierprozeduren 220 und einige andere Arten von Prozeduren (nicht dargestellt), die zum Verständnis der Erfindung nicht bedeutsam sind.
3 ist ein Flußdiagramm, das den Gesamtfluß eines beispielhaften Programms zeigt, das die Erfindung benutzt. In einem Schritt 302 ruft das Anwendungsprogramm 204 eine Escher-Initialisierungsprozedur (nicht gezeigt), die, unter anderen Dingen, einen oder mehrere Aufbereiter unter Verwendung der Aufbereiterinstallationsprozeduren 216 installiert. Eine der Vorteile von Escher ist, das eine Vielzahl unterschiedlicher Arten von Aufbereitern installiert werden können, einschließlich Aufbereitern, die zur Zeit, als das Anwendungsprogramm kompiliert wurden, nicht verfügbar waren.
In einem Schritt 303 ruft das Anwendungsprogramm die Qualitätssteuermanagementprozeduren 217 von Escher auf, um einen odere mehrere "Qualitätssammelobjekte" aufzubauen, die jeweils einen oder mehrere "Qualitätsgruppenobjekte" enthalten können. Ein Qualitätsgruppenobjekt ist ein Objekt, das durch das Escher-System in Übereinstimmung mit einer vorbestimmten Datenstruktur erzeugt wird, die an einem Platz eine Anzahl Qualitätssteuerkriterien, die Linienstiel, Typ von Schattierungen, von Beleuchtung, Detailniveau, Bildglättungsniveau usw. sammelt.
In einem Schritt 304 ruft das Anwendungsprogramm die Bildaufbau/Editierprozeduren 220 von Escher auf, um eine oder mehrere "Sichtobjekte" aufzubauen. Ein Sichtobjekt ist ein Objekt, das durch das Escher-System in Übereinstimmung mit einer vorbestimmten Datenstruktur geschaffen wird, die an einer Stelle eine Anzahl von Sichtkriterien sammelt, wie beispielsweise eine Kameraposition, Beleuchtung, eine Hartware-Bestimmung ("Zeichenkontext"), in das ein zweidimensionales Bild aufzubereiten ist, sowie eine Auswahl an Aufbereitern, unter anderen Dingen. Schritt 304 kann auch einen Aufruf an eine Escherprozedur sein, eine Qualitätsgruppe zur Verwendung im Aufbereitungsprozeß auszuwählen.
In einem Schritt 306 richtet das Anwendungsprogramm Aufrufe an die Modellaufbau/Editierprozeduren 218 von Escher, um ein oder mehrere Modelle aufzubauen. Ein Modell wird in Escher als eine Hierarchie von einem oder mehreren Objekten dar gestellt, von denen jedes eine Geometrie (Gestalt), ein Materialattribut (das Aussehen oder Oberfläche beschreibend), einen Stil (beispielsweise gefüllte Oberflächen, nur Ränder oder nur Punkte), eine Transformation (die relative Position, Orientierung und Größe der dreidimensionalen Objekte) in bezug auf einen Umgebungsraum oder eine Gruppe, (die lediglich weitere Objekte im nächstniedrigen Niveau der Hierarchie enthält) beschreibt. Wie der Ausdruck hier benutzt wird, kann ein "Modell" nur ein einziges Objekt bilden, wie beispielsweise ein Geometrieobjekt, ohne jegliches hierarchisch definiertes Unterobjekt.
In einem Schritt 308 ruft das Anwendungsprogramm die Aufbereiteraufrufprozeduren 212 auf, damit Escher ein oder mehrere Modelle, die vom Anwendungsprogramm erzeugt werden, in ein oder mehrere Ansichten aufbereitet, die durch das Anwendungsprogramm definiert sind. Die API für die Aufbereiteraufrufprozeduren 212 enthalten sowohl Echtzeitaufrufe als auch Aufrechterhaltungsbetriebsaufrufe. Für die Echtzeitaufrufe für das Anwendungsprogramm nur nicht-hierarchische Datenstrukturen zur Aufbereitung zu. Das Escher-System leitet die Strukturen sofort zum angegebenen Aufbereiter ohne Zwischenspeicherung irgendwelcher Zwischenergebnisse. Für Material, Stiel und Transformationsobjekte stellt das Escher-System lediglich den laufenden "Zustand" der Ansicht ein, wodurch die Aufbereitung nachfolgend empfangener Geometrien beeinflußt wird. Für Aufrechterhaltungsbetriebsaufrufe an die Aufbereitungsaufrufprozeduren 212 kann das vom Anwendungsprogramm 204 durchgelassene Objekt ein vollständiges, hierarchisch definiertes Modell sein; die Aufbereiteraufrufprozeduren 212 durchqueren automatisch dieses Modell, machen geeignete Aufrufe an den bezeichneten Aufbereiter an geeigneten Punkten bei der Durchquerung.
Sowohl bei Echtzeitaufrufen als auch bei Aufrechterhaltungsbetriebsaufrufen spezifiziert das Anwendungsprogramm 204 für die Aufbereiteraufrufprozeduren 212 sowohl das aufzurufende Objekt als auch ein Sichtobjekt. Der laufende "Zustand" der Aufbereitung wird stets innerhalb der Datenstruktur des Sichtobjekts aufrechterhalten, so daß das Anwendungsprogramm dasselbe Modell mehr als eine Sicht gleichzeitig aufbereiten kann, indem lediglich Aufrufe, die ein Sichtobjekt spezifizieren, und Aufrufe, die ein anderes Sichtobjekt spezifizieren, eingestreut werden. Diese Aufrufe stören einander nicht (sofern selbstverständlich nicht beide Sichtobjekte denselben Zeichnungskontext bezeichnen). Die zwei Sichtobjekte könnten den selben oder unter schiedliche Aufbereiter spezifizieren, und der Zeichnungskontext, der in den Sichtobjekten spezifiziert ist, kann zur Ausgabe zur gleichen oder zu unterschiedlicen Arten von Ausgabeeinrichtungen spezifiziert sein (wie beispielsweise zwei verschiedene Fenster auf einer einzigen Anzeige oder eine für die Anzeige und für einen Drucker). Darüber hinaus kann das Anwendungspgrogramm 204 Echtzeitaufrufe und Aufrechterhaltungsbetriebsaufrufe für dieselbe Ansicht miteinander mischen, wodurch der Anwendungsentwickler in die Lage versetzt wird, die Speicherung und/oder Durchquerung unterschiedlicher Teile einer Szene unterschiedlich zu optimieren.
Einige dieser Möglichkeiten sind in einem beispielhaften Flußdiagramm dargestellt, das in 4 gezeigt ist. In einem Schritt 402 ruft das Anwendungsprogramm die Aufbereiteraufrufprozeduren 212, die ein erstes Modell und ein erstes Sichtobjekt spezifizieren, auf. In einem Schritt 404 ruft das Anwendungsprogramm die Aufbereiteraufrufprozeduren, die das erste Modell und ein zweites Sichtobjekt spezifizieren, auf. In einem Schritt 406 ruft das Anwendungsprogramm die Aufbereiteraufrufprozeduren, die ein zweites Modell und das erste Sichtobjekt spezifizieren, auf. In einem Schritt 408 ruft das Anwendungsprogramm die Aufbereiteraufbereiterprozeduren, die das zweite Modell und das zweite Sichtobjekt spezifizieren, auf. In einem Schritt 410 ruft das Anwendungsprogramm die Aufbereiteraufrufprozeduren, die ein drittes Modell und das erste Sichtobjekt spezifizieren, auf usw.
Die Unabhängigkeit eines Escher-Sichtobjekts (einschließlich der Identifizierung des Aufbereiters) vom aufzubereitenden Modell schafft auch enorme Flexibilität im Ablauf der Vorgänge, die vom Anwendungsprogramm 204 ausgeführt werden. Beispielsweise müssen die Aufbereiter nicht installiert sein (Schritt 302) bis kurz vor den Aufrufen an die Aufbereiteraufrufprozeduren 212 (Schritt 308). Sichtobjekte müssen auch nicht definiert oder abgeschlossen sein (Schritt 304), bis ein Modell erstellt ist (Schritt 306). Ein Anwendungsprogramm kann daher ein Modell oder ein Teil eines Modells aufbauen und erlaubt es einem Benutzer, den Aufbereiter erst nachträglich auszuwählen. Die Auswahl des Aufbereiters kann getroffen werden, indem beispielsweise ein Pop-up-Schnellsuchfenster verwendet wird, das eine Anzahl bereits installierter Aufbereiter anbietet und das auch den Benutzer eine Möglichkeit bietet, einen weiteren Aufbereiter zu diesem Zeitpunkt zu installieren. Das Anwendungsprogramm kann dann das Modell (oder Modelle) unter Verwendung des gewählten Aufbereiters aufbereiten, an schließend das Modell oder aufgebaute neue Modelle editieren und/oder die Wahl der Aufbereiter ändern und das Modell (die Modelle) neu aufbereiten usw. Eine solche Flexibilität ist möglich gemacht, weil die Wahl des Aufbereiters nicht an das Modell gebunden ist, wenn es sich im Aufbau befindet, vielmehr spezifiziert das Anwendungsprogramm den Aufbereiter in seinen Aufrufen an die Aufbereiteraufrufprozeduren 212 von Escher.
Ein einfaches Anwendungsprogramm 204 in C-Sprache ist in Anhang A angegeben. In diesem Beispiel ruft das Programm zunächst die Escher-Initialisierungsroutine auf, die sowohl einen Drahtmodellaufbereiter als auch einen Z-Puffer-Aufbereiter installiert. Als nächstes wird eine Anwendungsroutine ExSetupQualityCollection() aufgerufen, um ein Qualitätssammelobjekt einzustellen und zu initialisieren. Diese Prozedur wird nachfolgend in größerem Detail beschrieben.
Als nächstes wird ein Sichtobjekt ("Ansicht") erzeugt, und ein spezieller Aufbereiter (der Drahtmodellaufbereitet) wird der Ansicht zugeordnet. Ein Kameraobjekt und ein Zeichnungskontextobjekt werden ebenfalls dem Sichtobjekt zugeordnet.
("Zeichenprobe") und fügt ein Polygonobjekt ("Polygon"), ein Linienobjekt ("Linie"), ein Transformationsobjekt ("Transformation") und ein Probenobjekt ("Subgruppe") hinzu. Das Anwendungsprogramm fügt dann Torosobjekt ("Toros", eine Form eines Geoemtrieobjektes) zum Gruppenobjekt hinzu. Als nächstes wird ein vom Benutzer spezifizierter Qualitätsindex für das Sichtobjekt eingerichtet, und das Modell wird durchquert und aufbereitet unter Verwendung des im Sichtobjekt spezifizierten Aufbereiters. Der in Sichtobjekt spezifizierte Aufbereiter wird dann in den Z-Puffer-Aufbereiter geändert, und dasselbe Modell wird erneut unter Verwendung des in Sichtobjekt spezifizierten Aufbereiters aufbereitet.
Vor der Fortsetzung ist es angebracht, einige Benamungsregeln zu erläutern, die im C-Sprachen-Quellencode verwendet werden, der in der vorliegenden Erfindung enthalten ist. In dieser Beschreibung sind Namen, die mit dem Prefex Et (Escher-Typ) beginnen, Datentypen, im Escher-Quellencode definiert sind. Namen, die mit dem Prefix Ec (Escher-Konstante) beginnen, sind Konstanten, die im Escher-Quellencode definiert sind. Namen, die mit dem Prefix Er (Escher-Routine) beginnen, sind Preozedurnamen, die durch das Anwendungsprogramm aufrufbar sind. Namen, die mit dem Prefix Ei (Escher-Intern) beginnen, sind Namen von internen Escher-Prozeduren, die nur durch andere Escher-Prozeduren aufgerufen werden. Viele derselben haben Gegen-Er-Prozeduren, die durch das Anwendungsprogramm aufgerufen werden und die im wesentlichen nicht mehr tun, als die entsprechende Ei-Prozedur aufzurufen. Aus diesem Grunde die Er- und Ei-Prozedurnamen hier austauschbar verwendet. Schließlich sind Namen, die mit dem Prefix Eg (Escher-Global) beginnen, globale Variable.
Die Namen von Escher-Routinen beginnen mit Ei oder Er, und ihnen folgen Unterwörter, die mit Großbuchstaben beginnen. Die Form der meisten Escher-Prozedurnamen, wie sie hier verwendet wird, ist ErFoo.DoSomething, wobei Foo der Typ der Daten ist, mit denen die Funktion arbeiten muß, und DoSomething der Vorgang ist, den die Routine mit dieser Datenart ausführen soll. Beispielsweise ist der Name einer Prozedur zur Erzeugung eines neuen Polygonobjekts die ErPolygon.New. Andere Benamungsregeln werden erwähnt, wenn sie auftreten.
Die verschiedenen Primärschritte eines Anwendungsprogramms, wie in 3 dargestellt, werden nun dedaillierter erläutert.
I. AUFBEREITERINSTALLATION
Die Installation von Aufbereitern für Escher verwendet einen generalisierten Erweiterungsmechanismus, der auch für die Installation anderer Erweiterungen, beispielsweise von Schattierern, verwendet wird. Erweiterungen für Macintosh-Ausführungen sind Dokumente, die in Massenspeicher in der Hardware von 1 gespeichert sind, mit einem Dateizweig und einem Betriebsmittelzweig. Der Dateizweig enthält den Code, der durch das Escher-System zu laden ist, und der Betriebsmittelzweig identifiziert die Code-Fragmente im Dateizweig.
Wenn ein Anwendungsprogramm 204, das mit einem Macintosh arbeitet, einen Aufruf an die Escherprozedur Erlnitialize() richtet, dann fragt das Eschersystem alle Erweiterungsdokumente in einem Erweiterungsordner des Rechnersystems ab. Alle Dokumente, die gefunden werden und die geeignete Betriebsmittelinformation enthalten, werden dann als zur Verwendung durch das Anwendungsprogramm verfügbar behandelt. Das Erweiterungsdokument spezifiziert eine Initialisierungsroutine, die alle notwendigen Schritte zum "Registrieren" der Dienste umfaßt, die sich mit dem Escher-System anbietet, sowie eine Beendigungsroutine.
Escher-Erweiterungen werden in eine verallgemeinerte Objekthierarchie in der Escher-Laufzeitumgebung geladen. Eschers Objekthierarchie hat eine "offene" Architektur, die jeder Anwendung erlaubt, eine Unterklasse an jeder von mehreren Niveaus in der Hierarchie "einzustecken". Aufbereiter sind eine der Objektklassen, die unterklassiert werden können.
A. Escherobjektsystem
Ein Objekt im Escher-System wird durch zwei Handhaben identifiziert, nämlich eine Objektklasse und ein Objekt. Die Objektklasse ist ein Zeiger vom Typ EtObjectClassPrivate, und der Objekttyp ist ein Langwort. Weil die Oberklasse jeder Unterklasse in der Escher-Klassenhierarchie ein gewisses Verhalten hat, speichert Escher Objektprivatdaten und Objektklassen in einer geschichteten Weise. Beispielsweise eine Unterklasse der Aufbereiterklasse wird abstrakt in der in 5 dargestellten Weise ausgelegt. 5 zeigt eine Objekt "Klasse" 502, die ein durchgehender Bereich von speicherhaltigen Zeigern aller dem Aufbereiter zugehöriger Verfahren ist, in diesem Falle ein Drahtmodell (WF)-Aufbereiter. Da der Drahtmodellaufbereiter aus der Aufbereiterklasse unterklassiert ist, ist die Aufbereiterklasse in Unterklassen von einer "Geteilt-Objekt"-Klasse unterklassiert, und die "Geteilt-Objekt"-Klasse ist aus der generalisierten "Objekt"-Klasse unterklassiert. Die Verfahrenstabellen 502 listen daher zunächst die der Objektklasse (Bereich 504) zugehörigen Verfahren. Diese Verfahren enthalten unter anderem Anordnen des Objekts, Duplizieren des Objekts und Ausspeichern des Objekts. Alle Objektklassenverfahrenstabellen zeigen auf denselben Escher-Prozeduren in diesen Eintragungen, sofern diese Eintragungen nicht bei der Initialisierung durch eine der absteigenden Klassen überschrieben worden sind, die in einer speziellen Verfahrenstabelle 502 dargestellt sind. Die Klasse 502 enthält als nächstes einen Bereich 506, der Zeiger auf einen Satz Verfahren enthält, die für alle Objekte in der "Geteilt-Objekt"-Klasse geeignet sind. Wenn es geschieht, gibt es keine "Geteilt-Objekt"-Verfahren, so daß in dieser Schicht kein Raum zugeteilt wird. Im Bereich 506 folgt ein Bereich 508, der Zeiger auf einen Satz Verfahren enthält, die für alle Aufbe reiter geeignet sind. Es gibt keine Schicht speziell für die Drahtmodell-Aufbereiterklasse, weil durch Verabredung im Escher-Design Blattklassen eine eigene Verfahrenstabelle haben.
Der Bereich 512 speichert alle Daten für einen Spezialfall von Klasse 12. Dieser Bereich ist in der gleichen Weise organisiert wie der Bereich 502. Insbesondere enthält er zunächst alle Daten, die für jeden Spezialfall eine Objektklasse im Bereich 514 geeignet sind, gefolgt von allen Daten, die für jeden Spezialfall einer Geteilt-Objektklasse im Bereich 516 geeignet sind, gefolgt von allen Daten, die für jeden Spezialfall eines Aufbereiterobjekts im Bereich 518 geeignet sind. Anders als die Klassendaten 502 enthalten die Spezialfalldaten 512 auch einen Bereich 520, der all die Daten enthält, die für einen Spezialfall eines Drahtmodellaufbereiterobjekts geeignet sind. Die Objektdaten im Bereich 514 enthalten lediglich einen Zeiger auf die Verfahrenstabellen 502, die gemeinsam für alle Spezialfälle von Drahtmodellaufbereiterobjekten sind. Die Geteilt-Objektdaten im Bereich 516 enthalten eine Bezugszählung, und die Aufbereiterobjektdaten im Bereich 518 und die Drahtmodellaufbereiterdaten im Bereich 520 werden später erläutert.
In 5 ist auch für Illustrationszwecke ein zweiter Spezialfall eines Objekts in der Drahtmodellaufbereiterklasse gezeigt. Der zweite Spezialfall hat all seine Daten im Bereich 522 versammelt, im selben Format wie die Daten des ersten Spezialfalls im Bereich 512. Die Objektdaten im Bereich 524 dieser Daten zeigen auf dieselbe Objektklassenverfahrenstabelle 502 wie es die Objektdaten für den ersten Spezialfall tun. Es sei angemerkt, daß der zweite Spezialfall in 5 nur angegeben ist, das Verhältnis zwischen Klassen und Spezialfalldaten im Escher-Objektmechanismus darzustellen. Es ist unwahrscheinlich, daß mehr als ein Spezialfall eines Drahtmodellaufbereiters insbesondere jemals in einer einzigen Spezialisierung eines Anwendungsprogramms koexistieren würde, jedoch ist dieses nicht ausgeschlossen.
Es ist nun nützlich, die im Escher-System verwendete Klasssenhierarchie zu beschreiben. Diese Hierarchie ist ausgedehnt, und nur jene Klassen, die für das Verständnis der Erfindung wesentlich sind, werden in 6 gezeigt. Bezugnehmend auf 6 kann man sehen, daß die EtObject-Klasse die Grundklasse für alle Klassen in der Hierarchie ist. Die EtSharedObject-Klasse ist unterklassiert, unter EtObject, wie es andere Klassen sind, die hier nicht wichtig sind. Unterklassiert unter die EtSharedObject-Klasse ist eine EtShapeObject-Klasse, eine EtRendererObject-Klasse, eine EtSetObject-Klasse, eine EtDrawContext-Klasse, eine EtViewObject-Klasse, eine EtQualityCollection-Klasse und eine EtQualityGroupObject-Klasse. Unterklassiert unter die EtShapeObject-Klasse sind eine EtStyleObject-Klasse eine EtTransformObject-Klasse, eine EtCamera-Object-Klasse, eine EtLightObjectKlasse, eine EtGeometryObject-Klasse, eine EtGroup-Klasse und eine EtShaderObject-Klasse, und unterklassiert unter die EdRendererObject-Klasse sind eine Z-Puffer-Klasse und eine Drahtmodellklasse. Unterklassiert unter die EtStyleObject-Klasse ist eine BackfacingStyle-Klasse, unter anderem. Unterklassiert unter die EtTranformObject-Klasse sind eine Dreh-Klasse, eine Maßstab-Klasse und eine Übersetzung-Klasse, unter anderem und hier nicht dargestellt. Unterklassiert unter die EtGeometryObject-Klasse sind Klassen für Linie, Punkt, Polygon, Poly-Line, Toros, und Dreieck als Objekte, unter anderem. Unterklassiert unter die EtGroup-Klasse sind eine EtLightGroup-Klasse, eine EtInfoGroup-Klasse und eine EtDisplayGroup-Klasse, von denen die letzte Unterklassen EtOrderedGroup und EtListGroup hat. Diese Klassenhierarchie beschreibt die Speicherung von Verfahrenstabellen und Spezialfalldaten für jede der in der Hierarchie enthaltenen Klassen. Die Klassen an der Enden der Hierarchie, das heißt die "Blätter" der Baumstrukturen sind bekannt als "Blatt"-Klassen.
B: Registrierung eines Aufbereiters
Die Basis für die Objektunterklassierung bei Escher besteht darin, daß Escher seine Verfahrenstabelle dynamisch zur Systemstartzeit unter Verwendung von Erweiterungsmechanismen aufbaut. Jede Objektklasse im System, einschließlich der Aufbereiterobjektklassen, wird unter der Steuerung durch die Erlnitialize-Prozedur, die durch das Anwendungsprogramm aufgerufen wird, "registriert", so daß ihre Funktionalität erforderlichenfalls verfügbar ist. Da jede Erweiterung geladen ist, erhält Escher die Adresse der Initialisierungsfunktion der Erweiterung aus dem Betriebsmittelzweig des Erweiterungsdokuments. Es ruft dann jene Funktion auf.
Das folgende ist eine C-Sprachen-Initialisierungsprozedur, genannt ErWF.Register, die durch die Drahtmodell-Aufbereitererweiterung verwendet wird.
Wenn eine Klasse registriert ist, liefert sie Verfahren, die das Verhalten von Spezialfällen der Klasse bestimmen. Die Klasse liefert diese Verfahren an Escher über einen Metahändler. Ein Metahändler ist eine Funktion, die Escher-Verfahrenstypen auf Funktionszeiger kardiert. Escher bittet die Metahändlerfunktion, ihm ein Verfahren eines gewissen Typs anzugeben, und wenn der Metahändler den Verfahrenstyp kennt, liefert er sein entsprechendes Verfahren. Wenn der Metahändler den angeforderten Verfahrenstyp nicht kennt, kehrt er auf Null zurück. Wie man sehen kann, registriert der erste Schritt des ErWF.Register die neue Drahtmodellunterklasse durch Aufruf des Aufbereiterklassenregisterierungsverfahrens ErRendererClass.Register mit einer Identifizierung des Metahändlers des Drahtmodellaufbereiters ErWF.MetaHandler als Argument. Der Metahändler des Drahtmodellaufbereiters ist wie folgt:
Escher ruft den Metahändler einmal jeden Eintrag in seine Verfahrenstabelle auf und verlangt jedesmal die Identifizierung eines anderen Drahtmodellverfahrens.
Die EtRendererObject-Klasse enthält eine Verfahrenstabelle für die Aufbereitung geometrischer Formen. Jeder Aufbereiter muß ein Verfahren zum Aufbereiten von wenigstens drei Geometriegrundtypen liefern: Punkt, Linie und Dreieck. Der Aufbereiter kann auch Verfahren zum Aufbereiten komplexerer Geometrietypen liefern. Nach dem Registrieren eines Metahändlers hofft die obige Drahtmodellprozedur die ErWF.Register daher die Aufbereiterklassenprozedur ErRendererClass_OverrideGeometrylTypeDrawMethod auf, um die Geometriezeichnungsverfahren, die er untersützt, einzurichten. Wie man sehen kann, registriert der Drahtmodellaufbereiter Prozeduren zum Aufbereiten von Geometrien vom Typ Polygon, Dreieck, Linie, Polylinie (Folge von verbundenen Linien) und Punkten, unter anderem.
Die ErwF.Register-Prozedur überschreibt auch gewisse Transformationsverfahren und Attributeinstellverfahren in einer Verfahrenstabelle der Aufbereiterklasse.
Man kann sehen, daß durch den Objektmechanismus von Escher neue Aufbereiter im Betrieb in das Escher-System installiert werden können, indem sie lediglich zu Unterklassen unter die EtRendererObject-Klasse gemacht werden.
II. AUFBAU EINES SICHTOBJEKTS
A. Datenstrukturen
Wie erwähnt, ist ein Sichtobjekt eine Datenstruktur, die unter anderen Dingen Kamerainformation, Beleuchtungsinformation, Durchquerungs- oder Zustandsinformation sowie eine Angabe über eine Auswahl von Aufbereitern enthält. Jedes Sichtobjekt ist ein Spezialfall der Klasse EtViewObject, der, wie in 6 angegeben, eine Unterklasse der Klasse EtSharedObject ist, die ihrerseits eine Unterklasse unter der Klasse EtObject ist. Dementsprechend hat, folgend dem Format von 5, ein Sichtobjekt das Format von 7 im Speicher. Speziell ein Bereich des Speichers 702 ist so bestimmt, daß er Zeiger auf Verfahren der EtViewObject-Klasse enthält, und dieser Bereich 702 enthält Zeiger 704 auf Objektverfahren und Zeiger 706 auf Geteiltobjektverfahren. Die EtViewObject-Klasse ist eine Blattklasse, so daß in Übereinstimmung mit der Escher-Regel die Klasse eine Verfahrenstabelle speziell für Sichtobjektverfahren ausläßt. Es sei auch angemerkt, daß in der vorliegenden Ausführungsform auch keine Geteiltobjektverfahren vorhanden sind.
Die Struktur enthält auch Spezialfalldaten für das Sichtobjekt im Bereich 710 des Speichers. Dieser Bereich enthält Spezialfalldaten, die für die Objektklasse in einem Teil 712 spezifisch sind (der auf die Objektklasse 702 zeigt), Spezialfalldaten, die für die Geteiltobjektklasse in einem Teil 714 spezifisch sind (eine Bezugszählung enthaltend), und Spezialfalldaten, die für die Sichtobjektklasse in einem Teil 716 spezifisch sind. Die Sichtobjektdaten sind eine Datenstruktur vom Typ EtViewPrivate, der wie folgt beschrieben ist:
Wie man sehen kann, enthält ein Sichtobjekt unter anderem einen Zeiger (*rendererClass) auf die Verfahren eines gerade gewählten Aufbereiters, einen Zeiger (*renderer) auf die Spezialfalldaten des augenblicklichen Aufbereiters, ein Zeichnungskontextobjekt, ein Kameraobjekt, Beleuchtungsobjekte (Leuchten), mehrere Schattiererobjekte und ein Qualitätsgruppenobjekt.
Die EtRendererPrivate-Struktur ist wie folgt definiert:
Diese Struktur enthält Zeiger auf eine Serie von Stapeln, die den augenblicklichen Zustand einer Durchquerung angeben. Wie unten detaillierter beschrieben werden diese Zustandsstapel jedesmal gestoßen, wenn Escher's Durchquerer ein "Gruppen"-Objekt in einem Modell öffnet und die Durchquerung des nächsten Niveaus der Hierarchie beginnt. Diese Stapel werden auf den früheren Zustand angehoben, wenn der Durchquerer seine Arbeit bei allen unteren Niveaus der Modellhierarchie vervollständigt und ein "Gruppen"-Objekt schließt.
Die EtRendererClass Datenstruktur ist wie folgt definiert:
Es sei daran erinnert, daß die Initialisierungsprozedur des Drahtmodellaufbereiters, die oben beschrieben wurde, eine Metahändler einrichtet, den Escher aufrufen kann, um gewisse Verfahren der Aufbereiterklasse zu überschreiben. Escher setzt die durch den Metahändler rückgeführten Zeiger in die EtRendererClass-Strukturfelder, die oben für die entsprechenden Verfahren definiert sind. Es sei auch daran erinnert, daß die Initialisierungsprozedur des Drahtmodellaufbereiters einige Verfahren überschreibt, insbesondere gewisse Geometriezeichenverfahren unter Verwendung einer EtRendererCless_OverrideGeometryTypeDrawMethode. Diese Prozedur schreibt den Zeiger auf die spezifizierte Aufbereiterprozedur in die Verfahrenstabelle auf die durch *geometryDrawMethods gezeigt wird, um dadurch Fehlerverfahren zu überschreiben, die vom Eschersystem ursprünglich bei der Initialisierung eingestellt wurden. Die EtMethodTable Datenstruktur ist lediglich eine Liste von Zeigern; für *geometryDrawMethods zeigt jeder Eintrag in der Tabelle auf die Prozedur zur Aufbereitung einer entsprechend dem Geometrietype beispielswei se Punkt, Linie, Dreieck usw.. Die Korrespondenz zwischen Stellen in dieser Tabelle und Geometrietypen wird bei der Kompelierung festgelegt.
Ein anderes Feld in der EtRendererClass-Datenstruktur, das erwähnt werden sollte, ist das geometryDrawMethods-Feld. Dieses Feld enthält einen Zeiger auf einer Prozedur, die Escher aufrufen wird, wenn von ihm verlangt worden ist, eine Geometrietype zu zeichnen, die der laufende Aufbereiter nicht unterstützt (d.h., der Verfahrenstabelleneintrag *geometryDrawMethods für die Geometrie ist NULL). Diese Prozedur zerlegt die spezifizierte Geometrie in ähnliche Geometrien, wie weiter unten im Detail erläutert. In der vorliegenden Ausführungsform kann die Zerlegungsprozedur nicht ausgeschaltet werden. In einer anderen Ausführungsform der Erfindung kann jedoch ein Aufbereiter dieses Zerlegungsverfahren unwirksam machen, um den Prozeß zu optimieren.
Die EtQualityGroupObject-Struktur wird nachfolgend beschrieben.
B. Prozeduren
Das Verfahren zum Aufbauen eines Sichtobjekts in Schritt 304 (3) ist im wesentlichen das Verfahren zum Einschreiben gewünschter Informationen in die Sichtobjektdatenstruktur. Das beispielhafte Anwendungsprogramm in Anhang A wird dazu verwendet, das Verfahren zu erläutern.
1. Erzeugen eines Sichtobjekts
Nach Initialisierung und Einrichtung einer Qualitätssammlung erzeugt das Anwendungsprogramm ein neues Sichtobjekt durch Aufruf von view = ErView_New(). Diese Prozedur erzeugt lediglich einen neuen Spezialfall eines Objekt in der EtRendererClass und füllt es mit Fehlerdaten.
2. Einstellen des Aufbereiters
Ein Aufbereiter kann an ein Sichtobjekt angehängt werden, indem eine Escherprozedur ErView_SetRenderer aufgerufen wird und das Sichtobjekt und das Aufbereiterobjekt einge geben werden. Dieser Aufruf erhöht die Referenzzählung des eingegebenen Aufbereiters. Wenn ein Aufbereiterobjekt bereits eingestellt ist, dann wird seine Bezugszählung vermindert.
Ein Aufbereiter kann auch durch Aufbereiterart eingestellt werden, ohne daß man zunächst ein Spezialfall eines Aufbereiterobjekts erhalten haben muß. In diesem Fall ruft das Anwendungsprogramm die Escherroutine ErView_SetRendererByType auf, und dieses ist die Prozedur, die durch das Beispielprogramm in Anhang A aufgerufen wird. Die durch diese Prozedur angegebenen Parameter sind das Sichtobjekt und die Typbestimmung, was ein Vier-Zeichen-Code ist, der einen Aufbereitertyp bezeichnet (beispielsweise Drahtmodell oder Z-Puffer). Die Escherprozedur ErView_SetRendererByType bestimmt, welcher Aufbereiter der spezifizierten Art registriert worden ist, und wenn ein solcher Aufbereiter registriert worden ist, wird ein Zeiger auf die Aufbereiterspezialdaten in den entsprechenden Eintrag des spezifizierten Sichtobjekts eingeschrieben.
3. Einstellen der Kamera
Vor dem Einstellen der Kamera muß ein Kameraobjekt geschaffen und initialisiert werden. Das Programmbeispiel in Anhang A führt dies durch Einschreiben der Kameraperspektivarten in eine geeignete perspectiveData-Datenstruktur aus und weist sie einem Kameraobjekt zu unter Verwendung der Escherprozedur ErViewAngleAspectCamera_NewData. Sobald ein Kameraobjekt erhalten ist, kann es dem Sichtobjekt zugeordnet werden, durch Aufruf von ErView_SetCamera, Eingeben des Sichtobjekts und des Kameraobjekts. Dieser Aufruf erhöht die Bezugszählung des eingegebenen Kameraobjekts. Wenn das Kameraobjekt bereits eingegeben war, wird seine Bezugszählung vermindert. Das Programmbeispiel in Anhang A benutzt dann das Kameraobjekt unter Verwendung der Escherfunktion ErObject_Dispose, da das Kameraobjekt nicht mehr getrennt benötigt wird.
4. Einstellen des Zeichnungskontextes
Vor dem Einstellen des Zeichnungskontextes muß ein Zeichnungskontextobjekt erzeugt und initialisiert werden. Im Programmbeispiel in Anhang A wird dieses durch Einrichten einer geeigneten Datenstruktur PixmapData bewerkstelligt und durch Eingeben in die Escherprozedur ErPixmapDrawContext_NewData. Das Zeichnungskontexobjekt wird dann dem Sichtobjekt unter Verwendung des Aufrufs ErView_SetDrawContext zugeordnet unter Verwendung des Aufrufs ErView_SetDrawContext und Eingeben des Sichtobjekts und des Zeichnungskontextobjekts. Das Anwendungsprogrammbeispiel in Anhang A stellt dann das Zeichnungskontextobjekt durch Übergabe an die Escherfunktion ErObject_Dispose ein.
Anderer Eigenschaften der Ansicht können auch in ähnlicher Weise spezifiziert werden, wie beispielsweise Beleuchtung und Schattierung
5. Auswahl des Aufbereitungsqualitätsniveaus
Dieses wird nachfolgend detaillierter beschrieben.
Man kann erkennen, daß der Aufbau und die Editierung eines Sichtobjekts vollständig getrennt vom Aufbau und Editieren eines anderen Sichtobjekts sind, so daß mehr als ein Sichtobjekt (einschließlich jener, die den selben oder unterschiedliche Aufbereiter spezifizieren) ohne gegenseitige Störung koexistieren können.
III. AUFBAU EINES MODELLS
Das Modellbildungsverfahren, das bei Escher verwendet wird, versteht man am besten aus einem Vergleich der Modellbildungsmuster, die bei zwei existierenden Produkten verwendet werden, die von Apple Computer angeboten werden: QuickDraw und QuckDraw GX. QuickDraw GX ist in Apple Computer "QuickDraw GX Programmer's Overview" (1994) beschrieben, das hier durch Bezugnahme in die Beschreibung eingebaut wird. Sowohl QuickDraw als auch QuickDraw GX führen zweidimensionale Graphikverarbeitung anstelle dreidimensionaler Verarbeitung aus. Das zweidimensionale Graphiksystem QuickDraw besitzt eine Prozeßschnittstelle und einen Globalgraphikzustand, der die Farbe, die Transferart und das Transfermuster der von ihr gezeichneten Formen definiert. Wenn die Gestaltezeichnungsroutinen von QuickDraw aufgerufen werden, zeichnet QuickDraw die Gestalt gemäß der Variablen in ihrem Graphikzustand. Ein Anwendungsprogramm kann den Graphikzustand durch Verwendung anderer Aufrufe an QuickDraw manipulieren.
QuickDraw GX unterscheidet sich von QuickDraw dadurch, daß anstelle einer Prozeßschnittstelle mit einem systemunterstützenden Graphikzustand Gestalten als Objekte dargestellt werden, die alle Information enthalten, die notwendig sind, um sie zu zeichnen. Es gibt keinen systemgestützten Graphikzustand. Weil Gestalten Objekte sind, kann QuickDraw GX Nutzen liefern, mit solchen Gestalten zu arbeiten, was QuickDraw nicht kann, weil die Routinen von QuickDraw nur Bilder in eine Bildpunktkarte zeichnen. QuickDraw GX liefert Funktionalität zum Arbeiten an Gestalten, sowie "hit"-Prüfung und geometrische Überschneidung.
Der Hauptdatentyp bei QuickDraw GX ist eine "Gestalt", die die Geometrie und andere Zeichnungsinformation in sich einschließt. Gestalten werden über ein "Sichttor" gezeichnet, das die Gestalten in "Sichtvorrichtungs"-Koordinaten transformiert. Wenn eine Gestalt bei QuickDraw GX zum Zeichnen eingegeben wird, dann wird die Gestalt durch jedes Sichttor gezeichnet, das an die Gestalt angehängt ist. Ein Sichttor kann mehrere Sichtvorrichtungen überlappen, in welchem Fall die Gestalt auf jede Sichtvorrichtung mit ihrer richtigen Auflösung gezeichnet wird. QuickDraw GX-Gestalten können in Hierarchien durch Verwendung der "Bildgestalt" organisiert werden. Jede Gestalt hat einen "Typ", der ihr zugeordnet ist, der angibt, ob sie eine Linie, ein Polygon, eine Kurve usw. ist. Der Zugang zu gestalten erfolgt über eine Prozeßschnittstelle und Handhabe.
Die Gestaltzeichnungsprozedur von QuickDraw GX kann zu jeder beliebigen Zeit aufgerufen werden, um eine Gestalt zu zeichnen. Die Anordnung von Gestalten, die gezeichnet werden, übereinander ist abhängig von der Reihenfolge, in der sie gezeichnet werden. Zwischen den Zeichenbefehlen wird keine Zustandsinformation rückgehalten, mit Ausnahme für interne Zwischenspeicherinformation, weil jede Gestalt alle Information in sich einschließt, die notwendig ist, um diese Gestalt zu zeichnen, einschließlich Sichttor, Sichtvorrichtung, Farbe, Übertragungsart und Zeichnungsstil.
Das Eschersystem unterscheidet sich bemerkenswert von QuickDraw und QuickDraw GX aufgrund der Natur der dreidimensionalen Aufbereitungsalgorithmen und der typischerweise größeren Datenvolumina, die erforderlich sind, um ein dreidimensionales Modell zu beschreiben.
Eschergestalten enthalten in sich nicht alle Informationen, die erforderlich ist, sie selbst zu zeichnen. Vielmehr unterhält Escher einen "Zustand", der zusätzliche Informationen darüber liefert, wie ein Gestalt aufzubereiten ist, sowie das ursprüngliche QuickDraw einen Zeichnungszustand für die Vordergrundfarbe am Graphikport aufrechterhält.
Escher's Zustandsmechanismus erlaubt den Aufbau hierarchischer Modelle, die Information angeben, wie Farbe oder Zeichnungsstiel, die durch Gestalten an unteren Niveaus der Hierarchie mitgeschleppt werden. Der Mechanismus liefert gesteigerte Flexibilität bei der Anführung eines Modells, das in einer Szene mehreremale zu verwenden ist, jedoch mit variierenden Attributen, ohne die Geometrie neu zu spezifizieren. Escher unterscheidet sich von QuickDraw GX auch darin, daß die Zeichnungsfläche für die Aufbereitung bei Escher vor der Aufbereitung des Bildes spezifiziert wird durch Anhang an ein Sichtobjekt und nicht durch Anhang an jede Gestalt, wie es bei QuickDraw GX der Fall ist.
Escher liefert mehrere Datentypen für den Einschluß von Geometrie und Aussehen in einer Modellhierarchie. Die allgemeinen Datentypenklassen sind Geometrie "Attributsatz", Stil, Transformation und Gruppe. Es ist vorteilhaft, das Aussehen in mehrere Datentypen in dieser Art zu separieren wegen der typischen Komplexität von dreidimensionalen Modellen. Selbst einfache dreidimensionale Gestalten können hunderte oder tausende geometrischer Figuren erfordern, um ein dem Realismus gleichkommendes Bild zu erzeugen. Um eine realistisch aussehende Gestalt beliebiger Komplexität zu erzeugen, wie beispielsweise einen Raum in einem Haus, können hunderte und tausende oder Millionen geometrischer Gestalten erforderlich sein. Beim Umgang mit Modellen dieser Größenordnung ist es häufig vorteilhaft, eine einfache Erscheinungscharakteristik an einer großen Gruppe geometrischer Formen anzuwenden, um dadurch Speicherplatz zu sparen und den Aufbau und die Editierung eine solchen Modells zu vereinfachen. Die obigen Datentypen erleichtern diese Aufgabe.
Bei den QuickDraw GX Modellhierarchien werden Transformationsumsetzungen einer "Bildgestalt" als mit jenen der Gestalten verkettet angesehen, die sie umfassen. Dieses bildet einen Bezug zur selben Gestalt mehr als einmal und verwendet Transformationsumsetzungen zur Bewegung oder Transformation der Gestalt, ohne ein zweite Kopie davon im Speicher zu haben. Eine solche Verkettung wird bei QuickDraw GX über einen Zustandsmechanismus erzielt, der eine Aufzeichnung der "augenblicklichen Transfor mationsumsetzung" bewahrt, wenn ein Modellhierarchie durchquert wird. QuickDraw GX Bildhierarchien werden von oben nach unten, von links nach rechts durchquert. Wenn in der Hierarchie weiter unten befindliche Gestalten überquert werden, werden Transformationsumsetzungen mit der laufenden Transformationsumsetzung verkettet. Nachdem alle Gestalten innerhalb einer Bildgestalt gezeichnet worden sind, kehrt die Durchquerung zum vorangehenden Bild zurück, falls vorhanden, und nimmt die Durchquerung ihrer Gestalten wieder auf. Dieses wird "Abwärtsdurchquerung" genannt. Bei der Rückkehr von einer Durchquerung wird die laufende Transformationsumsetzung auf das rückgestellt, was es war, bevor die Bildgestalt eingegeben wurde. Diesen Mechanismus kann man als einen Stapel von Umsetzungen auffassen, der während der Durchquerung gedrückt und gestoßen wird, Wenn die Grundbildgestalt fertiggezeichnet wird, ist die laufende Umsetzung NULL:
Escher liefert einen ähnlichen Durchquerungsmechanismus, obgleich wegen der gesteigerten Komplexität dreidimensionaler Modelle mehr als lediglich eine Transformationsumsetzung mitgeführt werden. Aussehen und Stile werden ebenfalls mitgeführt.
Während bei QuickDraw GX keine "laufende Transformationsumsetzung" vorhanden ist, wenn das QuickDraw GX-System nicht ein Bild durchquert, ist bei Escher für ein Anwendungsprogramm möglich, den laufenden Zustand selbst draufzulegen und abzuheben. Tatsächlich können Anwendungsprogramme Eschergestalten in einer anwendungsspezifischen hierarchischen Datenstruktur aufrechterhalten, falls gewünscht, und über eine sorgfältige Folgesteuerung der Aufrufe von Escherprozeduren 202 eine Systemhierarchie simulieren. Dieses Merkmal ist extrem vorteilhaft für Anwendungsprogramme, die komplexe anwendungsspezifische hierarchische Datenstrukturen verwenden, wie beispielsweise Animationssysteme, oder beim Portieren eines existierenden Anwendungsprogramms, das bereits seine eigenen Datenstrukturen hat. Das bekannte PHIGS-System und andere Aufrechterhaltungsbetriebssysteme verlangen, daß das gesamte Modell in einer einzigen Hierarchie liegt, und GL behandelt jedes Objekt unabhängig. Ein Anwendungsprogramm kann den Zustand einstellen, eine Anzahl unabhängiger geometrischer Objekte zeichnen und dann das Eschersystem veranlassen, ein in der Eschersystem-Datenstruktur aufgebautes und gespeichertes Modell aufzubereiten, dann mehrere unabhängige geometrische Objekte zu zeichnen, usw..
8 ist eine graphische Darstellung einer einfachen Modellhierarchie, die durch das beispielhafte Anwendungsprogramm in Anhang A aufgebaut wird. Es enthält zwei Niveaus, das erste (Grund-)Niveau, daß durch die EtDisplayGroupObject genannte "Gruppe" umschlossen wird, und das zweite, das durch die EtDisplayGroupObject genannte "Untergruppe" umschlossen wird. Jedes EtDisplayGroupObject kann man sich als einen Knoten in der Hierarchie vorstellen. Jedem Knoten Stilobjekte, Geometrieobjekte, Transformationsobjekte und andere Gruppenobjekte (wie in 8) zugeordnet sein, sowie Schattiererobjekte und Attributsatzobjekte.
Escher unterstützt zwei Arten von EtDisplayGroupObject, nämlich solche in der Unterklasse EtOrderedGroup und EtListGroup. Objekte, die an ein Beispiel in der EtListGroup-Klasse angehängt sind, haben keine Reihenfolge mit Ausnahme der Reihenfolge, in der sie zu der Gruppe hinzuaddiert wurden. Wenn während der Durchquerung Escher ein Listengruppenobjekt trifft, wird jedes Objekt in der Liste verarbeitet ("ausgeführt") in der Folge, in der es ursprünglich zu der Gruppe hinzugefügt wurde. Bezugnehmend auf 8, sobald die Gruppe group während einer Durchquerung geöffnet wird, führt Escher backfacingStyle, dann polygon, line, dann transform, dann subGroup in dieser Folge aus, weil dieses die Folge war, mit der sie zu group hinzugefügt wurden. Die Änderungen im Aufbereitungszustand, die durch backfacingStyle verursacht sind, gelten somit auch bei polygon und line, während die Änderungen am Aufbereitungszustand, die durch transform verursacht sind, gelten nur für die Objekte in subGroup. Die Escher-API enthält Aufrufe, die es dem Anwendungsprogramm erlauben, Objekte zum Beginn der Liste, zum Ende der Liste oder zwischen bereits in der Liste befindliche Objekte hinzuzufügen.
Ein Gruppenobjekt der Unterklasse EtOrderedGroup ist ähnlich einem Listengruppenobjekt mit der Ausnahme, daß der Durchquerer das Objekt sortiert, das der Gruppe zugefügt ist, in Abhängigkeit vom Typ, bevor sie ausgeführt werden. Insbesondere werden Objekte in der folgenden Sequenz ausgeführt: Transformationsobjekte, Stilobjekte, Attributsatzobjekte, Schattierer, Geometrien und zusätzliche Gruppen.
Für beide Arten Gruppenobjekte wird, wenn eine Untergruppe geöffnet wird, der dann laufende Zustand des Aufbereiters mitgeschleppt. Objekte in der Untergruppe können jede Charakteristik des Zustands für nachfolgend ausgeführte Objekte in der Untergruppe (oder in Untergruppen der Untergruppe) ändern, bei der Rückkehr zur Stammgruppe wird der Zustand jedoch in jenen Zustand wieder hergestellt, der vor dem Eintreten des Durchquerers in die Untergruppe herrschte.
Gruppenobjekte haben auch einen "Zustand", der ihnen zugeordnet ist, obgleich dies nicht mit dem "Zustand" des Durchquerers verwechselt werden darf. Der Zustand einer Gruppe ist lediglich eine Sammlung von Kennzeichen, die Aspekte definieren, wie die Gruppe zu behandeln ist. Die meisten der Kennzeichen sind für das Verständnis der vorliegenden Erfindung nicht wichtig, es kann jedoch hilfreich sein, eines dieser Kennzeichnen zu verstehen, nämlich "in-line". Bei Modellieranwendungen kann es manchmal nützlich sein, einen Satz von Materialien oder Stilen zusammen in ein Bündel zu gruppieren, auf das man in einem Modell mehrmals zurückgreifen kann. Wenn ein solches Bündel unter Verwendung normalen Auflegens und Abhebens eines Durchquererzustands oben beschrieben geschaffen wird, haben diese Objekte jedoch nicht den gewünschten Einfluß auf das Modell, weil die Gruppe den Zustand abhebt, nachdem er durch den Traverser ausgeführt ist. Dementsprechend kann das Anwendungsprogramm das "in-line"-Kennzeichen des Gruppenobjekts setzen, um dadurch zu spezifizieren, daß Eintritt in die Gruppe und Austritt aus der Gruppe nicht dazu da sind, den Zustand des Durchquerers draufzulegen oder abzuheben. Die Escher-API liefert Prozeduraufrufe zum Einstellen, Löschen und Erhalten des laufenden Wertes dieses Kennzeichens.
A. Datenstrukturen
Wie bei der Prozedur zum Aufbau einer Ansicht ist es hilfreich, gewisse Datenstrukturen zu beschreiben, bevor die Escherprozeduren beschrieben werden, die ein Anwendungsprogramm zum Aufbau eines Modells aufrufen kann.
In dem beispielhaften Anwendungsprogramm in Anhang A sind die Gruppen group und subGroup geordnete Anzeigegruppenobjekte. Sie haben einen Typ EtDisplayGroup, der in der Klassenhierarchie von 6 einen Klassenvorgänger von EtGroupObject, EtShapeObject, EtSharedObject und schließlich EtObject hat. Dementsprechend sind sie im Speicher mit Datenstrukturen wie in 9 gezeigt, repräsentiert. Insbesondere ist die geordnete Anzeigegruppenklassenverfahrenstabelle in einem Block von Speicher 902 enthalten, und die Beispielsdaten für group und subGroup sind in Blöcken 904 bzw. 906 enthalten. Die geordnete Anzeigegruppenklasse 902 beginnt mit dem Bereich 908, der Zeiger auf Objektverfahren enthält, ähnlich dem Bereich 504 in 5. Dem Bereich 908 folgt Bereich 910, der Zeiger auf alle Verfahren enthält, die für geteilte Objekt spezifisch sind (in der vorliegenden Ausführungsform gibt es keine). Diesem folgt ein Bereich 912, der Zeiger auf alle Gestaltobjektverfahren enthält, und diesem folgt ein Bereich 914, der Zeiger auf die Verfahren enthält, die für Gruppenobjekte spezifisch sind. Die letztgenannte Datenstruktur, EtGroutClass, hat die folgende Typdefinition:
Wie man sehen kann, sind Eintragungen für Zeiger auf verschiedene Verfahren enthalten, unter anderem ein Verfahren zum Hinzufügen eines Objekts zum Ende der Gruppe (add), und Verfahren zum Hinzufügen eines Objekts an einer speziellen Stelle innerhalb der Liste von Objekten, die bereits einer Gruppe zugewiesen sind (addBefore und addAfter) Nach Bereich 914 enthält die geordnete Anzeigengruppenklassenverfahrenstabelle 902 Zeiger auf die Verfahren, die für Anzeigengruppen in einem Bereich 916 spezifisch sind. Diese Datenstruktur EtDisplayGroupClass ist wie folgt definiert:
Die Verfahren in der EtDisplayGroupClass sind für das Verständnis der Erfindung nicht wesentlich, es sei jedoch angemerkt, daß die Klasse keine Zeige auf irgendwelche Zeichnungsverfahren enthält. Die Ziffer erläutert werden diese Verfahren in einem Sichtobjekt statt in einem Gruppenobjekt identifiziert, so daß sie durch einen Aufbereiter unwirksam gemacht werden können. Jedes Zeichnungsverfahren, das in der Klasse für ein Objekt identifiziert wird, würde Teil des aufzubauenden Modells werden, würde mit dem Modell selbst verwebt werden und wäre schwierig zu ändern, wenn ein Anwendungsprogramm wünscht, das Modell unter Verwendung eines anderen Aufbereiters aufzubereiten. Eine solche Anordnung würde es auch schwierig machen, mehr als einen Aufbereiter gleichzeitig aktiv zu machen, wie zuvor beschrieben wurde.
Nochmals Bezug nehmend auf die Verfahrenstabelle 902, wie es typisch für die Gestaltung des Eschersystems in bezug auf Blattklassen in der Klassenhierarchie (6) ist, enthält die Tabelle keine Verfahren, die spezifisch für geordnete Anzeigegruppen sind.
Die Datenstruktur der Beispielsdaten für subGroup ist dieselbe wie jene für group, so daß nur die Datenstruktur für group beschrieben wird. Wie bei der Datenstruktur für den Beispielsdatenblock 512 in 5 beginnt Block 904 mit Objektdaten im Bereich 920, speziell ein Zeiger auf den geordneten Anzeigegruppenklassenblock 902. Diesem folgt ein Bereich 922, der die geteilten Objektdaten enthält, speziell eine Referenzzählung. Diesem folgt ein Bereich 924, der die Gestaltobjektdaten (die auch sehr kurz sind) enthält. Dem Gestaltobjektdatenbereich 924 folgt ein Bereich 926, der die Objektdaten für Gruppenobjekte enthält, von denen im vorliegenden Beispiel keine vorhanden sind.
Dem Bereich 926 folgt ein Bereich 928, der die Beispielsdaten für Anzeigegruppenobjekte enthält. Solche Daten enthalten nur die "Zustands"-Kennzeichen, die oben beschrieben sind. Dem Bereich 928 folgt ein Bereich 930, der die Daten enthält, die spezifisch für ein Beispiel eines geordneten Anzeigegruppenobjektes sind. Diese Daten haben ein Format, das wie folgt definiert ist, wobei EtDLList eine Typdefinition für eine doppeltverbundene Liste ist:
Wie man sehen kann enthält der Bereich 930 Zeiger auf sechs doppeltverbundene Listen, einen für jede der Objekttypen, die zu einem Anzeigengruppenobjekt hinzugefügt werden können. Zur Vollständigkeit sei angemerkt, daß wenn group eine Listenanzeigegruppe anstelle einer geordneten Anzeigegruppe ist, der einzige Unterschied die Struktur des Bereichs 930 ist. Insbesondere würde der Bereich 930, der eine als EtListDisplayGroupPrivate definierte Struktur hätte, nur ein Zeiger auf eine einzige doppeltverbundene Liste für all die Objekte haben, die zur Anzeigegruppe hinzugefügt sind.
Zusätzlich zur Struktur EtListDisplayGroupObjekt verwendet das beispielhafte Anwendungsprogramm in Anhang A auf eine Datenstruktur EtStyleObject, eine Datenstruktur EtGeometryOject und eine Datenstruktur EtTransformObject. Diese Strukturen beziehen sich sämtlich auf Klassen von Objekten, die wie EtGroupObject von der EtShapeObject-Klasse unterklassiert sind (siehe 6). Wie bei anderen hier beschriebenen Objekten beziehen sie sich jeweils auf eine Verfahrenstabelle 902 9 und enthalten private Beispielsdaten, wie Bereich 904 oder 906 in 9. Diese drei Klassen sind jeweils unterklassiert aus derselben Hauptklasse (EtShapeObject), wie EtGroupObject ist (siehe 6), und deshalb sind die ersten drei Schichten sowohl der Klassendaten als auch der Beispielsdaten von der gleichen Struktur, wie in 9 gezeigt. die Blattklasse (BackfacingStyle), die in dem Beispielprogramm in der EtStyleObject Klasse augenblicklich verwendet wird, ist eine Unterklasse der EtStyleObject, so daß die vierten und letzten Schichten der Klassenverfahren für dieses Objekt Zeiger auf die Verfahren enthalten, die spezifisch für Stilobjekte sind. Die vierte Schicht der Beispielsdaten enthalten private Daten, die für alle Stilobjekte, sofern vorhanden, geeignet sind, und die fünften und letzten Schichten enthalten Daten, die für rückwärtsgewandte Stilobjekte geeignet sind.
In gleicher Weise ist die Blattklasse (translate), die wirklich im Beispielprogramm in der Klasse EtTransformObject verwendet wird, eine Unterklasse der Klasse EtTransformObject (siehe 6), daß die vierten und letzten Schichten der Klassenverfahren für das Transformationsobjekt Zeigerverfahren enthalten, die für Transformationsobjekte spezifisch sind. Die vierte Schicht der Beispielsdaten für das Transformationsobjekt enthält Daten, die für Transformationsobjekte spezifisch sind, die fünften und letzten Schichten enthalten Daten, die für Übersetzungstransformationsobjekte spezifisch sind.
Das Beispielprogramm erzeugt drei Objekte (polygon, line, torus), die Geometrieobjekte sind, und alle von ihnen sind in Blattklassen, Unterklassen der EtGroupObject sind (6). Somit enthalten die vierten und fünften Schichten der Klassenverfahrenstabelle für jedes dieser Objekte Zeiger auf Verfahren, die spezifisch für Geometrieobjekte sind. Die vierte Schicht der Beispielsdaten für jedes dieser Objekte enthält Daten, die für jedes Geometrieobjekt spezifisch sind, und die fünften und letzten Schichten der Beispielsdaten für jede dieser Objekte enthalten Daten, die für Polygon-, Linien- bzw. Torusobjekte spezifisch sind.
Während bei Escher Attributsätze (die Attribute wie diffuse Farbe enthalten) Oberflächenerscheinungscharakeristika enthalten, weisen Stile einen Aufbereiter an, wie er eine geometrische Gestalt zeichnen soll. Beispielsweise kann ein Polygon als eine vollständig ausgefüllte Gestalt aufbereitet werden, oder nur mit seinen Rändern. Ein weiteres Beispiel ist, daß Oberflächen sanft oder mit einem facerttierten Aussehen aufbereitet werden können. Ein weiteres Beispiel, das durch ein rückwärtsgewandtes Stilobjekt (Unterklasse von EtStyleObject) angegeben ist, bestimmt, ob Gestalten, die von der Kamera wegweisen, anzuzeigen sind, oder nicht. EcBackfacingStyle_RemoveBackfacing, die Charakteristik, die im Beispielsprogramm in Anhang A verwendet wird, gibt an, daß Gestalten, die von der Kamera wegweisen, nicht gezeichnet werden. Die privaten Daten für ein rückwärtsweisendes Stilobjekt enthält ein Langwort, das eine Konstante enthält, die angibt, ob sowohl nach vorn als auch nach hinten weisende Oberflächen zu zeichnen sind, ob nach hinten weisende Oberflächen zu entfernen sind oder ob nach hinten weisende Oberflächen, die keine zweiseitigen Attribute haben, mit ihren normalen getippt werden sollen, so daß sie stets gegen die Kamera weisen. Ein Anwendungsprogramm spezifiziert Stilcharakteristika in einem Modell durch Erzeugen eines geeigneten Stilobjektes und durch Addieren desselben an einer gewünschten Position in einem Gruppenobjekt des Modells.
Für Geometrieobjekte enthalten die privaten Daten in der letzten Schicht der Beispielsdaten Information, die notwendig ist, um eine spezielle Geometrie zu beschreiben. Beispielsweise spezifizieren private Daten in der letzten Schicht eines Polygonobjekts die Anzahl der Ecken, die Ecken und gewisse Attribute, die hier nicht relevant sind. Die privaten Daten in der letzten Schicht eines Linienobjekts enthalten die Stellen der zwei Endpunkte der Linie sowie einige Attributdaten, und die privaten Daten in der letzten Schicht eines Torusobjekts enthalten einen Ursprung, eine Orientierung, einen Hauptradius und einen Nebenradius sowie einige Attributdaten.
Ein Transformationsobjekt ermöglicht es dem Koordinatensystem, daß geometrische Gestalten enthält, geändert zu werden, so daß es möglich wird, Objekte im Raum anzuordnen und zu orientieren. Transformationen sind nützlich, die geometrische Darstellung von Objekten nicht ändern (die Ecken oder andere Daten, die die Gestalt beschreiben), vielmehr werden sie als Matrixen bei der Aufbereitung angewendet und "Bewegen" ein Objekt vorübergehend im Raum. Dieses ermöglicht, das auf ein einzelnes Objekt mehrfach mit unterschiedlichen Transformationen in einem Modell rückgegriffen werden kann, was die Möglichkeit bietet, ein Objekt an vielen verschiedenen Stellen innerhalb einer Szene anzuordnen. Ein Anwendungsprogramm spezifiziert Transformation durch Erzeugen eines geeigneten Transformationsobjekts aus einer Unterklasse der Klasse EtTransformObject (6) und durch Hinzufügen derselben an einer geeigneten Stelle in einer geeigneten Gruppe in einem Modell. Eine durch ein Anwendungsprogramm spezifizierte Transformation bleibt in der angegebenen Form bis zum Zeitpunkt der Aufbereitung erhalten, in welchem Punkt Escher die Transformation in eine vorübergehende Matrix konvertiert, die auf nachfolgende Objekte der Gruppe angewendet wird. Matrixen werden vor-multipliziert zu Vektoren eines Objekts. Escher-Transformationen vormultiplizieren die laufende Transformationsmatrix; deshalb spezifizieren Anwendungsprogramme Transformationen, die in umgekehrter Reihenfolge zu verketten sind. Dies befindet sich in Übereinstimmung mit der Anwendung von Matrixen in einer Hierarchie. Das heißt, Matrixe, die am Kopf der Hierarchie spezifiziert sind, werden zuletzt angewendet, und Matrixen, die gerade vor einem Objekt spezifiziert sind, werden zuerst angewendet. wendet, und Matrixen, die gerade vor einem Objekt spezifiziert sind, werden zuerst angewendet.
Escher unterstützt mehrere unterschiedliche Arten von Transformationen, von denen jede viel Escher durch Verwendung eines Objekts einer entsprechenden Unterklasse von EtTransformObject spezifiziert ist. Drei solcher Unterklasse sind in 6 dargestellt (Rotate, Scale und Translate). Die Escher-API liefert Prozeduren zum Erzeugen und Anordnen von Transformationsobjekten, zum Zeichnen derselben in Echtzeit, Einstellen ihres Inhalts auf neue Daten, erlangen der privaten Daten eines Transformationsobjektes, Einschreiben eines Transformationsobjekts in ein Dokument, usw. Die privaten Daten in der untersten Schicht von Beispielsdaten für ein Übersetzungstransformationsobjekt, das die Blattklasse ist, die im Beispielprogramm in Anhang A verwendet wird, spezifiziert die x-, y- und z-Koordinaten der Übersetzung.
B. Prozeduren
1. ErOrderedDisplyGroup_New()
Bezugnehmend auf Anhang A und 8 beginnt das beispielhafte Anwendungsprogramm den Aufbau des Modells der Gruppe 802, indem zuerst das neugeordnete Gruppenobjekt group unter Verwendung der Prozedur ErOrderedDisplayGroup_New() geschaffen wird. Escherobjekterschaffungsmechanismus ist ein rekursiver Mechanismus, der allgemein in dem Flußdiagramm von 10 dargestellt ist. Es sei angemerkt, daß die Klassenverfahrenstabelle für die geordnete Anzeigegruppenklasse während der Initialisierung nach Registrierung der geordneten Anzeigegruppenklasse geschaffen wurde, so daß nur ein Block von Beispielsdaten im neuen Objektmechanismus erschaffen und initialisiert werden muß.
Bezugnehmend auf 10 ruft zunächst im Schritt 1002 die "Neu"-Prozedur der Blattklasse seine Stammklasse "Neu"-Prozedur mit: (a) die statische Variable, die, wenn die Blattklasse registriert war, weist auf das obere Ende der Verfahrenstabelle jener Blattklasse, und (b) die Größe der Privatdatenstruktur der Blattklasse. In einem Schritt 1004 ruft dann die "Neu"-Prozedur jeder höheren Klasse die "Neu"-Prozedur seiner entspre chenden Stammklasse auf mit: (a) der Objektklassenzeiger geht darauf über, und (b) die Größe, die für alle absteigenden Klassen soweit benötigt wird, plus die Größe, die für die private Datenstruktur der augenblicklichen Klasse benötigt wird. In einem Schritt 1006 führt die "Neu"-Prozedur letzten Stammklasse (EiObject_New()) folgendes aus: (a) weist Speicherraum für die privaten Datenstrukturen zu, die für seine eigenen Privatdaten benötigt werden plus die Privatdaten für alle absteigenden Klassen. dieser Raum enthält dann den gesamten Block von Beispielsdaten für das neu geschaffene Objekt. Dann (b) initialisiert sie ihre eigene Privatdatenstruktur (durch Einschreiben des auf sie übergegangenen Objektklassenzeigers in das obere Ende des neu zugewiesenen Speicherblocks), und (c) kehrt zu seinem Aufrufer zurück (das die "Neu"-Prozedur der nächstniedrigen Klasse ist), wobei ein Zeiger auf den neu zugewiesenen Speicherblock rückgeführt wird. In einem Schritt 1008 führt dann die "Neu"-Prozedur der niedrigeren Klasse aus: (a) ruft ihre eigene Zugreifprozedur auf, um einen Zeiger auf die eigene private Datenstruktur der laufenden Klasse innerhalb des neu zugewiesenen Beispielsdatenblocks zu erhalten; (b) Initialisiert die eigene Privatdatenstruktur; und (c) kehrt zu ihrem Aufrufer zurück (der die "Neu"-Prozedur der nächstniedrigeren Klasse ist), wobei ein Zeiger auf den neu zugewiesenen Speicherblock rückgeführt wird. Die "Neu"-Prozedur der Blattklasse führt dasselbe aus, mit der Ausnahme, daß der Aufrufer typischerweise das Anwendungsprogramm anstelle einer "Neu"-Prozedur einer Unterklasse ist.
Einige wenige Beispiele von Escher's "Neu"-Prozeduren zeigen besser, wie dieses erreicht wird. Die "Neu"-Prozedur für ein geordnetes Anzeigegruppenobjekt, die die durch das Anwendungsprogramm aufgerufene Routine ist, hat folgendes Aussehen:
Wie man sehen kann, ruft diese Routine zunächst die "Neu"-Prozedur ihrer Stammklasse auf EiDisplayGroup_New() mit dem Zeiger auf die geordneten Anzeigegruppenklassenverfahrenstabellen EgOrderedDisplayGroupClass und die Größe der privaten Datenstruktur EtOrderDisplayGroupPrivate, die in der nächsten Schicht der Beispielsdaten für das gerade geschaffene Objekt benötigt werden. Wenn diese Prozedur rückkehrt, ist der Block von Beispielsdaten zugeordnet worden und sind höhere Niveaus initialisiert worden. Nach einer gewissen Fehlerprüfung erhält die Prozedur EiDisplayGroup_New() einen Zeiger (ordered) auf die geordnete Anzeigegruppenprivatdatenstruktur des zugewiesenen Blocks und initialisiert alle der doppeltverbundenen Listen auf NULL. Die Prozedur kehrt dann zum Anwendungsprogramm zurück, wobei der Zeiger auf den neugeschaffenen Beispielsdatenblock rückgeführt wird.
Die "Neu"-Prozedur der Anzeigegruppenklasse ist wie folgt:
Wie man sehen kann, ruft diese Prozedur zunächst die "Neu"-Prozedur EiGroup_New ihrer eigenen Stammklasse auf, setzt den Zeiger auf die Objektklasse und eine Datengröße, die durch die Größe von Privatdatengröße gegeben ist, die von der Stammklasse benötigt wird, plus die Speicherraumgröße, die für die Privatdaten der Objekte in der Gruppenklasse (EtDisplayGroupPrivate) benötigt wird. Nach Fehlerprüfung setzt EiDisplayGroup_New() einen Zeiger groupPrivate auf die Privatdaten des Gruppenobjekts und initialisiert ihn. Die Prozedur kehrt dann zu ihrem Aufrufer EiDisplayGroup_New() zurück.
Die "Neu"-Prozedur in der Klasse EtGroupObject ist wie folgt:
Die obige Prozedur folgt dem selben Pl wie die "Neu"-Prozeduren für die Anzeigegruppenklasse und die geordneten Anzeigegruppenklasse, mit dem Unterschied, daß keine privaten Daten speziell für die Klasse EiGroup_New() vorhanden sind. Somit initialisiert die Prozedur EiGroup_New() nicht irgendwelche privaten Daten, und die Datengröße, die sie zur "Neu"-Prozedur der Stammklasse EiShapeObject übergibt, ist dieselbe wie die Datengröße, die von der "Neu"-Prozedur der Anzeigegruppenklasse an EiGroup_New() übergeben wird.
Die Prozeduren fahren fort bis zur "Neu"-Prozedur der EtObject Klasse. Man erkennt, daß Escher denselben rekursiven Mechanismus zur Erschaffung von Objekten in jeder Klasse der Klassenhierarchie verwendet. Darüber hinaus erkennt man, daß Escher ähnliche rekursive Techniken verwendet, um die Funktionen einer großen Anzahl von Escher-API Aufrufen auszuführen.
2. ErGroup_AddObject()
Nochmals Bezug nehmend auf das beispielhafte Anwendungsprogramm in Anhang A, nach der Erschaffung eines neu geordneten Anzeigegruppenobjekts group erzeugt das Programm ein rückwärtsweisendes Stilobjekt und fügt es der Gruppe hinzu. Dieser Teil des Beispielsprogramms ist nicht wichtig für das Verständnis der Erfindung, ist vielmehr lediglich zur Verdeutlichung eingeschlossen, daß ein solches Objekt einer Gruppe hinzugefügt werden kann.
Als nächstes erzeugt das Beispielprogramm ein Polygonobjekt polygon unter Verwendung der Escherprozedur ErPolygon_New(). Diese Prozedur läuft ähnlich den "Neu"-Prozeduren ab, die oben unter Bezugnahme auf die Erzeugung eines geordneten Anzeigenobjekts erläutert worden sind, und braucht nicht nochmals beschrieben zu werden. Das Beispielsprogramm fügt dann polygon zu group hinzu unter Verwendung des Escher-API-AufrufS ErGroup_Addobject(). Letztere Prozedur ist wie folgt:
Wie man sehen kann, empfängt diese Prozedur als Argumente das der Gruppe hinzufügende Objekt und die Gruppe, dem dieses hinzuzufügen ist. Nach einigen Buchhaltungsoperationen ruft die Prozedur EiGroup_AcceptObject() auf, eine Escher-Prozedur zur Ermittlung, ob das angegebene Objekt von einer Art ist, die zu der angegebenen Art Gruppenobjekt hinzugefügt werden kann. Wenn beispielsweise das angegebene Objekt ein Lichtobjekt ist, kann es nicht zu einer geordneten Anzeigegruppe hinzugefügt werden. Im vorliegenden Fall ist das Ergebnis gültig, da ein Polygon zu einem Objekt EtOrderDisplayGroup Zugefügt werden kann.
Prozedur enthält dann einen Zeiger groupClass auf die EtGroupObject Klassenverfahrenstabelle für das spezielle geordnete Anzeigengruppenobjekt durch Aufruf der Prozedur "erhalte Unterklassenverfahren" der Stammklasse EtShapeObject von EtGroupObject. Die Prozedur ruft dann die Prozedur "Addiererobjekt" auf, auf die in dieser Verfahrenstabelle gezeigt wird, und kehrt dann zum Anwendungsprogramm zurück.
Der Zeiger in der Verfahrenstabelle auf die Prozedur "Addierobjekt" für die spezielle Gruppenobjekt wurde dort während der Initialisierung eingeschrieben, als die Klasse EtOrderedGroup sich selbst registrierte. Die angegebene Prozedur "Addierobjekt" ist wie folgt:
Bezugnehmend auf diese Prozedur kann man sehen, daß sie zunächst die "erhalte" Prozedur der geordneten Anzeigengruppenklasse verwendet, um einen Zeiger groupData auf die Privatdaten des spezifizierten geordneten Anzeigegruppenobjekts zu erhalten. Die Prozedur erhält dann die Art des zu addierenden spezifizierten Objekts (das ein Geometrieobjekt ist), und nach einer gewissen Fehlerprüfung ruft sie EiOrdererdDisplayGroup_GetObjectList() auf, um einen Zeiger theList auf die spezielle doppeltverbundene Liste des geordneten Anzeigegruppenobjekts für Geometrieobjekte zu erhalten. Die Prozedur ruft EiGroupPosition_New() auf, um eine neue Liste "Position"-Objekt zu schaffen, und ruft EiDLList_InsertNodeLast() auf, um das neue "Position"-Objekt am Ende der doppeltverbundenen List einzufügen. Die Prozedur kehrt dann zu ihrem Aufrufer EiGroup_AddObject() zurück.
Zur Vervollständigung sei angemerkt, daß die Prozedur zum Hinzufügen eines Objekts zu einem Listenanzeigegruppenobjekt sehr ähnlich jener zum Hinzufügen eines Objekts zu einem geordneten Anzeigegruppenobjekt ist mit der Ausnahme, daß nur eine doppeltverbundene List in einem Listenanzeigegruppenobjekt vorhanden ist. Es ist daher unnötig, eine von sechs Listen zu bestimmen, zu der das Objekt zuzufügen ist. Es sei auch angemerkt, das zusätzlich zu einer Objekthinzufügungsprozedur Escher's API auch Prozeduren enthält zur Hinzufügung eines Objekts hinter einer angegebenen Position in der Liste der Gruppe, zur Hinzufügung eines Objekts vor einer angegebenen Position in einer Liste der Gruppe, zur Entfernung eines Objekts von einer angegebenen Position in einer Liste der Gruppe zum Vorwärts- und Rückwärtsschreiten durch eine Liste der Gruppe, sowie andere Prozeduren.
3. ErObject_Dispose()
Nach dem Hinzufügen eines Objekts zur Gruppe legt das Beispielprogramm in Anhang A das Polygonobjekt weg, weil es im Anwendungsprogramm nicht mehr benötigt wird (abgesehen von seiner Anwesenheit im gerade geschaffenen Modell). Soweit das Anwendungsprogramm betroffen ist, das Polygonobjekt entfernt worden. In Wirklichkeit löscht die Escherprozedur ErObject_Dispose() zu diesem Zeitpunkt das Polygonobjekt aber nicht und löscht nicht die Zuordnung zum Speicherplatz. Da polygon ein geteiltes Objekt ist, vermindert statt dessen Escher lediglich die Bezugszählung in den geteilt Objekt Pri vatdaten für das Polygonobjekt. Die Bezugszählung war auf 1 gesetzt, als polygon erschaffen wurde, und wurde um 1 erhöht, als zu group hinzugefügt wurde. Der Aufruf von ErObject_Dispose() durch das Anwendungsprogramm vermindert lediglich die Bezugszählung von 2 auf 1. Wenn die Abwärtszählung die Bezugszählung auf 0 vermindert, löscht Escher wirklich das Objekt und löscht auch die Zuordnung des Speicherplatzes.
4. Neues Linienobjekt
Das Beispielprogramm in Anlage A erzeugt als nächstes ein neues Linienobjekt line, fügt es zu dem geordneten Anzeigegruppenobjekt group hinzu und "verfügt" dann über das Leitungsobjekt line. Die Escherprozeduraufrufe zur Ausführung derselben sind ähnlich jenen, die oben unter Bezugnahme auf das Polygonobjekt polygon beschrieben wurden und brauchen nicht nochmals wiederholt zu werden.
5. Hinzufügung eines Transformationsobjekts
Nach Aufnahme eines Stilobjektes und zweier Geometrieobjekte in die geordnete Anzeigegruppe group erzeugt das Beispielprogramm in Anlage A ein Übersetzungstransformationsobjekt und fügt es der Gruppe hinzu. Das Transformationsobjekt transform wird durch Aufruf der Escherprozedur ErTranslateTransform_New() erzeugt, das in einer rekursiven Art ähnlich ErOrderedDisplayGroup_New() arbeitet, wie oben beschrieben. Die nachfolgenden Aufrufe des Beispielprogramms von ErGroupAddobject (group, transform) arbeiten wie oben beschrieben. Es sei angemerkt, daß obwohl das Beispielprogramm das Transformationsobjekt zu dem geordneten Anzeigegruppenobjekt hinzufügt, nachdem bereits zwei Geometrieobjekte hinzugefügt worden sind, die Natur einer geordneten Anzeigegruppe auszuführende Transformationsobjekte vor Geometrieobjekten aufruft. Escher stellt diese Charakteristik durch Anordnen des Transformationsobjekts in einer getrennten doppeltverbundenen Liste innerhalb des geordneten Anzeigegruppenobjekts group ausschließlich für Transformationen dar und durch Anordnen der Geometrieobjekte in einer doppeltverbundenen Liste exklusiv für Geometrieobjekte. Beim Aufbereiten durchquert, wie oben beschrieben Escher die Transformationsobjektliste, bevor es die Geometrieobjektliste durchquert.
6. Erzeugung und Hinzufügung von subGroup
Nach dem Hinzufügen des Transformationsobjekts zum geordneten Anzeigengruppenobjekt group erzeugt das Beispielprogramm in Anhang A eine neue geordnete Anzeigegruppe subGroup durch Aufruf von ErOrderedDisplayGroup_New(). Diese Prozedur ist oben beschrieben. Das Beispielprogramm fügt dann subGroup zu dem zuvor erzeugten Anzeigeobjekt group hinzu unter Verwendung der Escherprozedur ErGroup_AddObject(), was ebenfalls oben beschrieben ist. Das Beispielprogramm hat auf diese Weise nun die in 8 dargestellte Hierarchie erzeugt. Das Beispielprogramm erzeugt dann ein neues Geometrieobjekt, speziell ein Torusgeometrieobjekt Torus unter Verwendung einer Escherprozedur ErTorus_New(), die ähnlich wie das oben beschriebene ErPolygon_New() arbeitet. Es fügt dann Torus zu subGroup unter Verwendung von ErGroup_AddObject() hinzu Und legt sowohl Torus als subGroup unter Verwendung von ErObject_Dispose() weg. An diesem Punkt ist das gesamte, in 8 dargestellte Modell aufgebaut worden und das Beispielprogramm bewegt sich zum Schritt 308 (3), um das Modell zur Ansicht aufzubereiten.
IV Aufbereitung des Modells zu den Ansichten
Escher findet die Aufbereitung von Objekten zu einer Ansicht zwischen Aufrufen an ErView-StartRendering() und ErView_EndRendering() statt. Diese Prozeduren initialisieren lediglich relevante Datenstrukturen vor dem Aufbereiten (einschließlich dem Ablegen eines Anfangszustandes auf einen Durchquerungsstapel) und Reinigen verschiedener Buchhaltungsinformationen nach dem Aufbereiten. Sie enthalten auch Aufrufe an des Aufbereiters eigene Start- und Endprozeduren, so daß der Aufbereiter dasselbe tun kann. Die Start- und Endprozeduren des Aufbereiters wurden für Escher bei der Registrierung des Aufbereiters spezifiziert und sind in geeigneten Verfahrenstabellen identifiziert. Insbesondere wurde die Endaufbereitungsprozedur des Aufbereiters durch den Metahändler des Aufbereiters in Abhängigkeit von einem Aufruf mit der konstanten EcMethodType_EndRenderer rückgeführt.
Escher unterstützt Mehrfachaufbereitung, bei dem Escher das Modell mehr als einmal durchquert, wobei jedesmal geeignete Aufbereiterprozeduren aufgerufen werden. Escher zeigt an, daß eine erneute Durchquerung erforderlich ist, indem ein Statuskennzeichen EcViewStatus_ReTraverse von der Prozedur ErView_EndRendering() zurückgesetzt wird. Wenn das Anwendungsprogramm ErView_EndRendering() aufruft, dann ruft diese Prozedur wiederum die Endaufbereitungsprozedur des Aufbereiters auf. Im Falle des Drahtmodellaufbereiters ist diese Prozedur ErWF-End() genannt. Der Aufbereiter ist das Wiederdurchquerungskennzeichen auf die Escherprozedur ErView_EndRendering(), die wiederum selbiges auf das Anwendungsprogramm als EcViewStatus_ReTraverse rückführt. Die bevorzugte Technik für das Ausführungsprogramm ist es daher, die Modellzeichnungsaufrufe in eine Ausführschleife zu setzen, die so oft wiederholt wird, wie ErView.EndRendering() das EcViewStatus-ReTranvers rückführt. Dieses ist das Format, das in dem Beispielprogramm in Anhang A verwendet wird.
Es sei angemerkt, daß die Anrufe an ErView.StartRendering() und ErView_EndRendering() ein Sichtobjekt View als ein Argument verwenden. Ein Anwendungsprogramm kann diese Prozedur in jeder Folge aufrufen, wobei unterschiedliche Ansichtsobjekte spezifiziert werden, so lange der Aufruf an ErView_EndRendering() für ein bestimmtes Ansichtsobjekt dem Aufruf an ErView_StartRendering() für dasselbe Ansichtsobjekt folgt und alle Zeichnungsaufrufe an diese Ansicht dazwischenliegen. Es ist auch ein Fehler, ErView_StartRendering() zweimal für ein spezielles Ansichtsobjekt aufzurufen, ohne ErView_EndRendering() für dasselbe Ansichtsobjekt dazwischen aufzuurfen und es ist ein Fehler, ErView_EndRendering() für ein bestimmtes Ansichtsobjekt aufzurufen, ohne zunächst ErView_StartRendering() für dieses Ansichtsobjekt aufgerufen zu haben. Verschiedene Ansichtsobjekte können jedoch denselben Aufbereiter spezifizieren, wenn gewünscht, da die Beispielsdaten für die unterschiedlichsten Ansichtsobjekte getrennt sind. Das beispielhafte Anwendungsprogramm in Anhang macht nur einen sehr einfachen Schlag bei zweimaligen Aufbereiten des Modells, insbesondere durch vollständiges Aufbereiten des Models unter Verwendung des zuvor definierten Sichtobjekts, das den Drahtmodellaufbereiter spezifiziert, dann die Wahl des Aufbereiters im Sichtobjekt ändert, um auf einen Z-Puffer-Aufbereiter zu zeigen, und das Modell noch einmal zu dem selben, nun geänderten Sichtobjekt aufzubereiten.
Zwischen Aufrufen an ErView_StartRendering() und ErView_EndRendering() kann ein Anwendumgsprogramm Aufrufe an entweder Echtzeit-Escher-Zeichnungsprozeduren oder Escher-Zeichnungsprozeduren für Aufrechterhaltungsbetrieb, oder beide, richten. Die Echtzeitroutinen nehmen Datenstrukturen (wie beispielsweise eine Polygondatenstruktur) als Parameter, während Aufrechterhaltungsbetriebsroutinen Objekte (beispielsweise ein EtGeometryObject) als Parameter nehmen. Echtzeitroutinen schleppen keine Durchquerung irgendeines Modells mit, während manche Aufrechterhaltungsbetriebsroutinen, wie beispielsweise ErDisplayGroup_Draw() eine Durchquerung eines Modells aufweisen.
A. Durchquerung eines Modells
Dementsprechend macht das beispielhafte Anwendungsprogramm in Anhang A einen einfachen Aufruf an die Aufbereiteraufrufprozeduren 212 von Escher (2), insbesonderen einen Aufruf an ErDisplayGroup_Draw(). Das Anwendungsprogramm nimmt das Modell zur Aufbereitung auf (dargestellt durch das geordnete Anzeigegruppenobjekt group, das den Wurzelknoten der Modellhierarchie bildet), und die Ansicht, in die das Modell aufzubereiten ist (durch Aufnehmen des Sichtobjekts). Das Anwendungsprogramm könnte zu diesem Zeitpunkt auch zusätzliche Aufrufe an Aufbereiteraufrufprozeduren 212 von Escher richten, um zusätzliche Objekte (einschließlich zusätzlicher Modelle) in der selben Ansicht aufzubereiten. Die Prozedur ErDisplayGroup_Draw() ist wie folgt:
Bezugnehmend auf die obige Prozedur, nach einer gewissen Fehlerprüfung ermittelt die Prozedur zunächst, daß group eine geordnete Anzeigegruppe ist, indem group an die Escherprozedur EiDisplayGroup_GetTypeIndex() überwiesen wird. Man erhält dann einen Zeiger func auf das Zeichnungsverfahren, was die geordnete Anzeigengruppenklasse ist, die während der Initialisierung mit dem Klassenverfahrenstabellenenddisplay group für geordnete Anzeigegruppenobjekte registriert wurde. Wenn das "in-line"-Kennzeichen für das Objekt group gesetzt ist, dann ruft das Programm die Prozedur auf, die durch func bezeichnet ist, nimmt group auf und das Sichtobjekt, zu dem die Gruppe aufzubereiten ist.
Wenn das "in-line"-Kennzeichen für das Objekt group nicht gesetzt ist, dann "legt" die Prozedur EiDisplayGroup_Draw() den Durchquerungszustand, bevor die Prozedur aufgerufen wird, die durch func identifiziert wird, und "hebt" den Überquerungszustand danach "ab".
In einer Ausführungsform ist der Zustand der Durchquerung als die augenblickliche Position in einem Stapel dargestellt, auf den aufgelegt oder von dem abgenommen werden kann und der an jedem Niveau eine Verkettung aller Transformationsmatrizen vor diesem Niveau der laufenden Stilcharakteristika, der laufenden Abschaltercharakteristika und der laufenden Attributsätze enthält. Jedesmal, wenn der Durchquerungszustand "abgelegt" wird, wird ein neues Niveau geschaffen, und alles dieser Information wird von dem früheren Niveau auf das laufende Niveau des Stapels kopiert. Darüber hinaus findet bei dieser Ausführungsform die Verkettung der Transformationsmatrizen durch wirkliche Ausführung jeder Matrix-Vormultiplikaltion statt, wenn das Transformationsobjekt bei der Durchquerung angetroffen wird.
In einer bevorzugten Ausführungsform werden jedoch die laufende Transformation, die laufenden Stilcharakteristika, die laufenden Attributsätze und die laufenden Schattierungscharakteristika in mehreren Stapeln gespeichert, wobei auf jeden von ihnen "abgelegt", nur wenn es notwendig ist. Ein Haupt "Zustands"-Stapel unterhält eine Aufzeichnung an jedem Niveau, von dem von den zusammengesetzten Stapeln abgehoben werden soll, wenn der Gesamtdurchquerungszustand von diesem Niveau abgehoben wird. Beispielsweise ist der laufende Transformationszustand unter Verwendung mehrerer Komponentenstapel repräsentiert, wie beispielsweise einem laufenden "Ort-zu-Welt"-Matrixstapel, ein inverser Matrixstapel, usw.. Statt einer Berechnung dieser Matrizen bei jedem Ablegen des Gesamtdurchquerungszustands wird nur die Folge von Transformationsmatrizen der letztberechneten Matrix zur laufenden Position in der Durchquerung des Modells aufgezeichnet. Die aktuelle Berechnung wird nicht ausgeführt, wenn nicht und bis nicht solches wirklich benötigt wird. Auf diese Weise wird eine große Anzahl Matrixberechnungen vermieden.
Es sollte angemerkt werden, daß im Aufrechterhaltungsbetrieb Escher ablegt und abhebt, wie erforderlich, während der Durchquerung des Modells. Im Echtzeitbetrieb kann das Anwendungsprogramm auch Escherablege- und -abhebroutinen aufrufen, so daß durch sorgfältige Vollbesteuerung der Aufrufe das Anwendungsprogramm seine eigene Durchquerung seiner eigenen Modelldatenbank ausführen kann.
Rückkehrend ZU EiDisplayGroup_Draw(), die Prozedur, die durch func angezeigt wird, ist EiView_OrdererdDisplayGroup(), die wie folgt ist:
Wie man sehen kann, ruft die obige Prozedur eine generalisierte Anzeigegruppenlistenzeichnungsfunktion EiDisplayGroupList_Draw() sechsmal auf, wobei jedesmal ein Bezug zu einer anderen der sechs doppeltverbundenen Listen in den Privatdaten des geordneten Anzeigegruppenobjekts group eingeführt wird. Insbesondere ruft die Prozedur die Listenzeichnungsprozedur mit einem Bezug zunächst zur Liste der Transformationen dann mit Bezug zur Liste der Stile und dann mit Bezug zur Liste der Attributsätze, dann mit Bezug zur Liste der Schattierer, dann mit Bezug zur Liste von Geometrien in der Gruppe und dann mit einem Zeiger zur Liste von Untergruppen in der Gruppe auf. Jedesmal führt die Prozedur zur Listenzeichnungsprozedur auch einen Bezug zur speziellen Prozedur ein, die die Art der Objekte, die auf der Liste sind, zeichnet. Wenn beispielsweise die Liste von Transformationen auf EiDisplayGroupList_Draw() übergeht, dann wird auch ein Bezug zur Escherprozedur EiTransform_Draw() übergeben. Als weiteres Beispiel, wenn die Liste von Geometrien an EiDisplayGroupList_Draw() übergeht, dann findet auch eine Übergabe an die Escherprozedur EiGeometry_Draw() Statt.
Man erkennt, daß wenn group ein Listenanzeigegruppenobjekt anstelle eines geordneten Anzeigegruppenobjekts wäre, nur ein Aufruf an EiDisplayGroupList_Draw() gemacht würde. Dieser Aufruf würde einen Bezug zu einzigen Liste von Objekten eingeben, die an group anhängen, und einen Bezug auf eine Prozedur, die sowohl den Typ jedes Objekts, wie auf der Liste angetroffen wird, bestimmt, und würde die geeignete Escherzeichnungsprozedur für diesen Typ aufrufen.
Die generalisierte Listenzeichnungsprozedur ist wie folgt:
Wie man sehen kann, kreist diese Prozedur lediglich durch alle Objekte auf der doppeltverbundenen Liste, die durch den Aufrufer spezifiziert oder, und überführt für jedes dieser Objekte das Objekt zur Zeichnungsprozedur, die durch den Aufrufer angegeben wird.
Einige der Escher-Objektzeichnungsprozeduren, die durch die Listenzeichnungsprozedur aufgerufen werden, werden nun beschrieben. Zur Vereinfachung der Beschreibung werden sie jedoch in einer anderen Reihenfolge gegenüber jener erläutert, in der sie aufgerufen werden, wenn eine geordnete Anzeigegruppe aufbereitet wird.
B. Zeichnen von Untergruppenobjekten eines Anzeigengruppenobjekts
Escher durchquert das Modell in rekursiver Weise, und aus diesem Grunde ist die Escherprozedur, die ErView-OrderedDisplayGroup() an die Listenzeichnungsprozedur für Gruppenobjekte übergibt, die in dem Gruppenobjekt group angetroffen werden, ganz einfach EiDisplayGroup_Draw(). Diese Prozedur ist oben erläutert.
C. Zeichnen von Geometrieobjekten in einem Anzeigengruppenobjekt
Die Escherprozedur die ErView-OrderedDisplayGroup() für die Listenzeichnungsroutine für Geometrieobjekte identifiziert, ist EiGeometry_Draw(), die wie folgt ist:
Wie man sehen kann, führt die obige Prozedur lediglich gewisse Fehlerprüfungen aus und ruft dann das Geometriezeichnungsverfahren auf, das durch die Geometrieklasse registriert war. Dieses Verfahren ist allgemein für alle Geometrieobjekte, und ist wie folgt:
Diese Routine erhält nach Fehlerprüfung zunächst einen Zeiger func auf das Verfahren, das der Aufbereiter der laufenden Ansicht vier Geometrieobjekte der aufzubereitenden Art registriert hat (in diesem Falle Polygone). Wenn func gleich NULL ist, dann findet eine Zerlegung des Geometrieobjektes in einer hier beschriebenen Weise statt. Im vorliegenden Falle hat jedoch der Drahtmodellaufbereiter ErWF_Geometry_Polygon() als die Prozedur zur Aufbereitung von Polygonobjekten registriert. (Siehe die obige Diskussion unter Bezugnahme auf ErWF_Register(). Diese Prozedur ist in Anhang B angegeben.
D. Zeichnen von Geometrieobjekten, die eine Zerlegung erfordern.
Im vorangehenden Abschnitt wurde beschrieben, wie Escher ein Geometriebojekt in einer aufzubereitenden Anzeigegruppe zu verarbeiten ist, in der Situation, wo der Aufbereiter der Ansicht eine Routine speziell für den Typ des Geometrieobjekts (d.h. Polygon) hat. Mit Escher zu verwendende Aufbereiter müssen wenigstens Routine unterstützen, die Punkte, Linien und Dreiecke aufbereiten und auch Routinen unterstützen können, die Geometrien höherer Niveaus aufbereiten. In einem Aspekt der Erfindung muß der Aufbereiter nicht alle Geometrietypen unterstützen, die Escher beim Aufbau eines Modells unterstützt. Vielmehr ermittelt Escher automatisch die Abwesenheit eines Aufbereitungsverfahrens für eine spezielle Geometrietype und zerlegt die Geometrie in weniger komplexe Teile. Sie führt diese dann erneut dem Aufbereiter in dieser weniger komplexen Form zu.
Der Drahtmodellaufbereiter der vorliegenden Erfindung unterstützt Polygonobjekte, jedoch für Zwecke der Erläuterung sei nun angenommen, daß er es nicht tut. Diese Darstellung ist hypothetisch auch weil das Drahtmodellaufbereitungsverfahren zum Aufbereiten von Dreiecken, was wie man sehen wird, die Geometrie ist, in das Escherpolygone zerlegt, dieselbe Drahtmodelllaufbereiterprozedur ist, die Polygone aufbereitet. Das heißt, die Aufbereiterprozedur ErWF_Geomery_Polygon() nimmt entweder ein Dreieck oder ein Polygon als ein Argument, bestimmt, was es ist, und bereitet es unter Verwendung desselben Codes auf. Dennoch dient die Hypothese der Erläuterung der Zerlegungstechnik von Escher.
1. Bei der Escher Initialisierung aufgerufene Prozeduren
Die Prozedur bei der Initialisierung zur Registrierung eines Aufbereiters ist zuvor beschrieben worden. Klassen und Unterklassen registrieren sich selbst ebenfalls während der Initialisierung. Die Polygonklasse beispielsweise am Anfang durch Aufruf der folgenden Funktion registriert:
Diese Routine erzeugt die Klassenverfahrenstabelle für ein Objekt in der Blattklasse polygon. Wie bei anderen Erzeugungsroutinen, die zuvor beschrieben wurden, wird der Block des Speichers zugeordnet und unter Verwendung Lagentechnik initialisiert, wobei die Klassenregistrierungsprozedur jeder Klasse zunächst die Größe, die für ihre eigenen Verfahrenstabellen erforderlich ist, der Klassenregistrierungsprozedur ihrer Stammklasse eingibt. Die Klasse polygon ist eine Blattklasse, so daß die Größe ihrer Verfahrenstabelle null ist. Oberhalb der Klasse polygon addiert jede Prozedur. Die Größe ihrer eigenen Verfahrenstabelle und ruft rekursiv die Klassenregistrierungsprozedur ihrer Stammklasse auf. Die letzte Registrierungsprozedur der Stammklasse weist Speicher für den gesamten Block von Verfahrenstabellen zu, initialisiert den eigenen Teil mit Zeigern auf ihre Fehlerverfahren und kehrt zum Aufruf der Klassenregistrierungsprozedur der Unterklasse zurück.
Auf dem Weg zurück zum ursprünglichen Aufrufer initialisiert die Klassenregistrierungsprozedur jeder Klasse ihre eigenen Verfahrenstabelle mit ihren eigenen Fehlerverfahren. Außerdem kann die Klassenregistrierungsprozedur jeder Klasse Verfahren zum Unwirksammachen ihrer Stammklasse spezifizieren, jedoch nur bei Option der Stammklasse. Dieses wird bewerkstelligt, wenn die Klassenregistrierungsprozedur der Stammklasse aufgerufen wird, ein Metahändler und für einige Klassen ein virtueller Metahändler spezifiziert werden als Argumente für den Aufruf. Diese Metahändler können durch die Klassenregistrierungsprozedur der Stammklasse aufgerufen werden, wenn es gewünscht wird, wobei ein Verfahrenstyp spezifiziert wird, und, wenn aufgerufen, der Me tahändler einen Zeiger der Prozedur rückführt, die gewünscht wird, um das Fehlerverfahren des spezifizierten Typs der Stammklasse unwirksam zu machen. Wenn eine Klasse keine Prozedur zum Unwirksammachen des Fehlerverfahrens des speziellen Typs der Stammklasse aufweist, kehrt der Metahändler auf NULL zurück.
Im Falle der Polygonklassenregistrierungsprozedur wird nur ein Metahändler zur Klassenregistrierungsprozedur der Stammklasse identifiziert. Der Metahändler ist wie folgt:
Von spezieller Relevanz für die vorliegende Diskussion sei angemerkt, daß wenn nach einer Geometriezerlegungsprozedur gefragt wird, der Metahändler eine zurückführt, nämlich EiPolygon_Decompose. Diese Prozedur wird nachfolgend beschrieben.
Die Klassenregistrierungsprozedur für die Stammklasse der Polygonklasse, EtGeometryObject, ist wie folgt:
Wie man sehen kann, ruft diese Prozedur die Klassenregistrierungsprozedur ihrer eigenen Stammklasse EiShapeClass_Register() auf, spezifiziert einen Metahändler und einen virtuellen Metahändler. Nachdem die Rekursion zur obigen Prozedur zurückkehrt, fährt das Verfahren fort durch Initialisierung seiner eigenen Verfahrenstabelle mit Zeigern auf Fehlerprozeduren. Es erhält diese Zeiger unter Verwendung einer Escherprozedur EiObjectClassData_GetMethod(), die unter anderem Metahändler der Unterklasse auffordert, den Zeiger für jedes gewünschte Verfahren anzugeben. Eines der Verfahren, das die Prozedur aufzufordern, vom Metahändler der Polygonklasse verlangt, ist ein Zerlegungsverfahren, und, wie zuvor hervorgehoben, das Verfahren, das es identifiziert, ist EiPolygon_Decompose().
Es verdient hervorgehoben zu werden, daß bei Escher das Zerlegungsverfahren in den Klassenverfahrenstabellen für jeden Geometrietyp identifiziert ist, nicht für jeden Aufbereiter. Die Zerlegungsverfahren sind daher als Teil des aufzubereitenden Modells eingeschlossen, nicht als Teil der Ansicht, zu der es aufbereitet wird oder als Teil des Aufbereiters. Man erkennt, daß bei einer anderen Ausführungsform es einem Aufbereiter erlaubt sein kann, die Zerlegungsverfahren für Geometrie, die er nicht direkt zeichnen kann, unwirksam zu machen. In noch einer weiteren Ausführungsform können die Zerlegungsverfahren der Aufbereiterunterklasse anstelle der Geometrieunterklasse hinzugefügt sein.
Eine Beschreibung des Metahändlers der Geometrieklasse ist nicht bedeutsam für das Verständnis der Erfindung, jedoch wird der virtuelle Metahändler der Geometrieklasse nachfolgend beschrieben:
Von spezieller Relevanz ist, daß wenn durch die Klassenregistrierprozedur der Klasse EtShapeObject aufgerufen, er einen Zeiger auf EiGeometry_Draw() rückführt als eine Objektzeichnungsprozedur.
2. Prozeduren, die während der Aufbereitung aufgerufen werden
Es wird noch einmal auf EiGeometry_DrawMethod() Bezug genommen, das oben beschrieben wurde. Wenn der Aufbereiter keine Prozedur für die Zeichnung von Geometrien derart registriert hat, die jener Prozedur angeboten werden, für die zum Zwecke der Illustration angenommen wird, daß dieses in bezug auf Polygone der Fall ist, dann übergibt diese Routine, wie zuvor erwähnt, die Geometrie an EiGeometry_Decompose(). Diese Prozedur ist wie folgt:
Wie man sehen kann, übergibt nach gewisser Fehlerprüfung diese Prozedur das Geometrieobjekt lediglich an das Verfahren, das durch seine Verfahrenstabelle identifiziert ist, für eine Zerlegungsprozedur. Für Polygone wurde dieses Verfahren zuvor registriert, wie oben beschrieben, als EiPolygon_Decompose, was wie folgt aufgebaut ist:
Die obige Prozedur verwendet eine Escher Prozedur EiPolygon_Triangulate() zur Zerlegung des Polygons in ein Bündel von Dreiecken. In einer Ausführungsform könnte die Triangulationsprozedur ein neues EtGroupObject erzeugen, um für alle neuen Dreiecke zu gelten. Um jedoch ein Niveau der Fehlerprüfung und Rekursion kurzzuschließen, weil es bereits bekannt ist, daß alle Objekte innerhalb der Gruppe Geometrieobjekte sind, setzt die Triangulationsprozedur jedoch vorzugsweise alle neuen Dreiecke in ein Objekt der Klasse EtGeometryBundle. Ein Geometriebündel ist ein lediglich internes Geometrieobjekt, das nur eine Liste von Geometrien enthalten kann.
Die obige Prozedur kann entweder im Echtzeitbetrieb oder im Aufrechterhaltungsbetrieb arbeiten. Im Echtzeitbetrieb ruft sie die Triangulationsprozedur mit einem Kennzeichen auf, das die Triangulationsprozedur anweist, das Ergebnis der Zerlegung nicht aufzubewahren, sondern vielmehr es einfach zu zeichnen. In der Aufrechterhaltungsbetriebsart ruft die obige Prozedur die Triangulationsprozedur mit einem Kennzeichen auf, das anzeigt, daß die Zerlegung aufbewahrt werden soll, sowie mit Bezug auf ein Feld, in welchem es aufzubewahren ist. In der obigen Prozedur ist das Feld, in der die Triangulationsprozedur einen Bezug auf das resultierende Geometriebündelobjekt einschreibt, polyPriv->decomposition, das die obige Prozedur dann an EiGeometry_Draw() übergibt.
EiGeometry_Draw() ist oben erklärt worden, und in der zuvor beschriebenen Weise ruft sie nach Fehlerprüfung lediglich das Verfahren auf, das in der Verfahrenstabelle des Geometrieobjektes, das ihm zugeleitet ist, identifiziert ist, um jenen Geometrietyp zu zeichnen. Gewöhnlich sind diese Verfahren, die durch den Aufbereiter registriert sind, jedoch sind Geometriebündelobjekte nicht öffentlich. Aufbereiter registrieren keine Routinen zum Zeichnen dieser Objekte. Statt dessen enthält die Verfahrenstabelle einen Zeiger auf Eschers Fehlerzeichnungsverfahren für Geometriebündel wie folgt:
Wie man sehen kann, schreitet diese Prozedur lediglich durch die Liste der Geometrieobjekte im Geometriebündelobjekt, die ihm zugeführt ist und übergibt jedes von ihnen wiederum an EiGeometry_Draw(). Dieses sind sämtlich Dreiecke, so daß EiGeometry_Draw() die Dreieckzeichnungsprozedur des Aufbereiters für jedes Dreieck in der Zerlegung aufruft.
E. Zeichnen von Transformationsobjekten in einem Anzeigegruppenobjekt
Die Escher Prozedur, die EiView_OrderedDisplayGroup() für die Listenzeichnungsroutine für Transformationsobjekte identifiziert, ist EiTransform_Draw() wie folgt:
Wie man sehen kann, ruft die obige Prozedur lediglich das Transformationszeichnungsverfahren für die Klasse EtTransformObject auf. Dieses Verfahren ist allen Transformationsobjekten gemeinsam und ist wie folgt:
Diese Routine erhält nach Fehlerprüfung als erstes einen Zeige func auf das Verfahren, das die Verfahrenstabelle des Aufbereiters der laufenden Ansicht zur Ausführung von Transformationsobjekten der auszuführenden Type (in diesem Falle Übersetzungen) hat. Eschers Fehlerprozedur zur Ausführung von Übersetzungstransformationen ist wie folgt:
V. Verwaltung und Verwendung von Qualitätssammlungen
A. Datenstrukturen
Ein Qualitätssammlungsobjekt ist eine Datenstruktur, die eine verbundene Liste von Qualitätsgruppenobjekten enthält. Ein Qualitätssammlungsobjekt ist ein Beispiel der Klasse EtQualityCollectionObject das, wie in 6 angegeben, eine Unterklasse der Klasse EtSharedObject ist, die wiederum eine Unterklasse unter der Klasse EtObject ist. Dementsprechend hat folgend dem Format von 5 ein Qualitätssammlungsobjekt das Format im Speicher, das in 11 dargestellt ist. Insbesondere ein Bereich des Speichers 1102 ist vorgesehen, Zeiger auf die Verfahren der Klasse EtQualityCollectionObject zu enthalten, und dieser Bereich 1102 enthält Zeiger 1104 auf Objektverfahren und Zeiger 1106 auf Geteiltobjektverfahren (von denen keine vorhanden sind). Die EtQualityCollectionObject ist eine Blattklasse, so daß die Klasse eine Verfahrenstabelle speziell für die Qualitätssammlungsobjektverfahren ausläßt. Dies Struktur enthält auch Beispielsdaten für das Qualitätssammlungsobjekt im Speicherbereich 1110. Dieser Bereich enthält Beispielsdaten, die für die Objektklasse spezifisch sind, in einem Teil 1112 (auf die Objektklasse 1102 zeigend), Beispielsdaten, die für die Teilobjektklasse spezifisch sind, in einem Teil 1114 (enthaltend eine Referenzzählung) und Beispielsdaten die für die Qualitätssammlungsobjektklasse spezifisch sind, in einem Teil 1116. Die Qualitätssammlungsobjektdaten sind eine Datenstruktur vom Typ EtQualityCollectionPrivate, die eine verbundene Liste von Qualitätsgruppenobjekten beginnt.
Ein Qualitätsgruppenobjekt ist eine Datenstruktur, die eine Gruppe von Qualitätssteuertypvariablen enthält, von denen jede einen Wert aufweist, der selbst unter zwei oder mehr Optionen in einem betreffenden Kompromiß zwischen Aufbereitungsqualität und Aufbereitungsgeschwindigkeit wählt. Jedes Qualitätsgruppenobjekt ist ein Beispiel der Klasse EtQualityGroupObjekt, wie in 6 gezeigt, eine Unterklasse der Klasse EtSharedObject ist. Ein Qualitätsgruppenobjekt hat das in 12 gezeigte Format. Insbesondere ein Bereich des Speichers 1202 enthält Zeiger auf Verfahren der Klasse EtQualityGroupObject, und dieser Bereich 1202 enthält Zeiger 1204 auf Objektverfahren und Zeiger 1206 auf Geteiltobjektverfahren (von denen keine vorhanden sind). Die Struktur enthält auch Bei spielsdaten für Qualitätsgruppenobjekt im Bereich 1210 des Speichers. Dieser Bereich enthält Beispielsdaten, die für die Objektklasse spezifisch sind, in einem Teil 1212 (auf die Objektklasse 1202 zeigend), Beispielsdaten, die für die Geteiltobjektklasse spezifisch sind, in einem Teil 1214 (eine Referenzzählung enthaltend), und Beispielsdaten, die für die Qualitätsgruppenobjektklasse spezifisch sind, in einem Teil 1216. Die Qualitätsgruppenobjektdaten sind eine Datenstruktur vom Typ EtQualityGroupObjectPrivate, die die in Tabelle I aufgeführten Felder enthält.
TABELLE I EtQualityGroupObjectPrivate
Wie man sehen kann, enthält abgesehen von den verbundenen Listenzeigern für andere Qualitätsgruppenobjekte in dem Qualitätssammelobjekt das Qualitätsgruppenobjekt ein Feld zum Speichern eines Qualitätsindexwertes, der der speziellen Gruppe zugeordnet ist. In einer Ausführungsform in der Qualitätsindex vom Typintervall und kann von 0,0 bis 1,0 reichen, aber bei anderen Ausführungsformen kann der Qualitätsindexwert beispielsweise eine ganze Zahl sein. Es sei angemerkt, daß in der vorliegend beschriebenen Ausführungsform der Qualitätsindexwert zwar in einem Feld in dem Qualitätsgruppenobjekt gespeichert ist, in einer anderen Ausführungsform der einer speziellen Qualitätsgruppe zugeordnete Qualitätsindex aber einfach ein berechneter Wert sein kann, wie beispielsweise n/N, wobei n die Position der speziellen Qualitätsgruppe in der verbundenen Liste der Sammlung und N die Gesamtzahl der Qualitäts gruppen in der Sammlung sind. In einer noch anderen Ausführungsform ist der Qualitätsindex, der einer speziellen Qualitätsgruppe zugeordnet ist, lediglich n, wobei die spezielle Qualitätsgruppe die n-Qualitätsgruppe in einer Sammlungsliste von Qualitätsgruppen ist. Viele andere Techniken können in verschiedenen Ausführungsformen verwendet werden, um einen Qualitätsindexwert einer entsprechender Qualitätsgruppe zuzuordnen.
Bezug nehmend noch einmal auf Tabelle I enthält jedes Qualitätsgruppenobjekt auch eine Liste von Qualitätstypeintragungen. Die Qualitätstypeintragungen sind ein Satz von Variablen, von denen jeder einen Wert enthält, der aus wenigstens zwei Optionen in einem jeweiligen Kompromiß zwischen Aufbereitungsqualität und Aufbereitungsgeschwindigkeit wählt. Für eine Ausführungsform gibt Tabelle II die verschiedenen Qualitätssteuervariablen und die verschiedenen Optionen an, die für diesen Parameter verfügbar sind.
TABELLE II QUALITÄTSTYPPARAMETER
Man erkennt, daß verschiedene Ausführungsformen einen anderen Satz Parameter in jeder Qualitätsgruppe enthalten kann und/oder unterschiedliche Optionen für jeden Parameter in der Tabelle aufweisen kann.
B. Prozeduren zur Einrichtung einer Qualitätssammlung
Bezug nehmend auf Anhang A., das beispielhafte Anwendungsprogramm richtet eine Qualitätssammlung ein, indem sie eine Prozedur ExSetupQualityCollection(&qualityCollection) aufruft. Diese Prozedur, die Teil des Anwendungsprogramm ist, verwendet von Escher angegebene Prozeduren zum Aufbau einer Sammlung von Qualitätsgruppen in einer gewünschten Weise. 13 ist ein Flußdiagramm einer Prozedur ExSetupQaualityCollection(), die eine Qualitätssammlung einrichtet, die vier Qualitätsgruppen hat, mit Qualitätsindizes 0,2, 0,4, 0,6 bzw. 0,8.
Bezug nehmend auf 13 schafft in einem Schritt 1302 die Routine zunächst ein neues Qualitätssammlungsobjekt. Dieses wird mit einem Aufruf an eine Escher Prozedur ErQualityCollectionObject_New() erzielt, die Platz zuweist und die Datenstrukturen in der gleichen Weise initialisiert, wie oben unter Bezugnahme auf 10 beschrieben ist. ErQualityCollectionObject_New() führt einen Zeiger zum neuen Qualitätssammlungsobjekt zurück, was die Prozedur von 13 in einer variablen qualityCollection speichert.
In einem Schritt 1304 erzeugt die Prozedur von 13 ein neues Qualitätsgruppenobjekt unter Verwendung einer Escher Routine ErQualityGroup_New(qualityIndex), wobei qualityIndex = 0,2. Diese Routine weist Speicherplatz für das neue Qualitätsgruppenobjekt unter Verwendung der Technik von 10 zu und initialisiert das Qualitätsindexfeld der Qualitätsgruppe auf 0,2.
In der vorliegend beschriebenen Ausführungsform setzt der Aufruf der Prozedur ErQualityGroupObject_New() den Qualitätsindex für die neue Gruppe permanent. Wenn das Gruppenobjekt später zu einer Qualitätssammlung hinzugefügt wird, setzt die Escher Prozedur, die dieses tut (unten beschrieben) die neue Gruppe in die verbundene Liste der Sammlung in die geeignete Folge, die durch den Qualitätsindex der Qualitätsgruppe bestimmt ist. Wenn der Qualitätsindex der hinzuzufügenden Gruppe den Qualitätsindex einer bereits in der Sammlung befindlichen Gruppe verdoppelt, wird ein Fehler rückgeführt.
In einer weiteren Ausführungsform nimmt ErQualityGroupObject_New() kein Argument, sondern initialisiert das Qualitätsindexfeld der neuen Gruppe auf einen Nullwert. Escher Routinen sind für das Anwendungsprogramm vorgesehen, um den Qualitätsindex der Gruppe nachfolgend zu setzen, wie gewünscht.
Zurückkehrend zur 13 setzt das Anwendungsprogramm nach Erschaffung der ersten neuen Qualitätsgruppe die Parameter in die erste Gruppe, wie im Schritt 1306 gewünscht. In der vorliegend beschriebenen Ausführungsform wird jeder der Qualitätstypenparameter, die in obiger Tabelle II aufgeführt sind, einem einzigen 4-Zeichen-Code vom Typ EtQualityType zugeordnet. Um zukünftige Verbesserungen zu ermöglichen, lesen und schreiben Anwendungsprogramme die Parameterwerte nicht direkt, sondern tun dies nur über gewisse Escher Routinen. Darüber hinaus können Anwendungsprogramme die Escher Routinen für die Ermittlung verwenden, welche Qualitätsparameter durch die spezielle Version von Escher unterstützt werden. Qualitätstypcodes sind bei Apple Computer, Inc. registriert, sind für Anwendungsprogrammentwickler verfügbar und für nachfolgende Weiterentwicklungen von Escher brauchbar.
Die Escher Routinen, die in Tabelle III angegeben sind, werden durch das Anwendungsprogramm verwendet, um den Inhalt einer Qualitätsgruppe zu verwalten.
TABELLE III QUALITÄTSGRUPPENAUFRECHTERHALTUNGSROUTINEN
Die Routine zur Erhaltung Qualitätsindex, der einer speziellen Qualitätsgruppe zugeordnet ist, wird als eine unabhängige Routine geliefert, weil der Qualitätsindexwert nicht einer der Qualitätstypen ist, die unter Verwendung von ErQualityGroup_GetTypeData() und Er QualityGroup_SetTypeData() verfügbar sind. In einer weiteren Ausführungsform kann der Indexwert, der einer speziellen Qualitätsgruppe zugeordnet ist, jedoch als einer der Qualitätstypen eingeschlossen sein, die unter Verwendung dieser Routinen zugänglich sind.
Im Schritt 1308 fügt die Prozedur von 13 das erste Qualitätssteuergruppenobjekt zum Qualitätssammelobjekt, das im Schritt 1302 erzeugt wurde, hinzu. Dieses wird unter Verwendung einer Escher Prozedur ErQualityCollection_AddGroup() erzielt, die eine von mehreren Qualitätssammelaufrechterhaltungsprozeduren ist, die in Tabelle IV beschrieben sind.
TABELLE IV QAUALITÄTSSAMMELAUFRECHTERHALTUNGSROUTINEN
Wie man sehen kann, fügt die Routine ErQualityCollection_AddGroup() die neue Qualitätsgruppe automatisch zur Sammlung in sortierter Reihenfolge in Übereinstimmung mit dem Qualitätsindex hinzu. Wenn der Qualitätsindex der neuen Gruppe bereits einer anderen Gruppe in der Sammlung zugeordnet ist, wird ein Fehler rückgemeldet. In einer anderen Ausführungsform können die Escher Routinen jedoch schreiben, um der Möglichkeit Rechnung zu tragen, daß zwei oder mehr Qualitätsgruppen den gleichen Qualitätsindex in einer einzigen Qualitätssammlung haben. Auch sind, wie zuvor erwähnt, andere Ausführungsformen möglich, in denen das Anwendungsprogramm den Qualitätsindex, der einer Gruppe wie gewünscht zugeordnet ist, ändern kann. Wenn in einer solchen Ausführungsform der Qualitätsindex bereits einer Gruppe in einer oder mehreren Qualitätssammlungsobjekten zugeordnet ist, erkennt man, daß gewisse Buchhaltungsfunktionen möglicherweise ausgeführt werden müssen, um jede betroffene Qualitätssammlung in sortierter Reihenfolge aufrechtzuerhalten und/oder um doppelte Qualitätsindizes in der selben Qualitätssammlung zu handhaben.
Bezug nehmend auf 3, nach dem Hinzufügen des ersten Qualitätsgruppenobjekts zum Qualitätssammlungsobjekt erzeugt die Prozedur ein zweites neues Qualitätsgruppenobjekt im Schritt 310, dieses Mal unter Verwendung eines Qualitätsindex von 0,4. Im Schritt 312 setzt die Prozedur die Parameter in das zweite Qualitätsgruppenobjekt wie gewünscht, und im Schritt 1314 fügt sie das zweite Qualitätsgruppenobjekt zum Qualitätsobjekt in der zuvor beschriebenen Weise hinzu.
In den Schritten 1316, 1318 und 1320 wird ein drittes Qualitätsgruppenobjekt mit einem Qualitätsindex von 0,6 erzeugt, wie gewünscht modifiziert und zum Qualitätsgruppenobjekt hinzugefügt. In gleicher Weise wird in den Schritten 1322, 1324 und 1326 ein viertes neues Qualitätsgruppenobjekt erzeugt, unter Verwendung eines Qualitätsindex von 0,8, die Parameter werden in geeigneter Weise im vierten Qualitätsgruppenobjekt eingestellt, und es wird zum Qualitätssammlungsobjekt in der zuvor beschriebenen Weise hinzugefügt. Dieses vervollständigt die Anwendungsprogrammprozedur ExSetupQualityCollection() (Schritt 1328).
Man erkennt, daß in einer weiteren Ausführungsform anstatt des Erfordernisses, das jedes Anwendungsprogramm seine Qualitätssammlung aufbaut, die Escher Routinen eine Prozedur lediglich zum Schaffen einer Fehlerqualitätssammlung liefern kann. Eine solche Fehlerqualitätssammlung kann vordefiniert werden, um vier oder fünf Qualitätsgruppen zu enthalten, die jeweils mit Qualitätstypwerten gefüllt sind, so daß der Gesamtfortschritt von der Qualitätsgruppe mit dem niedrigsten Qualitätsindex zur Qualitätsgruppe mit dem höchsten Qualitätsindex von einer monoton zunehmenden Gesamtqualität und einer monoton abnehmenden Gesamtgeschwindigkeit im Gesamtkompromißspektrum Qualität/Geschwindigkeit gefolgt wird.
Man erkennt weiterhin, daß für die Aufbereitung einiger Bilder eine erste Qualitätsgruppe, die einen ersten Satz Qualitätstypenwerten hat, mit einer höheren Qualität und einer niedrigeren Geschwindigkeit aufbereiten kann, als dieses mit einer zweiten Gruppe, die einen zweiten Satz Qualitätstypenwerten hat, der Fall wäre, während ein anderes Bild mit niedrigerer Qualität und höherer Geschwindigkeit mit der ersten Qualitätsgruppe aufbereitet werden könnte und mit höherer Qualität und niedriger Geschwindigkeit mit der zweiten Qualitätsgruppe. Aufbereitungen, die mit unterschiedlichen Aufbereitern ausgeführt werden, können auch in umgekehrter Reihenfolge ausgeführt werden. Wegen dieser Möglichkeiten führen Escher Routinen keine willkürliche Konzeption aus, von denen Permutationen von Qualitätstypwerten niedrigere oder höhere Qualitätsindizes zugeordnet sein sollten. Das Anwendungsprogramm ist frei, jeden gewünschten Satz Qualitätstypwerte in einer gegebenen Qualitätsgruppe zu errichten, ohne Rücksicht auf den Qualitätsindexwert, der einer solchen Qualitätsgruppe zugeordnet ist. Es versteht sich, daß in einer anderen Ausführungsform ein solches Verhältnis tatsächlich geschaffen werden kann.
C. Prozeduren zum Auswählen und Erhalten einer Qualitätsgruppe
Ein Vorteil, mehrere Qualitätsgruppen in einer Sammlung zur Verfügung zu haben, in denen jeweils ein entsprechender Qualitätsindexwert zugeordnet ist, besteht darin, daß ein Anwendungsprogramm einen Benutzer auffordern kann, einen gewünschten Punkt im Kompromiß zwischen Aufbereitungsqualität und Geschwindigkeit unter Verwendung eines intuitiv geeigneten Mechanismus auszuwählen. Bezug nehmend wieder auf das beispielhafte Programm in Anhang A. tut dies das Anwendungsprogramm unter Verwendung einer Anwendungsprogrammroutine ExGetDesiredQualityIndex(). 14 ist ein Flußdiagramm, das die Hauptschritte in einer solche Prozedur zeigt. Bezug nehmend auf 14 zeigt die Prozedur in einem Schritt 1402 ein Qualitätsknopfpiktogramm an. Solch ein Piktogramm ist in 15 dargestellt und wie man sehen kann, sieht es wie ein Knopf aus. Es hat einen Zeiger, der gerade auf einen Qualitätsindexwert 0,0 zeigt, und der Benutzer kann auf den Punkt der Nadel drücken und die Nadel um den Kreis drehen, um jeden gewünschten Qualitätsindex zwischen 0,0 und fast 1,0 auszuwählen. In einer Ausführungsform sind die verfügbaren Positionen des Knopfes stufenlos, was es dem Benutzer erlaubt, einen Qualitätsindex mit der vollen Feinheit des Binärregisters auszuwählen, in dem er gespeichert ist. Bei einer anderen Ausführungsform können nur diskrete Werte ausgewählt werden.
Zurückkehrend auf 14 nimmt in Schritt 1404 die Prozedur die Wahl des vom Benutzer gewählten Qualitätsindex an. Im Schritt 1406 wird der gewünschte Qualitätsindex zur Aufrufroutine rückgemeldet.
Der Aufbereiter wird über die ausgewählte Qualitätsgruppe informiert, in dem entweder zum Aufbereiterobjekt in einer Ausführungsform oder zum Sichtobjekt in einer Ausführungsform die Qualitätsgruppe angehängt wird. In der vorliegend beschriebenen Ausführungsform wird sie dem Sichtobjekt angehängt. Escher liefert in Tabelle V die Routinen zum Auswählen und Erhalten eines Qualitätsgruppenobjektes.
TABELLE V ROUTINEN ZUM AUSWÄHLEN UND ERHALTEN VON QUALITÄTSGRUPPEN
Das beispielhafte Anwendungsprogramm in Anhang A. verwendet die Escher Routine ErView_SelectQualityGroup(), um für das Sichtobjekt die Qualitätsgruppe auszuwählen, deren Qualitätsindex mit dem übereinstimmt oder ihm am nächsten kommt, der vom Be nutzer angegeben ist. Es sei angemerkt, daß andere Ausführungsformen andere Rundungsfunktionen für die Situation verwenden können, wo der gewünschte Qualitätsindex nicht mit jenem übereinstimmt, der irgendeiner der Qualitätsgruppen in der Qualitätssammlung zugeordnet ist. In der vorliegenden Ausführungsform wird die Qualitätssammlung mit dem nächstkommenden Qualitätsindexwert ausgewählt; wenn die Qualitätsindizes, die Zweitqualitätsgruppen zugeordnet sind, in gleicher Weise von dem gewünschten Qualitätsindex verschieden sind, dann wird die Gruppe mit dem höheren Qualitätsindex ausgewählt. In einer anderen Ausführungsform wird der gewünschte Qualitätsindex stets aufgerundet und in einer noch anderen Ausführungsform wird der gewünschte Qualitätsindex stets abgerundet.
D. Aufbereiterprozeduren
Jeder Aufbereiter, der dazu aufgerufen ist, eine Gestalt einer bestimmten Ansicht aufzubereiten, tut dies in Abhängigkeit von den individuellen Werten der Qualitätstypen in der Qualitätsgruppe, die dem Sichtobjekt gegenwärtig zugeordnet sind. Unterschiedliche Aufbereiter können wählen, auf unterschiedliche der Qualitätstypparameter anzusprechen und andere zu ignorieren. 16 ist ein Flußdiagramm einschlägiger Aspekte einer Prozedur ErRT_Geometry_Triangle() eines Strahlzeichneraufbereiters zum Aufbereiten eines Dreiecks.
Bezug nehmend auf 16 verwendet die Prozedur im Schritt 1602 die obengenannte Escher Prozedur ErViewGetQualityGroup() oder eine ähnliche, um einen Zeiger auf die Qualitätsgruppe zu erhalten, die augenblicklich der Ansicht zugeordnet ist. Im Schritt 1604 erhält die Prozedur die Daten für das Dreieck, das zu der Ansicht aufzubereiten ist. In den Schritten 1606, 1608 und 1610 schlägt die Prozedur Werte zweier unterschiedlicher Qualitätstypparameter in der laufenden Qualitätsgruppe nach, um zu bestimmen, welche Variation der Dreieckaufbereitungsprozedur verwendet werden sollte. Insbesondere im Schritt 1606 erhält die Prozedur unter Verwendung der Escher Prozedur ErQualityGroup_GetTypeData() den Wert für den Qualitätstypparameter "berechne Reflexionen". Wenn der Wert "ein" ist, was eine Wahl höhere Qualität/niedrigere Geschwindigkeit darstellt, geht die Steuerung zum Schritt 1608 über. Wenn "berechne Reflexionen" jedoch "aus" ist, geht die Steuerung zum Schritt 1610 über.
Schritt 1608 bestimmt als nächstes den Wert des Qualitätstypparameters "berechne Schatten" in der augenblicklichen Qualitätsgruppe. Wenn "berechne Schatten" "ein" ist, dann bereitet in einem Schritt 1612 die Prozedur das Dreieck unter Verwendung des Wertes für den Qualitätstypparameter "Strahltiefe" auf unter Verwendung von Reflexionen und unter Verwendung von Schatten. Wenn "berechne Schatten" "aus" ist, dann bereitet die Prozedur das Dreieck unter Verwendung der angegebenen Strahltiefe, unter Verwendung von Reflexionen jedoch ohne Schatten auf (Schritt 1614).
Wenn "berechne Reflexionen" "aus" war, dann macht im Schritt 1610 eine Bestimmung ähnlich dem Schritt 1608. Wenn "berechne Schatten" "ein" ist, dann bereitet im Schritt 1616 die Prozedur das Dreieck unter Verwendung der angegebenen Strahltiefe, unter Berechnung von Schatten jedoch ohne Berechnung von Reflexionen auf. Wenn "berechne Schatten" im Schritt 1610 "ein" ist, dann bereitet die Prozedur im Schritt 1618" das Dreieck unter Verwendung der angegebenen Strahltiefe, jedoch ohne Berechnung irgendwelcher Schatten oder Reflexionen auf.
Man kann sehen, daß zur Vereinfachung die Aufbereiterprozedur in 16 nur auf die "Strahltiefe", "berechne Reflexionen" und "berechne Schatten" – Qualitätstypparameter in dem augenblicklichen Qualitätsgruppenobjekt anspricht. Andere Aufbereiter können jedoch auf viel mehr der Qualitätstypparameter ansprechen, wie für die spezielle Art Aufbereiter geeignet sein kann.
Die vorangehende Beschreibung bevorzugter Ausführungsformen der vorliegenden Erfindung ist zum Zwecke der Erläuterung und Beschreibung gegeben worden. Sie ist nicht als erschöpfend oder die Erfindung auf die dargestellten genauen Ausführungsformen beschränkt zu verstehen. Augenscheinlich können viele Modifikationen und Variationen von Praktikern dieses Gebiets vorgenommen werden. Die Ausführungsformen wurden gewählt und beschrieben, um die Prinzipien der Erfindung und ihre praktische Anwendung am besten zu erläutern, um dadurch andere Fachleute in die Lage zu versetzen, die Erfindung für zahlreiche Ausführungsformen und mit zahlreichen Modifikationen zu verstehen, wie sie für den speziell vorgesehenen Zweck geeignet sind. Der Umfang der Erfindung soll durch die folgenden Ansprüche und ihre Äquivalente bestimmt werden.
ANLAGE A BEISPIELHAFTES ANWENDUGSPROGRAMM
ANHANG B ErWF Geometry Polygon()

Claims

Verfahren zum Erschaffen visueller Bilder auf einer Mehrzahl von unterschiedlichen Graphikausgabevorrichtungen zur Verwendung mit einem Objektzeichnungsuntersystem, welches einen Aufbereiter verwendet, der für das Objektzeichnungsuntersystem angegeben wird, um ein Objekt, das dem Objektzeichnungsuntersystem angegeben wird, in eine dem Objektzeichnungsuntersystem angegebene Szene aufzubereiten, umfassend die Schritte: Bereitstellen einer Darstellung eines Objekts in einem Speicher; Aufrufen des Objektzeichnungsuntersystems ein erstes Mal mit einer Identifikation des Objekts, einer Identifikation einer ersten Szene und einer Identifikation eines ersten zu verwendenden Aufbereiters; und Aufrufen des Objektzeichnungsuntersystems ein zweites Mal mit einer Identifikation des Objekts, einer Identifikation einer zweiten Szene und einer Identifikation eines zweiten zu verwendenden Aufbereiters; und Ausgeben der ersten und zweiten Szenen auf verschiedene der Graphikausgabevorrichtungen.
Verfahren zum Erschaffen einer auf jeweils unterschiedlichen Graphikausgabevorrichtungen anzeigbaren Szene zur Verwendung mit einem ersten Aufbereiter, umfassend die Schritte: Einschreiben einer Angabe eines Verfahrens des ersten Aufbereiters in eine Verfahrenstabelle für den ersten Aufbereiter, welches Verfahren aufzurufen ist, um Objekte einer speziellen Geometrie aufzubereiten. Empfangen einer Angabe eines in die Szene aufzubereitenden Objekts, welches eine erste Geometrie aufweist; Ermitteln, ob der erste Aufbereiter Objekte der ersten Geometrie aufbereiten kann; Aufrufen des ersten Aufbereiters, das Objekt in die Szene aufzubereiten, wenn der erste Aufbereiter Objekte der ersten Geometrie aufbereiten kann; wenn der erste Aufbereiter Objekte der ersten Geometrie nicht aufbereiten kann, Ausführen der Schritte: Zerlegen des Objekts in wenigstens ein Unterobjekt, von denen jedes eine Geometrie aufweist, die von der ersten Geometrie verschieden ist, und für jedes gegebene der Unterobjekte Aufrufen des ersten Aufbereiters, das gegebene Unterobjekt in die Szene aufzubereiten, wenn der erste Aufbereiter Objekte aufbereiten kann, die die Geometrie des gegebenen Unterobjekts aufweisen.
Verfahren nach Anspruch 2, weiterhin umfassend den Schritt des Empfangens einer Angabe des ersten Aufbereiters in Koordination mit dem Schritt des Empfangs einer Angabe eines aufzubereitenden Objekts.
Verfahren nach Anspruch 2 oder 3, wobei die spezielle Geometrie die erste Geometrie ist.
Verfahren nach einem der Ansprüche 2 bis 4, wobei der Schritt des Einschreibens den folgenden Schritt umfaßt: Für jede spezielle Geometrie, die der erste Aufbereiter aufbereiten kann, das Einschreiben einer Angabe eines entsprechenden Verfahrens des ersten Aufbereiters, das aufzurufen ist, um Objekte der speziellen Geometrie aufzubereiten, in einen entsprechenden Eintrag einer Verfahrenstabelle für den ersten Aufbereiter.
Verfahren nach einem der Ansprüche 2 bis 5, wobei der Schritt des Ermittelns, ob der erste Aufbereiter Objekte der ersten Geometrie aufbereiten kann, den Schritt des Ermittelns umfaßt, ob die Verfahrenstabelle für den ersten Aufbereiter eine Angabe eines Verfahrens enthält, das aufzurufen ist, um Objekte der ersten Geometrie aufzubereiten.
Verfahren nach einem der Ansprüche 2 bis 6, wobei der Schritt des Aufrufens des Aufbereiters zum Aufbereiten des Objekts den Schritt des Aufrufens des Verfahrens umfaßt, das durch die Verfahrenstabelle angegeben wird, um Objekte der ersten Geometrie aufzubereiten.
Verfahren nach einem der Ansprüche 2 bis 7 zur weiteren Verwendung mit einem zweiten Aufbereiter, weiterhin vor dem Empfangsschritt den folgenden Schritt umfassend: Für jede Subjektgeometrie, die der zweite Aufbereiter aufbereiten kann, das Einschreiben einer Angabe eines entsprechenden Verfahrens des zweiten Aufbereiters, das aufzurufen ist, um Objekte, die die Subjektgeometrie aufweisen, aufzubereiten, in einen entsprechenden Eintrag einer Verfahrenstabelle für den zweiten Aufbereiter.
Verfahren zum Erschaffen einer auf jeweils unterschiedlichen Graphikausgabevorrichtungen anzeigbaren Szene umfassend die Schritte in Folge: Starten der Ausführung eines Anwendungsprogramms; für einen ersten Aufbereiter das Einrichten einer Angabe wenigstens eines entsprechenden Verfahrens des ersten Aufbereiters, welches Verfahren aufzurufen ist, um Objekte, die eine entsprechende Geometrie aufweisen, aufzubereiten, wobei der Schritt des Einrichtens für jede spezielle Geometrie, die der erste Aufbereiter aufbereiten kann, den Schritt des Einschreibens in einen entsprechenden Eintrag einer Verfahrenstabelle für den ersten Aufbereiter einer Angabe des entsprechenden Verfahrens des ersten Aufbereiters umfasst, welches Verfahren aufzurufen ist, die Objekte mit der speziellen Geometrie aufzubereiten; und für ein Objekt das eine erste Geometrie hat, die der erste Aufbereiter aufbereiten kann, das Aufrufen des Verfahrens des ersten Aufbereiters, das in dem Einrichtungsschritt eingerichtet wurde, um Objekte aufzubereiten, die die erste Geometrie aufweisen.
Verfahren nach Anspruch 9, weiterhin umfassend nach dem Schritt des Startens der Ausführung des Anwendungsprogramms den Schritt der Einrichtung für einen zweiten Aufbereiter einer Angabe wenigstens eines Verfahrens des zweiten Aufbereiters, das aufzurufen ist, um Objekte aufzubereiten, die eine entsprechende Geometrie aufweisen.
Verfahren nach Anspruch 9 oder 10, weiterhin umfassend vor dem Schritt des Aufrufens und nach beiden Einrichtungsschritten den Schritt der Auswahl des ersten Aufbereiters über dem zweiten Aufbereiter für den Aufrufschritt unter der Steuerung durch das Anwendungsprogramm.
Verfahren nach einem der Ansprüche 9 bis 11, wobei der Einrichtungsschritt für einen zweiten Aufbereiter nach dem Schritt des Aufrufens durchgeführt wird, weiterhin umfassend den Schritt des Aufrufens für das Objekt des Verfahrens zum Aufbereiten von Objekten, die die erste Geometrie aufweisen, welches Verfahren in dem Einrichtungsschritt für einen zweiten Aufbereiter eingerichtet wurde.
Verfahren nach einem der Ansprüche 9 bis 12, weiterhin umfassend nach dem Einrichtungsschritt die Schritte: Zerlegen eines zweiten Objekts, das eine zweite Geometrie aufweist, die der erste Aufbereiter nicht aufbereiten kann, in wenigstens ein Unterobjekt, von denen jedes eine Geometrie aufweist, die von der zweiten Geometrie verschieden ist; und für jedes gegebene der Unterobjekte, deren Geometrie der erste Aufbereiter aufbereiten kann, das Aufrufen des Verfahrens des ersten Aufbereiters, das in dem Schritt des Einrichtens eingerichtet wurde, um Objekte aufzubereiten, die die Geometrie des gegebenen Unterobjekts aufweisen.
Vorrichtung zum Erzeugen einer auf jeweils unterschiedlichen Graphikvorrichtungen anzeigbaren Szene für den Gebrauch mit einem ersten Aufbereiter mit einer Verfahrenstabelle, umfassend: Mittel zum Schreiben in die Verfahrenstabelle des ersten Aufbereiters einer Angabe eines Verfahrens des ersten Aufbereiters, welches zum Aufbereiten von Objekten mit einer speziellen Geometrie aufzurufen ist; Mittel zum Empfang einer Angabe eines in die Szene aufzubereitenden Objekts, welches eine erste Geometrie aufweist; Mittel zum Ermitteln, ob der erste Aufbereiter Objekte der ersten Geometrie aufbereiten kann; Mittel zum Aufrufen des ersten Aufbereiters, um das Objekt in die Szene aufzubereiten, wenn der erste Aufbereiter Objekte der ersten Geometrie aufbereiten kann; und Mittel um, wenn der erste Aufbereiter Objekte der ersten Geometrie nicht aufbereiten kann, das Objekt in wenigstens ein Unterobjekt zu zerlegen, von denen jedes eine Geometrie aufweist, die von der ersten Geometrie verschieden ist, und für jedes gegebene der Unterobjekte Aufrufen des ersten Aufbereiters, das gegebene Unterobjekt in die Szene aufzubereiten, wenn der erste Aufbereiter Objekte aufbereiten kann, die die Geometrie des gegebenen Unterobjekts aufweisen.
Vorrichtung nach Anspruch 14, wobei die spezielle Geometrie die erste Geometrie ist.
Vorrichtung nach Anspruch 14 oder 15, wobei das Mittel zum Einschreiben Mittel umfaßt, um für jede spezielle Geometrie, welche der erste Aufbereiter aufbereiten kann, in einen entsprechenden Eintrag der Verfahrenstabelle für den ersten Aufbereiter eine Angabe eines entsprechenden Verfahrens des ersten Aufbereiters, welches zum Aufrufen von Objekten mit der speziellen Geometrie aufzurufen ist, einzuschreiben.
Vorrichtung nach einem der Ansprüche 14 bis 16, wobei das Mittel zum Aufrufen des Aufbereiters zum Aufberei ten des Objekts ein Mittel zum Aufrufen des Verfahrens umfaßt, welches durch die Verfahrenstabelle angegeben ist, um Objekte der ersten Geometrie aufzubereiten.
Vorrichtung zum Erschaffen einer auf jeweils unterschiedlichen Graphikausgabevorrichtungen anzeigbaren Szene umfassend die Mittel für, in Folge: Starten der Ausführung eines Anwendungsprogramms; für einen ersten Aufbereiter das Einrichten einer Angabe wenigstens eines entsprechenden Verfahrens des ersten Aufbereiters, das auf zurufen ist, um Objekte, die eine entsprechende Geometrie aufweisen, aufzubereiten, wobei der Schritt des Einrichtens für jede spezielle Geometrie, die der erste Aufbereiter aufbereiten kann, den Schritt des Einschreibens einer Angabe des entsprechenden Verfahrens des ersten Aufbereiters, das aufzurufen ist, die Objekte mit der speziellen Geometrie aufzubereiten, in einen entsprechenden Eintrag einer Verfahrenstabelle für den ersten Aufbereiter umfasst; und für ein Objekt das eine erste Geometrie hat, die der erste Aufbereiter aufbereiten kann, das Auf rufen des Verfahrens des ersten Aufbereiters, das in dem Einrichtungsschritt eingerichtet wurde, um Objekte aufzubereiten, die die erste Geometrie aufweisen.
Computer-lesbares, Programmbefehle tragendes Medium, welche, wenn sie durch ein Computersystem ausgeführt werden, eine auf jeweils unterschiedlichen Graphikausgabevorrichtungen anzeigbare Szene zur Verwendung mit einem ersten Aufbereiter erzeugen, wobei die Programmbefehle Befehle umfassen zum: Einschreiben einer Angabe eines Verfahrens des ersten Aufbereiters in eine Verfahrenstabelle für den ersten Aufbereiter, welches aufzurufen ist, um Objekte einer speziellen Geometrie aufzubereiten. Empfangen einer Angabe eines in die Szene aufzubereitenden Objekts, welches eine erste Geometrie aufweist; Ermitteln, ob der erste Aufbereiter Objekte der ersten Geometrie aufbereiten kann; Aufrufen des ersten Aufbereiters, das Objekt in die Szene aufzubereiten, wenn der erste Aufbereiter Objekte der ersten Geometrie aufbereiten kann; wenn der erste Aufbereiter Objekte der ersten Geometrie nicht aufbereiten kann, Ausführen der Schritte: Zerlegen des Objekts in wenigstens ein Unterobjekt, von denen jedes eine Geometrie aufweist, die von der ersten Geometrie verschieden ist, und für jedes gegebene der Unterobjekte Aufrufen des ersten Aufbereiters, das gegebene Unterobjekt in die Szene aufzubereiten, wenn der erste Aufbereiter Objekte aufbereiten kann, die die Geometrie des gegebenen Unterobjekts aufweisen.
Computer-lesbares, Programmbefehle tragendes Medium, welche, wenn sie durch ein Computersystem in Antwort auf durch ein auf dem Computersystem ausführendes Anwendungsprogramm ausgeführt werden, eine auf jeweils unterschiedlichen Graphikausgabevorrichtungen anzeigbare Szene erzeugen, wobei die Programmbefehle Befehle umfassen, um, nachdem das Anwendungsprogramm auf dem Computersystem seine Ausführung begonnen hat: Für jede spezielle Geometrie, die der erste Aufbereiter aufbereiten kann, eine Angabe eines entsprechenden Ver fahrens des ersten Aufbereiters einzuschreiben, das aufzurufen ist, um Objekte der speziellen Geometrie aufzubereiten, in einen entsprechenden Eintrag einer Verfahrenstabelle für den ersten Aufbereiter; und danach für ein Objekt das eine erste Geometrie hat, die der erste Aufbereiter aufbereiten kann, des Verfahrens des ersten Aufbereiters aufzurufen, das die Programmbefehle zum Aufbereiten von Objekten eingerichtet haben, die die erste Geometrie aufweisen.