Halli Hallo, ich habe eine Frage dich mich momentan sehr beschäftigt.

Wenn ich eine z.B. eine Würfelmatrix (10X10X10) zeichnen möchte, habe ich bisher eine Funktion à la "drawCube(x, y, z)" verwendet.
Wie der Funktionskopf erahnen lässt, zeichnet diese einen Würfel am gegebenen Punkt.
Diese Funktion wurde dann einfach in drei Schleifen ausgeführt.

An der Uni wurden wir angewiesen so ein Szenario stets mit affiner Transformation zu lösen.
Man solle also eine Funktion verwenden "drawCube(void)", die einen Würfel im Nullpunkt zeichnet.
In den 3 Schleifen würde dann eben mit glTranslate gearbeitet werden.

Kann mir jemand sagen, warum man letzeres der ersten Methode vorziehen soll?
Gibt es zwischen den beiden Methoden Unterschiede in der Perfomance?

In einem aktuellen Projekt werden >20000 solch Würfel gezeichnet, von daher wäre es gut zu wissen,
ob es da unterschiede gibt .

Vielen Dank im Vorraus, Felix.

Der einzige Unterschied dabei sollte (so wie ich es verstanden habe) sein, dass du die drei Koordiaten einmal als Parameter übergibst und einmal "sofort" an glTranslatef() sendest. Der Performanceunterschied sollte also eigentlich vernachlässigbar sein. Eigentlich sind beide Varianten nicht sehr performant. Besser wäre wohl die Würfel vorher "auszurechnen" und die Daten dann in einem VertexBufferObject zu speichern. glTranslatef() ist sowieso als veraltet markiert.

Hallo Markus,
der von dir angepsprochene Unterschied ist mir klar (Die Funktionen habe ich ja selber so definiert).
Meinst du mit dem BufferVertexObjekten, dass man das ganze in display listen packt? Das hatte ich vergessen zu erwähnen, die Zeichenoperationen werden natürlich in display listen
vorberechnet und dann nur noch aufgerufen.

glTranslatef() ist veraltet?? Das erstaunt mich jetzt ziemlich. Kannst du das mal näher erläutern, das ist doch eine grundlegene Funktion, die man ständig benötigt.

Gruß, Felix.

Ich glaube mit dem theoretischen Unterschied ist ein einsparbarere Arbeitsschritt gemeint. Die Vertices deiner Würfel müssen so oder so mit Modelviewmatrix multipliziert werden.

Wenn du jetzt aber die Matrix so belässt wie sie ist und anstelle dessen deine Vertices anpasst, dann musst du zu erst die Positionen deiner Vertices anpassen und anschließend müssen diese sowieso noch mit der Modelviewmatrix multipliziert werden.

Wenn du aber anstelle dessen die Matrix anpasst, dann kannst du die Vertices direkt übergeben und die finale Position erreichen sie trotzdem. Nur mit weniger Rechenschritten.

Allerdings kann ich Markus vollkommen zustimmen. Ideal sind beide Methoden nicht. Und der Unterschied zwischen beiden Methoden ist vernachlässigbar. Zu mal da Matrixmanipulationen mitunter mehr Zeit benötigen als das Errechen der finalen Positionen. Zu mal man auch nur 4 Vertices berechnen muss.

Besser wäre dort in jedem Fall die Verwendung von VBOs, da dies schlicht dem Charakter moderner Hardware entspricht.

Wegen veraltet:
Naja, mit OpenGL 3 fällt noch viel mehr raus. glBegin (siehe VBOs), glTranslatef (sowas soll man dann auffer CPU lösen), um die gravierendsten zu nennen. Achja, ne fixed pipeline gibts auch nicht mehr, dafür geht alles über Shader. Sehr anfängerfreundlich halt

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Oh man, ich bin ganz platt.
Das "alte" wird ja alles noch in Büchern gelehrt. (Was vielleicht daran liegt, dass es Grundlagen sind?!)

Auf jeden fall habe ich jetzt eine Richtung in die ich weiter Arbeiten kann.
Dann werde ich mich mal eingehend mit VBO beschäftigen.
Vielen Dank an alle.

Der Vorteil von der Methode mit glTranslate ist das du nur eine Displayliste für alle Würfel benötigst! Bei der anderen Methode müsstest du sonst alle Würfel in eine Displayliste werfen, was ziemlich unflexibel ist, wenn du z.B. einen einzelnen Würfel zur Laufzeit verschieben/drehen willst.


In einem größeren Projekt hat man sowieso seine eigenen Klassen für Matrizen, Vektoren usw. Normalerweise macht man dann seine Matrixoperationen komplett selbst, weil man sie sowieso auch für andere Dinge (z.B. Physik) benötigt und übergibt nur noch die finale Matrix an OpenGL. Inbesondere wenn man z.B. mit Quaternionen statt Matrizen arbeitet, kommt man mit OpenGL nicht weit.
Das der Immediate Mode (glBegin...glEnd) nicht sonderlich schnell sein kann dürfte schon durch die vielen Prozeduraufrufe klar werden.

Bei uns an der Uni wurde der Immediate Mode zwar erwähnt, aber man wurde dann relativ schnell auf Vertexbufferobjects verwiesen.

_________________
Yeah!

Die erste Variante schränkt dich als Programmierer ein.
In der 2. Varainte kannst du z.B. für jeden Würfel das gleiche VBO verwenden und über instancing alle Cubes zeichnen, bei der 1. Variante ist dies schon nicht mehr so trivial zu lösen.
Die 1. Version bindet Objektkoordinaten, neben den Meshdaten und die 2. Variante nur Meshdaten aber keine Objektkoordinaten, was die Implementierung dieser auch von aussen ermöglicht.
Auch aus Sicht eines Ressourcenmanagment Systems ist die 2. Variante besser.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Knaggy: Lass dich von den Äußerungen nicht schocken. Ja. In OpenGL 3.0 sind viele Sachen als veraltet markiert worden und sollten nicht mehr verwendet werden. Dadurch ist OpenGL 3.0 viel näher an dem was für Hardware am idealsten ist. Es hat aber niemand gesagt, dass ab sofort wirklich jeder mit OpenGL 3.0 arbeiten muss und, dass alles was man vorher gelernt hat falsch ist und nicht mehr verwendet werden darf. Auch wenn das bei dem Ein oder Anderen gerne mal so klingt. Nichts desto trotz ist OpenGL 3.0 deutlich näher an der Arbeitsweise der Grafikkarte und früher oder später wird kein Weg daran vorbei führen. OpenGL 3.0 ist recht neu und schraubt somit auch die Anforderungen sehr weit nach oben. Allerdings viele von den Funktionen wie VBO oder Vertex/Framgent Shader waren bereits vor 3.0 vorhanden. OpenGL 3.0 dient eher dazu die Schnittstelle aufzuräumen. Ich bin keineswegs gegen OpenGL 3.0. Ganz im Gegenteil. Sich neuen Technologien zu verschließen halte ich in unserem Gewerbe für fatal. Allerdings muss man die gegebenen Bibliotheken auch sinnvoll einsetzen. Das ist etwas was grundsätzlich jeder bedenken sollte.

Nichts destro trotz solltest du den Imediate mode (glBegin/glEnd) nicht mehr verwenden. Speziell für große Datenmengen ist das einfach nicht brauchbar (weil viel zu langsam). Wo du auch gerade erst mit OpenGL anfängst hast du noch nicht so viel Zeit gehabt dich an den imediate Mode zu gewöhnen.

Ja das ist so eines der größten Probleme, OpenGL1-2 hat viel angehäuft, was einfach völlig veraltet ist und teilweise nur Nachteile mit sich zieht.
Der Vorteil bei OpenGL3, als Neuling ist, dass man nicht viel lernen muss, da es nur sogenannte Buffer Objects(Frame Buffer Objects, Vertex Buffer Objects, Vertex Array Object, ...) gibt und dann für einige dinge noch spezielle Objekte(Texturen, Shader) damit ist die ganze Ressourcengeschichte schon abgearbeitet. Es gibt dann noch API zum nutzen bestimmter Features, wie z.B. Occlusion Query, Conditional Rendering, Transform Feedback und Instancing aber dann ist auch schon hier schluss.
Die API für OpenGL3 ist sehr übersichtlich und kurz, siehe hier. Allerdings sind einige Thematiken, wie Transform Feedback, recht schwer verdaulich und man muss nun auch von anfang an in Vektorrechnung standfest sein. Wenn man sich ein Defaulshader und eine Bibliothek für Vektoroperationen besorgt, dann ist OpenGL3 definitiv der bessere einstieg.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004