Vorbemerkungen. Art of Game Programming Winter (c) Peter Sturm, Universität Trier 1. ! Vorlesung. ! Übung. ! Was nicht vorkommt!

Transkript

1 Art of Game Programming Winter 2011 Vorbemerkungen! Vorlesung! Donnerstags, Uhr! Wahrscheinlich anderer Raum! Übung! Projektorientiert, Kleingruppen, 3-4 Aufgaben! Was nicht vorkommt!! Keine Walkthroughs, Cheats, etc.! Mit Computerspielen spielen ist NICHT Teil der Übung! Folienkopien und mehr! studip (c) Peter Sturm, Universität Trier 1

2 Art of Game Programming Winter 2011 Was sind Computerspiele? Interdisziplinär Graphik Design Mathematik Physik VWL Psychologie Informatik Audio Musik Sprache Text BWL Regie Kamera Schauspiel (c) Peter Sturm, Universität Trier 2

3 Art of Game Programming Winter 2011! Kernbereiche! Programmiersprachen! Effiziente Datenstrukturen! Parallelität! Computergraphik! Echtzeitgraphik, Animation! Verteilte Systeme! Netzwerke! Künstliche Intelligenz Informatik! Alle gängigen Anforderungen! Skalierbarkeit! Konsistenz! Verfügbarkeit! Sicherheit Beispiel: Verteilte Systeme (c) Peter Sturm, Universität Trier 3

4 Art of Game Programming Winter 2011 Das Netzwerk Client Internet Server Client! Clients überwiegend hinter dünnen Leitungen! DSL und Kabelmodem! Begrenzte Bandbreite! Minimale Datenmenge, Komprimierung,! Verbindungsabbrüche (Disconnects)! Latenz = Lag (c) Peter Sturm, Universität Trier 4

5 Art of Game Programming Winter 2011 Rennerfahrungen! Festrennen! Pro Quartal ein Fest! Alle 10 Minuten ein Rennen mit maximal 4 Teilnehmern! Preis: Ein schickes Pferd im Tausch gegen den alten Klepper! Meist standen zwischen 4 und 10 Teilnehmer an (zu jedem beliebigen Zeitpunkt)! Aufregung wie bei einem echten Rennen! Hoher Puls, kalte Hände, Hohe Konzentration,! Kein globaler Zustand! Unterschiedliche Sichten auf Rennergebnis! A geht als Erster vor B ins Ziel, B geht als Erster vor A ins Ziel, C gewinnt! Glücklicher Gewinner (c) Peter Sturm, Universität Trier 5

6 Art of Game Programming Winter 2011 Warum?! Echte (menschliche) Gegner bzw. Mitstreiter! Zusammenspiel mit Menschen aus der ganzen Welt! Virtuelle Freundschaften! Flucht in eine virtuelle Welt! Hinauswachsen über das reale Leben (RL)! Macht, Erfolg, Bestätigung! Bis hin zur Sucht (c) Peter Sturm, Universität Trier 6

7 Art of Game Programming Winter 2011 Spiele werden durch die Spieler geformt! Abbilder realer Umgangsformen! Positive Aspekte! Freundschaft! Negative Aspekte! Diebstahl! Partnerschaften! Vandalismus! Beleidigung! Verrat! Mögliche Folgen! Soziale Verarmung! fehlender persönlicher Kontakte! Realitätsverlust mit physischen Folgen! Starker sozialer Druck! durch Sippen/Clans/Gilden! Spielsucht! Erste Spezialkliniken/Abteilungen! Selbsthilfegruppen (c) Peter Sturm, Universität Trier 7

8 Art of Game Programming Winter 2011 Extremfälle! Spieler vergessen das reale Leben! Belgier stirbt 2008 an Erschöpfung nach exzessivem stundenlangen Spielen ohne Schlaf! 28-jähriger Koreaner stibrt nach 50 Stunden ununterbrochenem Spiel an Dehydrierung! Spieler stellen Spielszenen nach! 13-jähriger Chinese stirbt; Eltern verklagen Hersteller! Spieler können Welten nicht mehr trennen! Mitglieder virtuell verfeindeter Gruppen prügeln sich real zu Tode (c) Peter Sturm, Universität Trier 8

9 Art of Game Programming Winter 2011 Vorteilnahme (Exploits)! Speed Hacking / Teleporting! Geschwindigkeits- und Positionsmanipulationen! Botting! Programm kontrolliert den Spielercharakter! Mechanics Exploits! Überwinden physikalischer Schranken (z.b. durch Wänden gehen)! Data Mining! Unerlaubter Zugriff auf geschützte Daten Ausbeutung! Goldfarmer / Chinafarmer! Menschen spielen gegen Bezahlung! Erwirtschaften virtuelle Güter und verkaufen diese außerhalb des Spiels! Eine Schätzung geht von Beschäftigten aus (2008)! 80% wohnen in China! 500 Million Dollar Markt (c) Peter Sturm, Universität Trier 9

10 Art of Game Programming Winter 2011 Chancen! Wirtschaftsfaktor! Innovationsmotor! Technisch! Wissenschftlich! Virtuelle Realitäten! Überwindung des Raums! Serious Games! Gesellschaftliche Akzeptanz (c) Peter Sturm, Universität Trier 10

11 Art of Game Programming Winter 2011! Beispiel MMORG World of Warcraft! Blizzard Entertainment! Seit Ende 2004! Ca. 11 Millionen Abonnenten! 2. Quartal 2010! 1 Millarde Dollar Umsatz! 290 Millionen Dollar Gewinn Der Platzhirsch! Add-on Cataclysm (erscheint )! 3.3 Millionen Exemplare in den ersten 24 Stunden! 4.8 Millionen Exempare im ersten Monat! Wachsende Bedeutung! Wachsender Umsatz Ökonomischer Faktor! 7.3 Milliarden Dollar 2004 in USA (NPD Group)! Halo 2 brachte am ersten Tag mehr ein als jeder bisherige Kinofilm! 8 Spiele pro Sekunde! Weltweiter Umsatz mit Spielen! 26 Milliarden Dollar (geschätzt für 2010) (c) Peter Sturm, Universität Trier 11

12 Art of Game Programming Winter 2011 Neue Märkte: WoW und ebay (c) Peter Sturm, Universität Trier 12

13 Art of Game Programming Winter 2011 Soziales & Gesellschaftliches! Neue Räume für Randgruppen! Die Welt wird ein Dorf! Gemeinsamer Spielspaß! Physische Räumlichkeit überwinden! Virtuelle Freunde! Soziale Netze! Virtuelle Hochzeiten!! Psychologische Hilfe für den Alltag! Alternative Realitäten Technisch! Wachsende Teilnehmerzahlen! Aktuelle Server verkraften einige tausend Spieler! Immer größere Welten! Eine Welt (keine Mehrfachinstanziierung)! User-Generated Content! Eigene Quests! Rollenspiel (c) Peter Sturm, Universität Trier 13

14 Art of Game Programming Winter 2011 Forschungsschwerpunkte! Neurobiologie / Psychologie! Wie wichtig ist der Körper?! Mirror neurons! Wirtschaftswissenschaften! Virtuelle Güter und Transaktionen! Rechtswissenschaften! Virtuelle Besitztümer, Rechte, Pflichten, Steuersysteme! Informationssysteme! Skalierbarkeit, Verteilte Systeme! Offene Standards, Open Source Immersion! Echte Gefühle bei guter Immersion! Erhöhte Adrenalinproduktion! Furcht, Wut, Zorn, Freude, usw.! Ununterscheidbarkeit für Gehirn! Spiegelneuronen! Immerwährende philosophische Diskussion! Alle psychischen und physischen Reaktionen (c) Peter Sturm, Universität Trier 14

15 Art of Game Programming Winter 2011 Serious Games! Spiele mit einem Zweck! Beispiele! Simulationen (Militär, Politik, Ausbildung,...)! Edutainment! Game-based Learning! Organizational-dynamic Games! Games for Health! Productivity Games!...! Hoher Entwicklungsaufwand (c) Peter Sturm, Universität Trier 15

16 Art of Game Programming Winter 2011 Das Ideal: Photorealistisch! Anwendung der relevanten physikalischen Gesetze! Lichtreflektion und brechung! Samt u.a.! Objekteigenschaften (Oberflächenbeschaffenheit)! Viele Freiheitsgrade bei der räumlichen Modellierung! Mengenorientierte Ansätze! Raytracing und Radiosity! 50 fps und mehr leider noch nicht erreichbar! aber man arbeitet dran! Norbert Kern William Fawcett & Povray Team (c) Peter Sturm, Universität Trier 16

17 Art of Game Programming Winter 2011 Die Realität! Einfache Beschreibung der Objektoberfläche! Durch Elementarobjekte wie z.b. Dreiecke! Flexiblere Ansätze erkennbar! Starke Einschränkungen bei Reflektions- und Refraktionsverhalten! Viele Schummeleien und Tricks! Texturen nähern Aussehen an! Zusätzliche Maps simulieren Lichteinfluß, Oberflächenbeschaffenheit, Reflektionsverhalten,! Ziel: Hinreichend realistische Wirkung mit vertretbarem Aufwand 3D-Hardware! GPUs sind extrem leistungsfähige SIMD-Prozessoren! Ziel: Arbeitsteilung mit CPU! Technologischer Fortschritt! 3dfx Vodoo 2 u.a.! State of the Art! Aktuelle GPUs von nvidia und ATI!! Professionelle Hardware (c) Peter Sturm, Universität Trier 17

18 Art of Game Programming Winter 2011! Schwerpunkt wird auf Managed DirectX mit OpenGL-Anteilen liegen! Visual Studio und C#! XNA! Visual Studio kostenfrei! XNA: DirectX SDK: OpenGL: Software Physik! Verhalten und Wechselwirkungen der dargestellten Objekte! Beschleunigung, Trägheit! Starrheit, Flexibilität, Deformierbarkeit! Zunehmend komplexere Schadensmodelle! Rückwirkungen auf Graphikdarstellung! Wesentliches Spielelement! Eigenständige Physical Processing Units! Weitere Entlastung der CPU! Konsolidierungsphase! Einigung auf einen Physik -Standard (c) Peter Sturm, Universität Trier 18

19 Art of Game Programming Winter 2011 Multiplayer! Spezialfall verteilter Systeme! Skalierbarkeit! Performanz! Robustheit! Konsistenz! Virtual Reality! Interessante Herausforderungen! Technisch! Kulturell! Ökonomisch! Menschlich KI! Nicht jeder will Online spielen! Gewinnchancen gegen Computergegner manchmal höher!! Leistungsfähigkeit der Computergegner beeinflußt stark die Spielqualität! Gleiche Ausgangsposition! Gleiche Bedingungen! Vielfalt in der Reaktion! Maß an Dummheit! (c) Peter Sturm, Universität Trier 19

20 Art of Game Programming Winter 2011! 3D-Echtzeitgraphik (3)! Mathematische Grundlagen! Das Ideal: Raytracing und Radiosity! DirektX und OpenGL! Drahtgitter, Texturen, Licht,! 3D Hardware, Rendering Pipeline, Shader,! Engines! Physik (1) Outline! Multiplayer (4)! Verteilte Simulation! Massive Multiplayer Online Games (insbesondere MORPGs)! KI = Intelligenz der Computergegner (1)! Weitere Themengebiete (3)! Michael Abrash Graphics Programming! Watt Policarpo 3D Games (Volume I und II)! Fernando bzw. Pharr GPU Gems 1, 2, und 3 nvidia Literatur (c) Peter Sturm, Universität Trier 20

21 Kunst der Spieleprogrammierung Winter 2011 Motivation! 3D-Graphik! Mathematik im 3D-Raum! Abstraktionen! Koordinatensysteme! Punkt (Vektor)! Gerade, Fläche, Körper! Affine Transformationen! Verschieben, Skalieren, Drehen, Scheren y! Leistungsaspekte! Gleitkommazahlen! Viele viele Gleitkommaoperationen! Hoher Optimierungsdruck z x (c) Peter Sturm, Universität Trier 1

22 Kunst der Spieleprogrammierung Winter 2011 Koordinationsysteme! Bezugssysteme! Ursprung und orthogonale Richtungsvektoren! Objektposition relativ zum Ursprung! Absolutes Koordinatensystem! Relatives Koordinatensystem! Objektspezifischer Ursprung! Linkshändige und rechtshändige Modelle Punkte! Punkte sind relativ zu einem Koordinatensystem! Abstand vom Ursprung! Punkt: 3-Tupel! Operationen auf Punkte! Verschieben (Translation)! Skalierung! Rotation z & a# $! $ b! $! % c " b y a c x (c) Peter Sturm, Universität Trier 2

23 Kunst der Spieleprogrammierung Winter 2011 Affine Transformationen! Translation! Verschiebung bzgl. den Grundachsen! Mathematisch: Addition! V = V+D & x # & tx# & x + tx# $! $! $! $ y! + $ ty! = $ y + ty! $! $! $! % z " % tz" % z + tz "! Skalierung! Abstand zum Ursprung kleiner oder größer! Mathematisch: Multiplikation! V = S " V & sx# & x # & sx' x # $! $! $! $ sy! ' $ y! = $ sy' y! $! $! $! % sz" % z " % sz' z "! Rotation! Drehung (meist um eine Grundachse)! Mathematisch: Winkelfunktionen & x ' cos( ) ( y ' sin( ) #! V = R " V $!! Beispiel: Drehung im Z-Achse: $ x ' sin( ) + y *cos()! $! % z " Wünschenswert! Einheitliche Datenstruktur für alle affinen Transformationen! Matrizenoperationen! Homogenes Koordinatensystem! 4-dimensionale Koordinaten! Punkt = V(x, y, z, w) mit a = a/w und w!0! Gängig ist w=1! Transformationsmatrizen: 4x4 & x # $! $ y! $ z! $! % 1 " (c) Peter Sturm, Universität Trier 3

24 Kunst der Spieleprogrammierung Winter 2011 (c) Peter Sturm, Universität Trier 4 Translation! Einfache Verschiebungsmatrix! Operation!!!!! " # $ $ $ $ $ % & tz ty tx!!!!! " # $ $ $ $ $ % & '!!!!! " # $ $ $ $ $ % & =!!!!! " # $ $ $ $ $ % & ' ' ' z y x tz ty tx z y x Skalierung! Skalierungsmatrix! Operation!!!!! " # $ $ $ $ $ % & sz sy sx!!!!! " # $ $ $ $ $ % & '!!!!! " # $ $ $ $ $ % & =!!!!! " # $ $ $ $ $ % & ' ' ' z y x sz sy sx z y x Uniform: sx=sy=sz

25 Kunst der Spieleprogrammierung Winter 2011 (c) Peter Sturm, Universität Trier 5 Rotation! Nur über jeweils eine Grundachse! Alles andere geht auch, ist aber Brain Twister!! Grundmatrizen:!!!!! " # $ $ $ $ $ % & ' = ) cos( ) sin( 0 0 ) sin( ) cos( ( ( ( ( Rx!!!!! " # $ $ $ $ $ % & ' = ) cos( 0 ) sin( ) sin( 0 ) cos( ( ( ( ( Ry!!!!! " # $ $ $ $ $ % & ' = ) cos( ) sin( 0 0 ) sin( ) cos( ( ( ( ( Rz Matrizen zusammenfassen! Rotation und dann Verschiebung! Beispiel! Drehung um 45 Grad bzgl. X-Achse! Verschiebung um -80 bzgl. Y-Achse! Achtung: Erste Operation = Letzte Matrix! M2"M1: Erste Transformation ist M1!!!!! " # $ $ $ $ $ % & ' ' =!!!!! " # $ $ $ $ $ % & ' (!!!!! " # $ $ $ $ $ % & '

26 Kunst der Spieleprogrammierung Winter 2011 Konstruktion eines lokalen Systems!!! Matrizenoperationen bzgl. Koordinatensystem (Welt) Aufbau des lokalen Systems: 1.! Verschieben des Zentrums (Pivot) zum Ursprung 2.! Gewünschte affine Transformation ausführen 3.! Verschiebung zurück an den Ausgangspunkt Resultat: V2"Taff"V1 Matrixoperationen nicht kommutativ! Beispiel: Teekanne! Translation: Verschiebung an Y-Achse um -80! Rotation: Drehung an X-Achse um -45 Grad! Zuerst Translation, dann Rotation! Zuerst Rotation, dann Translation (c) Peter Sturm, Universität Trier 6

27 Kunst der Spieleprogrammierung Winter 2011 Live! T, dann R! R, dann T Weitere sinnvolle Funktionen! Vektoraddition! Kräftparallelogramm V W! Länge eines Vektors V+W 2 2 V = x + y +! Normalisierter Vektor: z 2 U = V V (c) Peter Sturm, Universität Trier 7

28 Kunst der Spieleprogrammierung Winter 2011 Normalvektor! Normale zu einer Oberfläche wird häufig benötigt N V! Kreuzprodukt: N = V x W! Bei Kurven muß erst die Tangentialebene bestimmt werden W & vy ' wz ( vz ' wy # $! N = $ vz ' wx ( vx ' wz! $! % vx ' wy ( vy ' wx" Skalarprodukt! Hilfsmittel zur Winkelbestimmung zwischen Vektoren x = V! W = vx! wx + vy! wy + vz! wz! Eigenschaft! x>0 wenn #<90 Grad! x=0 wenn #=90 Grad! x<0 wenn #>90 Grad! Winkelbestimmung zwischen V und W V! W cos(")= V! W (c) Peter Sturm, Universität Trier 8

29 Kunst der Spieleprogrammierung Winter 2011 Grundidee: Raytracing! Direkte Umsetzung des Sehens! Auge! Projektionsfläche (Monitor)! Szene (c) Peter Sturm, Universität Trier 1

30 Kunst der Spieleprogrammierung Winter 2011 Raytracer! Beschreibung der darzustellenden 3D-Szene! CSG: Constructive Solid Geometry! Beschreibung der Materialien! Farbe! Reflektionseigenschaften! Refraktionseigenschaften! Oberflächenstruktur! Extras: Rauhheit,! Lichtquellen! Kameraposition Verwendete Software! Povray (Persistence of Vision, Binaries und Sourcen für Windows, Linux,! Immer noch aktuell Version 3.6?! 10 MB (Windows)! 8 MB (Linux)! Moderne Alternative! Blender! 3D Studio Max!... (c) Peter Sturm, Universität Trier 2

31 Kunst der Spieleprogrammierung Winter 2011 CSG! Volumetrische Grundobjekte! Quader, Kugel, Zylinder,! Mengentheoretische Konstruktionsoperationen! Vereinigung! Schnitt! Differenz Finite Solid Primitives! Gängige Elemente! Box! Cone! Cylinder! Prism! Sphere! Torus! Text! Exoten! Blob! Height Field! Julia Fractal! Lathe! Superquadric Ellipsoid! Surface of Revolution (c) Peter Sturm, Universität Trier 3

32 Kunst der Spieleprogrammierung Winter 2011 Box Cone (c) Peter Sturm, Universität Trier 4

33 Kunst der Spieleprogrammierung Winter 2011 Cylinder Sphere (c) Peter Sturm, Universität Trier 5

34 Kunst der Spieleprogrammierung Winter 2011 Superquadric Ellipsoid Infinite Solid Primitives: Plane (c) Peter Sturm, Universität Trier 6

35 Kunst der Spieleprogrammierung Winter 2011 Mesh! Objektbeschreibungen auf der Basis von Dreiecken Mesh: Beispiel mesh { triangle { <-3,2,0> <-3,1,5> <1,1,5> } triangle { <-3,2,0> <-2,0,-4> <3,0,-4> } triangle { <-3,1,0> <1,0,5> <3,0,-4> } triangle { <-3,2,0> <-3,1,0> <1,1,5> } texture { MyTexture } } (c) Peter Sturm, Universität Trier 7

36 Kunst der Spieleprogrammierung Winter 2011 Anwendung von Meshes! 3D-Echtzeitgraphik basiert aktuell auf Dreiecken! Beschleunigerkarten unterstützen gezielt Dreiecke! Siehe DirectX und OpenGL (nächste Woche)! Identische Arbeitsschritte! Übertragung einer Szene an Graphikkarte! Generierung einer Povray-Beschreibung aus Dreiecken! Erweitere Definition: mesh2! Anlegen von Knotenvektoren! Definition der Dreiecke über Indizes! Einsparungen bei zusammenhängenden Meshes! Knoten tauchen immer in mehreren Dreiecken auf CSG: Beispiel 1! Beschreibung: cylinder { <0,1,0> <0,6,0> 1 texture { MyTexture } }! Weitere Bestandteile! Zwei Lichtquellen! Reflektiver Untergrund! Kamera (c) Peter Sturm, Universität Trier 8

37 Kunst der Spieleprogrammierung Winter 2011 Union CSG: Beispiel 2!! Kugeln an Zylinderenden hinzufügen Beschreibung: #declare Sol = union { cylinder { <0,1,0> <0,5,0> 0.5 } sphere { <0, 1, 0> 1 } sphere { <0, 5, 0> 1 } texture { MyTexture } } object { Sol } object { Sol translate <0,-3,0> rotate <90,0,0> translate <0,3,0> } (c) Peter Sturm, Universität Trier 9

38 Kunst der Spieleprogrammierung Winter 2011 Difference Intersection (c) Peter Sturm, Universität Trier 10

39 Kunst der Spieleprogrammierung Winter 2011 #declare Sol = union { cylinder { <0,1,0> <0,5,0> 0.5 } sphere { <0, 1, 0> 1 } sphere { <0, 5, 0> 1 } texture { MyTexture } } CSG: Beispiel 3 #declare TwoSol = union { object { Sol } object { Sol translate <0,-3,0> rotate <90,0,0> translate <0,3,0> } } #declare HalfSphere = intersection { sphere { <0,3,0> 3 } box { <0,0,-3> <-3,6,3> } } difference { object { HalfSphere } object { TwoSol } texture { MyTexture } } Object Modifiers! Material-, Reflektions, Refraktionseigenschaften etc. (c) Peter Sturm, Universität Trier 11

40 Kunst der Spieleprogrammierung Winter 2011 Pigment! Farben und Farbmuster! Einfache Farbe! texture { pigment { color rgb<1,0,0> } } Image Map (c) Peter Sturm, Universität Trier 12

41 Kunst der Spieleprogrammierung Winter 2011 Finish! Polieren der Objektoberfläche! Eigenleuchten (Ambient)! Reflektionseigenschaften! Lichtstreuung! Brillianz! Widerschein von Lichtquellen (Phong, Specular, Diffuse)! Eingeschränkt Oberflächenstrukturen (Roughness) Finish: Beispiele #declare MyTexture = texture { pigment { color Red } finish { ambient 0.2 phong 0.5 phong_size 10 reflection { 0.01 } diffuse 0.4 // specular 0.5 // roughness 0.5 // metallic 0.5 reflection Green // irid { 0.2 } // Seifenblasenfilm } } (c) Peter Sturm, Universität Trier 13

42 Kunst der Spieleprogrammierung Winter 2011 Brechung! Interior-Eigenschaften bei Objekten! ior = Brechungsindex! 1.0 Luft! 1.33 Wasser! 1.5 Glas! 2.4 Diamand! Zusätzliche Farbeigenschaft! Filter! Trasmit Weitere Möglichkeiten bzgl. Oberfläche! Trick zur Veränderung der Oberflächenbeschaffenheit! Störungen bzgl. Der Oberflächennormale! Parameter! Bump Map! Objektform ändert sich dadurch nicht! Diskrepanz zwischen Silhouette und scheinbar rauher Oberflächenstruktur (c) Peter Sturm, Universität Trier 14

43 Kunst der Spieleprogrammierung Winter 2011 Bumps: Beispiel Lichtquellen (c) Peter Sturm, Universität Trier 15

44 Kunst der Spieleprogrammierung Winter 2011 Spot Light Camera (c) Peter Sturm, Universität Trier 16

45 Kunst der Spieleprogrammierung Winter 2011 Radiosity Radiosity! Traditionelle Raytracer bestimmen die Helligkeit an jedem Punkt über! Diffuse (Lichtzugewandte Seite wird heller)! Specular (Widerschein der Lichtquelle)! Reflektion! Ambient (Grundhelligkeit)! Radiosity! Ambient wird genauer berechnet! In welchem Maß und und mit welchen Farben strahlen benachbarte Objekte (c) Peter Sturm, Universität Trier 17

46 Kunst der Spieleprogrammierung Winter 2011 Radiosity: Beispiel Normal: 5 Sekunden Radiosity: 35 Sekunden (c) Peter Sturm, Universität Trier 18

47 Kunst der Spieleprogrammierung Winter 2011 Einordnung! Raytracing als Darstellungsmethode für 3D-Echtzeit unrealistisch! Enorm hoher Aufwand O (# Pixel!# Objekte!# Lichtquellen)! Ausgangspunkt 3D-Szene! Welche Objekte sind auf dem Bildschirm sichtbar?! Ggf. Clipping! Aufwand hängt von Szenenkomplexität und Detaillierung ab O (# Objekte!# Lichtquellen) (c) Peter Sturm, Universität Trier 1

48 Kunst der Spieleprogrammierung Winter D-Pipeline!! Photorealismus häufig unnötig Vereinfachung! Keine exakte Lichtberechnung! Keine Reflektionen/Refraktionen 3D-Modell Verschiebungen Drehungen Bewegungen Clipping Triangulation!!! Tricks Reine Softwarelösung! CPU berechnet alle Schritte! Leistungsfähige CPU notwendig Hardware-Beschleunigung! Wesentliche Schritte übernimmt Spezial-Hardware Licht und Schatten 2D-Projektion Finish Shading Z-Buffer Texturen Perspektivenkorrektur Nebel Alpha-Blending... Darstellung 4.1 Aufgaben der CPU (c) Peter Sturm, Universität Trier 2

49 Kunst der Spieleprogrammierung Winter D-Modellierung! Beschreibung der 3D-Szene! Volumenorientiert (CSG)! Elementarvolumina: Quader, Zylinder, Kugel,...! Mengenoperationen! Flächenorientiert! Patchwork! Reguläre Flächen! Polygone! Dreiecke! Freiformflächen! Bezierkurven! Splines Retained- und Immediate-Mode! 3D-Laufzeitumgebungen unterscheiden zwei Modi! Retained Mode! 3D-Modell wird in der Hardware gespeichert und verwaltet! Zugriff ähnlich einer Hauptspeicher-DB! Implizite Umsetzung! Immediate Mode! 3D-Modell Bestandteil der Anwendung! Aufruf aller notwendigen Zeichenoperationen! Explizite Umsetzung! OpenGL, DirectX realisieren nur Immediate Mode! Retained scheint aber anstrebenswertes Ideal (c) Peter Sturm, Universität Trier 3

50 Kunst der Spieleprogrammierung Winter 2011 (c) Peter Sturm, Universität Trier 4 2. Tessellation / Triangulation! 3D-Hardware unterstützt nur bestimmte Elementarflächen! Z.B. nur Dreiecke! Umwandlung des 3D-Modells in Elementarflächen! Bei regulären Flächen einfach! Triangulation der Freiformflächen aufwendiger! Hohe Auflösung = Viele Dreiecke = Hoher Rechenaufwand 3. 2D-Projektion! Sichtbarkeit einzelner Dreiecke?! Ort in der 2D-Projektion?! Lösung eines linearen Gleichungssystems für jeden Punkt der Szene!! und ": Ort und Sichtbarkeit! # Tiefeninformation! Effizienz des Lösungsverfahrens! Faktor in der Laufzeit! Probleme! Teilweise sichtbare Dreiecke! e innerhalb eines Objekts!!! " # $ $ $ % &!!! " # $ $ $ % & '!!! " # $ $ $ % & +!!! " # $ $ $ % & =!!! " # $ $ $ % & ( +!!! " # $ $ $ % & ( +!!! " # $ $ $ % & z y x z y x z y x z y x z y x z y x e e e p p p p p p w w w v v v o o o ) * + p e o w v! " #

51 Kunst der Spieleprogrammierung Winter 2011 Schnittstelle CPU und GPU! Leistungsengpaß! Benötigter Speicherdurchsatz = n! 3! Punkt! n Anzahl der Dreiecke! Punktgröße: 3 Floats/Double, Farbinformation,! Fps: Frames per Second! Beispiel: n=20000, Punkt=3*8 Byte, 2 Byte Zusatz, 50 fps! Ca. 85 Mbyte/s Durchsatz TP! fps! Konsequenz! Unsichtbare Dreiecke vorher identifizieren! Redundanzen minimieren 4.2 Aufgaben der 3D-Hardware (c) Peter Sturm, Universität Trier 5

52 Kunst der Spieleprogrammierung Winter Finish! Z-Buffer! Tiefeninformation! Dreiecksflächen füllen! Farbe! Texturen! Schatten! Transparenzeffekte! Nebel! Anti-Alias! Kantenglättung! Tiefeninformation: Z-Buffer! Einfaches Beispiel: Dreiecke parallel zur Projektionsfläche! Auflösung des Z-Buffers (16 oder 32 Bit) #=7 #=2 #= (c) Peter Sturm, Universität Trier 6

53 Kunst der Spieleprogrammierung Winter 2011 Texturen! Bekleben der Dreieckfläche! Wiederholung derselben Textur bei großer Fläche (Tiling)! Große Texturen wünschenswert! Viel Speicher! Komprimierung! Photos häufig Ausgangspunkt = +! Perspektivische Korrektur abhängig von Tiefeninformation Texturen 2! Mip-Mapping! Unterschiedlich aufgelöste Texturen! Wahl entfernungsabhängig! Bump Mapping! Textur ist Höhenfeld! Kombination mit Shading! Rauhe Oberfläche! Environmental Mapping! Texture wird dynamisch aus der Umgebung berechnet! Spiegelungen (c) Peter Sturm, Universität Trier 7

54 Kunst der Spieleprogrammierung Winter 2011 Schatten! Licht...! Lichteinfluß auf Fläche berechnet CPU! Zusätzliche Texturen bestimmen Lichtwirkung! Transparente Leuchteffekte durch Alpha-Blending!... Und Schatten! Einzelne Dreiecke sind abgedunkelt! Einfaches Shading! Einheitliche Abdunklung! Gourad Shading! Iterative Zunahme der Abdunklung! Ausgangspunkt Beispiel: Spheres (c) Peter Sturm, Universität Trier 8

55 Kunst der Spieleprogrammierung Winter 2011 Transparenz! Überlagerung zweier Bilder! Hintergrundbild! Eingeblendetes Vordergrundbild P HG P VG! Alpha-Blending! Alphawert pro Pixel P = P + "! P Gesamt HG VG Alpha Ausgabe! Sauberer Wechsel zwischen Einzelbildern! Double-Buffer, Triple-Buffer,! Steuerung über VSYNC (c) Peter Sturm, Universität Trier 9

56 Kunst der Spieleprogrammierung Winter 2011 Trends! Ziel Auslastung CPU und GPU jeweils 100%! Trend! Aktuell mehr Steigerungspotential in der GPU! Parallelisierbarkeit der Abläufe! Verlagerung der Schnittstelle nach oben! z.b. Lichtquellen in HW (zuerst 8, )! Ansätze für Retained Mode! Komplexere geometrische Grundstrukturen! Splines,! Ausführliche Diskussion im Kapitel Hardware (c) Peter Sturm, Universität Trier 10

57 Die Kunst der Spieleprogrammierung Winter 2011! Echtzeit-Raytracing! Modell und Materialeigenschaften auf Raytracer! Kontinuierliche Darstellung! Polygon-Rendering! CPU wählt darzustellende Polygone aus! Render Pipeline Ansätze (c) Peter Sturm, Universität Trier 1

58 Die Kunst der Spieleprogrammierung Winter 2011 REALTIME RAYTRACING Echtzeit Raytracing! OpenRT Projekt! Universität Saabrücken, Andreas Dietrich! Kommerzielle Projekte! OptiX, nvidia! Intel auf Larrabee (c) Peter Sturm, Universität Trier 2

59 Die Kunst der Spieleprogrammierung Winter 2011 POLYGON RENDERING! Ursprung im professionellen Bereich! CAD und Filmentwicklung! Random Scan Display Processing Unit! Silicon Graphics war Marktführer! Ganze Rechner sind Graphikkarte! Siegeszug von 3dfx! Beschleuniger-Hardware für den PC! Aktuelle Firmen! nvidia! ATI Motivation (c) Peter Sturm, Universität Trier 3

60 Die Kunst der Spieleprogrammierung Winter 2011 Motivation! Aufgabenverteilung CPU-GPU! Darstellungsqualität erzwingt kontinuierliche Erhöhung der Polygonanzahl! Parallelisierungsgrad nimmt innerhalb der Pipeline zu! Anwendungsspezifische Programmierbarkeit CPU Speicher 2D-Projektion Vertex Shader Finish Pixel Shader Vollbildfilter (FSAA, etc.) Rendering Pipeline (c) Peter Sturm, Universität Trier 4

61 Die Kunst der Spieleprogrammierung Winter 2011 Aktuelles im professionellen Bereich! SGI (2002)! Onyx 3000 InfiniteReality4! Bis zu 16 Pipelines! Bis zu 128 Prozessoren! 1 TB Speicher! 716 GB/s I/O Specs (c) Peter Sturm, Universität Trier 5

62 Die Kunst der Spieleprogrammierung Winter 2011! Siegeszug beginnt mit der Voodoo 1 (1996)! 50 MHz Taktfrequenz! 2 bis 4 MByte Videospeicher! Voodoo 2 (1998)! Träume werden wahr! Voodoo 3 und danach wenig erfolgreich! nvidia kauft 3dfx (Nov 2000) 3dfx Chips von 3dfx (c) Peter Sturm, Universität Trier 6

63 Die Kunst der Spieleprogrammierung Winter dfx Voodoo 2! 2-4 Prozessoren pro Karte! 1 Pixelprozessor! 1-3 Texturprozessoren! 90 MHz Taktfrequenz! Mbyte Speicher! 2.1 Gbyte Speicherbandbreite (intern) 3dfx Voodoo 2: Zahlen! Leistungsdaten! 3 Millionen Dreiecke/s (gemessen: 25 Pixel Dreiecke)! 90 Mpixel/s! 180 Mpixel/s im Doppelpack (SLI)! Maximal 1024x768 Pixel Auflösung! 24 Bit Farben (Ausgabe 16 Bit Dithered)! 16 bpp Z-Buffer (c) Peter Sturm, Universität Trier 7

64 Die Kunst der Spieleprogrammierung Winter dfx Voodoo 2: Architektur! Ziel: Möglichst viele Operationen pro Pixel in einem Zyklus Speicher 2-4 MB TMU Speicher 4 MB PCI-Bus Pixelfx TMU nc Speicher 4 MB 3dfx Voodoo 2: SLI Speicher 2-4 MB TMU Speicher 4 MB! Scan Line Interface! Gerade Zeilen! Ungerade Zeilen PCI-Bus Pixelfx TMU nc Speicher 4 MB! 2 PCI-Slots! Traum jedes Spielers (Damals)! Schnell! Vergleichsweise Teuer Speicher 2-4 MB Pixelfx TMU TMU Speicher 4 MB Speicher 4 MB nc (c) Peter Sturm, Universität Trier 8

65 Die Kunst der Spieleprogrammierung Winter 2011 Die Graphik-Pipeline TMU2 TMU1 Texture Combine Unit TMU2 Linear Frame Buffer Write Iterated RGBA Constant RGBA Texture Combine Unit Frame Buffer Special Effects Unit Color & Alpha Combine Unit Alpha Test Depth Test (Z/W Buffer) Fog Alpha Blend 3dfx Voodoo 3 und danach! 3dfx ist seiner Zeit voraus und wird zu ambitioniert (c) Peter Sturm, Universität Trier 9

66 Die Kunst der Spieleprogrammierung Winter dfx Voodoo 6! nvidia RivaTNT! 1 Prozessor! 90 Mhz Taktfrequenz! 7 Millionen Transistoren! 12 Kbyte Cache! 16 Mbyte Speicher! 128 Bit Speicherbreite! 1.8 Gbyte Speicherbandbreite! Leistungsdaten! 6 Millionen Dreiecke/s! 180 Mpixel/s Füllrate! Maximal 1920x1200 Auflösung! 24 Bit Farben! 16/24 bpp Z-Buffer PCI-Bus Prefetch Scatter/Gather Virtual DMA Vertex Cache Setup & Pixel Processor Light & Effects Processor Setup & Pixel Processor Light & Effects Processor Constant Velocity FIFO Texture Cache (c) Peter Sturm, Universität Trier 10

67 Die Kunst der Spieleprogrammierung Winter 2011 GPUs (Anfang 2003) GPUs (2003) nvidia geforce fx (c) Peter Sturm, Universität Trier 11

68 Die Kunst der Spieleprogrammierung Winter 2011 Flop 2003: nvidia NV30! Extreme Wärmeentwicklung! Spezielles Lüfterdesign (Föhn)! O-Ton nvidia: Lautstärke kein Problem. Power Gamer spielen allemal mit Kopfhörer (c) Peter Sturm, Universität Trier 12

69 Die Kunst der Spieleprogrammierung Winter 2011 Vertex- und Pixel-Shader! Mehr und Besser GPUs 2005! nvidia! GeForce 7800 Ultra! ATI! Radeon X1800 (c) Peter Sturm, Universität Trier 13

70 Die Kunst der Spieleprogrammierung Winter 2011 nvidia! 320 Millionen Transistoren! Shader Version 3.0! Programme können beliebig groß werden! 8 Vertex Shader! 24 Pixel Shader! 512 MB GTX Variante erhältlich (650 Euro 12/05)! bis zu 550 MHz GPU-Takt! bis zu 1.7 GHz Speichertakt (DDR 3)! 256 Bit Speicherinterface Architektur Geforce6 und 7 Jetzt 8 Vertex Prozessoren Jetzt 24 Pixel Prozessoren Und 24 Z Units aus GPU Gems 2: (c) Peter Sturm, Universität Trier 14

71 Die Kunst der Spieleprogrammierung Winter 2011 Vertex Prozessor Pixel Prozessor! Arbeiten auf einem 4-Pixel-Quadrat (Quad)! Gefilterter Texture-Zugriff! Bilinear, Trilinear, Anisotroph! Jedes Quad wird mit GPU-Takt durch beide Units geroutet! 8 mathematische Operation pro Takt! 4 mathematische Operation und Texture fetch pro Takt (c) Peter Sturm, Universität Trier 15

72 Die Kunst der Spieleprogrammierung Winter 2011 ATI Radeon X1800 X1800 Architektur (c) Peter Sturm, Universität Trier 16

73 Die Kunst der Spieleprogrammierung Winter 2011 Vergleich Anzahl der integrierten Pixel-Pipelines wächst Trends! Vereinheitlichung der Shader! Unified Vertex and Pixel Shader in WGF 2.0 (DirectX 10)! Unified CPU und GPU Prozessoren?! Multiprozessoren (Diskret oder auf dem CHip)! siehe z.b. IBM Cell Prozessor! CPU-Interface weiter beschleunigen (PCI Express)! Sehr breiter Speicherbus! 256 Bit gängig! Eklat nvidia mit 128 Bit ganz schnellem Speicher! Freiformflächen statt Dreiecke? (c) Peter Sturm, Universität Trier 17

74 Die Kunst der Spieleprogrammierung Winter 2011 GPUs 2007! nvidia! GeForce 8800 GTX! ATI! Radeon HD 3000 Serie Graphik! NVIDIA G80 Graphikprozessor! Transistoren! 575 MHz Taktfrequenz! 1.3 GHz Shadertakt! Speicher! 786 MB DDR3! 900 MHz Taktfrequenz! 384 Busbreite! 128 Unified Shader (DirectX 10)! Preis: ca. 600 Euro (c) Peter Sturm, Universität Trier 18

75 Die Kunst der Spieleprogrammierung Winter 2011 Kenngrößen TOP 500 (c) Peter Sturm, Universität Trier 19

76 Die Kunst der Spieleprogrammierung Winter 2011 NVIDIA CUDA! Compute Unified Device Architecture 197! Mathematische / Physikalische Simulationen o.ä.! Jeweils 16 Prozessoren haben gemeinsamen Cache (8800 GTX)! Spezifische Compiler ! Tabelle rechts:! Beschleunigungsfaktor gegenüber Core 2 Duo E * 8800 GTX = Doppelter Spaß!! und viel Geld (~ 1200 Euro nur Graphik)! zzgl Watt Netzteil (c) Peter Sturm, Universität Trier 20

77 Die Kunst der Spieleprogrammierung Winter 2011 Kenngrößen ATI Radeon HD 3xxx (c) Peter Sturm, Universität Trier 21

78 Die Kunst der Spieleprogrammierung Winter 2011 Speicher-Interface TRENDS (c) Peter Sturm, Universität Trier 22

79 Die Kunst der Spieleprogrammierung Winter 2011 nvidia Fermi Intel Larrabee! Larabee Core! x86, 2 GHz (?), In-Order Execution, 4-Fach HT! Lokaler L1 Cache! 16-fach SIMD! Virtual Memory! Multi-Tasking! 64 Gflop! 32 Cores! Unified L2 Cache (partitioniert)! 2 TeraFlop! Ring Interconnect Fixed Functions CPU CPU CPU CPU L2 Cache CPU CPU CPU CPU GB RAM µos Speicher Controller OS Larrabee Karte PCIe (c) Peter Sturm, Universität Trier 23

80 Die Kunst der Spieleprogrammierung Winter 2011 Fragen? c t - Schlagseite (c) Peter Sturm, Universität Trier 24

81 6. 3D Programming! DirectX! Unmanaged (C++)! Managed (C#)! Fixed-function Pipeline! Shader! OpenGL! Microsoft XNA Zugänge (c) Peter Sturm, Universität Trier 1

82 DIRECTX DirectX! Laufzeitunterstützung für multimediale Anwendungen! Direkter Zugang zu HW-Funktionalität! Trotzdem hohe Kompatibilität! Eigenentwicklung von Microsoft! In Zusammenarbeit mit diversen HW-Herstellern! Aushandeln der Funktionalität! Seit DirectX 7.0! TnL HAL (Transform and Lightning) Hardware Abstraction Layer HAL Hardware DirectX Hardware Emulation Layer HEL (c) Peter Sturm, Universität Trier 2

83 ! DirectX Graphics! DirectDraw: 2D-Graphiken! Direct3D (D3D): 3D-Darstellung! DirectInput: Eingabegeräte! DirectPlay: Networking (Multiplayer) Funktionsumfang! DirectSetup: Installation von DirectX-Anwendungen! DirectMusic: Alles was mit Ton zu tun hat! DirectSound: (Low-Latency Sound)! DirectShow: Streaming Media Historie! Erste offizielle Version DirectX 5.0! TnL mit Version 7.0! GPU übernimmt zunehmend höhere Aufgaben! Aktuell Version 9.0c! Managed-Zugang! Neue Möglichkeiten bei den Shadern! Version 10 (Vista)! Unified Shader! Version 11 (7) (c) Peter Sturm, Universität Trier 3

84 DirectX SDK! Wo, Wie groß, Installation! 550MB aktuelles SDK (August 2009)! 18 MB Help für Visual Studio.NET! Dokumentation! C/C++ ist Teil des SDK! C# (allg. managed) war mal!! Viele Beispiele! Sample Browser Tools: dxdiag! DirectX-Installation: dxdiag (c) Peter Sturm, Universität Trier 4

85 Tools: capsviewer! Darstellung der Capabilities Tools: Effect Viewer (c) Peter Sturm, Universität Trier 5

86 Tools: MeshView! D3DSpy! Beobachten der Direct3D-Funktionsaufruf (lokal und remote)! DirectPlay Network Simulator! DirectX Error Lookup! Hexcode! Textuelle Beschreibung! Texture Tool! DMO Tester (DirectX Media Objects)! Streaming etc.! Force Feedback Editor Weitere Tools (c) Peter Sturm, Universität Trier 6

87 Die Render-Pipeline in D3D! Klassische Grundstruktur! Fixed Function Pipeline! Programmable Pipeline Grundsätzliches! Initialisierung! Wahl der gewünschten Hardware! Wahl des Treibers! Konfiguration (Vollbild, )! Beschreibung der 3D-Szene! Nutzung vorhandener Primitive (Box, Sphere, )! Nutzung der Basisabstraktionen (Dreieck, )! Wiederholtes Zeichnen der Frames! Eingebundenen in die Spielsimulation! Game-Loop (c) Peter Sturm, Universität Trier 7

88 Namespaces Microsoft.DirectX (c) Peter Sturm, Universität Trier 8

89 Devices! Hardware! Unterstützung durch Hardware! Software! Referenz! Reine Software-Implementierung! Betonung der Funktionalität! Effizienz nebensächlich! Meist nur auf einem Entwicklungssystem zugänglich Zugang zu einem Device! Manager-Objekt (manager)! Suche nach geeignetem Adaptor! Adapator = eigene HW! Z.B. Dual-Head-Karte hat zwei Adaptoren! Property: AdapterListEnumerator (Adaptors)! Durchlaufen und nach Adapter mit gewünschten Eigenschaften suchen! Capabilities! Stimmen Fähigkeiten des Geräts mit meinen Anforderungen überein? (c) Peter Sturm, Universität Trier 9

90 Knotenverarbeitung! Primitive setzen sich aus Einzelpunkten zusammen! Dreiecke (3 Punkte)! Polygonzug! Box (8 Punkte)! Punkte werden häufig mehrfach verwendet! z.b. jeder Punkt einer Box taucht in 6 Dreiecken auf! Wo werden Knoten gespeichert und bearbeitet?! SoftwareVertexProcessing: Standardisiert! HardwareVertexProcessing: Kartenabhängig! MixedVertexProcessing Primitive! Knotenpuffer (Vertex Buffer)! p1, p2, p3, p4, p5, p6,... p2 p3! Interpretation:! Point List: p1, p2, p3,! Line List: (p1,p2), (p3,p4), p1! Line Stripe: (p1,p2), (p2,p3), (p3,p4),! Triangle List: (p1,p2,p3), (p4,p5,p6),! Triangle Stripe: (p1,p2,p3), (p2,p3,p4), (p3,p4,p5),! Triangle Fan: (p1,p2,p3),(p1,p3,p4), (p1,p4,p5), p5 p4 p6 (c) Peter Sturm, Universität Trier 10

91 Allgemeine Vorgehensweise! Anlegen und Füllen eines VertexBuffer! Variable Informationen pro Knoten! VertexBuffer mit Device verbinden! device.setstreamsource()! Zeichnen! device.beginscene() device.drawprimitives(type,firstvertex,#vertex) device.endscene() device.present() // Darstellen Welche Informationen pro Knoten! Spezielle Klasse CustomVertex (c) Peter Sturm, Universität Trier 11

92 SHADER Historie! DirectX = Konzept zur allgemeinen Nutzung hardwarebeschleunigter Dienste! Standardisierung! Effizienz! Lastbalancierung! Kontrolliert HW-Bereiche hoher Innovation! Bis Version 7 Erweiterung der Fixed-Function-Pipeline! Aber mit Funktionsverlagerung in die GPU (Transform and Lighting)! Erste programmierbare Shader ab Version 8! Starke Restriktionen! Mit Version 10 werden GPUs zu echten SIMD-Rechnern (c) Peter Sturm, Universität Trier 12

93 Umfeld CPU GPU Core Core Shader Shader Hauptspeicher Videospeicher Einbettung Pipeline Vertex Shader Geometry Shader Clipping Screen Mapping Triangle Setup Triangle Traversal Pixel Shader Merger! Vertex Shader! Modifikationen auf Knotenbasis! Geometry Shader! Modifikationen auf Primitivbasis! Pixel Shader! Modifikationen auf Pixelbasis (c) Peter Sturm, Universität Trier 13

94 Capabilities SM 2.0/2.X SM 3.0 SM 4.0 Einführung DX 9.0, 2002 DX 9.0c, 2004 DX 10, 2007 VS Instruktionsslots 256 >= VS Max. Schritte beliebig PS Instruktionsslots >= 96 >= 512 >= PS Max. Schritte >= beliebig Temporäre Register >= VS Konstantenregister >= 256 >= * 4096 PS Konstantenregister * 4096 Flow Control Optional Ja Ja VS Texturen Nein * 512 PS Texturen * 512 Integer Support Nein Nein Ja VS Input Register PS Output Register Vertex Shader! Kleine Assemberprogramme! Anbindbar an einen Vertex Stream! Ausführung für jeden Vertex eines Streams! Vordefinierte Input- und Hilfsregister! Ergebnis steht in vordefinierten Ausgaberegistern! Repertoir an Shader-Instruktionen (c) Peter Sturm, Universität Trier 14

95 Input- und Output-Register! Input! Output Instruktionen (c) Peter Sturm, Universität Trier 15

96 Beispiel Pixel Shader! Kleine Assemblerprogramme! Können bei der Bestimmung der Pixelfarbe intervenieren! Grobarchitektur ähnlich Vertex Shader! 2 Instruktionstypen! Arithmetische Instruktionen! Texturinstruktionen (c) Peter Sturm, Universität Trier 16

97 Register Instruktionslimits (c) Peter Sturm, Universität Trier 17

98 Arithmetische Instruktionen Texture Instructions (c) Peter Sturm, Universität Trier 18

99 C for graphics:! Open Source! High-Level Shading Language! Ersetzt Assembler für Vertex- und Pixel-Shader! entstand in Zusammenarbeit mit Microsoft! unterstützt DirectX 9 HLSL! Vorteile! Cross-API (DirectX und OpenGL)! Cross-Plattform (Windows, Linux, Mac OS) Funktionsweise!!! Entwicklung der gewünschten Shader Digital Content Creation (DCC)! z.b. mittels Maya, 3ds max etc.! Spezielle Editoren! Spieleprogrammierung Übersetzung durch Cg-Compiler! Zum Übersetzungszeitpunkt der Anwendung! Zur Laufzeit der Anwendung (c) Peter Sturm, Universität Trier 19

100 Programmiermodell 3D-Anwendung Spiel 3D-API DX oder OGL CPU-GPU Boundary GPU Frontend Primitive Assembly Rasterization & Interpolation Raster Operations Programmable Vertex Processor Programmable Fragment Processor Cg Language Profiles! Gezielte Einschränkung von Cg auf spezifische Hardware- und Plattformeigenschaften! Unterstützte Profile! DirectX 9 Vertex- und Pixel-Shader (Versionen 2.x)! OpenGL ARB Vertex- und Fragment-Programs! OpenGL NV30 Vertex- und Fragment-Programs! DirextX 8! OpenGL NV2X! (c) Peter Sturm, Universität Trier 20

101 Cg Programme! Ersetzen die Assemblerroutinen in DirectX! Operieren auf in den Shadern definierten Ein- und Ausgaben! Bindung an Programmvariablen geschieht über spezielle Syntax! Innerhalb des Codes mehr oder weniger C Programmeingaben! Variierende Eingaben! Unterschiedliche Daten für jeden Aufruf des Vertex- oder Fragment-Programms! Uniforme Eingaben! Konstanten, Zusatzinformationen! Gleichbleibend für jeden Vertex- oder Fragment-Aufrufs innerhalb eines Streams (c) Peter Sturm, Universität Trier 21

102 Variierende Eingaben für Vertex-Programm! Vordefiniert (in Anlehnung an Fixed-Pipeline)! Position im 3D-Raum (Vertex)! Normalenvektor an diesem Punkt! Texturkoordinaten! Zusätzliche Werte pro Vertex definierbar Variierende Ausgaben für Vertex-Programm! werden variierende Eingaben für Fragment- Programm! Aus- und Eingabebeziehung wird ebenfalls über die Bindings hergestellt! In allen Profilen definierte Bindings! POSITION! PSIZE! FOG! COLOR0, COLOR1! TEXCOORD0 TEXCOOR7! POSITION muß immer ausgegeben werden (c) Peter Sturm, Universität Trier 22

103 Variierende Ausgaben für Fragmente! Zwingend! COLOR: Bestimmt die endgültige Farbe! DEPTH: Modifikation des Tiefenwerts Cg: Datentypen! Grundtypen! float (32 Bit), half (16 Bit), int, fixed (12 Bit), bool! Handles auf ein Texturobjekt! Vektoren (1 bis 4 Elemente): z.b. float1 bis float4! Matrixen (maximal 4x4): float2x2, float3x2, float4x4! Structures! Arrays! Assignments kopieren ganzes Feld (c) Peter Sturm, Universität Trier 23

104 Statements und Operatoren! Kontrollfluß! Unterprogramme, if/else, while, for! Keine Rekursion! Schleifen müssen in manchen Profilen aufrollbar sein (Anzahl der Durchläufe zum Übersetzungszeitpunkt bekannt)! Unmenge an arithmetischen Operationen! Trigonometrische Funktionen! Runden, Abschneiden, etc.! Multiplikationen auch auf Matrizen, Vektoren,! Kreuzprodukt, Determinante,! Abbildung auf Texturen Beispiel: lit() (c) Peter Sturm, Universität Trier 24

105 Beispiel: Geometrische Funktionen DirectX 10! Zu hohe CPU-Last in 3D-Echtzeitanwendungen! Zunehmend feinere Modellierung, Physik, KI! CPU übermäßig mit Ansteuerung der GPU beschäftigt! Ziele! Mehr Ressourcen in der GPU verwalten! Bessere Lastverteilung CPU-GPU! Multi-Passes komplett in GPU! Shader-Funktionalität verallgemeinern (CPUs)! Weg von den Capabilities, hin zu mehr Gleichheit! Komplette Neuimplementierung (c) Peter Sturm, Universität Trier 25

106 Fixed-Function Pipeline (Version 9) Programmierbare Pipeline (Version 9) Fixed-Function Pipeline wird auf den meisten aktuellen Graphikkarten durch interne Shader-Programme ausgeführt. (c) Peter Sturm, Universität Trier 26

107 Programmierbare Pipeline (Version 10) Command Input Virtualized Memory (GPU/System Memory) Input Assembler Vertex Buffer Index Buffer Vertex Shader Texture! Keine Fixed-Function-Pipeline mehr Geometry Shader Texture! Einsatz der Shader essentiell Stream Output! SDK enthält Shadersatz für einfaches Portieren älterer Anwendungen Rasterizer/ Interpolator Pixel Shader Texture Output Merger Depth/Stencil Render Target Die Shader! Vertex Shader! Transformation, Licht! Per-Vertex Operationen! Pixel Shader! Textur-Komposistion! Per-Pixel Operation! Geoemtry Shader! Per-Primitive Operationen! Eingabe: beschreibenden Knoten! Ausgabe: Stripes (Dreiecke, Linien, Punkte)! Ausgabeanzahl wird im Setup festgelegt (c) Peter Sturm, Universität Trier 27

108 Shader-Modell, Version 4! Gemeinsame Basis für alle Shader! Befehlssatz mit CPU vergleichbar! Integer und Bitoperation, Floating Point! Erweiterung zu allgemein nutzbaren SIMD-Rechnern! Freier Zugriff auf den Speicher!! Switch-Statements und Unterprogramme Keine Beschränkungen! Mehr allgemein zugreifbare Ressourcen! Beliebige Instruktionsanzahl Genauigkeit! IEEE Floating-Point Compliance (fast)! Präzises FP32-Rechnen! Sampling! Blending! Mathematische Operationen! Konvertierungen! Exaktes Zeichnen! Optimiertes Anti-Aliasing (c) Peter Sturm, Universität Trier 28

109 ! Vereinfachtes API! Setup! Verlagerung von Zustand auf GPU Weitere Verbesserungen! Speicherung zusätzlicher Zustandsinformation! Constant Buffers auf unterschiedlichen Ebenen! C-ähnliche Programmiersprache! Präprozessor! Elementare Datentypen (float, int, bool, )! Operatoren, Variablen, Funktionen, HLSL 4.0! Spezialisierung auf 3D-Graphik! Vektortypen sind elementar (float2, float3, float4, )! Geeignete Operationen (Matrizenmultiplikation)! Dedizierter Compiler (fxc.exe)! Abbildung höherer Funktionen auf Shader-Potential! Loop unrolling! Umfangreiche Mathematikfunktionalität! Reflection möglich (c) Peter Sturm, Universität Trier 29

110 Effects (fx) Effect Pool Effect Technique Variable Pass State Object Constant Shader DirectX 10 Vista-Architektur PIX Media Foundation WPF MIL DWM Microsoftwritten code IHV-written code GDI Legacy D3D APIs DX VA D3D9 D3D9 Ex Direct3D 10 DXGI OpenGL OpenGL ICD Common pipeline (DDI) User-Mode Driver User Mode Kernel Mode Win32 Kernel DXG Kernel Kernel-Mode Driver Sam Z. Glassenberg, WinHEC 2006 (c) Peter Sturm, Universität Trier 30

111 OPENGL OpenGL! DirectX = Microsoft! Single Source! Alternative: OpenGL! Sprach- und plattform-unabhängig! Ursprung 1992 (SGI)! jetzt Khronos Group Consortium (non-profit)! Open*! Adobe, AMD/ATI, Apple, ARM, Creative Labs, id Software, Epic Games, Ericsson, Google, IBM, Intel, Motorola, Mozilla, Nokia, Nvidia, Samsung, Sony, Oracle, Texas Instruments! Kein Microsoft " (c) Peter Sturm, Universität Trier 31

112 XNA! Aktuelle managed runtime für DirectX- Anwendungen! Eingeführt 2004! Seit September 2010 XNA Game Studio 4.0! Ziel-Plattformen! Windows PC! Xbox 360! Windows Phone 7! Umfangreiches Framework (Engine?) XNA (c) Peter Sturm, Universität Trier 32

113 7. Physik! Graphik beschreibt reale Körper! Unterschiedlichen Materialeigenschaften! Elastizität, Masse, Dichte, Motivation! Physik gibt diesen graphischen Gebilden Semantik! Bewegung, Trägheit, Kollision! Realismus mit wachsender Objektanzahl und komplexität extrem rechenaufwendig! Deformationen, Auseinanderfallen,! Partikel und Flüssigkeiten! Haar und Kleidung (c) Peter Sturm, Universität Trier 1

114 Ansätze! Typischerweise komplexe Differentialgleichungen! Geschlossene Lösungen für einfache Modelle! Punktmassen! Keine Reibung! Echtzeitsimulation der Physik! Approximative Lösung der Gleichungen! Je nach Auflösung sehr hohe Dimensionalität Newton! Newtonsche Gesetze (1687) (nach Wikipedia)! Trägheitsprinzip! Ein Körper verharrt in seinem Zustand der Ruhe oder der gleichförmigen geradlinigen Bewegung, solange die Summe aller auf ihn einwirkenden Kräfte Null ist.! Aktionsprinzip! Die Änderung der Bewegung einer Masse ist der Einwirkung der bewegenden Kraft proportional und geschieht nach der Richtung derjenigen geraden Linie, nach welcher jene Kraft wirkt.! Reaktionsprinzip! Kräfte treten immer paarweise auf. Übt ein Körper A auf einen anderen Körper B eine Kraft aus (actio), so wirkt eine gleichgroße, aber entgegen gerichtete Kraft von Körper B auf Körper A (reactio). (c) Peter Sturm, Universität Trier 2

115 ! Gesetze gelten auch in Zeiten der Relativitätstheorie! Solange die Geschwindigkeit nicht relativistisch ist! Zweites Gesetz F ( t) = m! a( t)! m = Masse eines Objektes (in Kilogramm)! a = Beschleunigung (m/s 2 )! F = Kraft (in Newton: N = kg m / s 2 ) Newton (2) Beschleunigung, Geschwindigkeit, Ort 2 d d a ( t) = V ( t) = 2 dt dt p( t)! Funktionen in der Zeit! Mittlere Beschleunigung bzw. Geschwindigkeit V avg = p(t + "t) # p(t) "t a avg = V (t + "t) #V (t) "t (c) Peter Sturm, Universität Trier 3

116 ! F = m!a konstant! Geschwindigkeit Konstante Kraft F F F V ( t) = " a d# = " d# = Vinit + # = Vinit + ( t! tinit ) m m m! Position F F p ( t) = " V (# ) d# = " ( Vinit + # ) d# = pinit + V ( t! tinit ) + ( t! tinit ) m 2m 2! Einfach ausrechnen!! Flugbahn eines Projektils! Kraft = Gravitation g (9.81 m/s 2 )! Ortsberechnung 1 p t) = pinit + V ( t! tinit ) + g( t! t 2! Beispiel Ballerburg! Atari ST ( init ) 2 Beispiel (c) Peter Sturm, Universität Trier 4

117 Wind?! Mehrere konstante Kräft! Alle Kräfte einfach addieren Wind Resultierende Gesamtkraft g Kollision (Klassische Phyisk)! Annahmen! Feste Körper! Keine Reibung! Impulsgleichungen + " mv 1 1 = m1v 1 +! + " m2v 2 = m2v 2 "! " = b!n " m m2(1 + # )( V1 " V b = " m + m " 1 2 ) 1 2! n p 1 m 1! V 1 n p 2! V 2 m 2! Stoßzahl!! 1 = Perfekt elastisch! 0 = Perfekt plastisch (c) Peter Sturm, Universität Trier 5

118 Etwas mehr Realismus! Realistisch sind es aber Funktionen in der Zeit:! a(t), V(t), p(t) 2 d d a ( t) = V ( t) = 2 dt dt p( t)! Geschlossene Lösung selten möglich! Numerische Integration! Diverse Verfahrensweisen! Euler, Verlet, Runge-Kutta, Numerische Integration! Lineare Approximation der Differentialgleichungen! Beispielsweise durch Taylorreihe S( t + # t) = S( t) +! Terme höherer Ordnung abschneiden = Fehler! Selten mehr als Ordnung 2! Numerische Stabilität! " n= 1 (# t) n! S( t)! Spezielle Vorlesungen aus der Mathematik empfehlenswert! n d dt n n (c) Peter Sturm, Universität Trier 6

119 ! "t in der numerischen Integration! Fehlerschranke! Numerische Stabilität! Entkopplung von Framerate float delta_t = 0.02; float game_time; float prev_game_time; float physical_lag_time = 0.0; Simulationsschleife while (game running) { game_time = current_time(); physical_lag_time += (game_time prev_game_time); while (physical_lag_time > delta_t) { SimulatePhysics(delta_t); physical_lag_time -= delta_t; } prev_game_time = game_time; RenderScene(); } Wirkliche Körper! Punktförmige oder sphärische Massen unrealistisch! Ermittlung des Schwerpunkts! Allgemein Volumenintegrale p center = 1 m ### Volume "rdxdydz! In Spielen! Effiziente Approximation über Polygonoberfläche (c) Peter Sturm, Universität Trier 7

120 Drehmomente! Rotationen beliebiger Körper um Schwerpunkt! Graphische Problematik wird mit dem Masse- und Kraftbegriff verknüpft ' J xx J xy J xz $ % " L( t) = % J xy J yy J yz "!( t) % J xz J yz J " & zz # Trägheitsprodukte Trägheitsmomente Beispielkörper! r = Radius J xx = m(3r + h 12 J yy = J xx 1 J zz = mr 2 2 )! Trägheitsprodukte sind 0 (c) Peter Sturm, Universität Trier 8

121 Federn! Federelemente (Linear)! Unterschiedliche Längen! Ruhelänge (es wirken keine Kräfte)! Größer als Ruhelänge: Kompression! Kleiner als Ruhelänge: Expansion F = k ) v Spring ( l! lre st! k = Stärke der Feder! v d = Vektor (parallel zur Feder, Länge 1) d aus Rabin Viskose Dämpfung! Zwei Körper bewegen sich in vergleichsweise dichten Medien aufeinander zu! Luft, Wasser, Öl,! Kraft ist relativ zum Volumen und zur Geschwindigkeit des Objekts F damping = c!(( V " V 1)! dˆ) ep 2 ep! dˆ! d ist Vektor in pe1 und pe2 (Länge 1)! c Dämpfungskoeffizient (c) Peter Sturm, Universität Trier 9