DGL Wiki - Benutzerbeiträge [de]

Link

2011-08-13T20:12:06Z

Coolcat: /* Texturen */ cgtextures.com

Diese Linksammlung soll allgemeine Links zu unterschiedlichen Themen bieten, die mit der Multimediaentwicklung zu tun haben.
{{Hinweis|Vielleicht ist eine Zusammenführung mit [[Tool]] sinnvoll!}}
{{Hinweis|Vielleicht ist eine Aufteilung in Unterseiten sinnvoll (möglicherweise mit Kategorien)}}

= Entwicklung mit OpenGL =

== Hardwareinfos ==
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://delphigl.de/glcapsviewer/listreports.php OpenGL Hardware Registry - Hardwareübersicht]
|{{Englisch}}
|Eine Datenbank aller Grafikkarten die in der Harware Registry vorhanden sind. Die einzelnen Artikel enthalten Infos darüber, welche Extensions von der Grafikkarte unterstützt werden.
|-
|[http://delphi3d.net/hardware/allexts.php OpenGL Hardware Registry - Extensionübersicht]
|{{Englisch}}
|Eine Datenbank aller Extensions die in der Harware Registry vorhanden sind. Die einzelnen Artikel enthalten Infos darüber, welche Grafikkarten die entsprechende Extension unterstützen.
|-
|}


== Tutorials ==

{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
||[[Tutorial|DGL Wiki - Tutorial]]
|{{Deutsch}}
|DelphiGL.com ist Betreiber dieses Wikis und stellt eine Vielzahl Tutorials mit Schwehrpunkt OpenGL zur Verfügung.
Neben Tutorials für Einsteiger und OpenGL Anfänger gibt es auch fortgeschrittene Themen wie Shader oder Partikelsysteme.Sprache der Wahl ist hier Delphi.
|-
|[http://www.joachimrohde.com/cms/xoops/modules/articles/index.php?cat_id=1 joachimrohde.com]
|{{Deutsch}}
|Auf dieser Seite findet ihr deutsche Übersetzungen der bekannten NeHe Tutorials. Sprache der Wahl ist hier C++.
|-
|[http://www.cg.tuwien.ac.at/studentwork/VRSem96/OpenGL/ Technische Universität Wien]
|{{Deutsch}}
|Diese Seite bietet einen allgemeinen Überblick über die primären Funktionen von OpenGL und richtet sich vor allem an Einsteiger.
|-
|[http://nehe.gamedev.net/ Nehe]
|{{Englisch}}
|Die berühmt berüchtigten NeHe Tutorials sind eine umfangreiche Sammlung an Tutorials zum Thema OpenGL. Von Anfängertutorials bis hin zu komplexen Effekten wird alles behandelt. Sprache der Wahl ist hier C++. (Eine Übersetzung der NeHe Tutorials findet ihr bei Joachim Rhode (siehe oben). )
|-
|[http://www.sulaco.co.za/tut.htm sulaco.co.za]
|{{Englisch}}
| OpenGL Beispiele in Delphi
|}

== OpenGL Funktionen ==

=== GL ===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:GL|DGL Wiki - Kategorie GL]]
|{{Deutsch}}
| Wiki-Kategorie die alle übersetzten OpenGL Befehle enthält.
|-
|[http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL.tar.gz OpenGL.org - Orginal Spezifkationen]
|{{Englisch}}
|Die Orginalspezifikationen der OpenGL 1.0 und OpenGL 1.1 Befehle. (Diese HTML-Dokumente sind nicht Copy&Paste freundlich, da sie vermutlich automatisch aus vorhandenen Dateien (Postscript) erzeugt wurden.)
|-
|[http://developer.3dlabs.com/documents/glmanpage_index.htm 3dLabs]
|{{Englisch}}
|Die Orginalspezifikationen der OpenGL 1.0 und OpenGL 1.1 Befehle.
|-
|[http://www.mevis.de/~uwe/opengl/opengl.html mevis.de]
|{{Englisch}}
|Sammlung von Englischsprachigen Spezifikationen für GL(bis Version 1.1), GLX und GLU Funktionen.
|-
|[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glfunc01_4f03.asp MSDN von Microsoft]
|{{Englisch}}
|OpenGL Dokumentation in der MSDN. Die Erklärung der MSDN sind meist keine reinen Kopien der Orginalspezifikationen, sondern enthalten hin und wieder auch zusätzliche Informationen, oder formulieren Texte auf verständlichere Art und Weise.
|-
|}

=== GLU ===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:GLU|DGL Wiki - Kategorie GLU]]
|{{Deutsch}}
| Wiki-Kategorie die alle übersetzten GLU Befehle enthält.
|-
|[http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glu/ OpenGL.org - Orginal Spezifkationen]
|{{Englisch}}
|Orginalspezifikationen für die GLU Befehle. (Diese HTML-Dokumente sind nicht Copy&Paste freundlich, da sie vermutlich automatisch aus vorhandenen Dateien (Postscript) erzeugt wurden.)
|-
|[http://www.mevis.de/~uwe/opengl/opengl.html mevis.de]
|{{Englisch}}
|Sammlung von englischsprachigen Spezifikationen für GL(bis Version 1.1), GLX und GLU Funktionen.
|-
|[http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glufnc01_0e43.asp MSDN von Microsoft]
|{{Englisch}}
|GLU Dokumentation in der MSDN. Die Erklärung der MSDN sind meist keine reinen Kopien der Orginalspezifikationen, sondern enthalten hin und wieder auch zusätzliche Informationen, oder formulieren Texte auf verständlichere Art und Weise.
|-
|}

=== GLX ===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:GLX|DGL Wiki - Kategorie GLX]]
|{{Deutsch}}
| Wiki-Kategorie die alle übersetzten GLX Befehle enthält.
|-
|[http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glx/ OpenGL.org - Orginal Spezifkationen]
|{{Englisch}}
|Orgninalspezifikationen der GLX Befehle bei OpenGL.org.
|-
|[http://www.mevis.de/~uwe/opengl/opengl.html mevis.de]
|{{Englisch}}
|Sammlung von Englischsprachigen Spezifikationen für GL(bis Version 1.1), GLX und GLU Funktionen.
|-
|}

=== WGL ===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:WGL|DGL Wiki - Kategorie WGL]]
|{{Deutsch}}
|Wiki-Kategorie die alle übersetzten WGL Befehle enthält.
|-
|[http://developer.3dlabs.com/documents/wglmanpage_index.htm 3dLabs]
|{{Englisch}}
|Sammlung einiger WGL Befehlsspezifikationen.
|-
|}

=== GLUT ===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://freeglut.sourceforge.net/docs/api.php The freeglut Projekt]
|{{Englisch}}
|Englischsprachige Dokumentation zum OpenGL Utility Toolkit kurz GLUT.
|-
|}

=== SDL ===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[:Kategorie:SDL|DGL Wiki - Kategorie SDL]]
|{{Deutsch}}
|Übersicht aller auf die SDL bezogenen Artikel hier im Wiki. Darunter befinden sich eine Vielzahl von Übersetzungen der SDL Befehlspezifikationen. Diese können auch in der [[SDL-Funktionsübersicht]] gefunden werden.
|-
|[http://www.libsdl.org/cgi/docwiki.cgi/SDL_20API libsdl.org]
|{{Englisch}}
|Das Dokumentationswiki von libSDL.org enthält die komplette Dokumenation zur SDL in englischer Sprache.
|-
|-
|[http://www.fp.sdl.de.vu/ fp.sdl.de.vu]
|{{Englisch}}
| Eine Webseite die speziell Informationen über die Programmierung von SDL unter Freepascal zur Verfügung stellt.
|-
|}

== FAQs ==
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[FAQ| DGL Wiki - FAQ]]
|{{Deutsch}}
|Ein FAQ (Frequently Asked Questions = Häufig gestellte Fragen) zu DelphiGL.com und dem DGL Wiki.
|-
|[http://www.3dsource.de/faq/index.htm 3dsource.de]
|{{Deutsch}}
|Ein FAQ zu Fragen rund um OpenGL.
|-
|}

== Effekte und Techniken mit OpenGL ==

===Glow===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.gamasutra.com/view/feature/2107/realtime_glow.php Gamasutra]
|{{Englisch}}
|Beschreibt, wie man mit Hilfe von Shader(hier DirectX Shader) den Gloweffekt in Realtime umsetzt. Dabei wird erst die Technik dahinter erklährt, und dann wie man sie Schritt für Schritt umsetzt.
|-
|[http://collective.valve-erc.com/index.php?go=tron1 valve-erc.com]
|{{Englisch}}
|Schritt für Schritt Anleitung, wie man mit Hilfe von Cg in OpenGL den Glow Effekt realisieren kann
|-
|}

===HDR===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.gamedev.net/columns/hardcore/hdrrendering/ gamedev.net]
|{{Englisch}}
|Hier wird sehr kurz eingeleitet, was HDR Rendering überhaupt ist, dann wird der Aufbau des *.hdr Formats erläutert, und dann geht es schon von 0 auf 100 zum Programmieren. Erklährungen gibt es kaum, dafür werden fertige Shader(für DirectX) geboten.
|-
|[http://www.gamedev.net/reference/articles/article2208.asp gamedev.net]
|{{Englisch}}
|Beschreibt auch nur etwas kurz das HDR Verfahren, jedoch mit mehr mathematischen Hintergrund in Sachen Tonemapping. Beispielcode für Tonemapping in C++ liegt bei.
|-
|}

===BSP Bäume===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.3dtechdev.com/tutorials/leafbsp/3dbsptrees.html 3dtechdev.com]
|{{Englisch}}
|Das beste Dokument überhaupt, für allem die selber BSP Bäume compilieren möchte. Ist belegt mit sehr viel Grafik. Erst beginnt er das Prinzip allgemein zum umschreiben, dann wird alles genau erläutert, und mit verständlichen Pseudocode untermalt.
|-
|[http://www.3dtechdev.com/tutorials/illegalgeometry/illegalgeometrytut.html 3dtechdev.com]
|{{Englisch}}
|Nicht ganz so gut geworden, wie sein erstes Tutorial, aber erklährt auch sehr gut, wie man illegale Geometrie aufspürt und beseitigt. Wieder mit Grafiken und Pseudocodes verständlich belegt. Hiermit kann man seinem Map-Compiler den letzten Schliff verleien.
|-
|[http://www.gamedev.net/reference/articles/article981.asp Gamedev]
|{{Englisch}}
|Von Michael Abrash, dürfte der ''Erfinder'' von Quake sein. Naja, meine Englischkenntnisse reichen hier nicht ganz aus, um den Text zu verstehen. Ist etwas umständlich geschrieben. Dafür mit Grafiken unterlegt.
|-
|[http://www.zfx-online.de/Tutorials.php?ID=11 Part 1 - Allgemein]
|{{Deutsch}}
|Einzigste deutsche Referenz zu BSP Bäumen, dafür Daumen hoch. Ist aber nicht das Wahre: schlechter C Code, und ich hatte auch nicht den Einduck, das er die Theorie zu diesem Thema bis in die Tiefe verstanden hat(oder er wollte es nicht zu akademisch Erklähren oO). Aber ein guter Einstieg in dieses Thema.
|-
|[http://www.zfx-online.de/Tutorials.php?ID=13 Part 2 - Kollision und PVS]
|{{Deutsch}}
|-
|[http://www.cs.uwec.edu/~stevende/cs455/programs/GameTutorials%20-%20Quake%203%20BSP%20Format.htm Quake3 *.bsp Format]
|{{Englisch}}
|Die beste Dokumentation für das BSP Format, die ich gefunden habe, besser als den Quake3 Sourcecode zu durchforsten. Leider etwas magere Eklährung zu wichtigen Themen wie Patches(Curved Surfaces). Ich pers. hatte jetzt 1 1/2 Wochen gebraucht, um das *.bsp Format vollständig zu verstehen. Ist aber anscheinend die beste Format Dokumentation im Netz.
|-
|[http://www.flipcode.com/articles/article_q2bsp.shtml Quake2 *.bsp Format]
|{{Englisch}}
|Kann auch nur soviel sagen, wie beim Link zuvor. Es fehlen hier auch zum Teil Informationen. Man muss halt viel ausprobieren, und sich den Quake 2 Source zu Herzen nehmen, damit man es versteht.
|-
|}

===Himmel & Wolken===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.gamedev.net/community/forums/topic.asp?topic_id=86024 Gamedev]
|{{Englisch}}
|Guter Thread mit vielen Anregungen und Links.
|-
|[http://www.gamedev.net/community/forums/topic.asp?topic_id=135654 Gamedev]
|{{Englisch}}
|Hier wird die Diskussion zum obigen Link weitergeführt.
|-
|[http://freespace.virgin.net/hugo.elias/models/m_clouds.htm Plasma]
|{{Englisch}}
|Eine nette Idee um Plasma in Echtzeit zu generieren, und zu verändern. Leider nichts zum Shading.
|-
|[http://nis-lab.is.s.u-tokyo.ac.jp/~nis/cdrom/sig00_cloud.pdf 3D Wolken]
|{{Englisch}}
|Paper über generieren und rendern von 3 dimensionalen Wolken inklusive Schatten und Lichtstrahlen. Ich hab nur den Lichtstahlen-Algorithmus ausprobiert. Saulangsam aber sehr einfach zu implementieren. Einen Blick ist es auf jeden Fall wert.
|-
|[http://www.geocities.com/ngdash/whitepapers/skydomecolor.html Skydome]
|{{Englisch}}
|Wenn man mal schnell gute Farben für seinen Skydome braucht...
|}

===Terrain===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.flipcode.com/articles/article_geomipmaps.shtml FlipCode]
|{{Englisch}}
|Artikel zu Geomipmaping. Zummindest hab ich es hier zum ersten mal gesehen. Und es funzt ganz gut.
|-
|[http://www.vterrain.org Virtual Terrain Project]
|{{Englisch}}
|Eine Seite mit Links und Artikeln zu allem, was etwas mit Terrainrendering zu tun hat.
|-
|}

===Sonstiges===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[[Materialsammlung]]
|{{Deutsch}}
|Sammlung von gängigen Parametern für [[glMaterial]] hier im Wiki.
|-
|[http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm Radiosity]
|{{Englisch}}
|Erklährt sehr schön die Funktionsweise von Radiosity, liefert Beispielcodes und ist recht gut illustriert.
|-
|[http://legion.gibbering.net/projectx/paper/shadow%20mapping/ Shadowmapping]
|{{Englisch}}
|Beschreibt das Trapezoidal Shadow Mapping - Verfahren für gerichte Lichter.
|-
|[http://www.flipcode.com/articles/article_generatingnames.shtml Namensgenerator]
|{{Englisch}}
|Per Zufallsgenrator Namen erzeugen, und nie wieder kreativ werden müssen.
|-
|[http://www.paulsprojects.net/tutorials/simplebump/simplebump.html Bumpmapping]
|{{Englisch}}
|Bumpmapping auf Lowend-Grakas. Damals war Bumpmapping noch was ganz tolles...
|-
|[http://www.paulsprojects.net/opengl/dpreflect/dpreflect.html Dot Product Reflect]
|{{Englisch}}
|zwar nur ne Demo, aber wenn man schon immer mal mit EMBM das Wasser aus Morrowind nachproggen wollte...
|-
|}

== Beispiele/Demos mit Quelltext ==
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.delphigl.de DelphiGL.de]
|{{Deutsch}}
| Hier finden sich besonders eindrucksvolle Newton Physik Demos. Meißtens sogar mit Quelltext.
|-
|[http://www.shadow3d.de.vu/ Shadow 3D]
|{{Deutsch}}
| Hier finden sich zwei Demos wie man Quake 3 Modelle lädt und eine glSlang Demo
|-
|[[Shadersammlung]] im DGL Wiki
|{{Deutsch}}
| Hier findet man freie Shadersourcen.
|-
|[http://www.humus.name Humus]
|{{Englisch}}
| Diverse eindrucksvolle Demos zu verschiedenen Techniken, häufig mit Quelltext in C (teilweise OpenGL / DirectX)
|}

== weitere Links ==
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www-user.tu-chemnitz.de/~pester/Lehre/CompGeo.pdf CompGeo.pdf]
|{{Deutsch}}
| Script "Einführung in die Computergeometrie" von Dr. Pester (TU-Chemnitz). Ideales Nachschlagewerk für die Mathematik die einem bei der Grafikprogrammierung so begegnet.
|-
|[http://www.robsite.de/ robsite.de]
|{{Deutsch}}
| Auf dieser riesigen Seite finden sich auch viele weitere Links über verschiedene Themen der 3D Programmierung.
|-
|[http://www.3dlinks.com/links.cfm?categoryid=3&subcategoryid=21 3dlinks.com]
|{{Englisch}}
| Diese Seite hat es sich zur Hauptaufgabe gemacht Links auf Seiten mit dem Thema 3D zu sammeln.
|-
|[http://www.two-kings.de/links.html two-kings.de]
|{{Englisch}}
| Sammlung diverser interessanter Links, vorallem auf Themen im gamedev-Forum verweisend.
|-
|[http://www.delgine.com Delgine.com]
|{{Englisch}}
| Heimat des freien 3D Modellers "DeleD", welcher in Delphi programmiert ist. Ihr findet dort auch Modellpackete, Texturpackete, Plugins und Hilfe bei der Programmierung von Delphi und OpenGL.
|}

= Spieleentwicklung =

==Allgemein==
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.spieleprogrammierung.net/ Spieleprogrammierung - OpenGL - GLSL - OpenAL - KI - Animation - Spielephysik]
|{{Deutsch}}
|Auf dieser Seite findet Ihr Artikel, Tutorials und Programmbeispiele rund um das Thema Spieleprogrammierung. Programmiersprache ist hier C/C++.
|-
|[http://graphics-and-physics-framework.spieleprogrammierung.net/ OpenGL Graphics And Physics Framework]
|{{Deutsch}}
|Auf dieser Seite findet Ihr ein frei verfügbares OpenGL basiertes Grafik und Physik Framework (LGPL-Lizenz) samt zugehöriger Probammbeispiele. Programmiersprache ist hier C/C++.
|-
|[http://audio-framework.spieleprogrammierung.net/ OpenAL Audio Framework]
|{{Deutsch}}
|Auf dieser Seite findet Ihr ein frei verfügbares OpenAL Audio Framework (LGPL-Lizenz) samt zugehöriger Probammbeispiele. Unterstützt werden 3D Sounds, EFX (EAX Alternative) Reverb Effekte sowie Audio Streaming (Music and Voices). Programmiersprache ist hier C/C++.
|-
|[http://spieleentwicklung-im-web.spieleprogrammierung.net/ Spieleentwicklung im Web]
|{{Deutsch}}
|Auf dieser Seite findet Ihr Links (E-Books, Präsentationen, wissenschaftliche Arbeiten und Tutorials) zu verschiedenen Themengebieten der Spieleentwicklung.
|-
|}

==Kopierschutz==
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://inner-smile.com/nocrack.phtml Inner-Smile.com]
|{{Englisch}}
| Seite mit Gedanken zum Thema "Wie schütze ich meine Programme vor Crackern". Falls die Seite nicht erreichbar ist hat Google noch ne [http://www.google.com/search?q=cache:hpqPT5G4WB0J:www.inner-smile.com/nocrack.phtml+http://inner-smile.com/nocrack.phtml&hl=de&gl=de&ct=clnk&cd=1 Version im Archiv].
|-
|}

== Künstliche Intelligenz ==
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.kbs.uni-hannover.de/Lehre/KI2/Presentationen/presentation9798/esprit/spieltheorie/spieltheorie.html Uni-Hannover - Spieltheorie]
|{{Deutsch}}
|Artikel über die Grundlagen von KI in Spielen.
|-
|[http://www.robsite.de/tutorials.php?tut=ki Robsite KI-Tutorials]
|{{Deutsch}}
| Sammlung von Texten zum Thema KI in Spielen. Beispiele sind meist in C++.
|-
|[http://ai-depot.com/ AI-Depot.com]
|{{Englisch}}
| Seite die sich ausschließlich mit KI in Spielen beschäftigt.
|-
|[http://www.ai-junkie.com/links.html AI-Junkie.com]
|{{Englisch}}
|Linkseite mit vielen KI relevanten Links. Die Seite AI-Junie selbst behandelt auch viele Themen rund um KI.
|-
|[http://www.aiwisdom.com/ AIWisdom.com]
|{{Englisch}}
|Seite die sich mit KIs in Spielen beschäftigt und sich zum Ziel gesetzt hat, alle Artikel zum Thema zu finden und zu Katalogisieren. Es gibt hier auch Artikel über die KIs bestehender Spiele.
|-
|[http://www.aiguru.com/ AIGuru.com]
|{{Englisch}}
|Newsseite zum Thema KI, Künstliches Leben, Hiernforschung, Robotik, Nanotechnologie - Halt alles was Spass macht.
|-
|[http://www.generation5.org/ Generation5.org]
|{{Englisch}}
|Seite über KI, Robotik, etc. . Leider scheint die Seite Probleme zu haben regelmäßig aktualisiert zu werden. Aber zumindest sollte man einige Artikel finden. Die werden ja nicht schlecht.
|-
|www.gameai.com
|{{Englisch}}
|''Wurde Januar 2010 als down gemeldet. Weiss irgendwer etwas genaueres?'' Seite zum Thema KI in Spielen. Soll wohl einen gewissen Stellenwert in der AI-Szene haben.
|-
|[http://www-i1.informatik.rwth-aachen.de/~algorithmus/algo19.php Algorithmus der Woche - Informatikjahr 2006]
|{{Deutsch}}
|Vielleicht schon etwas älter aber doch eine gute Anleitung um eine einfache Schach-KI zu erstellen.
|}

= Ressourcen =
In dieser Gruppe finden sich Links um die Ressourcen für Eure Projekte zu erstellen.

== Texturen / 2D-Grafiken ==

=== Texturen ===
{| width = "100%" {{Prettytable_B1}}
!width="20%"|Link
!width="10%"|Genre
!width="10%"|Lizenz
!width="5%"|GPL
!width="5%"|MPL
!width="5%"|OSS
!width="5%"|CSS
!width="5%"|Komm.
!width="35%"|Bemerkungen
|-
|[http://www.davegh.com/vg/home.htm davegh.com]
|Fantasy
|[http://www.davegh.com/vg/termsandconditions.htm Eigene]
|?
|?
|✔
|✔
|✘
|Die Lizenz vererbt sich in die Projekte hinein.
|-
|[http://www.cgtextures.com/ cgtextures.com]
|Allgemein
|[http://www.cgtextures.com/content.php?action=license Eigene]
|✘
|✘
|✘
|?
|?
|Die Lizenz will im wesentlichen verhindern das Texturen in anderen Textursammlungen auftauchen. So wie ich das verstehe ist es kein Problem die Texturen unter einer anderen Lizenz zu veröffentlichen als die eigentliche Software. Die Software kann also sehr wohl OpenSource sein. Im Zweifelsfalls einfach den Support anschreiben, der ist sehr nett.
|-
|url
|Futuristisch, Mittelalter, etc.
|CC-BY-SA, etc., gerne auch mit Direktlink auf die Lizenzseite, so vorhanden.
|✔/✘/?
|✔/✘/?
|✔/✘/?
|✔/✘/?
|✔/✘/?
|Alle Bilder sind von Käse
|}
'''Legende:'''
:'''Kostenpflichtige Seiten''' sind mit einem * zu '''kennzeichnen'''
:GPL: Kompatibel mit der GPL
:MPL: Kompatibel mit der MPL
:OSS: Verwendung in OpenSource Software nicht verboten
:CSS: Verwendung in ClosedSource Software nicht verboten
:Komm: Verwendung in kommerzieller Software nicht verboten

=== Texturerstellung ===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://3d.diehlsworld.de/textures/index.htm 3d.diehlsworld.de]
|{{Deutsch}}
|Auf dieser Seite findet ihr kurze aber inhaltlich reiche Tutorials zu der Frage "Wie erstelle ich XXXXX-Texturen". Dabei reicht die Palette von Untergrundtexturen wie Gras, Sand , Fels und Wasser (und Kombinationen dieser) bis hin zu Blitzen und Partikeln. Als Programm wird hier Photoshop verwendet.
|-
|[http://www.gimps.de/gimp/textur-muster/ gimps.de]
|{{Deutsch}}
|Schritt für Schritt Anleitungen wie man mit Gimp verschiedene Texturen erstellt.
|-
|[http://cbt.k090999.de/gimp.php#texturen k090999.de]
|{{Deutsch}}
|Gimptutorials zum Erstellen verschiedene Texturen.
|}

== Modelle / 3D-Grafiken ==

=== Blender ===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://blendpolis.de/f/viewtopic.php?t=5786 Blendpolis]
|{{Deutsch}}
| Ein Thread im Forum von [http://blendpolis.de Blendpolis] in dem '''sehr''' viele Tutorials aufgelistet sind
|-
|[http://blendpolis.de/f/article_cat.php?fldAuto=7 Blendpolis]
|{{Deutsch}}
| Eigentliche Tutorial Seite von [http://blendpolis.de Blendpolis] die Auswahl ist hier aber nicht so groß
|-
|[http://wikivid.com/index.php/Blender Blender at wikivid.com]
|{{Englisch}}
| Linksammlung von Blender Video Tutorials
|-
|[http://www.blender.org/education-help/tutorials/getting-started/ blender3d.org]
|{{Englisch}}
| Auch die Heimatseite von Blender bietet viele Tutorials unter anderm auch Video Tuorials
|-
|[http://www.Blenderunderground.com Blenderunderground]
|{{Englisch}}
| '''sehr gute''' Video-Tutorials
|}

== Sounds ==

===Musik===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.jamendo.com/ Jamendo.com]
|{{Englisch}}
|Viele Künstler stellen hier ihre Alben unter einer Creative Commons Lizenz online. Man kann dort die Künstler auch kontaktieren und fragen ob man ihre Musik nutzen kann. Taugt außerdem als Radio! ;)
|-
|[http://incompetech.com/m/c/royalty-free/ Incompetech.com]
|{{Englisch}}
|Viele sehr schön gemacht instrumentale Musik aus allen möglichen Genres. Sie ist frei verwenderbar, wenn man den Macher der Musik (Kevin MacLeod) in seinem Programm erwähnt. Aber das hat er auch verdient. Folgende Programme nutzen beispielsweise (auch) Musik von incompetech.com:
* OpenParty
|-
|}

===Soundeffekte===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://www.freesound.org/ freesound.org]
|{{Englisch}}
|Diverse Sounds unter [http://www.creativecommons.org/ CreativeCommons] Lizenzen.
|}

===Soundprogramme===
{| width = "100%" {{Prettytable_B1}}
!width="25%"|Link
!width="5%"|Sprache
!width="70%"|Beschreibung
|-
|[http://audacity.sourceforge.net/?lang=de Sourceforgeseite von Audacity]
|{{Deutsch}}
|Ein einfaches, freies Programm um Sounddateien zu bearbeiten. Man kann es auch nutzen um Soundeffekte neu zu erstellen, indem man z.B. ein Geräusch mit dem Mikrofon aufnimmt und einige Effekt anwendet, um es passender und nicht mehr aufgenommen klingen zu lassen.
|-
|[http://lmms.sourceforge.net/ LMMS]
|{{Englisch}}
|LMMS (Linux MultiMedia Studio) ist ein OpenSource+Freeware Composer-Programm ähnlich zum bekannteren aber auch teuren CuBase(r). Trotz des Namens auch für Windows erhältlich.
|}

glClearDepth

2011-05-09T15:31:38Z

Coolcat: /* Parameter */

= glClearDepth =

== Name ==
'''glClearDepth''' - legt den Wert fest mit dem der Tiefenpuffer beim löschen des selbigen gefüllt wird.

== Delphi-Spezifikation ==
procedure glClearDepth(depth: TGLclampd); stdcall;

== Parameter ==
<table border=1 rules=all>
<tr>
<td>''depth''</td>
<td>Ist der Wert, mit dem beim löschen der Tiefenpuffer gefüllt wird. Voreingestellt ist 1, der größtmögliche Tiefenwert.</td>
</tr>
</table>

== Beschreibung ==
Mit glClearDepth können Sie den Wert festlegen mit dem der [[Tiefenpuffer]] beim Löschen des Puffers (mittels [[glClear]]) überschrieben wird.

== Hinweise ==
Der übergebene Wert (depth) wird auf das Interval [0,1] begrenzt. Der Wert 0 ist der kleinstmögliche Tiefenwert, 1 der größtmögliche.

== Fehlermeldungen ==
GL_INVALID_OPERATION wird generiert wenn glClearDepth innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

== Zugehörige Wertrückgaben ==
[[glGet]] mit Token [[glGet#GL_DEPTH_CLEAR_VALUE|GL_DEPTH_CLEAR_VALUE]]

== Siehe auch ==
(andere Löschfunktionen)
[[glClear]], [[glClearAccum]], [[glClearColor]], [[glClearIndex]], [[glClearStencil]]

[[Kategorie:GL|ClearDepth]]
[[Kategorie:GL1.0]]

glClearDepth

2011-05-09T15:30:27Z

Coolcat: /* Hinweise */ Umgerechnet ist hier missverständlich.

= glClearDepth =

== Name ==
'''glClearDepth''' - legt den Wert fest mit dem der Tiefenpuffer beim löschen des selbigen gefüllt wird.

== Delphi-Spezifikation ==
procedure glClearDepth(depth: TGLclampd); stdcall;

== Parameter ==
<table border=1 rules=all>
<tr>
<td>''depth''</td>
<td>Ist der Wert, mit dem beim löschen der Tiefenpuffer gefüllt wird.</td>
</tr>
</table>

== Beschreibung ==
Mit glClearDepth können Sie den Wert festlegen mit dem der [[Tiefenpuffer]] beim Löschen des Puffers (mittels [[glClear]]) überschrieben wird.

== Hinweise ==
Der übergebene Wert (depth) wird auf das Interval [0,1] begrenzt. Der Wert 0 ist der kleinstmögliche Tiefenwert, 1 der größtmögliche.

== Fehlermeldungen ==
GL_INVALID_OPERATION wird generiert wenn glClearDepth innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

== Zugehörige Wertrückgaben ==
[[glGet]] mit Token [[glGet#GL_DEPTH_CLEAR_VALUE|GL_DEPTH_CLEAR_VALUE]]

== Siehe auch ==
(andere Löschfunktionen)
[[glClear]], [[glClearAccum]], [[glClearColor]], [[glClearIndex]], [[glClearStencil]]

[[Kategorie:GL|ClearDepth]]
[[Kategorie:GL1.0]]

Tutorial Vertexbufferobject

2011-05-04T08:30:10Z

Coolcat: /* Ave! */ Zeitgemäßge Überarbeitung

==Ave!==

Und willkommen zu meinem zweiten Tutorial. Diesmal beschäftigen wir uns mit den sogenannten ''Vertex Buffer Objects''. Die Extension '''GL_ARB_vertex_buffer_object''' wurde vom ARB am 12.Februar 2003 fertiggestellt. Später im Jahr 2003 wurde sie in den Core von OpenGL 1.5 aufgenommen. In diesem Tutorial werden diese Core-Funktionen verwendet. Das Verhalten der Extension sollte aber identisch sein.

VBOs (Vertex Buffer Objects) sind quasi eine Erweiterung der Vertexarrays, die jedoch den großen Vorteil besitzen, dass ihre Vertexdaten serverseitig, also im schnellen VRAM der Grafikkarte, statt wie bei den VAs im Hauptspeicher, abgelegt werden. Das ist bei einer Displayliste zwar (fast) genauso der Fall, allerdings können die Daten nicht so einfach dynamisch geändert werden, was bei einem VBO aber bei Bedarf sehr einfach ist.

Kurz gesagt vereint das VBO also die Flexibilität eines Vertexarrays mit der Geschwindigkeit einer Displayliste und eignet sich daher besonders für das Rendern aufwändiger Geometrie, egal ob statisch oder dynamisch.

Eine weitere tolle Neuerung der VBO-API ist die Tatsache, dass man sich von OpenGL einen Pointer übergeben lassen kann, mit dessen Hilfe man Vertexdaten direkt in den VRAM schreiben kann. Dadurch spart man sich natürlich den Umweg über den Hauptspeicher und somit auch den erhöhten Speicherbedarf des Programmes beim Laden von Modellen o. Ä.

VBOs bieten übrigens auch die Möglichkeit, sie je nach Anwendungsfall vom Grafikkartentreiber "optimieren" zu lassen. So legt man Vertexdaten, die im Nachhinein nicht mehr verändert werden sollenm am besten mit dem Schlüsselwort ''STATIC_DRAW'' ab, während dynamische Vertexdaten über ''DYNAMIC_DRAW'' abgelegt werden sollten. Doch dazu gibts später nähere Informationen.

==Hardwareunterstützung==

Inzwischen sollten alle gängigen Grafikkarten diese Extension problemlos unterstützen, ältere Modelle tun dies aber evtl. nur emuliert über den Treiber. Will man sein Programm auch für sehr alte Hardware (Karten älter als ATIs Radeon 9x00 bzw. NVidias GeForce 4-Serie) lauffähig machen, sollte man noch einen alternativen Renderpfad auf Basis von Displaylisten einbauen.

==Erstellen des Vertexbufferobjects==

Wie der Name vermuten lässt, handelt es sich beim VBO um ein Objekt, welches in Sachen Syntax an die anderen in OpenGL verfügbaren Objekte wie z. B. Texturenobjekte angelehnt ist. Das Erstellen eines VBOs geht daher genauso einfach von der Hand:

<source lang="pascal">
glGenBuffers(1, @VBO);
</source>

Nun sollten wir in VBO eine gültige ID zurückgeliefert bekommen haben, welche ein Vertex buffer object referenziert.

Nachdem wir nun ein VBO erstellt haben, sollten wir dieses natürlich auch "aktivieren" (also binden), damit wir mit ihm arbeiten können:

<source lang="pascal">
glBindBuffer(GL_ARRAY_BUFFER, VBO);
glEnableClientState(GL_VERTEX_ARRAY);
</source>

Wie erwähnt binden wir in der ersten Zeile unser frisch erstelltes VBO, während wir in der zweiten Zeile Vertexarrays auf der Clientseite aktivieren. Dies ist deshalb nötig, da wir das VBO später genauso zeichnen werden wie dies bei einem normalen VA der Fall wäre.

==Übergabe der Vertexdaten (Variante 1: Ohne Umweg über den Hauptspeicher)==

Wie in der Einleitung bereits erwähnt, bietet uns die VBO-API die Möglichkeit, unsere Vertexdaten ohne Umweg über den Hauptspeicher direkt in den Grafikkartenspeicher zu schreiben. Da dies eines der besten Features dieser neuen Extension ist, wollen wir uns auch zuerst mit dieser Übergabemethode beschäftigen.

''Allerdings erstmal eine kleine Warnung vorweg: Pointer sind ein recht komplexes Thema, und ihre Nutzung erfordert einige Kenntnisse. Wer weder weiß, wie man damit umgeht, noch wie man sie einsetzt, sollte sich da zuerstmal schlau machen. Denn mit Pointer kann man ganz böse Sachen machen, wenn man sie nicht richtig nutzen kann!''

Um unsere Vertexdaten als Pointer zu nutzen,müssen wir erstmal eine Vertexstruktur erstellen und auch einen passenden Pointertyp. Der Pointertyp ist zwar nicht zwingend (ein ^ täte es auch), aber macht die Sache übersichtlicher:

<source lang="pascal">
PVertex = ^TVertex;
TVertex = packed record
S,T,X,Y,Z : TGLFloat;
end;
</source>

Sicher fragen sich einige von euch jetzt, warum unser TVertex gerade so aussieht (also zuerst S,T und dann der Rest). Das liegt daran, dass wir unser VBO später über die Funktion [[glInterleavedArrays]] rendern werden, welche wissen will, wie unsere Vertexdaten im Speicher abgelegt sind. Unsere Vertexstruktur entspricht dabei dem Format ''GL_T2F_V3F''. ''T2F'' entspricht 2 Floats für die Texturenkoordinaten (S&T), gefolgt von ''V3F'' für die drei Floatwerte die unsere Vertexkoordinaten repräsentieren. Wenn ihr ein anderes Vertexformat verwendet, müsst ihr euch auch ein passendes Vertexformat aus der Spezifikation heraussuchen.
Ich verwende oben übrigens einen '''packed Record''' (auch wenn dies bei unserem Vertexformat nicht unbedingt ein Muss ist). Dies tue ich deshalb, da Delphi Werte bei einem normalen Record für einen beschleunigten Zugriff an einem (Double)Word-Raster ausrichtet und dies deshalb bei bestimmten Vertexformaten Probleme bereiten könnte.

Hoffe mal das euch obiges klar ist,denn jetzt gehts ans Eingemachte. Wir kommen zum "schwersten" (ist ja ein relativer Begriff) Teil des Tutorials, nämlich der Übergabe der Vertexdaten an das VBO. Dazu müssen wir OpenGL zuerstmal mitteilen, wie groß unser VBO eigentlich sein soll,damit wir auch genug Platz im VRAM bekommen:

<source lang="pascal">
glBufferData(GL_ARRAY_BUFFER, VertexAnzahl*SizeOf(TVertex), nil, GL_STATIC_DRAW);
</source>

Schauen wir uns also mal die Parameter von [[glBufferData]] an. Zuerst müssen wir OpenGL mitteilen, was für einen Puffer wir erstellen wollen (in zukünftigen Versionen werden wohl noch andere folgen, z. B. Überbuffer). In unserem Falle also einen Arraypuffer. Parameter zwei übergibt dann den Speicherplatz, den wir reservieren wollen und ist recht selbsterklärend. Der dritte Parameter würde normalerweise einen Pointer auf unsere Vertexdaten enthalten. Da wir diese aber nicht im Hauptspeicher abgelegt haben, sondern über einen Pointer dort noch ablegen wollen, übergeben wir hier '''nil'''. OpenGL nimmt dies zur Kenntnis und spuckt dementsprechend auch keinen Fehler aus.

Den letzten Parameter hab ich auch schon kurz in der Einführung angesprochen. Er teilt OpenGL mit, auf welchen Anwendungsfall unser VBO optimiert werden soll. Dabei gibt es folgende Anwendungsfälle,die ihr euch dann entsprechend eurer VBO-Verwendung aussuchen könnt:

{|rules="all" border = "1"
! STREAM_DRAW
| Die Vertexdaten werden einmal übergeben und dann eher selten als Quelle für OpenGL-Befehle genutzt.
|-
! STREAM_READ
| Die Vertexdaten werden einmal übergeben und dann selten von der Anwendung angefordert.
|-
! STREAM_COPY
| Die Vertexdaten werden einmal durch Kopieren von der GL übergeben und dann eher selten als Quelle für OpenGL-Befehle genutzt.
|-
! STATIC_DRAW
| Die Vertexdaten werden einmal übergeben und dann recht oft von der Anwendung zum Rendern genutzt.
|-
! STATIC_READ
| Die Vertexdaten werden einmal übergeben und dann recht oft von der Anwendung angefordert.
|-
! STATIC_COPY
| Die Vertexdaten werden einmal durch Kopieren von der GL übergeben und dann recht oft von der Anwendung zum Rendern genutzt.
|-
! DYNAMIC_DRAW
| Die Vertexdaten werden wiederholt angegeben (verändert) und recht oft von der Anwendung zum Rendern genutzt.
|-
! DYNAMIC_READ
| Die Vertexdaten werden wiederholt durch das Auslesen von Daten durch OpenGL angegeben (verändert) und oft von der Anwendung angefordert.
|-
! DYNAMIC_COPY
| Die Vertexdaten werden wiederholt durch das Auslesen von Daten durch OpenGL angegeben (verändert) und recht oft zum Rendern genutzt.
|}

Beachtet werden sollte, dass es sich bei obigen Anwendungsmuster nur um Hinweise (Hints) handelt, die es auch in anderen Bereichen von OpenGL gibt. Diese Hinweise sind allerdings nicht verbindlich und werden von Treiber zu Treiber unterschiedlich behandelt.

Nachdem OpenGL nun weiss was für ein VBO wir genau haben wollen, brauchen wir letztendlich nur noch einen Pointer, der "auf" das VBO zeigt:

<source lang="pascal">
VBOPointer := glMapBuffer(GL_ARRAY_BUFFER, GL_WRITE_ONLY);
</source>

Die Funktion [[glMapBuffer]] liefert uns einen Pointer zurück, der den Speicherplatz des VBOs in den Adressraum des Clients "ummappt", also in den Hauptspeicher. Dadurch wird es dann möglich, über eine Adresse im Hauptspeicher des Rechners direkt in den Grafikkartenspeicher zu schreiben. Der zweite Parameter gibt übrigens an, das wir in das VBO schreiben wollen. Der einzige weitere zulässige Parameter ist hier '''GL_READ_ONLY''', welcher zum Auslesen des VBOs dient.

Endlich haben wir einen Pointer auf unser inzwischen auch im VRAM der Grafikkarte richtig dimensioniertes Vertexbufferobject, und sind nun in der Lage dort unsere Vertexdaten abzulegen. Was jetzt folgt ist ein wenig Pseudo-Code der diesen Vorgang darstellt. Pseudo-Code deshalb, weil die Vertexdaten die ins VBO kommen ja in jeder Anwendung unterschiedlich sind, und man so auch selbst ein wenig denken muss:

<source lang="pascal">
VertexDatenLaenge := 0;
for i := 0 to High(MeineVertexDaten) do
begin
VertexPointer := VBOPointer;

VertexPointer^.X := GeneriertesVertex.X;
VertexPointer^.Y := GeneriertesVertex.Y;
VertexPointer^.Z := GeneriertesVertex.Z;
VertexPointer^.S := GeneriertesVertex.S;
VertexPointer^.T := GeneriertesVertex.T;

inc(Integer(VBOPointer), SizeOf(TVertex));

inc(VertexDatenLaenge);
end;
</source>

Da sich dieses Tutorial (und v. a. diese Methode der Vertexdatenübergabe) an die fortgeschritteneren wendet, rede ich nicht lange um den heissen Brei herum. Wir durchlaufen also eine Schleife, in der wir unsere Vertexdaten dynamisch erstellen. Entweder in jedem Durchlauf, oder wir laden die Daten vor der Schleife z. B. aus einem 3D-Modell und entfernen sie danach aus dem Hauptspeicher. Erste Methode spart sowohl beim Programmstart, also auch während des Programmlaufes Arbeitsspeicher, während letztere dies nur während des Programmablaufs macht.

Wir setzen die Adresse des Pointers der auf das momentan zu verändernde Vertex zeigt also auf die aktuelle Zeigerposition im VBO und schreiben dann unser Vertex direkt in den Grafikkartenspeicher. Ist dies getan, müssen wir die Adresse unseres VBOPointers natürlich um die Größe des gerade geschriebenen Vertexes erhöhen. Der Typecast auf ein Integer geschieht deshalb, weil man Pointer in Delphi nicht so einfach erhöhen oder verringern kann, Integers hingegen schon.

Ich gehe mal davon aus,das meine Leserschaft mit obigem Codeschnippsel keinerlei Probleme hatte und bringe diese Methode der Übergabe von Vertexdaten an das VBO dann auch mit folgender Quellcodezeile zu Ende:

<source lang="pascal">
glUnMapBuffer(GL_ARRAY_BUFFER);
</source>

Wie unschwer zu erraten geben wir hier unser VBO für den weiteren Zugriff wieder frei. Dies ist nötig um dies später rendern zu können.

==Übergabe der Vertexdaten (Variante 2: Über den Hauptspeicher)==

Wem obige Variante nicht zugesagt hat, weil sie ihm zu komplex war, oder weil er seine Vertexdaten aus diversen Gründen im Hauptspeicher braucht, dem wird in diesem Abschnitt geholfen.

Das Übergeben der Vertexdaten an das VBO über den Hauptspeicher gestaltet sich nämlich sehr einfach:

<source lang="pascal">
glBufferData(GL_ARRAY_BUFFER, SizeOf(VertexDaten), @VertexDaten, GL_STATIC_DRAW);
</source>

Sieht einfach aus,hört sich einfach an und ist auch einfach! Statt wie im letzten Kapitel für die Vertexdaten einen Zeiger auf '''nil''' zu übergeben, übergeben wir OpenGL jetzt einen direkten Zeiger auf die Vertexdaten die im Hauptspeicher abgelegt sind. Die Daten werden dann zum VBO hochgeladen, und können anschliessen auch wieder aus dem Hauptspeicher entfernt werden.

==Rendern des VBOs==

Kommen wir nun also schon zum Ende unseres VBO-Tutorials. Dank der Einfachheit dieser Extension gabs halt einfach nicht mehr zu erklären. Das Zeichnen gestaltet sich nämlich OpenGL-typisch mehr als einfach:

<source lang="pascal">
glInterleavedArrays(GL_T2F_V3F, SizeOf(TVertex), nil);
glDrawArrays(GL_QUADS, 0, VertexDatenLaenge);
</source>

Schnell gezeichnet und schnell erklärt. Der erste Parameter gibt an, in welchem Format die Vertexdaten unseres VBOs abgelegt wurden (wir erinnern uns: '''GL_T2F_V3F'''), während der zweite Parameter den Speicherplatz, der zwischen zwei Vertices liegt, angibt. Würden wir ein einfaches Vertexarray zeichnen, so wäre der letzte Parameter ein Pointer auf die Vertexdaten im Hauptspeicher. Da wir allerdings vorher unser VBO gebunden haben, teilt hier ein '''nil''' mit, dass die vorher ins VBO geschriebenen Vertexdaten gerendert werden sollen.

Mittels [[glDrawArrays]] sagen wir OpenGL dann noch, das es unsere VBO-Daten als Quads rendern soll.

==Freigabe==

Wie mit allen Objekten in der OpenGL ists auch keine schlechte Idee, unser VBO freizugeben,wenn es nicht mehr benötigt wird. Und obwohl beim Löschen des Renderkontextes solche Objekte vom Grafikkartentreiber freigegeben werden sollten, wäre es keine schlechte Idee des selbst zu erledigen,für den Fall das der Treiber da schlampig arbeitet:

<source lang="pascal">
glDeleteBuffers(1, @VBO);
</source>

==Weitere Vertexformate==
Wem allein Texturkoordinaten und Vertices nicht reichen, sondern auch Farbangaben oder Vertexnormalen braucht, muss sich eines der folgenden Formate aussuchen. Die Konstantennamen sind logisch aufgebaut: ''GL_AngabeAnzahlTyp_AngabeAnzahlTyp...''
Als Angabe gibt es '''V'''ertex, '''T'''exturkoordinaten, '''N'''ormalen und '''C'''olor-Werte, also Farben.
Anzahl ist die Anzahl der Komponenten pro Angabe (V3 wären zum Bespiel die X, Y und Z-Koordinaten eines dreidimensionalen Vertex).
Typ ist entweder '''F'''loat oder '''U'''nsigned '''B'''yte. Die Vertexdaten müssen in der richtigen Reihenfolge mit den richtigen Typen an das VBO übergeben werden.

<source lang="pascal">
GL_V2F
GL_V3F
GL_C4UB_V2F
GL_C4UB_V3F
GL_C3F_V3F
GL_N3F_V3F
GL_C4F_N3F_V3F
GL_T2F_V3F
GL_T4F_V4F
GL_T2F_C4UB_V3F
GL_T2F_C3F_V3F
GL_T2F_N3F_V3F // Wohl eines der sinnvollsten Vertexformate. 2 Floats für Texturkoordinaten, 3 Floats für den Normalenvektor und 3 Floats für den eigentlichen Vertex.
GL_T2F_C4F_N3F_V3F
GL_T4F_C4F_N3F_V4F
</source>

Es ist sinnvoll, sich für jedes der Vertexformate, die man verwendet, einen Typen anzulegen, um später einfacher mit den VBOs arbeiten zu können.

Falls man mit Shadern arbeitet kann man sich die Wahl des Vertexformates eigentlich sparen, denn hier kann man z.B. für jeden Attributtyp den man braucht (Vertex, Normale, Farbe, Normale, etc.) ein eigenes VBO anlegen und dieses dann entsprechend seinen Bedürfnissen im Shader interpretieren, oder einfach nur ein riesiges VBO nutzen und dort alle Daten nach Belieben ablegen und im Shader selbst interpretieren.

==Nachwort==

Das wars auch schon. Wie zu erkennen ist das Vertexbufferobjekt mal wieder eine gut durchdachte, recht nützliche und zudem auch weit nutzbare Erweiterung, die OpenGL technisch wieder einen Schritt weitergebracht hat.

Wer mehr wissen will, der sollte sich unbedingt mal die passende [http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt Spezifikation] ansehen.

Hoffe das Tutorial hat euch soviel Spaß gemacht wie mir das Verfassen des selbigen und ich hoffe auf reges Feedback!

Euer

Sascha Willems (webmaster_at_delphigl.de)

==Links==
[http://developer.nvidia.com/attach/6427 Nvidia: Using Vertex Buffer Objects]

[http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt Spezifikation]

{{TUTORIAL_NAVIGATION|[[Tutorial_Cubemap]]|[[Tutorial_Vertexprogramme]]}}

[[Kategorie:Tutorial|Vertexbuffer]]

Tutorial Vertexbufferobject

2011-05-04T08:22:41Z

Coolcat: /* Erstellen des Vertexbufferobjects */ ARB entfernt

=GL_ARB_Vertex_Buffer_Object=
==Ave!==

Und willkommen zu meinem zweiten GL_ARB-Extension Tutorial. Diesmal beschäftigen wir uns mit der recht neuen '''GL_ARB_Vertex_Buffer_Object'''-Extension, die vom ARB am 12.Februar 2003 fertiggestellt und später im Jahr 2003 auch als Corefeature in OpenGL 1.5 promoted wurde.

VBOs (Vertex Buffer Objects) sind quasi eine Erweiterung der recht weit verbreiteten Vertexarrays, die jedoch den großen Vorteil besitzen, dass ihre Vertexdaten serverseitig, also im schnellen VRAM der Grafikkarte, statt wie bei den VAs im Hauptspeicher, abgelegt werden. Das ist bei einer Displayliste zwar (fast) genauso der Fall, allerdings können die Daten nicht so einfach dynamisch geändert werden, was bei einem VBO aber bei Bedarf sehr einfach ist.

Kurz gesagt vereint das VBO also die Flexibilität eines Vertexarrays mit der Geschwindigkeit einer Displayliste und eignet sich daher besonders für das Rendern aufwändiger Geometrie, egal ob statisch oder dynamisch.

Eine weitere tolle Neuerung der VBO-API ist die Tatsache, dass man sich von OpenGL einen Pointer übergeben lassen kann, mit dessen Hilfe man Vertexdaten direkt in den VRAM schreiben kann. Dadurch spart man sich natürlich den Umweg über den Hauptspeicher und somit auch den erhöhten Speicherbedarf des Programmes beim Laden von Modellen o. Ä.

VBOs bieten übrigens auch die Möglichkeit, sie je nach Anwendungsfall vom Grafikkartentreiber "optimieren" zu lassen. So legt man Vertexdaten, die im Nachhinein nicht mehr verändert werden sollenm am besten mit dem Schlüsselwort ''STATIC_DRAW'' ab, während dynamische Vertexdaten über ''DYNAMIC_DRAW'' abgelegt werden sollten. Doch dazu gibts später nähere Informationen.

==Hardwareunterstützung==

Inzwischen sollten alle gängigen Grafikkarten diese Extension problemlos unterstützen, ältere Modelle tun dies aber evtl. nur emuliert über den Treiber. Will man sein Programm auch für sehr alte Hardware (Karten älter als ATIs Radeon 9x00 bzw. NVidias GeForce 4-Serie) lauffähig machen, sollte man noch einen alternativen Renderpfad auf Basis von Displaylisten einbauen.

==Erstellen des Vertexbufferobjects==

Wie der Name vermuten lässt, handelt es sich beim VBO um ein Objekt, welches in Sachen Syntax an die anderen in OpenGL verfügbaren Objekte wie z. B. Texturenobjekte angelehnt ist. Das Erstellen eines VBOs geht daher genauso einfach von der Hand:

<source lang="pascal">
glGenBuffers(1, @VBO);
</source>

Nun sollten wir in VBO eine gültige ID zurückgeliefert bekommen haben, welche ein Vertex buffer object referenziert.

Nachdem wir nun ein VBO erstellt haben, sollten wir dieses natürlich auch "aktivieren" (also binden), damit wir mit ihm arbeiten können:

<source lang="pascal">
glBindBuffer(GL_ARRAY_BUFFER, VBO);
glEnableClientState(GL_VERTEX_ARRAY);
</source>

Wie erwähnt binden wir in der ersten Zeile unser frisch erstelltes VBO, während wir in der zweiten Zeile Vertexarrays auf der Clientseite aktivieren. Dies ist deshalb nötig, da wir das VBO später genauso zeichnen werden wie dies bei einem normalen VA der Fall wäre.

==Übergabe der Vertexdaten (Variante 1: Ohne Umweg über den Hauptspeicher)==

Wie in der Einleitung bereits erwähnt, bietet uns die VBO-API die Möglichkeit, unsere Vertexdaten ohne Umweg über den Hauptspeicher direkt in den Grafikkartenspeicher zu schreiben. Da dies eines der besten Features dieser neuen Extension ist, wollen wir uns auch zuerst mit dieser Übergabemethode beschäftigen.

''Allerdings erstmal eine kleine Warnung vorweg: Pointer sind ein recht komplexes Thema, und ihre Nutzung erfordert einige Kenntnisse. Wer weder weiß, wie man damit umgeht, noch wie man sie einsetzt, sollte sich da zuerstmal schlau machen. Denn mit Pointer kann man ganz böse Sachen machen, wenn man sie nicht richtig nutzen kann!''

Um unsere Vertexdaten als Pointer zu nutzen,müssen wir erstmal eine Vertexstruktur erstellen und auch einen passenden Pointertyp. Der Pointertyp ist zwar nicht zwingend (ein ^ täte es auch), aber macht die Sache übersichtlicher:

<source lang="pascal">
PVertex = ^TVertex;
TVertex = packed record
S,T,X,Y,Z : TGLFloat;
end;
</source>

Sicher fragen sich einige von euch jetzt, warum unser TVertex gerade so aussieht (also zuerst S,T und dann der Rest). Das liegt daran, dass wir unser VBO später über die Funktion [[glInterleavedArrays]] rendern werden, welche wissen will, wie unsere Vertexdaten im Speicher abgelegt sind. Unsere Vertexstruktur entspricht dabei dem Format ''GL_T2F_V3F''. ''T2F'' entspricht 2 Floats für die Texturenkoordinaten (S&T), gefolgt von ''V3F'' für die drei Floatwerte die unsere Vertexkoordinaten repräsentieren. Wenn ihr ein anderes Vertexformat verwendet, müsst ihr euch auch ein passendes Vertexformat aus der Spezifikation heraussuchen.
Ich verwende oben übrigens einen '''packed Record''' (auch wenn dies bei unserem Vertexformat nicht unbedingt ein Muss ist). Dies tue ich deshalb, da Delphi Werte bei einem normalen Record für einen beschleunigten Zugriff an einem (Double)Word-Raster ausrichtet und dies deshalb bei bestimmten Vertexformaten Probleme bereiten könnte.

Hoffe mal das euch obiges klar ist,denn jetzt gehts ans Eingemachte. Wir kommen zum "schwersten" (ist ja ein relativer Begriff) Teil des Tutorials, nämlich der Übergabe der Vertexdaten an das VBO. Dazu müssen wir OpenGL zuerstmal mitteilen, wie groß unser VBO eigentlich sein soll,damit wir auch genug Platz im VRAM bekommen:

<source lang="pascal">
glBufferData(GL_ARRAY_BUFFER, VertexAnzahl*SizeOf(TVertex), nil, GL_STATIC_DRAW);
</source>

Schauen wir uns also mal die Parameter von [[glBufferData]] an. Zuerst müssen wir OpenGL mitteilen, was für einen Puffer wir erstellen wollen (in zukünftigen Versionen werden wohl noch andere folgen, z. B. Überbuffer). In unserem Falle also einen Arraypuffer. Parameter zwei übergibt dann den Speicherplatz, den wir reservieren wollen und ist recht selbsterklärend. Der dritte Parameter würde normalerweise einen Pointer auf unsere Vertexdaten enthalten. Da wir diese aber nicht im Hauptspeicher abgelegt haben, sondern über einen Pointer dort noch ablegen wollen, übergeben wir hier '''nil'''. OpenGL nimmt dies zur Kenntnis und spuckt dementsprechend auch keinen Fehler aus.

Den letzten Parameter hab ich auch schon kurz in der Einführung angesprochen. Er teilt OpenGL mit, auf welchen Anwendungsfall unser VBO optimiert werden soll. Dabei gibt es folgende Anwendungsfälle,die ihr euch dann entsprechend eurer VBO-Verwendung aussuchen könnt:

{|rules="all" border = "1"
! STREAM_DRAW
| Die Vertexdaten werden einmal übergeben und dann eher selten als Quelle für OpenGL-Befehle genutzt.
|-
! STREAM_READ
| Die Vertexdaten werden einmal übergeben und dann selten von der Anwendung angefordert.
|-
! STREAM_COPY
| Die Vertexdaten werden einmal durch Kopieren von der GL übergeben und dann eher selten als Quelle für OpenGL-Befehle genutzt.
|-
! STATIC_DRAW
| Die Vertexdaten werden einmal übergeben und dann recht oft von der Anwendung zum Rendern genutzt.
|-
! STATIC_READ
| Die Vertexdaten werden einmal übergeben und dann recht oft von der Anwendung angefordert.
|-
! STATIC_COPY
| Die Vertexdaten werden einmal durch Kopieren von der GL übergeben und dann recht oft von der Anwendung zum Rendern genutzt.
|-
! DYNAMIC_DRAW
| Die Vertexdaten werden wiederholt angegeben (verändert) und recht oft von der Anwendung zum Rendern genutzt.
|-
! DYNAMIC_READ
| Die Vertexdaten werden wiederholt durch das Auslesen von Daten durch OpenGL angegeben (verändert) und oft von der Anwendung angefordert.
|-
! DYNAMIC_COPY
| Die Vertexdaten werden wiederholt durch das Auslesen von Daten durch OpenGL angegeben (verändert) und recht oft zum Rendern genutzt.
|}

Beachtet werden sollte, dass es sich bei obigen Anwendungsmuster nur um Hinweise (Hints) handelt, die es auch in anderen Bereichen von OpenGL gibt. Diese Hinweise sind allerdings nicht verbindlich und werden von Treiber zu Treiber unterschiedlich behandelt.

Nachdem OpenGL nun weiss was für ein VBO wir genau haben wollen, brauchen wir letztendlich nur noch einen Pointer, der "auf" das VBO zeigt:

<source lang="pascal">
VBOPointer := glMapBuffer(GL_ARRAY_BUFFER, GL_WRITE_ONLY);
</source>

Die Funktion [[glMapBuffer]] liefert uns einen Pointer zurück, der den Speicherplatz des VBOs in den Adressraum des Clients "ummappt", also in den Hauptspeicher. Dadurch wird es dann möglich, über eine Adresse im Hauptspeicher des Rechners direkt in den Grafikkartenspeicher zu schreiben. Der zweite Parameter gibt übrigens an, das wir in das VBO schreiben wollen. Der einzige weitere zulässige Parameter ist hier '''GL_READ_ONLY''', welcher zum Auslesen des VBOs dient.

Endlich haben wir einen Pointer auf unser inzwischen auch im VRAM der Grafikkarte richtig dimensioniertes Vertexbufferobject, und sind nun in der Lage dort unsere Vertexdaten abzulegen. Was jetzt folgt ist ein wenig Pseudo-Code der diesen Vorgang darstellt. Pseudo-Code deshalb, weil die Vertexdaten die ins VBO kommen ja in jeder Anwendung unterschiedlich sind, und man so auch selbst ein wenig denken muss:

<source lang="pascal">
VertexDatenLaenge := 0;
for i := 0 to High(MeineVertexDaten) do
begin
VertexPointer := VBOPointer;

VertexPointer^.X := GeneriertesVertex.X;
VertexPointer^.Y := GeneriertesVertex.Y;
VertexPointer^.Z := GeneriertesVertex.Z;
VertexPointer^.S := GeneriertesVertex.S;
VertexPointer^.T := GeneriertesVertex.T;

inc(Integer(VBOPointer), SizeOf(TVertex));

inc(VertexDatenLaenge);
end;
</source>

Da sich dieses Tutorial (und v. a. diese Methode der Vertexdatenübergabe) an die fortgeschritteneren wendet, rede ich nicht lange um den heissen Brei herum. Wir durchlaufen also eine Schleife, in der wir unsere Vertexdaten dynamisch erstellen. Entweder in jedem Durchlauf, oder wir laden die Daten vor der Schleife z. B. aus einem 3D-Modell und entfernen sie danach aus dem Hauptspeicher. Erste Methode spart sowohl beim Programmstart, also auch während des Programmlaufes Arbeitsspeicher, während letztere dies nur während des Programmablaufs macht.

Wir setzen die Adresse des Pointers der auf das momentan zu verändernde Vertex zeigt also auf die aktuelle Zeigerposition im VBO und schreiben dann unser Vertex direkt in den Grafikkartenspeicher. Ist dies getan, müssen wir die Adresse unseres VBOPointers natürlich um die Größe des gerade geschriebenen Vertexes erhöhen. Der Typecast auf ein Integer geschieht deshalb, weil man Pointer in Delphi nicht so einfach erhöhen oder verringern kann, Integers hingegen schon.

Ich gehe mal davon aus,das meine Leserschaft mit obigem Codeschnippsel keinerlei Probleme hatte und bringe diese Methode der Übergabe von Vertexdaten an das VBO dann auch mit folgender Quellcodezeile zu Ende:

<source lang="pascal">
glUnMapBuffer(GL_ARRAY_BUFFER);
</source>

Wie unschwer zu erraten geben wir hier unser VBO für den weiteren Zugriff wieder frei. Dies ist nötig um dies später rendern zu können.

==Übergabe der Vertexdaten (Variante 2: Über den Hauptspeicher)==

Wem obige Variante nicht zugesagt hat, weil sie ihm zu komplex war, oder weil er seine Vertexdaten aus diversen Gründen im Hauptspeicher braucht, dem wird in diesem Abschnitt geholfen.

Das Übergeben der Vertexdaten an das VBO über den Hauptspeicher gestaltet sich nämlich sehr einfach:

<source lang="pascal">
glBufferData(GL_ARRAY_BUFFER, SizeOf(VertexDaten), @VertexDaten, GL_STATIC_DRAW);
</source>

Sieht einfach aus,hört sich einfach an und ist auch einfach! Statt wie im letzten Kapitel für die Vertexdaten einen Zeiger auf '''nil''' zu übergeben, übergeben wir OpenGL jetzt einen direkten Zeiger auf die Vertexdaten die im Hauptspeicher abgelegt sind. Die Daten werden dann zum VBO hochgeladen, und können anschliessen auch wieder aus dem Hauptspeicher entfernt werden.

==Rendern des VBOs==

Kommen wir nun also schon zum Ende unseres VBO-Tutorials. Dank der Einfachheit dieser Extension gabs halt einfach nicht mehr zu erklären. Das Zeichnen gestaltet sich nämlich OpenGL-typisch mehr als einfach:

<source lang="pascal">
glInterleavedArrays(GL_T2F_V3F, SizeOf(TVertex), nil);
glDrawArrays(GL_QUADS, 0, VertexDatenLaenge);
</source>

Schnell gezeichnet und schnell erklärt. Der erste Parameter gibt an, in welchem Format die Vertexdaten unseres VBOs abgelegt wurden (wir erinnern uns: '''GL_T2F_V3F'''), während der zweite Parameter den Speicherplatz, der zwischen zwei Vertices liegt, angibt. Würden wir ein einfaches Vertexarray zeichnen, so wäre der letzte Parameter ein Pointer auf die Vertexdaten im Hauptspeicher. Da wir allerdings vorher unser VBO gebunden haben, teilt hier ein '''nil''' mit, dass die vorher ins VBO geschriebenen Vertexdaten gerendert werden sollen.

Mittels [[glDrawArrays]] sagen wir OpenGL dann noch, das es unsere VBO-Daten als Quads rendern soll.

==Freigabe==

Wie mit allen Objekten in der OpenGL ists auch keine schlechte Idee, unser VBO freizugeben,wenn es nicht mehr benötigt wird. Und obwohl beim Löschen des Renderkontextes solche Objekte vom Grafikkartentreiber freigegeben werden sollten, wäre es keine schlechte Idee des selbst zu erledigen,für den Fall das der Treiber da schlampig arbeitet:

<source lang="pascal">
glDeleteBuffers(1, @VBO);
</source>

==Weitere Vertexformate==
Wem allein Texturkoordinaten und Vertices nicht reichen, sondern auch Farbangaben oder Vertexnormalen braucht, muss sich eines der folgenden Formate aussuchen. Die Konstantennamen sind logisch aufgebaut: ''GL_AngabeAnzahlTyp_AngabeAnzahlTyp...''
Als Angabe gibt es '''V'''ertex, '''T'''exturkoordinaten, '''N'''ormalen und '''C'''olor-Werte, also Farben.
Anzahl ist die Anzahl der Komponenten pro Angabe (V3 wären zum Bespiel die X, Y und Z-Koordinaten eines dreidimensionalen Vertex).
Typ ist entweder '''F'''loat oder '''U'''nsigned '''B'''yte. Die Vertexdaten müssen in der richtigen Reihenfolge mit den richtigen Typen an das VBO übergeben werden.

<source lang="pascal">
GL_V2F
GL_V3F
GL_C4UB_V2F
GL_C4UB_V3F
GL_C3F_V3F
GL_N3F_V3F
GL_C4F_N3F_V3F
GL_T2F_V3F
GL_T4F_V4F
GL_T2F_C4UB_V3F
GL_T2F_C3F_V3F
GL_T2F_N3F_V3F // Wohl eines der sinnvollsten Vertexformate. 2 Floats für Texturkoordinaten, 3 Floats für den Normalenvektor und 3 Floats für den eigentlichen Vertex.
GL_T2F_C4F_N3F_V3F
GL_T4F_C4F_N3F_V4F
</source>

Es ist sinnvoll, sich für jedes der Vertexformate, die man verwendet, einen Typen anzulegen, um später einfacher mit den VBOs arbeiten zu können.

Falls man mit Shadern arbeitet kann man sich die Wahl des Vertexformates eigentlich sparen, denn hier kann man z.B. für jeden Attributtyp den man braucht (Vertex, Normale, Farbe, Normale, etc.) ein eigenes VBO anlegen und dieses dann entsprechend seinen Bedürfnissen im Shader interpretieren, oder einfach nur ein riesiges VBO nutzen und dort alle Daten nach Belieben ablegen und im Shader selbst interpretieren.

==Nachwort==

Das wars auch schon. Wie zu erkennen ist das Vertexbufferobjekt mal wieder eine gut durchdachte, recht nützliche und zudem auch weit nutzbare Erweiterung, die OpenGL technisch wieder einen Schritt weitergebracht hat.

Wer mehr wissen will, der sollte sich unbedingt mal die passende [http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt Spezifikation] ansehen.

Hoffe das Tutorial hat euch soviel Spaß gemacht wie mir das Verfassen des selbigen und ich hoffe auf reges Feedback!

Euer

Sascha Willems (webmaster_at_delphigl.de)

==Links==
[http://developer.nvidia.com/attach/6427 Nvidia: Using Vertex Buffer Objects]

[http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt Spezifikation]

{{TUTORIAL_NAVIGATION|[[Tutorial_Cubemap]]|[[Tutorial_Vertexprogramme]]}}

[[Kategorie:Tutorial|Vertexbuffer]]

Tutorial Vertexbufferobject

2011-05-04T08:22:20Z

Coolcat: /* Übergabe der Vertexdaten (Variante 1: Ohne Umweg über den Hauptspeicher) */ ARB entfernt...

=GL_ARB_Vertex_Buffer_Object=
==Ave!==

Und willkommen zu meinem zweiten GL_ARB-Extension Tutorial. Diesmal beschäftigen wir uns mit der recht neuen '''GL_ARB_Vertex_Buffer_Object'''-Extension, die vom ARB am 12.Februar 2003 fertiggestellt und später im Jahr 2003 auch als Corefeature in OpenGL 1.5 promoted wurde.

VBOs (Vertex Buffer Objects) sind quasi eine Erweiterung der recht weit verbreiteten Vertexarrays, die jedoch den großen Vorteil besitzen, dass ihre Vertexdaten serverseitig, also im schnellen VRAM der Grafikkarte, statt wie bei den VAs im Hauptspeicher, abgelegt werden. Das ist bei einer Displayliste zwar (fast) genauso der Fall, allerdings können die Daten nicht so einfach dynamisch geändert werden, was bei einem VBO aber bei Bedarf sehr einfach ist.

Kurz gesagt vereint das VBO also die Flexibilität eines Vertexarrays mit der Geschwindigkeit einer Displayliste und eignet sich daher besonders für das Rendern aufwändiger Geometrie, egal ob statisch oder dynamisch.

Eine weitere tolle Neuerung der VBO-API ist die Tatsache, dass man sich von OpenGL einen Pointer übergeben lassen kann, mit dessen Hilfe man Vertexdaten direkt in den VRAM schreiben kann. Dadurch spart man sich natürlich den Umweg über den Hauptspeicher und somit auch den erhöhten Speicherbedarf des Programmes beim Laden von Modellen o. Ä.

VBOs bieten übrigens auch die Möglichkeit, sie je nach Anwendungsfall vom Grafikkartentreiber "optimieren" zu lassen. So legt man Vertexdaten, die im Nachhinein nicht mehr verändert werden sollenm am besten mit dem Schlüsselwort ''STATIC_DRAW'' ab, während dynamische Vertexdaten über ''DYNAMIC_DRAW'' abgelegt werden sollten. Doch dazu gibts später nähere Informationen.

==Hardwareunterstützung==

Inzwischen sollten alle gängigen Grafikkarten diese Extension problemlos unterstützen, ältere Modelle tun dies aber evtl. nur emuliert über den Treiber. Will man sein Programm auch für sehr alte Hardware (Karten älter als ATIs Radeon 9x00 bzw. NVidias GeForce 4-Serie) lauffähig machen, sollte man noch einen alternativen Renderpfad auf Basis von Displaylisten einbauen.

==Erstellen des Vertexbufferobjects==

Wie der Name vermuten lässt, handelt es sich beim VBO um ein Objekt, welches in Sachen Syntax an die anderen in OpenGL verfügbaren Objekte wie z. B. Texturenobjekte angelehnt ist. Das Erstellen eines VBOs geht daher genauso einfach von der Hand:

<source lang="pascal">
glGenBuffers(1, @VBO);
</source>

Nun sollten wir in VBO eine gültige ID zurückgeliefert bekommen haben, welche ein Vertex buffer object referenziert.

Nachdem wir nun ein VBO erstellt haben, sollten wir dieses natürlich auch "aktivieren" (also binden), damit wir mit ihm arbeiten können:

<source lang="pascal">
glBindBufferARB(GL_ARRAY_BUFFER, VBO);
glEnableClientState(GL_VERTEX_ARRAY);
</source>

Wie erwähnt binden wir in der ersten Zeile unser frisch erstelltes VBO, während wir in der zweiten Zeile Vertexarrays auf der Clientseite aktivieren. Dies ist deshalb nötig, da wir das VBO später genauso zeichnen werden wie dies bei einem normalen VA der Fall wäre.

==Übergabe der Vertexdaten (Variante 1: Ohne Umweg über den Hauptspeicher)==

Wie in der Einleitung bereits erwähnt, bietet uns die VBO-API die Möglichkeit, unsere Vertexdaten ohne Umweg über den Hauptspeicher direkt in den Grafikkartenspeicher zu schreiben. Da dies eines der besten Features dieser neuen Extension ist, wollen wir uns auch zuerst mit dieser Übergabemethode beschäftigen.

''Allerdings erstmal eine kleine Warnung vorweg: Pointer sind ein recht komplexes Thema, und ihre Nutzung erfordert einige Kenntnisse. Wer weder weiß, wie man damit umgeht, noch wie man sie einsetzt, sollte sich da zuerstmal schlau machen. Denn mit Pointer kann man ganz böse Sachen machen, wenn man sie nicht richtig nutzen kann!''

Um unsere Vertexdaten als Pointer zu nutzen,müssen wir erstmal eine Vertexstruktur erstellen und auch einen passenden Pointertyp. Der Pointertyp ist zwar nicht zwingend (ein ^ täte es auch), aber macht die Sache übersichtlicher:

<source lang="pascal">
PVertex = ^TVertex;
TVertex = packed record
S,T,X,Y,Z : TGLFloat;
end;
</source>

Sicher fragen sich einige von euch jetzt, warum unser TVertex gerade so aussieht (also zuerst S,T und dann der Rest). Das liegt daran, dass wir unser VBO später über die Funktion [[glInterleavedArrays]] rendern werden, welche wissen will, wie unsere Vertexdaten im Speicher abgelegt sind. Unsere Vertexstruktur entspricht dabei dem Format ''GL_T2F_V3F''. ''T2F'' entspricht 2 Floats für die Texturenkoordinaten (S&T), gefolgt von ''V3F'' für die drei Floatwerte die unsere Vertexkoordinaten repräsentieren. Wenn ihr ein anderes Vertexformat verwendet, müsst ihr euch auch ein passendes Vertexformat aus der Spezifikation heraussuchen.
Ich verwende oben übrigens einen '''packed Record''' (auch wenn dies bei unserem Vertexformat nicht unbedingt ein Muss ist). Dies tue ich deshalb, da Delphi Werte bei einem normalen Record für einen beschleunigten Zugriff an einem (Double)Word-Raster ausrichtet und dies deshalb bei bestimmten Vertexformaten Probleme bereiten könnte.

Hoffe mal das euch obiges klar ist,denn jetzt gehts ans Eingemachte. Wir kommen zum "schwersten" (ist ja ein relativer Begriff) Teil des Tutorials, nämlich der Übergabe der Vertexdaten an das VBO. Dazu müssen wir OpenGL zuerstmal mitteilen, wie groß unser VBO eigentlich sein soll,damit wir auch genug Platz im VRAM bekommen:

<source lang="pascal">
glBufferData(GL_ARRAY_BUFFER, VertexAnzahl*SizeOf(TVertex), nil, GL_STATIC_DRAW);
</source>

Schauen wir uns also mal die Parameter von [[glBufferData]] an. Zuerst müssen wir OpenGL mitteilen, was für einen Puffer wir erstellen wollen (in zukünftigen Versionen werden wohl noch andere folgen, z. B. Überbuffer). In unserem Falle also einen Arraypuffer. Parameter zwei übergibt dann den Speicherplatz, den wir reservieren wollen und ist recht selbsterklärend. Der dritte Parameter würde normalerweise einen Pointer auf unsere Vertexdaten enthalten. Da wir diese aber nicht im Hauptspeicher abgelegt haben, sondern über einen Pointer dort noch ablegen wollen, übergeben wir hier '''nil'''. OpenGL nimmt dies zur Kenntnis und spuckt dementsprechend auch keinen Fehler aus.

Den letzten Parameter hab ich auch schon kurz in der Einführung angesprochen. Er teilt OpenGL mit, auf welchen Anwendungsfall unser VBO optimiert werden soll. Dabei gibt es folgende Anwendungsfälle,die ihr euch dann entsprechend eurer VBO-Verwendung aussuchen könnt:

{|rules="all" border = "1"
! STREAM_DRAW
| Die Vertexdaten werden einmal übergeben und dann eher selten als Quelle für OpenGL-Befehle genutzt.
|-
! STREAM_READ
| Die Vertexdaten werden einmal übergeben und dann selten von der Anwendung angefordert.
|-
! STREAM_COPY
| Die Vertexdaten werden einmal durch Kopieren von der GL übergeben und dann eher selten als Quelle für OpenGL-Befehle genutzt.
|-
! STATIC_DRAW
| Die Vertexdaten werden einmal übergeben und dann recht oft von der Anwendung zum Rendern genutzt.
|-
! STATIC_READ
| Die Vertexdaten werden einmal übergeben und dann recht oft von der Anwendung angefordert.
|-
! STATIC_COPY
| Die Vertexdaten werden einmal durch Kopieren von der GL übergeben und dann recht oft von der Anwendung zum Rendern genutzt.
|-
! DYNAMIC_DRAW
| Die Vertexdaten werden wiederholt angegeben (verändert) und recht oft von der Anwendung zum Rendern genutzt.
|-
! DYNAMIC_READ
| Die Vertexdaten werden wiederholt durch das Auslesen von Daten durch OpenGL angegeben (verändert) und oft von der Anwendung angefordert.
|-
! DYNAMIC_COPY
| Die Vertexdaten werden wiederholt durch das Auslesen von Daten durch OpenGL angegeben (verändert) und recht oft zum Rendern genutzt.
|}

Beachtet werden sollte, dass es sich bei obigen Anwendungsmuster nur um Hinweise (Hints) handelt, die es auch in anderen Bereichen von OpenGL gibt. Diese Hinweise sind allerdings nicht verbindlich und werden von Treiber zu Treiber unterschiedlich behandelt.

Nachdem OpenGL nun weiss was für ein VBO wir genau haben wollen, brauchen wir letztendlich nur noch einen Pointer, der "auf" das VBO zeigt:

<source lang="pascal">
VBOPointer := glMapBuffer(GL_ARRAY_BUFFER, GL_WRITE_ONLY);
</source>

Die Funktion [[glMapBuffer]] liefert uns einen Pointer zurück, der den Speicherplatz des VBOs in den Adressraum des Clients "ummappt", also in den Hauptspeicher. Dadurch wird es dann möglich, über eine Adresse im Hauptspeicher des Rechners direkt in den Grafikkartenspeicher zu schreiben. Der zweite Parameter gibt übrigens an, das wir in das VBO schreiben wollen. Der einzige weitere zulässige Parameter ist hier '''GL_READ_ONLY''', welcher zum Auslesen des VBOs dient.

Endlich haben wir einen Pointer auf unser inzwischen auch im VRAM der Grafikkarte richtig dimensioniertes Vertexbufferobject, und sind nun in der Lage dort unsere Vertexdaten abzulegen. Was jetzt folgt ist ein wenig Pseudo-Code der diesen Vorgang darstellt. Pseudo-Code deshalb, weil die Vertexdaten die ins VBO kommen ja in jeder Anwendung unterschiedlich sind, und man so auch selbst ein wenig denken muss:

<source lang="pascal">
VertexDatenLaenge := 0;
for i := 0 to High(MeineVertexDaten) do
begin
VertexPointer := VBOPointer;

VertexPointer^.X := GeneriertesVertex.X;
VertexPointer^.Y := GeneriertesVertex.Y;
VertexPointer^.Z := GeneriertesVertex.Z;
VertexPointer^.S := GeneriertesVertex.S;
VertexPointer^.T := GeneriertesVertex.T;

inc(Integer(VBOPointer), SizeOf(TVertex));

inc(VertexDatenLaenge);
end;
</source>

Da sich dieses Tutorial (und v. a. diese Methode der Vertexdatenübergabe) an die fortgeschritteneren wendet, rede ich nicht lange um den heissen Brei herum. Wir durchlaufen also eine Schleife, in der wir unsere Vertexdaten dynamisch erstellen. Entweder in jedem Durchlauf, oder wir laden die Daten vor der Schleife z. B. aus einem 3D-Modell und entfernen sie danach aus dem Hauptspeicher. Erste Methode spart sowohl beim Programmstart, also auch während des Programmlaufes Arbeitsspeicher, während letztere dies nur während des Programmablaufs macht.

Wir setzen die Adresse des Pointers der auf das momentan zu verändernde Vertex zeigt also auf die aktuelle Zeigerposition im VBO und schreiben dann unser Vertex direkt in den Grafikkartenspeicher. Ist dies getan, müssen wir die Adresse unseres VBOPointers natürlich um die Größe des gerade geschriebenen Vertexes erhöhen. Der Typecast auf ein Integer geschieht deshalb, weil man Pointer in Delphi nicht so einfach erhöhen oder verringern kann, Integers hingegen schon.

Ich gehe mal davon aus,das meine Leserschaft mit obigem Codeschnippsel keinerlei Probleme hatte und bringe diese Methode der Übergabe von Vertexdaten an das VBO dann auch mit folgender Quellcodezeile zu Ende:

<source lang="pascal">
glUnMapBuffer(GL_ARRAY_BUFFER);
</source>

Wie unschwer zu erraten geben wir hier unser VBO für den weiteren Zugriff wieder frei. Dies ist nötig um dies später rendern zu können.

==Übergabe der Vertexdaten (Variante 2: Über den Hauptspeicher)==

Wem obige Variante nicht zugesagt hat, weil sie ihm zu komplex war, oder weil er seine Vertexdaten aus diversen Gründen im Hauptspeicher braucht, dem wird in diesem Abschnitt geholfen.

Das Übergeben der Vertexdaten an das VBO über den Hauptspeicher gestaltet sich nämlich sehr einfach:

<source lang="pascal">
glBufferData(GL_ARRAY_BUFFER, SizeOf(VertexDaten), @VertexDaten, GL_STATIC_DRAW);
</source>

Sieht einfach aus,hört sich einfach an und ist auch einfach! Statt wie im letzten Kapitel für die Vertexdaten einen Zeiger auf '''nil''' zu übergeben, übergeben wir OpenGL jetzt einen direkten Zeiger auf die Vertexdaten die im Hauptspeicher abgelegt sind. Die Daten werden dann zum VBO hochgeladen, und können anschliessen auch wieder aus dem Hauptspeicher entfernt werden.

==Rendern des VBOs==

Kommen wir nun also schon zum Ende unseres VBO-Tutorials. Dank der Einfachheit dieser Extension gabs halt einfach nicht mehr zu erklären. Das Zeichnen gestaltet sich nämlich OpenGL-typisch mehr als einfach:

<source lang="pascal">
glInterleavedArrays(GL_T2F_V3F, SizeOf(TVertex), nil);
glDrawArrays(GL_QUADS, 0, VertexDatenLaenge);
</source>

Schnell gezeichnet und schnell erklärt. Der erste Parameter gibt an, in welchem Format die Vertexdaten unseres VBOs abgelegt wurden (wir erinnern uns: '''GL_T2F_V3F'''), während der zweite Parameter den Speicherplatz, der zwischen zwei Vertices liegt, angibt. Würden wir ein einfaches Vertexarray zeichnen, so wäre der letzte Parameter ein Pointer auf die Vertexdaten im Hauptspeicher. Da wir allerdings vorher unser VBO gebunden haben, teilt hier ein '''nil''' mit, dass die vorher ins VBO geschriebenen Vertexdaten gerendert werden sollen.

Mittels [[glDrawArrays]] sagen wir OpenGL dann noch, das es unsere VBO-Daten als Quads rendern soll.

==Freigabe==

Wie mit allen Objekten in der OpenGL ists auch keine schlechte Idee, unser VBO freizugeben,wenn es nicht mehr benötigt wird. Und obwohl beim Löschen des Renderkontextes solche Objekte vom Grafikkartentreiber freigegeben werden sollten, wäre es keine schlechte Idee des selbst zu erledigen,für den Fall das der Treiber da schlampig arbeitet:

<source lang="pascal">
glDeleteBuffers(1, @VBO);
</source>

==Weitere Vertexformate==
Wem allein Texturkoordinaten und Vertices nicht reichen, sondern auch Farbangaben oder Vertexnormalen braucht, muss sich eines der folgenden Formate aussuchen. Die Konstantennamen sind logisch aufgebaut: ''GL_AngabeAnzahlTyp_AngabeAnzahlTyp...''
Als Angabe gibt es '''V'''ertex, '''T'''exturkoordinaten, '''N'''ormalen und '''C'''olor-Werte, also Farben.
Anzahl ist die Anzahl der Komponenten pro Angabe (V3 wären zum Bespiel die X, Y und Z-Koordinaten eines dreidimensionalen Vertex).
Typ ist entweder '''F'''loat oder '''U'''nsigned '''B'''yte. Die Vertexdaten müssen in der richtigen Reihenfolge mit den richtigen Typen an das VBO übergeben werden.

<source lang="pascal">
GL_V2F
GL_V3F
GL_C4UB_V2F
GL_C4UB_V3F
GL_C3F_V3F
GL_N3F_V3F
GL_C4F_N3F_V3F
GL_T2F_V3F
GL_T4F_V4F
GL_T2F_C4UB_V3F
GL_T2F_C3F_V3F
GL_T2F_N3F_V3F // Wohl eines der sinnvollsten Vertexformate. 2 Floats für Texturkoordinaten, 3 Floats für den Normalenvektor und 3 Floats für den eigentlichen Vertex.
GL_T2F_C4F_N3F_V3F
GL_T4F_C4F_N3F_V4F
</source>

Es ist sinnvoll, sich für jedes der Vertexformate, die man verwendet, einen Typen anzulegen, um später einfacher mit den VBOs arbeiten zu können.

Falls man mit Shadern arbeitet kann man sich die Wahl des Vertexformates eigentlich sparen, denn hier kann man z.B. für jeden Attributtyp den man braucht (Vertex, Normale, Farbe, Normale, etc.) ein eigenes VBO anlegen und dieses dann entsprechend seinen Bedürfnissen im Shader interpretieren, oder einfach nur ein riesiges VBO nutzen und dort alle Daten nach Belieben ablegen und im Shader selbst interpretieren.

==Nachwort==

Das wars auch schon. Wie zu erkennen ist das Vertexbufferobjekt mal wieder eine gut durchdachte, recht nützliche und zudem auch weit nutzbare Erweiterung, die OpenGL technisch wieder einen Schritt weitergebracht hat.

Wer mehr wissen will, der sollte sich unbedingt mal die passende [http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt Spezifikation] ansehen.

Hoffe das Tutorial hat euch soviel Spaß gemacht wie mir das Verfassen des selbigen und ich hoffe auf reges Feedback!

Euer

Sascha Willems (webmaster_at_delphigl.de)

==Links==
[http://developer.nvidia.com/attach/6427 Nvidia: Using Vertex Buffer Objects]

[http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt Spezifikation]

{{TUTORIAL_NAVIGATION|[[Tutorial_Cubemap]]|[[Tutorial_Vertexprogramme]]}}

[[Kategorie:Tutorial|Vertexbuffer]]

Tutorial Vertexbufferobject

2011-05-04T08:21:00Z

Coolcat: /* Ave! */ "vor kurzem" ist nicht mehr ganz zutreffend

=GL_ARB_Vertex_Buffer_Object=
==Ave!==

Und willkommen zu meinem zweiten GL_ARB-Extension Tutorial. Diesmal beschäftigen wir uns mit der recht neuen '''GL_ARB_Vertex_Buffer_Object'''-Extension, die vom ARB am 12.Februar 2003 fertiggestellt und später im Jahr 2003 auch als Corefeature in OpenGL 1.5 promoted wurde.

VBOs (Vertex Buffer Objects) sind quasi eine Erweiterung der recht weit verbreiteten Vertexarrays, die jedoch den großen Vorteil besitzen, dass ihre Vertexdaten serverseitig, also im schnellen VRAM der Grafikkarte, statt wie bei den VAs im Hauptspeicher, abgelegt werden. Das ist bei einer Displayliste zwar (fast) genauso der Fall, allerdings können die Daten nicht so einfach dynamisch geändert werden, was bei einem VBO aber bei Bedarf sehr einfach ist.

Kurz gesagt vereint das VBO also die Flexibilität eines Vertexarrays mit der Geschwindigkeit einer Displayliste und eignet sich daher besonders für das Rendern aufwändiger Geometrie, egal ob statisch oder dynamisch.

Eine weitere tolle Neuerung der VBO-API ist die Tatsache, dass man sich von OpenGL einen Pointer übergeben lassen kann, mit dessen Hilfe man Vertexdaten direkt in den VRAM schreiben kann. Dadurch spart man sich natürlich den Umweg über den Hauptspeicher und somit auch den erhöhten Speicherbedarf des Programmes beim Laden von Modellen o. Ä.

VBOs bieten übrigens auch die Möglichkeit, sie je nach Anwendungsfall vom Grafikkartentreiber "optimieren" zu lassen. So legt man Vertexdaten, die im Nachhinein nicht mehr verändert werden sollenm am besten mit dem Schlüsselwort ''STATIC_DRAW'' ab, während dynamische Vertexdaten über ''DYNAMIC_DRAW'' abgelegt werden sollten. Doch dazu gibts später nähere Informationen.

==Hardwareunterstützung==

Inzwischen sollten alle gängigen Grafikkarten diese Extension problemlos unterstützen, ältere Modelle tun dies aber evtl. nur emuliert über den Treiber. Will man sein Programm auch für sehr alte Hardware (Karten älter als ATIs Radeon 9x00 bzw. NVidias GeForce 4-Serie) lauffähig machen, sollte man noch einen alternativen Renderpfad auf Basis von Displaylisten einbauen.

==Erstellen des Vertexbufferobjects==

Wie der Name vermuten lässt, handelt es sich beim VBO um ein Objekt, welches in Sachen Syntax an die anderen in OpenGL verfügbaren Objekte wie z. B. Texturenobjekte angelehnt ist. Das Erstellen eines VBOs geht daher genauso einfach von der Hand:

<source lang="pascal">
glGenBuffers(1, @VBO);
</source>

Nun sollten wir in VBO eine gültige ID zurückgeliefert bekommen haben, welche ein Vertex buffer object referenziert.

Nachdem wir nun ein VBO erstellt haben, sollten wir dieses natürlich auch "aktivieren" (also binden), damit wir mit ihm arbeiten können:

<source lang="pascal">
glBindBufferARB(GL_ARRAY_BUFFER, VBO);
glEnableClientState(GL_VERTEX_ARRAY);
</source>

Wie erwähnt binden wir in der ersten Zeile unser frisch erstelltes VBO, während wir in der zweiten Zeile Vertexarrays auf der Clientseite aktivieren. Dies ist deshalb nötig, da wir das VBO später genauso zeichnen werden wie dies bei einem normalen VA der Fall wäre.

==Übergabe der Vertexdaten (Variante 1: Ohne Umweg über den Hauptspeicher)==

Wie in der Einleitung bereits erwähnt, bietet uns die VBO-API die Möglichkeit, unsere Vertexdaten ohne Umweg über den Hauptspeicher direkt in den Grafikkartenspeicher zu schreiben. Da dies eines der besten Features dieser neuen Extension ist, wollen wir uns auch zuerst mit dieser Übergabemethode beschäftigen.

''Allerdings erstmal eine kleine Warnung vorweg: Pointer sind ein recht komplexes Thema, und ihre Nutzung erfordert einige Kenntnisse. Wer weder weiß, wie man damit umgeht, noch wie man sie einsetzt, sollte sich da zuerstmal schlau machen. Denn mit Pointer kann man ganz böse Sachen machen, wenn man sie nicht richtig nutzen kann!''

Um unsere Vertexdaten als Pointer zu nutzen,müssen wir erstmal eine Vertexstruktur erstellen und auch einen passenden Pointertyp. Der Pointertyp ist zwar nicht zwingend (ein ^ täte es auch), aber macht die Sache übersichtlicher:

<source lang="pascal">
PVertex = ^TVertex;
TVertex = packed record
S,T,X,Y,Z : TGLFloat;
end;
</source>

Sicher fragen sich einige von euch jetzt, warum unser TVertex gerade so aussieht (also zuerst S,T und dann der Rest). Das liegt daran, dass wir unser VBO später über die Funktion [[glInterleavedArrays]] rendern werden, welche wissen will, wie unsere Vertexdaten im Speicher abgelegt sind. Unsere Vertexstruktur entspricht dabei dem Format ''GL_T2F_V3F''. ''T2F'' entspricht 2 Floats für die Texturenkoordinaten (S&T), gefolgt von ''V3F'' für die drei Floatwerte die unsere Vertexkoordinaten repräsentieren. Wenn ihr ein anderes Vertexformat verwendet, müsst ihr euch auch ein passendes Vertexformat aus der Spezifikation heraussuchen.
Ich verwende oben übrigens einen '''packed Record''' (auch wenn dies bei unserem Vertexformat nicht unbedingt ein Muss ist). Dies tue ich deshalb, da Delphi Werte bei einem normalen Record für einen beschleunigten Zugriff an einem (Double)Word-Raster ausrichtet und dies deshalb bei bestimmten Vertexformaten Probleme bereiten könnte.

Hoffe mal das euch obiges klar ist,denn jetzt gehts ans Eingemachte. Wir kommen zum "schwersten" (ist ja ein relativer Begriff) Teil des Tutorials, nämlich der Übergabe der Vertexdaten an das VBO. Dazu müssen wir OpenGL zuerstmal mitteilen, wie groß unser VBO eigentlich sein soll,damit wir auch genug Platz im VRAM bekommen:

<source lang="pascal">
glBufferDataARB(GL_ARRAY_BUFFER, VertexAnzahl*SizeOf(TVertex), nil, GL_STATIC_DRAW);
</source>

Schauen wir uns also mal die Parameter von [[glBufferData]] an. Zuerst müssen wir OpenGL mitteilen, was für einen Puffer wir erstellen wollen (in zukünftigen Versionen werden wohl noch andere folgen, z. B. Überbuffer). In unserem Falle also einen Arraypuffer. Parameter zwei übergibt dann den Speicherplatz, den wir reservieren wollen und ist recht selbsterklärend. Der dritte Parameter würde normalerweise einen Pointer auf unsere Vertexdaten enthalten. Da wir diese aber nicht im Hauptspeicher abgelegt haben, sondern über einen Pointer dort noch ablegen wollen, übergeben wir hier '''nil'''. OpenGL nimmt dies zur Kenntnis und spuckt dementsprechend auch keinen Fehler aus.

Den letzten Parameter hab ich auch schon kurz in der Einführung angesprochen. Er teilt OpenGL mit, auf welchen Anwendungsfall unser VBO optimiert werden soll. Dabei gibt es folgende Anwendungsfälle,die ihr euch dann entsprechend eurer VBO-Verwendung aussuchen könnt:

{|rules="all" border = "1"
! STREAM_DRAW
| Die Vertexdaten werden einmal übergeben und dann eher selten als Quelle für OpenGL-Befehle genutzt.
|-
! STREAM_READ
| Die Vertexdaten werden einmal übergeben und dann selten von der Anwendung angefordert.
|-
! STREAM_COPY
| Die Vertexdaten werden einmal durch Kopieren von der GL übergeben und dann eher selten als Quelle für OpenGL-Befehle genutzt.
|-
! STATIC_DRAW
| Die Vertexdaten werden einmal übergeben und dann recht oft von der Anwendung zum Rendern genutzt.
|-
! STATIC_READ
| Die Vertexdaten werden einmal übergeben und dann recht oft von der Anwendung angefordert.
|-
! STATIC_COPY
| Die Vertexdaten werden einmal durch Kopieren von der GL übergeben und dann recht oft von der Anwendung zum Rendern genutzt.
|-
! DYNAMIC_DRAW
| Die Vertexdaten werden wiederholt angegeben (verändert) und recht oft von der Anwendung zum Rendern genutzt.
|-
! DYNAMIC_READ
| Die Vertexdaten werden wiederholt durch das Auslesen von Daten durch OpenGL angegeben (verändert) und oft von der Anwendung angefordert.
|-
! DYNAMIC_COPY
| Die Vertexdaten werden wiederholt durch das Auslesen von Daten durch OpenGL angegeben (verändert) und recht oft zum Rendern genutzt.
|}

Beachtet werden sollte, dass es sich bei obigen Anwendungsmuster nur um Hinweise (Hints) handelt, die es auch in anderen Bereichen von OpenGL gibt. Diese Hinweise sind allerdings nicht verbindlich und werden von Treiber zu Treiber unterschiedlich behandelt.

Nachdem OpenGL nun weiss was für ein VBO wir genau haben wollen, brauchen wir letztendlich nur noch einen Pointer, der "auf" das VBO zeigt:

<source lang="pascal">
VBOPointer := glMapBuffer(GL_ARRAY_BUFFER, GL_WRITE_ONLY);
</source>

Die Funktion [[glMapBuffer]] liefert uns einen Pointer zurück, der den Speicherplatz des VBOs in den Adressraum des Clients "ummappt", also in den Hauptspeicher. Dadurch wird es dann möglich, über eine Adresse im Hauptspeicher des Rechners direkt in den Grafikkartenspeicher zu schreiben. Der zweite Parameter gibt übrigens an, das wir in das VBO schreiben wollen. Der einzige weitere zulässige Parameter ist hier '''GL_READ_ONLY''', welcher zum Auslesen des VBOs dient.

Endlich haben wir einen Pointer auf unser inzwischen auch im VRAM der Grafikkarte richtig dimensioniertes Vertexbufferobject, und sind nun in der Lage dort unsere Vertexdaten abzulegen. Was jetzt folgt ist ein wenig Pseudo-Code der diesen Vorgang darstellt. Pseudo-Code deshalb, weil die Vertexdaten die ins VBO kommen ja in jeder Anwendung unterschiedlich sind, und man so auch selbst ein wenig denken muss:

<source lang="pascal">
VertexDatenLaenge := 0;
for i := 0 to High(MeineVertexDaten) do
begin
VertexPointer := VBOPointer;

VertexPointer^.X := GeneriertesVertex.X;
VertexPointer^.Y := GeneriertesVertex.Y;
VertexPointer^.Z := GeneriertesVertex.Z;
VertexPointer^.S := GeneriertesVertex.S;
VertexPointer^.T := GeneriertesVertex.T;

inc(Integer(VBOPointer), SizeOf(TVertex));

inc(VertexDatenLaenge);
end;
</source>

Da sich dieses Tutorial (und v. a. diese Methode der Vertexdatenübergabe) an die fortgeschritteneren wendet, rede ich nicht lange um den heissen Brei herum. Wir durchlaufen also eine Schleife, in der wir unsere Vertexdaten dynamisch erstellen. Entweder in jedem Durchlauf, oder wir laden die Daten vor der Schleife z. B. aus einem 3D-Modell und entfernen sie danach aus dem Hauptspeicher. Erste Methode spart sowohl beim Programmstart, also auch während des Programmlaufes Arbeitsspeicher, während letztere dies nur während des Programmablaufs macht.

Wir setzen die Adresse des Pointers der auf das momentan zu verändernde Vertex zeigt also auf die aktuelle Zeigerposition im VBO und schreiben dann unser Vertex direkt in den Grafikkartenspeicher. Ist dies getan, müssen wir die Adresse unseres VBOPointers natürlich um die Größe des gerade geschriebenen Vertexes erhöhen. Der Typecast auf ein Integer geschieht deshalb, weil man Pointer in Delphi nicht so einfach erhöhen oder verringern kann, Integers hingegen schon.

Ich gehe mal davon aus,das meine Leserschaft mit obigem Codeschnippsel keinerlei Probleme hatte und bringe diese Methode der Übergabe von Vertexdaten an das VBO dann auch mit folgender Quellcodezeile zu Ende:

<source lang="pascal">
glUnMapBuffer(GL_ARRAY_BUFFER);
</source>

Wie unschwer zu erraten geben wir hier unser VBO für den weiteren Zugriff wieder frei. Dies ist nötig um dies später rendern zu können.

==Übergabe der Vertexdaten (Variante 2: Über den Hauptspeicher)==

Wem obige Variante nicht zugesagt hat, weil sie ihm zu komplex war, oder weil er seine Vertexdaten aus diversen Gründen im Hauptspeicher braucht, dem wird in diesem Abschnitt geholfen.

Das Übergeben der Vertexdaten an das VBO über den Hauptspeicher gestaltet sich nämlich sehr einfach:

<source lang="pascal">
glBufferData(GL_ARRAY_BUFFER, SizeOf(VertexDaten), @VertexDaten, GL_STATIC_DRAW);
</source>

Sieht einfach aus,hört sich einfach an und ist auch einfach! Statt wie im letzten Kapitel für die Vertexdaten einen Zeiger auf '''nil''' zu übergeben, übergeben wir OpenGL jetzt einen direkten Zeiger auf die Vertexdaten die im Hauptspeicher abgelegt sind. Die Daten werden dann zum VBO hochgeladen, und können anschliessen auch wieder aus dem Hauptspeicher entfernt werden.

==Rendern des VBOs==

Kommen wir nun also schon zum Ende unseres VBO-Tutorials. Dank der Einfachheit dieser Extension gabs halt einfach nicht mehr zu erklären. Das Zeichnen gestaltet sich nämlich OpenGL-typisch mehr als einfach:

<source lang="pascal">
glInterleavedArrays(GL_T2F_V3F, SizeOf(TVertex), nil);
glDrawArrays(GL_QUADS, 0, VertexDatenLaenge);
</source>

Schnell gezeichnet und schnell erklärt. Der erste Parameter gibt an, in welchem Format die Vertexdaten unseres VBOs abgelegt wurden (wir erinnern uns: '''GL_T2F_V3F'''), während der zweite Parameter den Speicherplatz, der zwischen zwei Vertices liegt, angibt. Würden wir ein einfaches Vertexarray zeichnen, so wäre der letzte Parameter ein Pointer auf die Vertexdaten im Hauptspeicher. Da wir allerdings vorher unser VBO gebunden haben, teilt hier ein '''nil''' mit, dass die vorher ins VBO geschriebenen Vertexdaten gerendert werden sollen.

Mittels [[glDrawArrays]] sagen wir OpenGL dann noch, das es unsere VBO-Daten als Quads rendern soll.

==Freigabe==

Wie mit allen Objekten in der OpenGL ists auch keine schlechte Idee, unser VBO freizugeben,wenn es nicht mehr benötigt wird. Und obwohl beim Löschen des Renderkontextes solche Objekte vom Grafikkartentreiber freigegeben werden sollten, wäre es keine schlechte Idee des selbst zu erledigen,für den Fall das der Treiber da schlampig arbeitet:

<source lang="pascal">
glDeleteBuffers(1, @VBO);
</source>

==Weitere Vertexformate==
Wem allein Texturkoordinaten und Vertices nicht reichen, sondern auch Farbangaben oder Vertexnormalen braucht, muss sich eines der folgenden Formate aussuchen. Die Konstantennamen sind logisch aufgebaut: ''GL_AngabeAnzahlTyp_AngabeAnzahlTyp...''
Als Angabe gibt es '''V'''ertex, '''T'''exturkoordinaten, '''N'''ormalen und '''C'''olor-Werte, also Farben.
Anzahl ist die Anzahl der Komponenten pro Angabe (V3 wären zum Bespiel die X, Y und Z-Koordinaten eines dreidimensionalen Vertex).
Typ ist entweder '''F'''loat oder '''U'''nsigned '''B'''yte. Die Vertexdaten müssen in der richtigen Reihenfolge mit den richtigen Typen an das VBO übergeben werden.

<source lang="pascal">
GL_V2F
GL_V3F
GL_C4UB_V2F
GL_C4UB_V3F
GL_C3F_V3F
GL_N3F_V3F
GL_C4F_N3F_V3F
GL_T2F_V3F
GL_T4F_V4F
GL_T2F_C4UB_V3F
GL_T2F_C3F_V3F
GL_T2F_N3F_V3F // Wohl eines der sinnvollsten Vertexformate. 2 Floats für Texturkoordinaten, 3 Floats für den Normalenvektor und 3 Floats für den eigentlichen Vertex.
GL_T2F_C4F_N3F_V3F
GL_T4F_C4F_N3F_V4F
</source>

Es ist sinnvoll, sich für jedes der Vertexformate, die man verwendet, einen Typen anzulegen, um später einfacher mit den VBOs arbeiten zu können.

Falls man mit Shadern arbeitet kann man sich die Wahl des Vertexformates eigentlich sparen, denn hier kann man z.B. für jeden Attributtyp den man braucht (Vertex, Normale, Farbe, Normale, etc.) ein eigenes VBO anlegen und dieses dann entsprechend seinen Bedürfnissen im Shader interpretieren, oder einfach nur ein riesiges VBO nutzen und dort alle Daten nach Belieben ablegen und im Shader selbst interpretieren.

==Nachwort==

Das wars auch schon. Wie zu erkennen ist das Vertexbufferobjekt mal wieder eine gut durchdachte, recht nützliche und zudem auch weit nutzbare Erweiterung, die OpenGL technisch wieder einen Schritt weitergebracht hat.

Wer mehr wissen will, der sollte sich unbedingt mal die passende [http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt Spezifikation] ansehen.

Hoffe das Tutorial hat euch soviel Spaß gemacht wie mir das Verfassen des selbigen und ich hoffe auf reges Feedback!

Euer

Sascha Willems (webmaster_at_delphigl.de)

==Links==
[http://developer.nvidia.com/attach/6427 Nvidia: Using Vertex Buffer Objects]

[http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt Spezifikation]

{{TUTORIAL_NAVIGATION|[[Tutorial_Cubemap]]|[[Tutorial_Vertexprogramme]]}}

[[Kategorie:Tutorial|Vertexbuffer]]

Benutzer:Coolcat

2011-01-30T16:38:58Z

Coolcat:

* Realname: Martin Weusten
* Studium (abgeschlossen):
** Diplom Informatiker
** Vertiefungsrichtung: Computergrafik
** RWTH Aachen University
* Platform: Linux, C++
* Web: [http://martin-weusten.de martin-weusten.de]
* Jabber: http://jabber.rwth-aachen.de/w/images/c/ca/Jid-martin.weusten.jpg http://jabber.rwth-aachen.de/w/images/b/ba/Modrewrite-martin.weusten.gif
::(das ist '''keine''' EMailadresse, sondern eine [http://jabber.rwth-aachen.de/wiki/Jabber_-_Einfach_erkl%C3%A4rt! Jabberadresse!])

Diskussion:glBlendColor

2011-01-02T21:03:13Z

Coolcat: /* GL_ARB_imaging Erweiterung */

== GL_ARB_imaging Erweiterung ==

glBlendColor ist doch bestimmt nicht nur Teil dieser Erweiterung, sondern auch Teil von OpenGL 2.0? Oder 2.1? Jedenfalls wäre es sonst sicher glBlendColorARB. Vielleicht kann das jemand mit Zeit mal checken... --[[Benutzer:Coolcat|Coolcat]] 22:01, 2. Jan. 2011 (CET)

Diskussion:glBlendColor

2011-01-02T21:01:47Z

Coolcat: GL_ARB_imaging Erweiterung

== GL_ARB_imaging Erweiterung ==

glBlendColor ist doch bestimmt nicht nur Teil dieser Erweiterung, sondern auch Teil von OpenGL 2.0? Oder 2.1....vielleicht kann jemand mit Zeit das mal checken... --[[Benutzer:Coolcat|Coolcat]] 22:01, 2. Jan. 2011 (CET)

Datei:Formel Clamp To Edge Range.png

2010-10-21T15:24:09Z

Coolcat: hat eine neue Version von „Datei:Formel Clamp To Edge Range.png“ hochgeladen: Vorzeichen korrigiert.

Bereich für GL_CLAMP_TO_EDGE ( glTexParameter ).

glPolygonOffset

2010-10-18T11:37:16Z

Coolcat: /* Siehe auch */ glDepthRange hinzugefügt

= glPolygonOffset =

== Name ==
'''glPolygonOffset''' - setzt die Skalierung und Einheiten, die für die Tiefenberechnung verwendet werden sollen.

== Delphi-Spezifikation ==
procedure '''glPolygonOffset'''(''factor'': TGLfloat; ''units'': TGLfloat);

== Parameter ==

{| border="1" rules="all"
! ''factor''
| Definiert einen Skalierungsfaktor, der benutzt wird, um einen variablen Tiefenversatz (Depth Offset) für jedes Polygon. Der '''Initialwert ist 0'''.
|-
! ''units''
| Wird mit einem implementationsabhängigen Wert multipliziert, um einen konstanten Tiefenversatz zu erreichen. Der '''Initialwert ist 0'''.
|}

== Beschreibung ==
Wenn '''GL_POLYGON_OFFSET_FILL''', '''GL_POLYGON_OFFSET_LINE''' oder '''GL_POLYGON_OFFSET_POINT''' aktiviert ist, wird der Tiefenwert jedes [[Fragment]]s um einen bestimmten Wert verschoben, nachdem der eigentliche Tiefenwert aus den betreffenden Vertexinformationen interpoliert wurde. Der Wert wird errechnet aus 
''factor'' * DZ + r * ''units'', wobei 
* DZ die Maßeinheit für die Tiefenverschiebung relativ zum Bildschirmbereich des Polygons und
* r der kleinste Wert ist, der garantiert noch eine gültige Verschiebung für die aktuelle OpenGL-Implementation liefert.
Der Offset wird addiert bevor der [[Tiefentest]] durchgeführt wird und bevor die Werte in den [[Tiefenpuffer]] geschrieben werden.

'''glPolygonOffset''' ist nützlich, um
* Raster-Bildern (engl: hidden-line images) zu rendern.
* [[Decals]] auf Oberflächen zu mappen.
* Solide Körper mit beleuchteten Kanten (highlighted edges) zu rendern.
* [[ZFighting]] zu beheben.

== Hinweise ==
'''glPolygonOffset''' ist ab OpenGL Version 1.1 verfügbar.

'''glPolygonOffset''' hat keinen Effekt auf die Tiefenwerte im [[Feedbackpuffer]].

'''glPolygonOffset''' hat keinen Effekt auf die [[Selektion]].

== Fehlermeldungen ==
'''GL_INVALID_OPERATION''' wird generiert, wenn '''glPolygonOffset''' innerhalb eines [[glBegin]]-[[glEnd]]-Blocks aufgerufen wird.

== Zugehörige Wertrückgaben ==
[[glIsEnabled]] mit Token [[glIsEnabled#GL_POLYGON_OFFSET_FILL|GL_POLYGON_OFFSET_FILL]], [[glIsEnabled#GL_POLYGON_OFFSET_LINE|GL_POLYGON_OFFSET_LINE]], oder [[glIsEnabled#GL_POLYGON_OFFSET_POINT|GL_POLYGON_OFFSET_POINT]]

[[glGet]] mit Token [[glGet#GL_POLYGON_OFFSET_FACTOR|GL_POLYGON_OFFSET_FACTOR]] oder [[glGet#GL_POLYGON_OFFSET_UNITS|GL_POLYGON_OFFSET_UNITS]]

== Siehe auch ==
[[glDepthFunc]], [[glDepthRange]], [[glEnable]], [[glGet]], [[glIsEnabled]], [[glLineWidth]], [[glStencilOp]], [[glTexEnv]]

[[Kategorie:GL|PolygonOffset]]
[[Kategorie:GL1.1|PolygonOffset]]

glDepthRange

2010-10-18T11:36:46Z

Coolcat: /* Siehe auch */ glPolygonOffset hinzugefügt

= glDepthRange =

== Name ==
'''glDepthRange''' - Bestimmt wie z-Werte von normalisierten Gerätekoordinaten (Device coordinates) zu Fensterkoordinaten (Window coordinates) umgerechnet werden.

== Delphi-Spezifikation ==
procedure '''glDepthRange'''(''zNear'': TGLclampd; ''zFar'': TGLclampd);

== Parameter ==
{| border=1 rules=all
! ''near''
| Beschreibt wie die vordere [[Clipping Plane|Schnittebene]] in Fensterkoordinaten umgerechnet werden soll. 
'''Vorgabewert''' ist 0.
|-
! ''far''
|Beschreibt, wie die hintere [[Clipping Plane|Schnittebene]] in Fensterkoordinaten umgerechnet werden soll. 
'''Vorgabewert''' ist 1.
|}

== Beschreibung ==
Nach dem die Z-Koordinaten abgeschnitten (clipping) und durch '''w''' geteilt wurden, reichen sie von -1.0 bis 1.0 im Bezug auf die vordere und hintere [[Clipping Plane|Schnittebene]]. 
'''glDepthRange''' gibt an auf welchen Bereich der Fensterkoordinaten die Werte von -1.0 bis 1.0 linear abgebildet werden. Also wie aus dem Z-Wert eines Fragmentes, der an dieser Stelle im Bereich von -1.0 bis 1.0 liegt, der Wert für den DepthBuffer berechnet wird. Unabhängig von der tatsächlichen Implementierung darf dieser Wert im Intervall von 0.0 bis 1.0 liegen. Eine Z-Koordinate von -1.0 wird auf den Wert des Parameters near abgebildet und 1.0 entspricht den Wert des Parameters far.
 

== Hinweise ==
Es ist nicht notwendig, dass ''near'' kleiner als ''far'' ist. Umgekehrtes Mapping z.B. mit 1, 0 wird akzeptiert
 
Früher hat man den DepthBuffer nur jeden zweiten Frame gelöscht, abwechselnd die Bereiche von 0.0 bis 0.5 und 1.0 bis 0.5 genutzt und die Richtung des DepthTests dementsprechend angepaßt.
Aufgrund von HW Optimierungen wie z.B. Hyper-Z usw. ist die Technik aber heutzutage nicht mehr angebracht und führt eher zu einem Geschwindigkeitsnachteil.

== Fehlermeldungen ==
'''GL_INVALID_OPERATION''' wird generiert, wenn '''glDepthRange''' innerhalb eines [[glBegin]]-[[glEnd]]-Blocks aufgerufen wird.

== Zugehörige Wertrückgaben ==
[[glGet]] mit Token [[glGet#GL_DEPTH_RANGE|GL_DEPTH_RANGE]]

== Siehe auch ==
[[glDepthFunc]], [[glPolygonOffset]], [[glViewport]]

[[Kategorie:GL|DepthRange]]
[[Kategorie:GL1.0|DepthRange]]

dglOpenGL.pas/en

2010-10-09T09:20:21Z

Coolcat: /* The DelphiGL header */

{{Warnung| '''Delphi is already shipping with an OpenGL header, but that header is ''outdated and also buggy''. Therefore we ''urge everyone to NOT use that header, especially as it lacks most of OpenGL's current functionality.'''''}}

<div align="center">[[Bild:Flag_german.gif]][[dglOpenGL.pas| Gehe zur deutschen Version dieser Seite ]][[Bild:Flag_german.gif]]</div>

=The DelphiGL header=
So to compensate for the flaws of the outdated and buggy default header that is shipped with Delphi, the [http://www.delphigl.com (german) Delphi OpenGL Community] is providing it's own header that's permanently updated to provide steady support for new OpenGL features and functionality. This makes updating to a new header version easily (usually backwards compatibility is preserved), and it's even possible to use the header with other pascal compilers like Freepascal.

It includes all OpenGL functions (currently up-to and including OpenGL 4.0) as well as all GLU ('''OpenGL Utility Libary''') functions and supports all ARB, EXT, NV and ATI extensions. It also includes additional, though lesser common extensions from other vendors like Apple, HP and SGI.

A special feature of this header are boolean variables for each included extensions that are flagged upon initialisation (those boolean vars carry the same as their corresponding extensions), so you can quickly check wether an extension is support or not (instead of checking the strings returned by [[glGetString/en]]).

==Licence/Terms of use==
The '''dglOpenGL.pas''' is distributed unter the terms and conditions of the '''Mozilla Public License Version 1.1'''. You can grab a copy of that licence [http://www.mozilla.org/MPL/MPL-1.1.html here].

<code>The contents of the dglOpenGL.pas are used with permission, subject to 
the Mozilla Public License Version 1.1 (the "License"); you may 
not use this file except in compliance with the License. You may 
obtain a copy of the License at 
http://www.mozilla.org/MPL/MPL-1.1.html 
 
Software distributed under the License is distributed on an 
"AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or 
implied. See the License for the specific language governing 
rights and limitations under the License.</code>

==.NET support==
Due to lack of interest, .NET support has been removed as of header version 2.1!

{{Hinweis|The .Net header won't be developed any further, but reported errors may be fixed. So new OpenGL functionality can only be found in the normal header.}}

==Initializing function pointers (crucial)==
Along with the removal of .NET support, support for loading methods dynamically has also been removed and is no longer possible with the standard header. So it's crucial to call either '''AtivateRenderingContext''' or '''ReadExtensions''' alongside with '''ReadImplementationProperties''' in your application before accessing any of the OpenGL functions. Otherwise you'll likely be prompted with an access violation at address 0x00000000.

''So if you get such an access violation please check if you called the above functions!''

Example for '''initializing''' the OpenGL function pointers (''needs to be called before you access any OpenGL functions'') :
<source lang="pascal">procedure OpenGLInit;
begin
InitOpenGL; // Don't forget, or first gl-Call will result in an access violation!
MyDC := GetDC(...);
MyRC := CreateRenderingContext(...);
ActivateRenderingContext(MyDC, MyRC); // Necessary, will also load function pointers for all extension
...
end;</source>

Example for '''finishing''' the OpenGL render context (''should be called before quitting your application'') :
<source lang="pascal">procedure OpenGLFinish;
begin
DeactivateRenderingContext; // Deactivates the current context
wglDeleteContext(myRC);
ReleaseDC(Handle, myDC);
end;</source>

==Download==

<div align="center">
'''{{ArchivLink|file=dglOpenGL|text=Current dglOpenGL.pas}} (Supports ''OpenGL 4.0'', works with Delphi 4 and up and Freepascal))'''

'''{{ArchivLink|file=dglOpenGL_net|text=Last dglOpenGL.pas wit .NET support}} (Supports ''OpenGL 2.1'')'''

'''For Delphi 3 users :'''
''[[Benutzer:Mars|Mars]] has posted a version of the dglOpenGL.pas that will work with Delphi 3, you can get it here : 
[http://www.delphigl.com/forum/viewtopic.php?p=26697#25642 dglOpenGL.pas for Delphi 3] 
''(You need to be registered on the forums to download it)''

''There is also an inofficial version of this [http://www.delphigl.com/forum/viewtopic.php?t=4216 headers for C++].''
</div>

== History ==
{{dglOpenGL_History}}

Performance

2010-09-22T15:07:28Z

Coolcat: /* Quellen / Links */ Link aktualisiert, AMD hat das Dokument verschoben.

__TOC__

Dieser Artikel liefert einige Tipps dazu wie man eine OpenGL-Anwendung optimieren kann. Einige der hier genannten Tipps schließen sich gegenseitig aus. Welche Vorgehensweise die beste ist hängt immer davon ab wo gerade der Engpass liegt. Es bringt zum Beispiel wenig den Shader zu optimieren, wenn eigentlich die zu langsame CPU das Problem ist.

=== Grundlagen ===
Die folgenden Tipps sind eigentlich Pflicht, insbesondere da sie meist leicht zu realisieren sind. Beherzigt man diese überhaupt nicht, muss man sich nicht über eine unglaublich langsame Anwendung wundern. Die Reihenfolge gibt so ungefähr die Wichtigkeit an.
# Schließe nicht sichtbare Polygone so schnell wie möglich vom Rendering aus.
#* Aktiviere [[Backface Culling]].
#* Benutze [[Frustum Culling]].
#* Vor allem bei statischer Geometrie (die sich nicht bewegt) bieten sich die etablierten [[Techniken_und_Algorithmen#Raumunterteilungstechniken|Raumunterteilungstechniken]] wie BSP-Tree, Quad-Tree, usw. an.
# Vermeide Kommunikation zwischen CPU und GPU.
#* Lade nicht deine Texturen/Vertexdaten in jedem Frame neu auf die Grafikkarte hoch. Vermeide den Immediate Mode, also [[glBegin]]() und [[glEnd]](). Sofern du aber nur ein, zwei einzelne Dreiecke rendern möchtest ist der Immediate Mode akzeptabel.
#* Verwende [[VBO|Vertexbuffer-Objects]] oder [[Displayliste]]n.
# Verwende glDraw***-Aufrufe sparsam. Hiermit sind ALLE Befehle gemeint die irgendetwas rendern, z.B. [[glDrawArrays]], [[glDrawElements]], ..., aber auch [[glMultiDrawArrays]], usw...
#* Lieber ein paar Polygone mehr rendern, wenn du dadurch glDraw***-Aufrufe einsparen kannst.
#* Es spielt so gut wie keine Rolle, ob du 500 oder 1 Polygon renderst, da ein glDraw***-Aufrufe alleine schon ziemlich viel Zeit braucht.
# Optimiere deine Modelle. Nutze den Mesh-Optimierer in deiner 3D-Modellierungssoftware. Dies bringt zwar meist nicht viel, ist aber ja auch nicht mehr als ein Knopfdruck.
# Die Grafikkarte hat einen Cache für bereits vom Vertexshader verarbeitete Vertices. Dieser wird genutzt, wenn du [[Indices]] verwendest. Der Vertexshader muss also im optimalen Fall für jeden Vertex nur einmal ausgeführt werden, auch wenn der Vertex in mehreren Dreiecken verwendet wird. In jedem [[Mesh|geschlossenen]] und [[Mesh|2-mannigfaltigen]] Dreiecksnetz wird jeder Vertex im Durchschnitt von 6 Dreiecken verwendet. Hier lässt sich also so einiges an Speicher und Rechenleistung sparen.
# Nutze den Z-Buffer aus.
#* Sortiere nicht deine Polygone einzeln nach der Entfernung zur Kamera (Painters-Algorithm), sondern verwende den Z-Buffer.
#* Sofern du aufwendige Shader oder viele Texturen verwendest, rendere deine Objekte (nicht Polygone) von vorne nach hinten. Also grob sortieren und den Rest den Z-Buffer machen lassen.
#* Wenn du transparente Objekte hast, rendere zunächst von sortiert vorne nach hinten die undurchsichtigen Objekte. Die transparenten Objekte renderst du dann anschließend von hinten nach vorne.
# Vermeide wenn möglich häufige Shader-, Textur-, Material- und Statewechsel.

===Performance Killer===
# Die OpenGL eigene Selektion wird nur schlecht als recht unterstützt. Eine [[Tutorial_ColorPicking|Color-Picking-Selection]] kann abhilfe leisten.
# [[glPushAttrib]] und glPopAttrib gelten laut [http://developer.amd.com/media/gpu_assets/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf diesem ATI Dokument] als "State Evils", welche sich negativ auf die Performance auswirken.
# Sofern die Extension [http://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt GL_ARB_texture_non_power_of_two] nicht unterstützt wird, könnte eine Grafikkarte bei Texturen deren Kantenlänge keiner 2er-Potenz entspricht (also z.B. 256, 512, 1024, ...) in den Software-Modus umschalten. Im Software-Modus wird die Grafikkarte komplett von der CPU emuliert. Das dies nicht schnell sein kann dürfte klar sein.

=== Fortgeschrittene Techniken ===
Die folgenden Tipps sind nicht so einfach zu realisieren oder erfordern Kenntnisse über fortgeschrittene Features wie [[Shader]], [[Instancing]]. Die Reihenfolge der Tipps ist hier nicht von Bedeutung.
# Ein glDraw*** wird nicht sofort ausgeführt, d.h. die CPU erhält die Kontrolle zurück bevor die GPU fertig mit rendern ist. Erst beim vertauschen von Front- und Backbuffer ("[[SwapBuffers]]") oder einem expliziten [[glFinish]] wird synchronisiert. Folglich gebe zuerst der Grafikkarte was zu arbeiten, rechne dann deine Spiellogik, Physik, etc. auf der CPU und rufe dann erst [[SwapBuffers]] auf. Sowas geht natürlich nicht immer, aber man kann beispielsweise Physik und Rendern in zwei Frames aufspilten. Also du berechnest immer die Physik für das nächste Frame, während die GraKa das aktuelle Frame rendert. Siehe auch [[glFlush]].
# Überlege ob du Grafikspeicher sparen kannst indem du z.B. Texturkoordinaten oder Normalen zur Laufzeit im [[Shader]] berechnest. (Beispiel: [[Shader#Beispiel:_Heightmap-Terrain|Heightmap-Terrain]])
# Wenn du viele identische Objekte renderst, überlege ob du [[Instancing]] einsetzen kannst. Erfordert allerdings halbwegs aktuelle Grafikhardware.
# Überlege ob du aufwendige Berechnungen, z.B. ein [[GLSL_Partikel_2|Partikelsystem]], nicht besser vollständig auf der Grafikkarte realisierst. Stichworte: [[FBO|Framebuffer-Objects]] und [[Transform-Feedback]].
# Verzichte auf einen [[Geometryshader]], wenn du ihn nicht unbedingt benötigst.
# Mit [[Triangulation|Triangle Strips]] lässt sich die Anzahl der notwendigen Vertices (bzw. Indices) bis auf ein Drittel reduzieren. Auch hier kommt der Vertexcache der Grafikkarte zum Einsatz.
# Überlege ob du deine Modelle immer in höchster Detailstufe ( mit Texturierung, Beleuchtung und anderen teuren Effekten ) zeichnen musst, wenn nicht, verwende [[LOD]] ( ''Level-Of-Detail'' ).
# Überlege ob du bei statischen Szenen komplexe Beleuchtungsberechnungen durch [[Lightmaps]] ersetzen kannst. Lightmaps benötigen zwar einiges an Grafikspeicher, jedoch müssen Berechnungen z.B. für Schatten nur einmal durchgeführt werden. Dies funktioniert sowohl bei [[GLSL_Licht_und_Schatten|Shadow Maps]] als auch bei [[Volumetrische_Stencilschatten|volumetrischen Stencilschatten]]. Auch [[Reflexion]]en oder [[Kaustik]]en stellen kein Problem dar.

=== Shader ===
Die folgenden Tipps beschäftigen sich mit der Optimierung von [[Shader]]n. Auch hier ist die Reihenfolge nicht von Bedeutung.
# Vermeide den Universal-Shader. Shader-Wechsel sind zwar aufwendig, aber eine gigantische if-Verzweigung die für jeden Vertex und jeden Pixel (!) ausgeführt werden muss ist noch wesentlich aufwendiger. Optimiere deinen Shader für die Aufgabe die er erfüllen muss.
# Vermeide aufwendige Berechnungen im Shader. Möglicherweise ist es sinnvoll komplexe Berechnungen im voraus zu berechnen und im Shader eine Lookup-Textur zu verwenden. Sofern eine komplexe Berechnung nur von Uniform-Variablen abhängig ist, ist es oft sinnvoll einfach eine weitere Uniform-Variable zu spendieren und einmal auf der CPU zu berechnen.
# Verwende nach Möglichkeit die in GLSL [[Tutorial_glsl#Eingebaute_Funktionen|integrierten Funktionen]]. Diese Funktionen können zum Teil wesentlich schneller sein da sie zum Teil direkt in der Hardware implementiert sind.
# Optimiere deine Shader so weit wie möglich. Effizienz hat hier Vorrang vor der Lesbarkeit, da die Operationen möglicherweise millionenfach pro Frame ausgeführt werden. Im Fall der Fälle dann einfach mal etwas ausführlicher kommentieren.
# Versuche insbesondere aufwendige Operationen wie zum Beispiel eine Wurzel zu vermeiden. Bedenke das sich solche Operationen auch in eingebauten Funktionen wie beispielsweise {{INLINE_CODE|length}}, {{INLINE_CODE|distance}} und {{INLINE_CODE|normalize}} verstecken können.
# Vermeide Random-Access auf Texturen. Zwei nebeneinander liegende Texel einer Textur können üblicherweise schneller aus dem Speicher geladen werden als zwei Texel an völlig unterschiedlichen Positionen in der Textur. Nutze den GPU-Cache!
# Versuche nicht Speicher zu sparen in dem du Variablen im Shader zusammenfasst. Beispielsweise macht eine Variable {{INLINE_CODE|vec4 positionAndSize}} wenig Sinn, wenn Position und Größe nur wenig miteinander zu tun haben und du z.B. ständig mit {{INLINE_CODE|positionAndSize.xyz}} arbeitest. Verwende lieber separate Variablen, also {{INLINE_CODE|vec3 position}} und {{INLINE_CODE|float size}}. So kann der Compiler besser optimieren. Dies gilt natürlich nur für lokale Variablen im Shader. Wenn du mit dieser Methode Werte in einer Textur zusammenfassen kannst ist dies natürlich sehr sinnvoll!
# Es gibt diverse Tools mit denen du feststellen kannst wo genau deine Anwendung die meiste Zeit benötigt bzw. wo du optimieren solltest.
#* [http://developer.nvidia.com/object/nvperfkit_home.html NVIDIA PerfKit]
#* [http://news.developer.nvidia.com/2006/12/nvidia_perfgrap.html NVIDIA PerfGraph]
#* [http://developer.amd.com/gpu/shader/Pages/default.aspx AMD GPU ShaderAnalyzer]
#* bitte ergänzen...

=== Quellen / Links ===
* [http://developer.nvidia.com/object/gpu_programming_guide.html NVIDIA GPU Programming Guide]
* [http://developer.amd.com/media/gpu_assets/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf OpenGL Performance Tuning, GDC 2006]

Performance

2010-09-22T15:06:49Z

Coolcat: /* Performance Killer */

__TOC__

Dieser Artikel liefert einige Tipps dazu wie man eine OpenGL-Anwendung optimieren kann. Einige der hier genannten Tipps schließen sich gegenseitig aus. Welche Vorgehensweise die beste ist hängt immer davon ab wo gerade der Engpass liegt. Es bringt zum Beispiel wenig den Shader zu optimieren, wenn eigentlich die zu langsame CPU das Problem ist.

=== Grundlagen ===
Die folgenden Tipps sind eigentlich Pflicht, insbesondere da sie meist leicht zu realisieren sind. Beherzigt man diese überhaupt nicht, muss man sich nicht über eine unglaublich langsame Anwendung wundern. Die Reihenfolge gibt so ungefähr die Wichtigkeit an.
# Schließe nicht sichtbare Polygone so schnell wie möglich vom Rendering aus.
#* Aktiviere [[Backface Culling]].
#* Benutze [[Frustum Culling]].
#* Vor allem bei statischer Geometrie (die sich nicht bewegt) bieten sich die etablierten [[Techniken_und_Algorithmen#Raumunterteilungstechniken|Raumunterteilungstechniken]] wie BSP-Tree, Quad-Tree, usw. an.
# Vermeide Kommunikation zwischen CPU und GPU.
#* Lade nicht deine Texturen/Vertexdaten in jedem Frame neu auf die Grafikkarte hoch. Vermeide den Immediate Mode, also [[glBegin]]() und [[glEnd]](). Sofern du aber nur ein, zwei einzelne Dreiecke rendern möchtest ist der Immediate Mode akzeptabel.
#* Verwende [[VBO|Vertexbuffer-Objects]] oder [[Displayliste]]n.
# Verwende glDraw***-Aufrufe sparsam. Hiermit sind ALLE Befehle gemeint die irgendetwas rendern, z.B. [[glDrawArrays]], [[glDrawElements]], ..., aber auch [[glMultiDrawArrays]], usw...
#* Lieber ein paar Polygone mehr rendern, wenn du dadurch glDraw***-Aufrufe einsparen kannst.
#* Es spielt so gut wie keine Rolle, ob du 500 oder 1 Polygon renderst, da ein glDraw***-Aufrufe alleine schon ziemlich viel Zeit braucht.
# Optimiere deine Modelle. Nutze den Mesh-Optimierer in deiner 3D-Modellierungssoftware. Dies bringt zwar meist nicht viel, ist aber ja auch nicht mehr als ein Knopfdruck.
# Die Grafikkarte hat einen Cache für bereits vom Vertexshader verarbeitete Vertices. Dieser wird genutzt, wenn du [[Indices]] verwendest. Der Vertexshader muss also im optimalen Fall für jeden Vertex nur einmal ausgeführt werden, auch wenn der Vertex in mehreren Dreiecken verwendet wird. In jedem [[Mesh|geschlossenen]] und [[Mesh|2-mannigfaltigen]] Dreiecksnetz wird jeder Vertex im Durchschnitt von 6 Dreiecken verwendet. Hier lässt sich also so einiges an Speicher und Rechenleistung sparen.
# Nutze den Z-Buffer aus.
#* Sortiere nicht deine Polygone einzeln nach der Entfernung zur Kamera (Painters-Algorithm), sondern verwende den Z-Buffer.
#* Sofern du aufwendige Shader oder viele Texturen verwendest, rendere deine Objekte (nicht Polygone) von vorne nach hinten. Also grob sortieren und den Rest den Z-Buffer machen lassen.
#* Wenn du transparente Objekte hast, rendere zunächst von sortiert vorne nach hinten die undurchsichtigen Objekte. Die transparenten Objekte renderst du dann anschließend von hinten nach vorne.
# Vermeide wenn möglich häufige Shader-, Textur-, Material- und Statewechsel.

===Performance Killer===
# Die OpenGL eigene Selektion wird nur schlecht als recht unterstützt. Eine [[Tutorial_ColorPicking|Color-Picking-Selection]] kann abhilfe leisten.
# [[glPushAttrib]] und glPopAttrib gelten laut [http://developer.amd.com/media/gpu_assets/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf diesem ATI Dokument] als "State Evils", welche sich negativ auf die Performance auswirken.
# Sofern die Extension [http://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt GL_ARB_texture_non_power_of_two] nicht unterstützt wird, könnte eine Grafikkarte bei Texturen deren Kantenlänge keiner 2er-Potenz entspricht (also z.B. 256, 512, 1024, ...) in den Software-Modus umschalten. Im Software-Modus wird die Grafikkarte komplett von der CPU emuliert. Das dies nicht schnell sein kann dürfte klar sein.

=== Fortgeschrittene Techniken ===
Die folgenden Tipps sind nicht so einfach zu realisieren oder erfordern Kenntnisse über fortgeschrittene Features wie [[Shader]], [[Instancing]]. Die Reihenfolge der Tipps ist hier nicht von Bedeutung.
# Ein glDraw*** wird nicht sofort ausgeführt, d.h. die CPU erhält die Kontrolle zurück bevor die GPU fertig mit rendern ist. Erst beim vertauschen von Front- und Backbuffer ("[[SwapBuffers]]") oder einem expliziten [[glFinish]] wird synchronisiert. Folglich gebe zuerst der Grafikkarte was zu arbeiten, rechne dann deine Spiellogik, Physik, etc. auf der CPU und rufe dann erst [[SwapBuffers]] auf. Sowas geht natürlich nicht immer, aber man kann beispielsweise Physik und Rendern in zwei Frames aufspilten. Also du berechnest immer die Physik für das nächste Frame, während die GraKa das aktuelle Frame rendert. Siehe auch [[glFlush]].
# Überlege ob du Grafikspeicher sparen kannst indem du z.B. Texturkoordinaten oder Normalen zur Laufzeit im [[Shader]] berechnest. (Beispiel: [[Shader#Beispiel:_Heightmap-Terrain|Heightmap-Terrain]])
# Wenn du viele identische Objekte renderst, überlege ob du [[Instancing]] einsetzen kannst. Erfordert allerdings halbwegs aktuelle Grafikhardware.
# Überlege ob du aufwendige Berechnungen, z.B. ein [[GLSL_Partikel_2|Partikelsystem]], nicht besser vollständig auf der Grafikkarte realisierst. Stichworte: [[FBO|Framebuffer-Objects]] und [[Transform-Feedback]].
# Verzichte auf einen [[Geometryshader]], wenn du ihn nicht unbedingt benötigst.
# Mit [[Triangulation|Triangle Strips]] lässt sich die Anzahl der notwendigen Vertices (bzw. Indices) bis auf ein Drittel reduzieren. Auch hier kommt der Vertexcache der Grafikkarte zum Einsatz.
# Überlege ob du deine Modelle immer in höchster Detailstufe ( mit Texturierung, Beleuchtung und anderen teuren Effekten ) zeichnen musst, wenn nicht, verwende [[LOD]] ( ''Level-Of-Detail'' ).
# Überlege ob du bei statischen Szenen komplexe Beleuchtungsberechnungen durch [[Lightmaps]] ersetzen kannst. Lightmaps benötigen zwar einiges an Grafikspeicher, jedoch müssen Berechnungen z.B. für Schatten nur einmal durchgeführt werden. Dies funktioniert sowohl bei [[GLSL_Licht_und_Schatten|Shadow Maps]] als auch bei [[Volumetrische_Stencilschatten|volumetrischen Stencilschatten]]. Auch [[Reflexion]]en oder [[Kaustik]]en stellen kein Problem dar.

=== Shader ===
Die folgenden Tipps beschäftigen sich mit der Optimierung von [[Shader]]n. Auch hier ist die Reihenfolge nicht von Bedeutung.
# Vermeide den Universal-Shader. Shader-Wechsel sind zwar aufwendig, aber eine gigantische if-Verzweigung die für jeden Vertex und jeden Pixel (!) ausgeführt werden muss ist noch wesentlich aufwendiger. Optimiere deinen Shader für die Aufgabe die er erfüllen muss.
# Vermeide aufwendige Berechnungen im Shader. Möglicherweise ist es sinnvoll komplexe Berechnungen im voraus zu berechnen und im Shader eine Lookup-Textur zu verwenden. Sofern eine komplexe Berechnung nur von Uniform-Variablen abhängig ist, ist es oft sinnvoll einfach eine weitere Uniform-Variable zu spendieren und einmal auf der CPU zu berechnen.
# Verwende nach Möglichkeit die in GLSL [[Tutorial_glsl#Eingebaute_Funktionen|integrierten Funktionen]]. Diese Funktionen können zum Teil wesentlich schneller sein da sie zum Teil direkt in der Hardware implementiert sind.
# Optimiere deine Shader so weit wie möglich. Effizienz hat hier Vorrang vor der Lesbarkeit, da die Operationen möglicherweise millionenfach pro Frame ausgeführt werden. Im Fall der Fälle dann einfach mal etwas ausführlicher kommentieren.
# Versuche insbesondere aufwendige Operationen wie zum Beispiel eine Wurzel zu vermeiden. Bedenke das sich solche Operationen auch in eingebauten Funktionen wie beispielsweise {{INLINE_CODE|length}}, {{INLINE_CODE|distance}} und {{INLINE_CODE|normalize}} verstecken können.
# Vermeide Random-Access auf Texturen. Zwei nebeneinander liegende Texel einer Textur können üblicherweise schneller aus dem Speicher geladen werden als zwei Texel an völlig unterschiedlichen Positionen in der Textur. Nutze den GPU-Cache!
# Versuche nicht Speicher zu sparen in dem du Variablen im Shader zusammenfasst. Beispielsweise macht eine Variable {{INLINE_CODE|vec4 positionAndSize}} wenig Sinn, wenn Position und Größe nur wenig miteinander zu tun haben und du z.B. ständig mit {{INLINE_CODE|positionAndSize.xyz}} arbeitest. Verwende lieber separate Variablen, also {{INLINE_CODE|vec3 position}} und {{INLINE_CODE|float size}}. So kann der Compiler besser optimieren. Dies gilt natürlich nur für lokale Variablen im Shader. Wenn du mit dieser Methode Werte in einer Textur zusammenfassen kannst ist dies natürlich sehr sinnvoll!
# Es gibt diverse Tools mit denen du feststellen kannst wo genau deine Anwendung die meiste Zeit benötigt bzw. wo du optimieren solltest.
#* [http://developer.nvidia.com/object/nvperfkit_home.html NVIDIA PerfKit]
#* [http://news.developer.nvidia.com/2006/12/nvidia_perfgrap.html NVIDIA PerfGraph]
#* [http://developer.amd.com/gpu/shader/Pages/default.aspx AMD GPU ShaderAnalyzer]
#* bitte ergänzen...

=== Quellen / Links ===
* [http://developer.nvidia.com/object/gpu_programming_guide.html NVIDIA GPU Programming Guide]
* [http://ati.amd.com/developer/gdc/2006/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf OpenGL Performance Tuning, GDC 2006]

Model Loader

2010-04-04T09:41:15Z

Coolcat: /* Format und Model Loader Liste */

==Was ist das?==
Ein Modell-Loader ist eine Unit, oder DLL die ein 3D-Model in einem bestimmten Typ* vorliegt für ein Programm oder für was auch immer lädt, damit es angezeigt werden kann.

==Für was brauch ich das?==
Wenn man 3D Modelle von speziellen Objekten (z.B. Einheiten, Landschaftsgegenstände und Gebäude in Strategiespiele, oder Gegner für Shooter) benötigt, ist es wesentlich komfortabler ein Modell in einem speziellen 3D Modellierungsprogramm zu modellieren, als es „von Hand“ in OpenGL zu bauen. Man muss allerdings anschließend die Daten (Informationen zur Geometrie, Texturierung eventl. Animierung) selbst aus den abgespeicherten Modellformaten extrahieren.

Und genau da kommt der „Model Loader“ ins Spiel. Dieses Stück Code ermöglicht es dem Nutzer die Daten komfortabel aus den Dateien zu Laden. Das erleichtert die Arbeit im Vergleich zu selber gebauten Objekten natürlich enorm. Und die Modelle sehen, wenn man genügend Talent hat, auch meist wesentlich besser aus.

==Speichern alle Formate Animationen?==
Nein! Es sind sogar nur recht wenige die Animationen bieten. Außerdem gibt es Modeller die Animationen nicht in einer Datei sondern in vielen Einzeldateien speichern. Allerdings heißt das nicht, dass nur die Modelle aus teuren Modellern Animationen (vernünftig) speichern können. Es gibt auch freie und günstige Software (Milkshape 3D), die so etwas kann.

==Welche Modellformate gibt es?==
Hier eine kleine Auflistung der gebräuchlichsten Formate:
* .blend ([http://blender3d.org Blender])
* .collada ([http://www.khronos.org/collada/ Collada])
* .3ds (3D Studio)
* .lwo (Lightwave)
* .ms3d (Milkshape 3D)
* .bsp (ID Software BSP)
* .md3 (ID Software MD3)
* .x (Microsoft DirectX)
* .off (Object File Format)

==Wozu gibt es Exporter Plugins und Scripte?==
Für 3D Entwicker ist es wichtig, die erstellten Meshdaten auch in ein vorhandenes oder eigenes Format zu speichern.
Hierzu gibt es von den meisten 3D Editioren Plugins oder Scripte die dieses erledigen.

Einige Programme wie 3DS Max und Blender bieten beides, wobei in Fall von 3DS Max lieber Plugins verwendet werden sollten (Geschwindigkeitsvorteil). Blender bietet für Scripte einen Python Interpreter, der lediglich ein bischen modifiziert wurde.

Mit der Möglichkeit, eigene Format zu speichern, kann man sich auch aus dem Lizensproblem für bestimmte Formate rauswinden und man hat die Möglichkeit das Format an benötigte Bedingungen anzupassen.

== Format und Model Loader Liste ==
{|{{Prettytable_B1}}
!width="10%"| Format
!width="40%"| Format Features
!width="50%"| Loader
|-
| Cal3D
|
* kombinieren von Animationen (30% gehen, 50% rennen, 20% stolzieren und Winken)
* stufenloses [[Level of Detail]]
|
{|{{Prettytable_B1}} width="100%"
! Name
! nutzbar mit
! Umgesetzte Features
|-
| [http://gna.org/projects/cal3d/ Cal3D]
| C++
| alle Cal3D (0.10) Features
|-
| DCal3D
| Delphi / Object Pascal
| nur Cal3D 0.6 Features
|}
|-
| 3DS
|
* Meshbasierendes 3D-Format
* Vertexbasierende Animationen via Keyframes
* Normalen werden indirekt über Smoothinggroups gesichert
'''Format stammt noch aus DOS-zeiten, daher diverse Einschränkungen :'''
* Maximal 65k Vertices pro [[Mesh]]
* Texturnamen sind auf [http://de.wikipedia.org/wiki/8.3 8.3 Dateinamen] beschränkt
* Bones werden nicht exportiert
* Normalen werden nicht exportiert (nur Smoothinggroups)
'''Kein freies Format'''
|
{|{{Prettytable_B1}} width="100%"
! Name
! nutzbar mit
! Umgesetzte Features
|-
| [http://www.delphigl.com/forum/viewtopic.php?t=2421 gl3ds]
| Delphi / Object Pascal
| Unbekannt
|-
| [http://www.lib3ds.org/ lib3ds]
| C/C++
| Unbekannt
|}
|-
| OFF
|
* extrem einfaches 3D-Format
* ASCII und Binär-Variante
* nur Vertices, Normalen, Texturkoordinaten und Farben
* nicht auf Dreiecke beschränkt, beliebige Polygone möglich.
* '''nicht jeder Exporter (z.B. Blender) kann das vollständige Format!'''
| Da das Format so einfach ist ist ein Loader schnell implementiert:
[http://web.mit.edu/lugao/MacData/afs/athena/software/geomview_v1.9.3/www/OFF.html Formatbeschreibung].
|}

[[Kategorie:Technik_oder_Algorithmus]]

Model Loader

2010-04-04T09:33:06Z

Coolcat: /* Welche Modellformate gibt es? */ OFF-Format

shader ConeVolumeShadow

2010-01-31T15:24:31Z

Coolcat: /* Code */

{{Offline}}

=Shadername=
Zurück zur [[Shadersammlung]]
{|{{Prettytable_B1}} width=100%
!width=60%|Beschreibung
!width=20%|Autor
!width=20%|Version
|-
|Kegelvolumen-Schatten
|Coolcat
|1.0
|}

==Bilder==
{|
| [[Bild:shader_ConeVolumeShadow1.jpg|thumb|256px]]
| [[Bild:shader_ConeVolumeShadow2.jpg|thumb|256px]]
|}

== Voraussetzungen ==
Aufgrund der besonderen Funktionsweise funktioniert dieser Shader nur dann, wenn es sich bei sämtlichen Objekte in der Szene die einen Schatten werfen sollen um Kugeln handelt. Des weiteren muss innerhalb der Anwendung manuell berechnet werden welches Objekt auf welches andere Objekt einen Schatten wirft. Je mehr Objekte ein Schatten auf ein einzelnes Objekt werfen, desto langsamer wird das Verfahren.

Möglicherweise lässt sich das beschriebene Verfahren auch auf andere einfache geometrische Objekte verallgemeinern. In Frage kommen etwa Planetenringe. Auf diese Möglichkeiten geht dieser Artikel jedoch nicht weiter ein.

== Geometrie-Crashkurs ==
Um den Shader zu verstehen ist ein wenig Geometrie-Wissen erforderlich, insbesondere bezüglich des Skalarproduktes. Wer meint das Skalarprodukt und seine Eigenschaften schon zu kennen, kann diesen Abschnitt einfach überspringen. Wenn etwas unklar ist kann man ja noch einmal hierher zurückkommen.

Das Skalarprodukt, häufig auch als Dot-Product bezeichnet, ist für zwei 3D-Vektoren <tt>a</tt> und <tt>b</tt> wie folgt definiert:
:<tt>dot(a,b) := a.x*b.x + a.y*b.y + a.z*b.z</tt>
Der Betrag <tt>|a|</tt> eines Vektors <tt>a</tt> ist als dessen Länge bezüglich der euklidischen Norm definiert. Dies ist im wesentlichen der gute alte [http://de.wikipedia.org/wiki/Satz_des_Pythagoras Pythagoras] für drei Dimensionen:
:<tt>|a| := sqrt(a.x*a.x + a.y*a.y + a.z*a.z)</tt>
Eine wichtige Eigenschaft dieses Skalarproduktes ist, dass sich darüber der Winkel <tt>w</tt> zwischen den beiden Vektoren bestimmen lässt. Es gilt:
:<tt>dot(a,b) = |a| * |b| * cos(w)</tt>
Dies wollen wir ausnutzen. In der folgenden Zeichnung sind und die Punkte <tt>A</tt>, <tt>B</tt> und <tt>C</tt> bekannt. Wir wollen <tt>B'</tt> und die Strecke <tt>h</tt> berechnen, also <tt>B</tt> im rechten Winkel auf den Vektor <tt>AC</tt> projizieren.

[[Bild:shader_ConeVolumeProjection.png]]

Mit Hilfe des Skalarproduktes ist dies recht einfach. Zunächst berechnen wir den Vektor <tt>AB := B - A</tt>, sowie den Vektor <tt>AC := C - A</tt>. Letzteren normalisieren wir, indem wir durch die Länge teilen: <tt>n := AC / |AC|</tt>. Da <tt>n</tt> die Länge 1 hat gilt:
:<tt>dot(AB, n) = |AB| * cos(w)</tt>
Aus der Mittelstufe sollte bekannt sein, dass der [http://de.wikipedia.org/wiki/Kosinus#Geometrische_Definition Kosinus wie folgt definiert] ist:
:<tt>cos(w) = Ankathete / Hypotenuse</tt>
Die Hypotenuse ist hier die Strecke <tt>|AB|</tt> und die Ankathete ist die gesuchte Strecke <tt>|AB'| := |B' - A|</tt>. Es gilt also:
:<tt>cos(w) = Ankathete / Hypotenuse</tt>
:<tt><=> cos(w) = |AB'| / |AB|</tt>
:<tt><=> |AB| * cos(w) = |AB'|</tt>
:<tt><=> dot(AB, n) = |AB'|</tt>
Da <tt>n</tt> normalisiert war lässt sich der Punkt <tt>B'</tt> nun leicht berechnen: <tt>B' := A + n * |AB'|</tt>. Die Strecke <tt>h</tt> berechnet sich aus dem Abstand zwischen <tt>B</tt> und <tt>B'</tt>, also <tt>h := |B - B'|</tt>.

== Funktionsweise ==
Kommen wir nun zum eigentlichen Shader. Verwendet man eine Punktlichtquelle hat das Schatten-Volumen einer Kugel eine sehr einfache Form, nämliche die eines Kreiskegels. Da eine Punktlichtquelle aber unschöne harte Schatten wirft, wollen wir eine Kugellichtquelle verwenden. Eine Kugellichtquelle besteht aus unendlich vielen Punktlichtquellen die kugelförmig angeordnet sind. Da bei dieser Lichtquelle das Licht aus leicht unterschiedlichen Richtungen auf das Objekt fällt entstehen wie in der Realität weiche Schatten.

Das Schatten-Volumen einer von einer Kugellichtquelle beleuchteten Kugel lässt sich durch zwei Kreiskegel beschreiben. Dies machen wir uns zu nutze. Wie auf dem folgenden Bild erkennbar gibt es einen inneren Kegel (''inner cone'') und einen äußeren Kegel (''outer cone''). Befinden wir uns außerhalb des äußeren Kegels erhalten wir die volle Lichtstärke, da der Occluder keine Auswirkungen hat. Innerhalb des inneren Kegels befinden wir uns dagegen vollständig im Schatten. Die dritte Möglichkeit ist eine Position innerhalb des äußeren aber außerhalb des inneren Kegels. Hier ist die Halbschattenzone die für den weichen Schatten sorgt.

[[Bild:shader_ConeVolumeSoftShadow.png]]

Die Hauptachse beider Kegel liegt wie zu erkennen ist auf der Geraden durch Lichtquelle <tt>L</tt> und Occluder <tt>O</tt>. Im Shader beschreiben wir beide Kegel durch den Radius an zwei Punkten, nämlich den Radius auf Höhe der Lichtquelle und auf Höhe des Occluders. Für den äußeren Kegel bedienen wir uns eines Tricks, den wir nehmen für die Lichtquelle einfach einen negativen Radius an. Die Beschreibung beider Kegel ist also bis auf das Vorzeichen der Lichtquellenradius bei beiden Kegeln identisch. Wir haben damit genug Daten um den Radius an jeder Stelle beider Kegel zu berechnen.

Der Punkt <tt>F</tt> ist die Position des gerade gerenderten Fragments. Der erste Schritt besteht nun darin den Punkt <tt>F'</tt> zu berechnen. Eine detaillierte Erklärung dazu findet sich im [[#Geometrie-Crashkurs|vorhergehenden Abschnitt]]. Den Abstand zwischen <tt>F</tt> und <tt>F'</tt> bezeichnen wir als <tt>rF</tt>.

Nun geht es darum den Radius des inneren und äußeren Kegels (<tt>rF_inner</tt> bzw. <tt>rF_outer</tt>) auf Höhe von F' zu berechnen. Dies geht über den beliebten Dreisatz, die nötigen Formeln finden sich oben im Bild. Der einzige Unterschied bei beiden Formeln liegt nur im Vorzeichen für den Radius der Lichtquelle.

Es folgt eine große Fallunterscheidung die ermittelt in welcher Zone (Licht/Halbschatten/Vollschatten) wir uns befinden. Das Ergebnis ist ein Faktor <tt>s</tt> der später mit der Beleuchtung multipliziert wird. Dabei steht <tt>1.0</tt> für volles Licht und <tt>0.0</tt> für Dunkelheit. Zu beachten ist, dass <tt>rF_inner</tt> auch negativ werden kann. In dem Fall befinden wir uns soweit hinter dem Occluder, dass keine Vollschatten-Zone mehr existiert.
<source lang="text">if (dLF' < dLO || rF >= rF_outer) {
// Fragment vor dem Occluder oder außerhalb des äußeren Kegels.
s = 1.0;
}
else if (rF_inner >= rF) {
// Wir befinden uns im Vollschatten
s = 0.0;
}
else if (rF_inner >= 0 || rF >= -rF_inner) {
// Wir befinden uns im Halbschatten, lineare Interpolation
s = (rF - rF_inner) / (rF_outer - rF_inner);
}
else {
// Wir empfangen Licht von zwei Richtungen, also oben und unten am Occluder vorbei.
// Die beiden rF heben sich gegenseitig auf.
s = (-2*rF_inner) / (rF_outer - rF_inner);
}</source>

{{Hinweis|Eine kleine Randnotiz: Der Schatten wird orthogonal zur Geraden <tt>LO</tt> interpoliert. Diese Berechnung ist nicht physikalisch korrekt. Allerdings dürfte der Unterschied niemandem auffallen.}}

==Code==
====Das "Drumherum"====
Im wesentlichen gibt es zwei Dinge zu beachten:
# Wann immer man geometrische Berechnungen durchführt muss man darauf achten das alle Punkte und Vektoren im gleichen Koordinatenraum vorliegen. Der hier vorgestellte Shader arbeitet im View-Space und erwartet daher auch die Daten der Lichtquelle und der Occluder-objekt im View-Space. Liegen also z.B. die Koordinaten der Lichtquelle in Weltkoordinaten vor, müssen sie vor Übergabe an den Shader mit der View-Matrix (das was z.B. [[gluLookAt]] produziert) multipliziert werden.
# Die Anzahl der Occluder die an den Shader übergeben werden sollte so klein wie möglich sein. Aus diesem Grund sollte man Objekte ausschließen die sowieso keine Auswirkungen auf das gerade gerenderte Objekt haben. Wir müssen also Objekte ausschließen die vollständig außerhalb des äußeren Kegels liegen. Ein derartiger Test funktioniert zumindest für Kugeln ähnlich wie der den wir im Shader für einzelne Punkte machen. Hier addieren/subtraieren wir aber noch an geeigneter Stelle den Radius des getesteten Objektes. Letztlich vergleichen wir die Länge von <tt>|P-P'| - rP</tt> mit der Länge von <tt>rQ_outer</tt>. Dieser Ansatz ist zwar nicht exakt, meldet aber niemals ein Objekt außerhalb, wenn es eigentlich innerhalb liegt. Umgekehrt kann dies allerdings passieren, da eigentlich der Punkt <tt>Q</tt> geprüft wird.

: [[Bild:shader_ConeVolumeExclude.png]]

====Vertexshader====
Der Vertexshader ist nichts besonderes. Er transformiert einfach nur die Vertexposition sowie die Normale und gibt die Daten weiter. Dieser Shader ist im wesentlichen aus UltimateConquest übernommen. Daher werden hier Vertexattribute und Matrixuniforms selbst definiert. Sofern man noch mit OpenGL 2.x arbeitet kann man aber problemlos die dort verfügbaren eingebauten Uniforms und Attribute benutzen.
<source lang="glsl">uniform mat4 uModelViewProjection;
uniform mat4 uModelView;
uniform mat3 uNormalMatrix;

attribute vec3 aPosition;
attribute vec3 aNormal;
attribute vec2 aTexCoord;

varying vec3 vPosition;
varying vec3 vNormal;
varying vec2 vTexCoord;

void main() {
gl_Position = uModelViewProjection * vec4(aPosition, 1.0);
vPosition = (uModelView * vec4(aPosition, 1.0)).xyz;
vNormal = normalize(uNormalMatrix * aNormal);
vTexCoord = aTexCoord;
}
</source>

====Fragmentshader====
Der Fragmentshader macht den eigentlich Job. Es handelt sich um einen aufgeblasenen Per-Pixel-Light-Shader. Zusätzlich zur normalen Diffuse-Beleuchtung wird in der Funktion <tt>shadowFactor()</tt> auch noch ein Schattenfaktor berechnet. Diese Funktion berechnet das Produkt sämtlicher Kegelvolumen für das aktuelle Fragment. Am Ende erhalten wir einen Wert zwischen 0.0 und 1.0 der dann einfach mit der Diffuse-Beleuchtung verrechnet wird.
<source lang="glsl">uniform sampler2D uTexture;

// the lightsource described by position and radius
uniform vec4 uLightsource;
vec3 lsPosition = uLightsource.xyz;
float lsRadius = uLightsource.w;

// each shadow volume is described by position (xyz) and radius (w) of the occluder packed into a single vec4
const int shadowMaxCount = 5;
uniform vec4 uShadows[shadowMaxCount];
uniform int uShadowCount;

varying vec3 vPosition;
varying vec3 vNormal;
varying vec2 vTexCoord;

const vec3 cAmbient = vec3(0.025,0.025,0.025);

// simple local diffuse per-pixel lighting
float diffuseFactor() {
vec3 lightDir = normalize(lsPosition-vPosition);
vec3 normal = normalize(vNormal);
return max(dot(lightDir, normal), 0.0);
}

// process all shadow volumes
float shadowFactor() {
float s = 1.0;
// iterate all shadow volumes
for (int i=0; i<uShadowCount; ++i) {
// extract data
vec4 occluder = uShadows[i];
vec3 ocPosition = occluder.xyz;
float ocRadius = occluder.w;

// project fragment (vPosition) on the cone axis => F_
vec3 nvLO = ocPosition - lsPosition;
float dLO = length(nvLO);
nvLO /= dLO;
vec3 vLF = vPosition - lsPosition;
float dLF_ = dot(vLF, nvLO);
if (dLF_ < dLO) {
// fragment before occluder => no shadow
continue;
}
vec3 F_ = lsPosition + dLF_ * nvLO;
float rF = distance(F_, vPosition);

// compute outer and inner radius at F_
float rF_outer = (ocRadius + lsRadius) * (dLF_ / dLO) - lsRadius;
if (rF >= rF_outer) {
// outside the outer cone => no shadow
continue;
}
float rF_inner = (ocRadius - lsRadius) * (dLF_ / dLO) + lsRadius;
if (rF_inner >= rF) {
// inside the inner cone => full shadow
return 0.0;
}
else if (rF_inner >= 0.0 || rF >= -rF_inner) {
// soft shadow, linear interpolation
s *= (rF - rF_inner) / (rF_outer - rF_inner);
}
else {
// light from both sides of the occluder
s *= (-2.0*rF_inner) / (rF_outer - rF_inner);
}
}
return s;
}

void main() {
vec3 texcolor = texture2D(uTexture, vTexCoord).xyz;
gl_FragColor.xyz = cAmbient * texcolor;
float lightFactor = diffuseFactor();
if (lightFactor > 0.004) {
// don't compute shadows for fragments that are already dark from local lighting
lightFactor *= shadowFactor();
}
gl_FragColor.xyz += texcolor * lightFactor;
gl_FragColor.w = 1.0;
}</source>

2010-01-31T10:59:19Z

Coolcat: hat eine neue Version von „Datei:shader ConeVolumeProjection.png“ hochgeladen