Einstieg in die moderne 3D-Programmierung
-
Mein Ziel ist es, eine gewisse Kompetenz in der 3D-Programmierung zu erlangen.
Es ist auch nicht mein erster Anlauf im Verlaufe der Jahre, aber bisher habe ich mich nur Online-Resourcen benutzt und meines Wissens gibt es bis heute keine brauchbaren bzw. ausreichend umfangreichen.Daher suche ich nach Büchern, die von kompetenten Autoren geschrieben wurden und umfangreiches Wissen kompakt vermitteln.
Zu Lernzwecken habe ich mich unter anderem an einem blockbasiertes Spiel wie Minecraft versucht... aber schon simpel anmutende Dinge stellten sich als unerwartet schwierig heraus (z.B. bestimmen, auf welchen Block ich schaue). Dann hatte ich eine Situation, in der ich in einem Shader gerne auf ein Array mit Texturen unter Benutzung von Indices aus einem UBO o.ä. hätte zugreifen wollen, hatte aber keine Ahnung, ob oder wie das geht oder wie die Fachbegriffe dazu heißen, falls es geht. Dann hatte ich an vielen Stellen Performanceprobleme... Minecraft schaffte es, ein Vielfaches der Blocks bei gleicher Framerate zu rendern, obwohl schon Minecraft angeblich schlecht optimiert sein soll - außerdem hatte ich aus Performancegründen schon die gesamte Welt in ein riesiges VBO gesteckt und damit in Kauf genommen, dass ich nicht einmal Änderungen vornehmen konnte ohne das ganze Ding zu aktualisieren. Und mangels Überblick hatte ich auch keine ernsthaften Ansätze, wie ich das hätte schneller bekommen können.
Naja, wie dem auch sei, sich nur anhand von Google in ein derartiges komplexes Thema einzuarbeiten ist weitgehend zum Scheitern verurteilt und eben deswegen suche ich Literatur, welche die Konzepte in der Grafikprogrammierung vollständig vermittelt anstatt alles fetzchenweise zu präsentieren.
Noch etwas, ich arbeite unter Linux, deswegen würde ich Bücher vorziehen, die mit OpenGL arbeiten. Aber ich bin mir auch nicht zu schade, MinGW+Wine zu verwenden, falls es zu DirectX bessere Literatur gibt. Einzige Einschränkung wäre dann, dass es sich auf DirectX 10 beziehen sollte, da Wine DirectX 11 noch nicht unterstützt.
-
;3D schrieb:
Mein Ziel ist es, eine gewisse Kompetenz in der 3D-Programmierung zu erlangen.
Üben, üben, üben...
;3D schrieb:
Zu Lernzwecken habe ich mich unter anderem an einem blockbasiertes Spiel wie Minecraft versucht... aber schon simpel anmutende Dinge stellten sich als unerwartet schwierig heraus (z.B. bestimmen, auf welchen Block ich schaue).
Klingt mir so, als scheitert es eher an der Mathematik, als an OpenGL? Das Stichwort in dem Fall lautet "Picking".
;3D schrieb:
Dann hatte ich eine Situation, in der ich in einem Shader gerne auf ein Array mit Texturen unter Benutzung von Indices aus einem UBO o.ä. hätte zugreifen wollen, hatte aber keine Ahnung, ob oder wie das geht oder wie die Fachbegriffe dazu heißen, falls es geht.
Ein Begriff dazu wäre z.B. Array Texture.
;3D schrieb:
Dann hatte ich an vielen Stellen Performanceprobleme... Minecraft schaffte es, ein Vielfaches der Blocks bei gleicher Framerate zu rendern, obwohl schon Minecraft angeblich schlecht optimiert sein soll - außerdem hatte ich aus Performancegründen schon die gesamte Welt in ein riesiges VBO gesteckt und damit in Kauf genommen, dass ich nicht einmal Änderungen vornehmen konnte ohne das ganze Ding zu aktualisieren. Und mangels Überblick hatte ich auch keine ernsthaften Ansätze, wie ich das hätte schneller bekommen können.
D.h. du versuchst immer, die ganze Welt zu rendern? Wärs nicht vielleicht wesentlich effizienter, nur die Teile der Welt zu rendern, die auch wirklich sichtbar sind (alles, was hinter dem Betrachter liegt, kann man z.B. schonmal sicher ausschließen)!? Stichworte dazu: View Frustum Culling, Visibility, Occlusion Culling.
;3D schrieb:
Naja, wie dem auch sei, sich nur anhand von Google in ein derartiges komplexes Thema einzuarbeiten ist weitgehend zum Scheitern verurteilt und eben deswegen suche ich Literatur, welche die Konzepte in der Grafikprogrammierung vollständig vermittelt anstatt alles fetzchenweise zu präsentieren.
Vermutlich nicht ganz, was du erwartest, aber auf jeden Fall empfehlen kann ich:
http://www.amazon.de/Mathematics-Game-Programming-Computer-Graphics/dp/1435458869/ref=sr_1_1?ie=UTF8&qid=1386966828&sr=8-1&keywords=mathematics+for+3d+game
http://www.amazon.de/Real-time-Rendering-Tomas-Akenine-Möller/dp/1568814240/ref=sr_1_1?ie=UTF8&qid=1386966857&sr=8-1&keywords=real-time+rendering
Beide Bücher sind allerdings akademisch angehaucht, was für viele möglicherweise gewöhnungsbedürftig ist...
-
dot schrieb:
Üben, üben, üben...
Aber sicher
Nur, was mich oft zur Frustration brachte war, dass ich vor einem bestimmten Problem stand und nicht mal Ansätze hatte, weil mir der Überblick über die mir überhaupt zur Verfügung stehenden OpenGL-Mittel und generelle Techniken fehlte.dot schrieb:
Klingt mir so, als scheitert es eher an der Mathematik, als an OpenGL? Das Stichwort in dem Fall lautet "Picking".
Ja, in diesem Fall wohl schon. Sowas wie Quaternions machen mir immer noch Knoten ins Hirn.
Ich glaube das Hauptproblem war (ist schon ein paar Jährchen her), dass ich kleine Debugpunkte in die Welt setzen wollte, die visualisieren sollten, wo sich mein Algorithmus entlanghangelt. Wenn die Punkte konzentriert vor mir gewesen wären, wäre die Richtung die Blickrichtung und damit korrekt gewesen. Aber egal was ich gemacht habe, die Punkte gingen an einer fixen Linie an einer der Weltachsen entlang. Nach Stunden der Fehlersuche ahnte ich dann, dass ich irgendwo einen massiven Denkfehler hatte (fälschlicherweise Blickrichtung wieder rausgerechnet oder so), aber meine mentale Kapazitäten haben nicht ausgereicht, den Denkfehler auf den Punkt zu bringen. Drum habe ich dann frustriert kapituliert (zumal der Algorithmus dann auch ohne die blöden Punkte funktioniert hat).dot schrieb:
Ein Begriff dazu wäre z.B. Array Texture.
Danke, ist schon mal gut zu wissen, dass es geht, damit habe ich einen Ansatz beim nächsten Mal.
dot schrieb:
D.h. du versuchst immer, die ganze Welt zu rendern? Wärs nicht vielleicht wesentlich effizienter, nur die Teile der Welt zu rendern, die auch wirklich sichtbar sind (alles, was hinter dem Betrachter liegt, kann man z.B. schonmal sicher ausschließen)!? Stichworte dazu: View Frustum Culling, Visibility, Occlusion Culling.
Das stimmt. Ich weiß nicht mehr, ob ich zuerst die Welt blockweise gerendert habe und dann wegen Problemen zu der "all in one"-Variante gewechselt habe oder ob ich noch ändern wollte. Ich dachte auch schon an occlusion culling, aber der simple Ansatz (mit einigen Probelinien testen, ob die Linien vorher ein undurchsichtiges Objekt treffen) wäre wohl nicht sehr zuverlässig (wenn ein kleines Loch in einer Wand ist, sieht man trotzdem nichts dahinter). Und übertreiben darf ich es auch nicht mit meinen Linien, da das jedes Frame gemacht werden muss. Und für irgendwelche komplizierteren Methoden war ich noch nicht bereit. Ich glaube, Minecraft betreibt auch keinerlei occlusion culling und rendert fröhlich unsichtbare Höhlensysteme unter der Erde. Und liefert ärgerlicherweise trotzdem gute Performance.
dot schrieb:
Vermutlich nicht ganz, was du erwartest, aber auf jeden Fall empfehlen kann ich:
http://www.amazon.de/Mathematics-Game-Programming-Computer-Graphics/dp/1435458869/ref=sr_1_1?ie=UTF8&qid=1386966828&sr=8-1&keywords=mathematics+for+3d+game
http://www.amazon.de/Real-time-Rendering-Tomas-Akenine-Möller/dp/1568814240/ref=sr_1_1?ie=UTF8&qid=1386966857&sr=8-1&keywords=real-time+rendering
Beide Bücher sind allerdings akademisch angehaucht, was für viele möglicherweise gewöhnungsbedürftig ist...Danke! Und wenn das heißt, das die Bücher viel Information auf wenig Raum bieten, habe ich kein Problem damit.
Aber gibt es einen Grund, warum die gebrauchten Exemplare allesamt teurer als die neuen sind?
-
dot schrieb:
Aber gibt es einen Grund, warum die gebrauchten Exemplare allesamt teurer als die neuen sind?
Weil ich die alle schon in der Hand hatte und signiert habe !
-
John Carmack schrieb:
dot schrieb:
Aber gibt es einen Grund, warum die gebrauchten Exemplare allesamt teurer als die neuen sind?
Weil ich die alle schon in der Hand hatte und signiert habe !
qft