From fc3ffe84497bc418532143bd3c0c05fbfea1abd0 Mon Sep 17 00:00:00 2001 From: NorthScorp UG Date: Tue, 27 Oct 2020 18:18:24 +0100 Subject: [PATCH] neue Kapitel erschlossen --- Betriebssysteme.md | 91 ++++++++++++++++++++- Computergrafik.md | 197 ++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 284 insertions(+), 4 deletions(-) diff --git a/Betriebssysteme.md b/Betriebssysteme.md index c62417f..06cd82e 100644 --- a/Betriebssysteme.md +++ b/Betriebssysteme.md @@ -198,4 +198,93 @@ durch 1. Freigabe der Ressourcen 2. Benachrichtigung der "Eltern" -3. Adoption der "Kinder" \ No newline at end of file +3. Adoption der "Kinder" + +## Threads +Naive Lösung: für jede nebenläufige Aktivität einen Prozess erstellen. Jedoch hat ein Prozess: +- Kosten des Managements +- kosten der isolation +- Kosten der Kommunikation + +$\rightarrow$ Parallelität mittels Prozessen ist teuer (revidiertes Prozessmodell) + +Daher suche nach kostengünstigerem Modell zur Parallelisierung nebenläufiger Aktivitäten + +> Definition Prozess: Ein (Multithread-) Prozess ist eine vollständige Beschreibung einer ablaufenden Aktivität. Dazu gehört insbesondere +> 1. Das ablaufende Programm +> 2. zugeordnete Betriebsmittel +> 3. Rechte +> 4. prozessinterne parallele Aktivitäten (Threads) und ihre Bearbeitungszustände + +> Definition Thread: ist eine sequenzielle Aktivität im Betriebsmittelkontext (d.h. innerhalb) eines Prozesses + +parallele Aktivitäten innerhalb eines Prozesses werden durch parallele Threads repräsentiert. + +Anmerkung: +1. **Eigentümer von Ressourcen und Rechten** sind immer noch prozesse +2. das **Programm eines Prozesses** kann nun Code für mehr als eine sequenzielle Aktivität enthalten +3. **Gegenstand der Prozesszuteilung** sind nun Threads +4. das **ursprüngliche Prozessmodell** ist eine Spezialisierung dieses Modells (ein Prozess mit genau einem Thread) +5. ein **Prozessdescriptor** (PCB) eines Multithread-Prozessmodells enhält alle Informationen des PCBs eines Single-Thread-Prozessmodells plus Informationen über alle seine Threads +6. ein **TCB** enthält lediglich den Threadszustand und den Ablaufkontext + +Threads werden daher oft als *Leichtgewichtprozesse* bezeichnet + + +Threads treten in verschiedenen Varianten auf +1. komfortabel (integriert in Programmiersprache) +2. "zu Fuß" (durch Bibiliotheken oder API) + +Implementierungsebenen +1. Prozessmodell des Betriebssystems ist Multithread Modell + - Thread Implementierung im Betriebssystem + - das Betriebssystem hat Kenntnis über Threads + - Kernel Level Threads (KLTs) +2. Prozessmodell des Betriebssystems ist Single-Thread-Modell + - Thread Implementierung auf Anwendungsebene + - nur auf Endbenutzer-Ebene ist Kenntnis über Threads + - User Level Thread (ULTs) + +| Pro KLT | Pro ULT | +| Performanz durch Parallelität | Performanz durch geringen Overhead | +| Nutzung von Mehrprozessor/Mehrkernarchitektur | Thread Management ohne Systemaufrufe | +| ein blockierender Systemaufruf in einem Thread blockiert nicht auch gleichzeitig alle anderen Threads des gleichen Prozesses | Thread Umschaltung ohne Mitwirkung des Betriebssystems | +| | Individualität: anwendungsindividuelle Thread Schedulingstrategien möglich | +| | Portabilität | + +es gibt Work-Arounds: alle gefählrichen Systemaufrufe einpacken (in Pakete) + +Wahl zwischen ULT- und KLT hängt ab von: +1. Vorraussetzung: Prozessmodell des Betriebssystems Multithread Modell? +2. Anwendungsprofil: E/A-Profil, Parallelität, Portabilität, Individualität + +# Scheduling +## Das Problem +Anzahl der Aktivitäten >> Anzahl der Prozessoren +- nicht alle können gleichzeitig arbeiten +- eine Auswahl muss getroffen werden +- Auswahlstrategie: Schedunling-Strategie/Algorithmus +- die Betriebssystem Komponente Scheduler +- Ziel: Effizientes Ressourcenmanagement + +Threads können +- aktiv sein (besitzt einen Prozessor) +- rechenbereit sein (Bsp. hätte gerne einen Prozessor) +- kurzfristig warten (Bsp. benötigt keinen Prozesoor aber Arbeitsspeicher) +- langfristig warten (Bsp. benötigt länger keinen Prozessor/Arbeitsspeicher) + +Folge: effizientes Ressourcenmanagement benötigt präzise Informationen über Threadzustände. + +## Aufgabe der Zustandsmodelle +Beschreibung: +- des Ablaufzustands von Threads (aktiv/bereit/wartend) +- der mögliche Zustandsübergänge (z.B. bereit->aktiv) + +Nutzung +- jeder Thread ist zu jedem Zeitpunkt in genau einem dieser Zustände +- jeder Thread wechselt seinen Zustand gemäß der im Modell definierten Zustandsübergänge, hervorgerufen durch z.B. Zuteilung eines Prozessors +- Ressourcenmanagement: nutz Zustand als Informationsquelle für Entscheidungen + +Beschreibungsmittel: endliche deterministische Automaten +- Menge der annehmbaren Zustände ist endlich +- Folgezustand ist immer eindeutig bestimmt diff --git a/Computergrafik.md b/Computergrafik.md index 96a3424..fab9746 100644 --- a/Computergrafik.md +++ b/Computergrafik.md @@ -1,5 +1,5 @@ --- -title: Computerbild +title: Computergrafik date: Wintersemester 20/21 author: Robert Jeutter --- @@ -7,7 +7,7 @@ author: Robert Jeutter Computergrafik ist in erster Linie Bildsynthese mit dem Computer! dabei zu lösende Teilaufgaben: -- identifiezierung relevanter mathematischer Funktionen +- identifizierung relevanter mathematischer Funktionen - Umsetzung passender/effizienter Algorithmen und Datenstrukturen - Erzeugung virtueller Umgebungen - Kompromisse zwischen Genauigkeit und Berechnungsaufwand @@ -84,7 +84,7 @@ Entsprechend der Definition für Skalarprodukte muss die Matrix A gleich viele S **Kommutativität**: ist im Allgemeinen bei Matrixmultiplikation nicht gewährleistet $A*B \not = B*A$ -### Kartesiche Koordinaten +### Kartesische Koordinaten Dreidimensionales kartesisches Koordinatensystem werden aufgespannt durch die drei linear unabhängigen Einheitsvektoren $\vec{x}$,$\vec{y} und $\vec{z}. 3D-Punktobjekte werden durch Vektoren im $\R^3$ repräsentiert. Diese Vektoren werden Ortsvektoren genannt, da Sie einen Ort im Raum repräsentieren. Die Koordinaten eines Vektors sind wiederum eine senkrechte Projektion des Vektors auf die Koordinatenachse. @@ -282,3 +282,194 @@ Kamera ist definiert durch - Blickrichtung D - Oben-Vektor U ("view up vector", senkrecht zu D) +## Projektion +3D Objekt auf eine Ebene projiezieren: +- Teil der Kameratransformation +- erfolgt meist in Kamerakoordinaten +- Projektionsarten + - Parallelprojektion (z.B. Ansicht von oben) stets affine Projektion + - zentralperspektivische Projektion (Zentralperspektive) keine affine Projektion, d.h. im Allgemeinen bleibt paralleles nicht parallel + +### Orthogonale Projektion +- einfachste der Parallelprojektionen +- Projektionsebene ist parallel zur XY Ebene +- Projektionsrichtung hier stets parallel zur z-Achse (rechtwinklig zur Projektionsebene) +- z Koordinaten werden auf gleichen Wert gesetzt (z.B. 0 ist dann die Projektionsmatrix) +- Anwendung: $O'=P*R*T*O$ wenn T und R die Transformationsschritte der Kameraprojektion sind und O das Objekt in Weltkoordinaten +$$P=\begin{pmatrix} + 1&0&0&0\\ + 0&1&0&0\\ + 0&0&0&0\\ + 0&0&0&1 + \end{pmatrix}$$ + +### Schiefwinklige Parallelprojektion +- typische Parallelprojektion mit 2 Parametern +- Projektionsebene ist parallel zur XY Ebene +- Projektionsrichtung hat zwei Freiheitsgrade und ist typischerweise nicht orthogonal zur Projektionsebene (d.h. schiefwinklig) +- Projektionsrichtung (Schiefe) ist über 2 Winkel parametrisierbar +- Herleitung + $P=\begin{pmatrix} + 1 & 0 & -cos(\alpha)*f & 0 \\ + 0 & 1 & -sin(\alpha)*f & 0 \\ + 0 & 0 & 0 & 0 \\ + 0 & 0 & 0 & 1 + \end{pmatrix$$} +- es gilt: $x'=x-cos(\alpha)*f*z$ und $y'=y-sin(\alpha)*f*z$ + + +### Zentralperspektive +- entspricht einer Lochkamera bzw etwa dem "einäugigen" Sehen +- Augpunkt im Ursprung des Kamerakoordinatensystems +- Projektionsfläche ist eine Ebene parallel zu XY Ebene +- Eigenschaften + - perspektivische Verkürzung + - parallele Linien des Objekts fluchten oft in einen Fluchtpunkt + +$$\begin{pmatrix} d&0&0&0\\ 0&d&0&0 \\ 0&0&0&1 \\ 0&0&1&0 \end{pmatrix} * \begin{pmatrix}x\\y\\z\\1\end{pmatrix} = \begin{pmatrix} d*x\\ d*y\\ 1 \\ z \end{pmatrix} \rightarrow \begin{pmatrix} \frac{d*x}{z} \\ \frac{d*y}{z} \\ \frac{1}{z} \end{pmatrix}$$ + +Fluchtpunkte +- hat ein Modell parallele Kanten oder parallele Striche in Texturen, dann ergibt sich für jede solche Richtung r in der Abbildung ein Fluchtpunkt, auf den diese parallelen Kanten/Striche hinzu zu laufen scheinen +- es gibt jedoch Ausnahmen, bei denen Paralleles in der Abbildung Parallel bleibt (z.B. horizontale Kanten der Schwellen in der Abbildung) +- Da es beliebig viele Richtungen geben kann, sind auch beliebig viele Fluchtpunkte in einem Bild möglich +- Rotationen können Fluchtpunkte ändern, Translationen jedoch nicht + +Ermittlung eines Fluchtpunktes: Wird aus einer Richtung r und dem Aufpunkt eine Gerade definiert, dann schneidet diese Gerade die Projektionsfläche im Fliuchtpunkt für die Richtung r. + +- Eine Richtung r, die in der Projektionsfläche enthalten ist, führt zu einer Gerade durch den Augpunkt, welche nie die Projektionsfläche schneidet. Alle Linien mit einer solchen Richtung bleiben folglich parallel +- Der Fluchtpunkt der Richtung r ist abhängig von 1. dieser Richtung, 2. der Projektionsfläche und 3. dem Augpunkt +- Nur wenn eines der 3 obigen Elemente geändert wird, ändert sich die Lage des Fluchtpunktes von r +- da Verschiebungen von Objekten weder deren Richtungen, den Augpunkt oder die Projektionsebene verändern, belibt die Lage der Fluchtpunkte bei Verschiebungen stets erhalten +- Die Rotation eines Objektes ändert im Allgemeinen die im Objekt enthaltenen Richtungen und damit auch deren Fluchtpunkt + + +### Zusammenfassung +- Mittels Matrixmultiplikation kann eine Folge unterschiedlicher 3D-Transformationen in einer einzigen 4x4-Matrix zusammengefasst werden. Dies schließt Projektionsmatrizen (Abbildung von 3D nach 2D) mit ein. +- Affine Abbildungen lassen die w-Koordinate unverändert. Bei Parallelprojektionen ist das so. +- Die perspektivische Kameratransformation ist eine allgemeine homogene Matrix und keine affine Abbildung. Die w-Koordinate kann dadurch verändert werden. Zur Rückführung in kartesische Koordinaten ist eine Division durch die w-Koordinate erforderlich! +- Bei zentralperspektivischer Projektion ergibt sich pro Schar paralleler Kanten/Texturlinien/etc jeweils ein Fluchtpunkt (Spezialfall: Richtung ist parallel zur Projektionsebene, dann Fluchtpunkt im Unendlichen). Durch Rotation eines Objektes (relativ zur Kamera) ändert sich im Allgemeinen die Lage der Fluchtpunkte. Neben dem gestalterischen Aspekt (Bildkomposition) spielen Fluchtpunkte bei der Bilderkennung (z.B. Berechnung der Ausrichtung von 3D-Objekten) eine Rolle + + +# Modellierung +## Geometrische Modellierung +### Grundlagen +Bei der geometrischen Modellierung geht es im allgemeinen um die computergestütze Beschreibung der Form geometrischer Objekte + +Objekte: +- Beschreibung von dreidimensionalen geometrischen Formen +- verschiedenste Formate existieren, meistens eine Gruppierung der geometrischen Eigenschaften (Eckpunkte, Kanten, Flächen) + +Dateiformate: +- für das speichern der dreidimensionalen geometrischen Formen gibt es verschiedenste Dateiformate +- STL: ist beispielweise Standard für viele CAD Systeme +- OBJ: weitverbreitetes Dateiformat + + +### B-Rep +B-Rep = Boundary Representation: Für die Beschreibung dreidimensionaler Festkörper gibt es mehrere Möglichkeiten. Ein Standard ist die Boundary Representation, eine Modellgeschreibung durch die festlegung begrenzender Oberflächen +- Darstellungsform eines Flächen- oder Volumenmodells +- beschreibt Objekt durch begrenzende Oberflächen +- sind schnell verarbeitbar +- Definition eines Ojekts erfolgt über einen vef-Graph (vertex, edge, face) + - Knotenliste: beinhaltet Koordinatenpunkt + - Kantenliste: für jede Kante werden zwei Punkte referenziert + - Flächenliste: für jede Fläche wird Reihenfolge von Kanten angegeben + + +## Szenengraph +Szene (Computergrafik) +- eine dreidimensionale Beschreibung von Objekten, Lichtquellen und Materialeigenschaften +- setzt virtuellen Betrachter voraus, sowie dessen Position und Blickwinkel + +Szenegraph: +- hierarchische Gruppierung der Objekte in einer Szene +- somit eine objektorientierte Datenstruktur +- aus graphentheoretischer Sich: gerichteter Graph ohne Kreise + + +## Rendering +Beim rendern erfolgt eine Bilderzeugung aus einer gegebenen Szene. Der Weg von der Szene bis zum fertigen Bild erfolgt dabei über eine sogenannte **Render-Pipeline**: + +Geometrisches Objekt-> Transformieren-> Vertex Shader-> Raster Konvertierung-> Fragment Shader-> Ausgabebild + +### Vertex Shader +- verarbeitet alle Eckpunkte (Vertices) des 3D-Modells +- für jeden Vertex wird dieser Shader im Normalfall einmal aufgerufen +- ermöglicht eine Beeinflussung der Objektform +- Hauptaufgabe ist die Transformation der virtuellen 3D Position auf 2D koordinaten für den Bildschirm +- Input + - Vertices aller relevanter Objekte der Szene + - gewünschte Transformation +- Output + - auf Bildschirm projizierte 2D Koordinaten + - zugehörige Tiefeninformationen + +Alle Transformationen die auf ein Vertex wirken und die anschließende Projektion wird als eine sogenannte MVP-Matrix zusammengefasst. + +### Model View Projection +Gegeben: +- Modell als Vertices mit kartesischen 3D koordinaten und definierten Dreiecken +- Kamera (3D Position, Ausrichtung) welche das Modell betrachtet +Gesucht: +- transformierte Position +- Rendering des Modells aus Sicht der Kamera + +$\rightarrow$ benötigen Abbildung von 3D-Vertexkoordinaten auf 2D-Kamerabildkoordinaten + +Umsetzung: +- zuerst Transformation von Modellraum (gegebenen Koordinaten) in Weltkoordinaten (Model) +- danach Transformation in Kameraraum, für einfachere Projektion (View) +- abschließende projektion auf Kamerabildebene und Umrechnung in Bildraum (Projektion) + +Model: $M=T*R*S$ (Transformation in Weltkoordinaten) + +View: $V=T_V^{-1}*R_V^{-1}$ (Transformation in Kameraraum) + +Kameraraum: +- Kamera sitzt im ursprung (0,0,0) +- hat keine Rotation + +Projektion: P +- Bildebenenprojektion kann durch Zentralperspektivische Projektionsmatrix erfolgen +- Frustum (Kamerasichtfeld) legt fest welche Objekte im Sichtfeld liegen und somit in der Bildebene sichtbar sind + +Ergebnis +- Zusammenfassung der Transformation ergibt die Model-View-Projektion-Matrix $P*V*M=MVP_{Matrix}$ +- Anwendung der MVP-Matrix auf alle Vertices eines Modells $p_m$ ergibt die notwendige Bildraumprojektion des Modells: $p'_m=P*V*M*p_m$ +- Vorteile: die MVP-Matrix muss nur einmal berechnet werden und kann auf alle Vertices eines Modells angewandt werden + +### Zusammenfassung +- geometrische Modellierung zur Beschreibung von Objekten +- Anwendung der Transformation +- Projektion der Objekte auf den Bildschirm + +## Effiziente geometrische Algorithmen und Datenstrukturen +### Bintree +- effizientes Suchen und Einfügen in eindimensionale Domänen +- logarithmische Komplexität pro Zugriff möglich +- Gefahr: lineare Komplexität, wenn nicht balanciert + +analog zu Quad- und Octrees: +- typisch ost Teilung in Mitte (bisektion) +- Bereiche mit homogenem Inhalt (gleiche Farbe/ keine Elemente) werden nicht weiter unterteilt +- Komprimierungseffekt + +### Quadtree +- eine (meist quadratische) Fläche kann bei Bedarf in vier gleichgroße Quadranten unterteilt werden +- Bedarf entsteht, wenn die Fläche keine homogenen Eigenschaften aufweist (z.B. bei unterschiedlich gefärbten Pixeln). D.h. Flächen (bzw Quadranten) werden solange unterteilt, bis sie homogen sind +- Anwendung + - Geometrische 2D Objekte können in hierarischische Struktur einsortiert werden, wodurch die räumliche Suche nach diesen Objekten beschleunigt wird + - Effiziente Speicherung von Rasterbildern wird möglich (Komprimierung, da nur strukturierte Bereiche unterteilt werden) + + +### Octree +### KD Tree +### BSP Tree +### Hüllkörper Hierarchie +### weitere Anwendungsfälle +### Ray Picking mit KD Baum +### Aufwandsabschätzung bzgl Dreiecksanzahl +### Aufwandsabschätzung in fps +### Heurisitk zur Unterteilung +### Behandlung ausgedehnter Objekte +