OpenGL + Qt Tutorial (2024)

• Anpassung der Klasse OpenGLWindow an die in QOpenGLWidget bzw. QOpenGLWindow verwendeten Funktionsnamen

• Vorstellung der Klasse SceneView, die das bisherige TriangleWindow oder RectangleWindow ersetzt

• Transformationsmatrizen: Model → World → Kamera → Projektion (Klassen Transform3D und Camera)

• Tastatur- und Mauseingabebehandlung (Klasse KeyboardMouseHandler)

• Kapselung der Shaderprogramme und Initialisierung und Verwendung derselben (Klasse ShaderProgram)

• Kapselung der Zeichenroutinen für das Gitterraster, Abblendeffekt am Horizont im Shader (Klasse GridObject und Shader grid.vert und grid.frag)

• Kapselung der Zeichenroutinen für die Boxen (Klassen BoxObject und BoxMesh, und Shader withWorldAndCamera.vert und simple.frag)

OpenGLWindow.cpp:initOpenGL()

void OpenGLWindow::initOpenGL() {Q_ASSERT(m_context == nullptr);m_context = new QOpenGLContext(this);m_context->setFormat(requestedFormat());m_context->create();m_context->makeCurrent(this);Q_ASSERT(m_context->isValid());initializeOpenGLFunctions();initializeGL(); // call user code}

OpenGLWindow.cpp: Funktion resizeEvent()

void OpenGLWindow::resizeEvent(QResizeEvent * event) {QWindow::resizeEvent(event);// initialize on first callif (m_context == nullptr)initOpenGL();resizeGL(width(), height());}

5.3.1. Klassendeklaration

Zwecks Überblick ist hier zunächst die Klassendeklaration in Teilen. Zuerst die üblichen Verdächtigen:

class SceneView : public OpenGLWindow {public:SceneView();virtual ~SceneView() override;protected:void initializeGL() override;void resizeGL(int width, int height) override;void paintGL() override;

Dann kommen die Ereignisbehandlungsroutinen für die Tastatur- und Mauseingaben. Dazu gehören auch die Hilfsfunktionen checkInput() und processInput(), die im Abschnitt zur Tastatur- und Mauseingabe erklärt sind. Die Member-Variablen m_keyboardMouseHandler und m_inputEventReceived gehören auch dazu.

void keyPressEvent(QKeyEvent *event) override;void keyReleaseEvent(QKeyEvent *event) override;void mousePressEvent(QMouseEvent *event) override;void mouseReleaseEvent(QMouseEvent *event) override;void mouseMoveEvent(QMouseEvent *event) override;void wheelEvent(QWheelEvent *event) override;private:void checkInput();void processInput();KeyboardMouseHandlerm_keyboardMouseHandler;boolm_inputEventReceived;

Dann kommt die Funktion updateWorld2ViewMatrix() zur Koordinatentransformation und die dazugehörigen Member-Variablen.

void updateWorld2ViewMatrix();QMatrix4x4m_projection;Transform3Dm_transform;Cameram_camera;QMatrix4x4m_worldToView;

Zuletzt kommen Member-Variablen, die die Shader-Programme und Zeichenobjekte kapseln (beinhalten Shader, VAO, VBO, EBO, etc.)

QList<ShaderProgram>m_shaderPrograms;BoxObjectm_boxObject;GridObjectm_gridObject;};

Und das war’s auch schon - recht kompakt, oder?

5.3.2. Das Aktualisierungskonzept

Erklärtes Ziel dieser OpenGL-Implementierung ist nur dann zu rendern, wenn es wirklich notwendig ist. Also:

Wenn man jetzt bei jedem Eintreffen eines solchen Ereignisses jedesmal neu zeichnen würde, wäre das mit ziemlichem Overhead verbunden. Besser ist es, beim Eintreffen eines solchen Ereignisses einfach nur ein Neuzeichnen anzufordern. Da die UpdateRequest-Ereignisse normalerweise mit der Bildschirmfrequenz synchronisiert sind, kann es natürlich sein, dass mehrfach hintereinander UpdateRequest-Events an die Eventloop angehängt werden. Dabei werden diese aber zusammengefasst und nur ein Event ausgeschickt. Es muss ja auch nur einmal je angezeigtem Frame gezeichnet werden.

Grundsätzlich muss man also nur die Funktion QWindow::requestUpdate() (oder unsere Bequemlichkeitsfunktion renderLater()) aufrufen, damit beim nächsten VSync wieder neu gezeichnet wird.

Leider funktionier das Verfahren im Fall des ExposeEvent bzw. ResizeEvent nicht perfekt. Gerade unter Windows führt das beim Vergrößern des Fensters zu unschönen Artefakten am rechten und unteren Bildschirmrand. Daher muss man in diesem Fall tatsächlich sofort in der Ereignisbehandlungsroutine neu zeichnen und dabei den OpenGL Viewport bereits an die neue Fenstergröße anpassen. Das Neuzeichnen wird direkt im ExposeEvent-Handler von OpenGLWindow ausgelöst:

void OpenGLWindow::exposeEvent(QExposeEvent * /*event*/) {renderNow(); // update right now}

Bei Größenveränderung des Fensters sendet Qt immer zuerst ein ResizeEvent gefolgt von einem ExposeEvent aus. Daher sollte man in der Funktion SceneView::resizeEvent() nicht renderLater() aufrufen!

Ohne eine Aufruf von renderLater() im ResizeEvent-Handler erhält man folgende Aufrufreihenfolge bei der Fenstervergrößerung:

OpenGLWindow::resizeEvent()OpenGLWindow::exposeEvent()SceneView::paintGL(): Rendering to: 1222 x 891OpenGLWindow::resizeEvent()OpenGLWindow::exposeEvent()SceneView::paintGL(): Rendering to: 1224 x 892

Ruft man stattdessen renderLater() auf, erhält man:

OpenGLWindow::resizeEvent()OpenGLWindow::exposeEvent()SceneView::paintGL(): Rendering to: 1283 x 910SceneView::paintGL(): Rendering to: 1283 x 910OpenGLWindow::resizeEvent()OpenGLWindow::exposeEvent()SceneView::paintGL(): Rendering to: 1288 x 912SceneView::paintGL(): Rendering to: 1288 x 912

Wie man sieht, wird jedes Mal doppelt gezeichnet, was eine deutlich spürbare Verzögerung bedeutet. Grundsätzlich hilf es zu wissen, dass:

5.3.3. Verwendung der Klasse SceneView

Die Klasse SceneView wird als QWindow-basierte Klasse selbst via Widget-Container in den Testdialog eingebettet (siehe Tutorial 03).

Bei der Analyse des Tutorialquelltextes kann man sich von außen nach innen "arbeiten":

Es gibt im Quelltext von TestDialog.cpp nur ein neues Feature: Antialiasing (siehe letzter Abschnitt "Antialiasing" dieses Tutorials).

5.3.4. Implementierung der Klasse SceneView

Und da wären wir auch schon bei der Implementierung des Klasse SceneView.

Im Konstruktor werden letztlich 3 Dinge gemacht:

SceneView::SceneView() :m_inputEventReceived(false){// tell keyboard handler to monitor certain keysm_keyboardMouseHandler.addRecognizedKey(Qt::Key_W);m_keyboardMouseHandler.addRecognizedKey(Qt::Key_A);m_keyboardMouseHandler.addRecognizedKey(Qt::Key_S);m_keyboardMouseHandler.addRecognizedKey(Qt::Key_D);m_keyboardMouseHandler.addRecognizedKey(Qt::Key_Q);m_keyboardMouseHandler.addRecognizedKey(Qt::Key_E);m_keyboardMouseHandler.addRecognizedKey(Qt::Key_Shift);// *** create scene (no OpenGL calls are being issued below, just the data structures are created.// Shaderprogram #0 : regular geometry (painting triangles via element index)ShaderProgram blocks(":/shaders/withWorldAndCamera.vert",":/shaders/simple.frag");blocks.m_uniformNames.append("worldToView");m_shaderPrograms.append( blocks );// Shaderprogram #1 : grid (painting grid lines)ShaderProgram grid(":/shaders/grid.vert",":/shaders/simple.frag");grid.m_uniformNames.append("worldToView"); // mat4grid.m_uniformNames.append("gridColor"); // vec3grid.m_uniformNames.append("backColor"); // vec3m_shaderPrograms.append( grid );// *** initialize camera placement and model placement in the world// move objects a little bit to the back of the scene (negative z coordinates = further back)m_transform.translate(0.0f, 0.0f, -5.0f);m_camera.translate(0,5,0);m_camera.rotate(-30, m_camera.right());}

Im Destruktor der Klasse werden die OpenGL-Objekte wieder freigegeben:

SceneView::~SceneView() {m_context->makeCurrent(this);for (ShaderProgram & p : m_shaderPrograms)p.destroy();m_boxObject.destroy();m_gridObject.destroy();}

Wichtig ist hier, dass der OpenGL-Context für das aktuelle Fenster aktuell gesetzt wird (m_context->makeCurrent(this)). Damit können dann die OpenGL-Objekte freigegeben werden. Dies erfolgt in den destroy() Funktionen der Shaderprogramm-Wrapper-Klasse und Zeichen-Objekt-Wrapper-Klassen.

5.3.5. OpenGL-Initialisierung

Die eigentlich Initialisierung der OpenGL-Objekte (Shaderprogramme und Pufferobjekte) erfolgt in initializeGL():

#define SHADER(x) m_shaderPrograms[x].shaderProgram()void SceneView::initializeGL() {// initialize shader programsfor (ShaderProgram & p : m_shaderPrograms)p.create();// tell OpenGL to show only faces whose normal vector points towards usglEnable(GL_CULL_FACE);// enable depth testing, important for the grid and for the drawing order of several objectsglEnable(GL_DEPTH_TEST);// initialize drawable objectsm_boxObject.create(SHADER(0));m_gridObject.create(SHADER(1));}

Dank der Kapselung der Shaderprogramm-Initialisierung in der Klasse ShaderProgram und der Kapselung der Zeichenobjekt-spezifischen Initialisierung in den Objekten ist diese Funktion sehr viel übersichtlicher als in den bisherigen Tutorials.

Das Makro SHADER(x) wird verwendet, um bequem auf das QOpenGLShaderProgram Objekt in der Wrapper-Klasse zuzugreifen.

Die beiden glXXX Befehle in der Mitte der Funktion schalten zwei für 3D Szenen wichtige Funktionen ein:

Die Funktion glDepthFunc(GL_LESS) muss nicht aufgerufen werden, da das bei OpenGL der Standard ist.

Für den Tiefentest ist ein zusätzlicher Tiefenpuffer notwendig (bisher hatten wir nur den Farbpuffer (engl. Color Buffer). Wichtig ist daher, dass bei Verwendung eines Tiefenpuffers dieser Puffer ebenso wie der Farbpuffer zu Beginn des Zeichnens gelöscht wird. Dies passiert in paintGL():

void SceneView::paintGL() { ...glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);...}

format.setDepthBufferSize(8);

• Nicht gedrückt

• Gerade gedrückt

• Wurde gedrückt

5.4.1. Der Tastatur- und Maus-Zustandsmanager

Man könnte die gesamte Tastatur- und Mausbehandlung natürlich auch direkt in der Klasse SceneView implementieren, in der auch die Ereignisbehandlungsfunktionen aufgerufen werden. Es ist aber übersichtlicher, diese in der Klasse KeyboardMouseHandler zu kapseln.

Die Aufgabe dieser Klasse ist letztlich sich zu merken, welche Taste/Mausknopf gerade gedrückt ist. Die Implementierung der Klasse ist für das Tutorial eigentlich nicht so wichtig, vielleicht lohnt aber ein Blick auf die Klassendeklaration:

class KeyboardMouseHandler {public:KeyboardMouseHandler();virtual ~KeyboardMouseHandler();// functions to manage known keysvoid addRecognizedKey(Qt::Key k);void clearRecognizedKeys(); // event handler helpersvoid keyPressEvent(QKeyEvent *event);void keyReleaseEvent(QKeyEvent *event);void mousePressEvent(QMouseEvent *event);void mouseReleaseEvent(QMouseEvent *event);void wheelEvent(QWheelEvent *event); // state changing helper functionsbool pressKey(Qt::Key k);bool releaseKey(Qt::Key k);bool pressButton(Qt::MouseButton btn, QPoint currentPos);bool releaseButton(Qt::MouseButton btn); // query functionsbool keyDown(Qt::Key k) const;bool buttonDown(Qt::MouseButton btn) const;QPoint mouseDownPos() const { return m_mouseDownPos; }int wheelDelta() const; // state reset functionsQPoint resetMouseDelta(const QPoint currentPos);int resetWheelDelta();void clearWasPressedKeyStates();private:enum KeyStates {StateNotPressed,StateHeld,StateWasPressed};std::vector<Qt::Key>m_keys;std::vector<KeyStates>m_keyStates;KeyStatesm_leftButtonDown;KeyStatesm_middleButtonDown;KeyStatesm_rightButtonDown;QPointm_mouseDownPos;intm_wheelDelta;};

Eine KeyboardMouseHandler-Klasse wird nach der Erstellung durch Aufrufe von addRecognizedKey() konfiguriert (siehe Konstruktor der Klasse SceneView).

Für die Tastatur- und Maus-Ereignisbehandlungsroutinen gibt es passende Hilfsfunktionen, sodass man von den Event-Funktionen der eigenen View-Klasse einfach diese Hilfsfunktionen aufrufen kann. Die Zustandsänderungslogik (auch das Prüfen auf AutoRepeat) wird in diesen Funktionen gemacht. Bei bekannten Tasten wird der QKeyEvent oder QMouseEvent akzeptiert, sonst ignoriert.

Den Zustand einzelner Tasten kann man auch programmgesteuert durch die pressXXX und releaseXXX Funktionen ändern.

Danach kommen die Funktionen zum Abfragen des Zustands. Bei Tasten ist die Abfrage mit keyDown() oder buttonDown() recht klar (sowohl der Zustand "gerade gedrückt", als auch "gedrückt und wieder losgelassen" liefern hier true zurück).

Bei der Mausbewegung und Scroll-Rad muss immer die Veränderung zwischen zwei Abfragezeitpunkten angeschaut werden. Bei Verwendung einer Free-Mouse-Look-Taste (hier rechte Maustaste), wird beim Drücken dieser Taste die globale Cursorpostion abgelegt, welche über mouseDownPos() abgefragt werden kann. Bei Mouse-Wheel-Ereignissen werden die Drehstufen (Winkel/Ticks) addiert.

Wenn man diese Änderungen nun in eine Bewegung umwandelt, muss man diese nach dem Auslesen wieder zurücksetzen. Dies erfolgt mit den Funktionen resetMouseDelta() und resetWheelDelta(), welche beide die bislang erfassten Differenzen zurückliefern. Die const-Abfragefunktionen mouseDownPos() und wheelDelta() können also verwendet werden, um zu Testen, ob es eine Maus-/Scrollradbewegung gab. Und beim Anwender der Änderungen ruf man die resetXXX() Funktionen auf.

Zuletzt muss man die Funktion clearWasPressedKeyStates() nach Abfrage der Tasten aufrufen, um die "wurde gedrückt" Zustände wieder in den "Nicht gedrückt" Zustand zurückzusetzen.

Die Implementierung der Klasse ist recht einfach und selbsterklärend und muss hier nicht näher ausgeführt werden. Interessant ist die Verwendung der Klasse. Dazu müssen wir uns zunächst den Programmauflauf der Ereignisschleife und Auswertung der Tasteneingabe genauer anschauen.

5.4.2. Die Ereignisschleife und Tastatur-/Mausevents

Zwischen zwei Frames (also Aufrufen von paintGL()) läuft das Programm in der Ereignisschleife. Sobald eine Taste gedrückt oder losgelassen wird, ruft Qt die entsprechende Ereignisbehandlungsfunktion auf, d.h. keyPressEvent() bzw. keyReleaseEvent(). Ebenso werden bei Mausaktionen die entsprechenden Aktionen ausgelöst.

Die Aufrufe werden an die gleichnamigen Funktionen in Zustandsmanager (KeyboardMouseHandler) weitergereicht. Wenn die betreffende Taste dem Zustandsmanager bekannt ist, wird der aktuelle Zustand im Zustandsmanager entsprechend geändert.

Nun wird noch geprüft, ob die Taste eine Szenenveränderung (bspw. Kamerabewegung) bewirkt. Dies erfolgt in der Funktion SceneView::checkInput().

void SceneView::checkInput() {// trigger key held?if (m_keyboardMouseHandler.buttonDown(Qt::RightButton)) {// any of the interesting keys held?if (m_keyboardMouseHandler.keyDown(Qt::Key_W) ||m_keyboardMouseHandler.keyDown(Qt::Key_A) ||m_keyboardMouseHandler.keyDown(Qt::Key_S) ||m_keyboardMouseHandler.keyDown(Qt::Key_D) ||m_keyboardMouseHandler.keyDown(Qt::Key_Q) ||m_keyboardMouseHandler.keyDown(Qt::Key_E)){m_inputEventReceived = true;renderLater();return;}// has the mouse been moved?if (m_keyboardMouseHandler.mouseDownPos() != QCursor::pos()) {m_inputEventReceived = true;renderLater();return;}}// scroll-wheel turned?if (m_keyboardMouseHandler.wheelDelta() != 0) {m_inputEventReceived = true;renderLater();return;}}

In dieser Funktion werden nun die Abfragefunktionen verwendet, d.h. der Zustand des Tastatur-/Maus-Zustandsmanagers wird nicht verändert. Auch ist zu beachten, dass die Abfrage nach dem Mausrad separat erfolgt.

Wird eine relevante Taste oder Mausbewegung erkannt, wird durch Aufruf von renderLater() ein Zeichenaufruf in die Event-Schleife eingereiht (kommt beim nächsten VSync) und das Flag m_inputEventReceived wird gesetzt dann geht die Kontrolle wieder zurück an die Ereignisschleife.

Es ist nun möglich, dass ein weiteres Tastaturereignis eintrifft, bevor das UpdateRequest-Ereignis eintritt. Bspw. könnte dies das QEvent::KeyRelease-Ereignis eines gerade zuvor eingetroffenen QEvent::KeyPress-Ereignisses derselben Taste sein. Deshalb wird der Zustand einer Taste beim keyReleaseEvent() auf "Wurde gedrückt" geändert, und nicht einfach wieder zurück auf "Nicht gedrückt". Sonst hätte man im Zustandsmanager keine Information mehr darüber, dass die Taste in diesem Frame kurz gedrückt wurde. Das ist zwar bei hohen Bildwiederholfrequenzen hinreichend unwahrscheinlich, kann aber bei sehr komplexen Szenen (bzw. schwacher Hardware) hilfreich sein.

5.4.3. Auswertung der Eingabe und Anpassung der Kameraposition- und Ausrichtung

Die eigentliche Auswertung der Tastenzustände und Bewegung der Kamera erfolgt am Anfang der SceneView::paintGL()-Funktion:

void SceneView::paintGL() {// process input, i.e. check if any keys have been pressedif (m_inputEventReceived)processInput(); ...

Da die Zeichenfunktion aus einer Vielzahl von Gründen aufgerufen werden kann, dient das Flag m_inputEventReceived dazu, nur dann die Eingaben auszuwerten, wenn es tatsächlich welche gab.

Die Auswertung des Tastatur- und Mauszustandes erfolgt in der Funktion SceneView::processInput():

void SceneView::processInput() {m_inputEventReceived = false;if (m_keyboardMouseHandler.buttonDown(Qt::RightButton)) {// Handle translationsQVector3D translation;if (m_keyboardMouseHandler.keyDown(Qt::Key_W)) translation += m_camera.forward();if (m_keyboardMouseHandler.keyDown(Qt::Key_S)) translation -= m_camera.forward();if (m_keyboardMouseHandler.keyDown(Qt::Key_A)) translation -= m_camera.right();if (m_keyboardMouseHandler.keyDown(Qt::Key_D)) translation += m_camera.right();if (m_keyboardMouseHandler.keyDown(Qt::Key_Q)) translation -= m_camera.up();if (m_keyboardMouseHandler.keyDown(Qt::Key_E)) translation += m_camera.up();float transSpeed = 0.8f;if (m_keyboardMouseHandler.keyDown(Qt::Key_Shift))transSpeed = 0.1f;m_camera.translate(transSpeed * translation);// Handle rotations// get and reset mouse delta (pass current mouse cursor position)QPoint mouseDelta = m_keyboardMouseHandler.resetMouseDelta(QCursor::pos());static const float rotatationSpeed = 0.4f;const QVector3D LocalUp(0.0f, 1.0f, 0.0f); // same as in Camera::up()m_camera.rotate(-rotatationSpeed * mouseDelta.x(), LocalUp);m_camera.rotate(-rotatationSpeed * mouseDelta.y(), m_camera.right());// finally, reset "WasPressed" key statesm_keyboardMouseHandler.clearWasPressedKeyStates();}int wheelDelta = m_keyboardMouseHandler.resetWheelDelta();if (wheelDelta != 0) {float transSpeed = 8.f;if (m_keyboardMouseHandler.keyDown(Qt::Key_Shift))transSpeed = 0.8f;m_camera.translate(wheelDelta * transSpeed * m_camera.forward());}updateWorld2ViewMatrix();}

Auch in dieser Funktion werden Bewegungen der Kamera durch Tastendrücke und Schwenker durch Mausbewegung unabhängig vom Scrollrad-Zoom behandelt. Am Ende der Funktion werden die Welt-zu-Perspektive-Transformationsmatrizen angepasst. Die relevanten Matrizen und auch das Kamera-Objekt (Klasse Camera) sind im Abschnitt "Transformationsmatrizen und Kamera" weiter unten beschrieben.

Die Bewegung der Kamera ist recht einfach nachvollziehbar - je nach gedrückter Taste wird eine Verschieberichtung auf den Vektor translation addiert. Der tatsächliche Verschiebevektor wird durch Multiplikation mit einer Geschwindigkeit transSpeed berechnet. Hier ist auch die "Verlangsamung-bei-Shift-Tastendruck"-eingebaut.

Die Drehung der Kamera hängt von der Mausbewegung ab. Hier wird die Funktion resetMouseDelta() aufgerufen, welche zwei Funktionen hat:

Bei der Bewegung erfolgt die Neigung der Kamera um die x-Achse des lokalen Kamerakoordinatensystems (wird zurückgeliefert durch die Funktion m_camera.right(). Analog könnte man die Kamera auch um die lokale y-Achse der Kamera schwenken (wie in einem Flugsimulator üblich), dies führt aber zu recht beliebigen Ausrichtungen. Möchte man die Kamera eher parallel zum "Fußboden" halten, dann dreht man die Kamera um die y-Achse des Weltenkoordinatensystems (Vektor 0,1,0).

Am Ende des Tastaturabfrageteils werden noch die "wurde gedrückt"-Zustände zurückgesetzt.

Das Scrollrad soll in diesem Beispiel ein deutlich schnelleres Vorwärts- oder Rückwärtsbewegen durch die Szene ermöglichen. Deshalb werden die Mausradbewegungen mit größerer Verschiebegeschwindigkeit skaliert. Wie auch bei der Abfrage der Mausbewegung wird in der Funktion resetWheelDelta() der aktuell akkumulierte Scrollweg zurückgeliefert und intern im Zustandsmanager wieder auf 0 gesetzt.

5.4.4. Auf gedrückte Tasten reagieren

Wie oben erläutert wird das Neuzeichnen nur bei Registrieren eines Tastendrucks angefordert. Nehmen wir mal an, die rechte Maustaste ist gedrückt und die Vorwärtstaste W wird gedrückt gehalten. Dann sendet das Betriebssystem (bzw. Window-Manager) in regelmäßigen Abständen KeyPress-Events (z.B. 50 je Sekunde, je nach Einstellung). Diese sind dann als AutoRepeat gekennzeichnet und führen damit nicht zu einer Änderung im Eingabe-Zustandsmanager, aber zu einer erneuten Prüfung der Neuzeichnung (Aufruf von checkInput()). Und da eine Kamera-relevante Taste gedrückt gehalten ist, wird ein Neuzeichnen via renderLater() angefordert. Als Konsequenz ruckelt das Bild dann im Rythmus der Tastenwiederholrate…​ nicht sehr angenehm anzusehen.

Daher muss das Prüfen auf gedrückte Tasten regelmäßig, d.h. einmal pro Frame erfolgen. Und der geeignete Ort dafür ist das Ende der paintGL()-Funktion:

void SceneView::paintGL() { ...checkInput();}

Ganz zum Schluss wird nochmal auf eine Tasteneingabe geprüft und damit bei Bedarf ein UpdateRequest eingereiht.

Damit wäre die Tastatur- und Mauseingabe auch schon komplett.

ShaderProgram.h

class ShaderProgram {public:ShaderProgram();ShaderProgram(const QString & vertexShaderFilePath, const QString & fragmentShaderFilePath);void create();void destroy();QOpenGLShaderProgram * shaderProgram() { return m_program; } // paths to shader programs, used in create()QStringm_vertexShaderFilePath;QStringm_fragmentShaderFilePath;QStringListm_uniformNames; // uniform (variable) namesQList<int>m_uniformIDs; // uniform IDs (resolved in create())private:QOpenGLShaderProgram*m_program;};

SceneView.cpp:SceneView()

SceneView::SceneView() :m_inputEventReceived(false){ ...// Shaderprogram #0 : regular geometry (painting triangles via element index)ShaderProgram blocks(":/shaders/withWorldAndCamera.vert",":/shaders/simple.frag");blocks.m_uniformNames.append("worldToView");m_shaderPrograms.append( blocks );// Shaderprogram #1 : grid (painting grid lines)ShaderProgram grid(":/shaders/grid.vert",":/shaders/grid.frag");grid.m_uniformNames.append("worldToView"); // mat4grid.m_uniformNames.append("gridColor"); // vec3grid.m_uniformNames.append("backColor"); // vec3m_shaderPrograms.append( grid ); ...}

ShaderProgram.cpp:create()

void ShaderProgram::create() {Q_ASSERT(m_program == nullptr);m_program = new QOpenGLShaderProgram();if (!m_program->addShaderFromSourceFile(QOpenGLShader::Vertex, m_vertexShaderFilePath))qDebug() << "Vertex shader errors:\n" << m_program->log();if (!m_program->addShaderFromSourceFile(QOpenGLShader::Fragment, m_fragmentShaderFilePath))qDebug() << "Fragment shader errors:\n" << m_program->log();if (!m_program->link())qDebug() << "Shader linker errors:\n" << m_program->log();m_uniformIDs.clear();for (const QString & uniformName : m_uniformNames)m_uniformIDs.append( m_program->uniformLocation(uniformName));}

5.6.1. Transformationen

Das Thema Transformationsmatrizen ist in den in der Einleitung zitierten Webtutorials/Anleitungen ausreichend beschrieben. Die Format zur Transformation eines Punktes/Vektors pModel in den Modellkoordinaten zu den View-Koordinaten pView benötigt 3 Transformationsmatrizen:

pView = M_projection * M_World2Camera * M_Model2World * pModel

Dies entspricht den Schritten:

Da die Objekte in Modell bzw. Weltkoordinaten definiert und verwaltet werden, sollte besser OpenGL die Transformationen durchführen (dafür ist es ja gemacht). Je nach Anzahl der zu transformierenden Objekte kann nun den objektspezifischen ersten Transformationsschritt in das Weltenkoordinatensystem auf der CPU durchführen (idealerweise parallelisiert). Die Transformation von Weltkoordinaten in die projezierte Darstellung macht dann OpenGL. Da diese Matrix für alle Objekte gleich ist, kann man diese auch bequem den Shaderprogrammen übergeben. D.h. die Matrix:

M_World2View = M_Projection * M_World2Camera * M_Model2World

wird als uniform-Variable an die Shaderprogramme übergeben. Die Transformieren dann damit hocheffizient auf der Grafikkarte alle Vertex-Koordinaten.

5.6.2. Aktualisierung der World2View Matrix

Die Projektionsmatrix ändert sich bei jeder Viewport-Änderung, da sich damit zumeist das Breite/Höhe-Verhältnis ändert. Sonst ändert sich diese Matrix eigentlich nie, außer vielleicht in den Benutzereinstellungen (wenn z.B. Linseneigenschaften wie Öffnungswinkel oder Zoom verändert werden).

Die Model2World-Matrix bleibt wie oben geschrieben außen vor, da objektabhängig.

Die Kameramatrix (World2Camera) ändert sich jedoch ständig während der Navigation durch die Szene. Da die Navigation am Anfang der Neuzeichenroutine ausgewertet wird, erfolgt die Neuberechnung der Matrix (falls notwendig) auch direkt vorm Neuzeichnen.

Die eigentliche Berechnung erfolgt in der Funktion updateWorld2ViewMatrix. Dank der Funktionalität der Matrixklasse QMatrix4x4 eine sehr kompakte Funktion.

void SceneView::updateWorld2ViewMatrix() {// transformation steps:// model space -> transform -> world space// world space -> camera/eye -> camera view// camera view -> projection -> normalized device coordinates (NDC)m_worldToView = m_projection * m_camera.toMatrix() * m_transform.toMatrix();}

Die Multiplikation mit der Modell-Transformationsmatrix (m_transform) ist eigentlich nicht zwingend notwendig, dient aber der Demonstration der Animationsfähigkeit (konstantes Rotieren der Welt um die y-Achse). Dazu den #if 0 Block in paintGL() nach #if 1 ändern.

Die ganze Arbeit der Konfiguration und Erstellung der Translations, Rotations, und Skalierungsmatrizen macht die Klasse Transform3D. In der Funktion toMatrix() werden diese einzelnen Matrizen zur Gesamtmatrix kombiniert (implementiert mit Lazy-Evaluation):

const QMatrix4x4 &Transform3D::toMatrix() const {if (m_dirty) {m_dirty = false;m_world.setToIdentity();m_world.translate(m_translation);m_world.rotate(m_rotation);m_world.scale(m_scale);}return m_world;}

Die Kamera-Klasse ist davon abgeleitet und beinhaltet letztlich nur die inverse Transformation vom Welten- zum Beobachterkoordinatensystem (siehe auch https://www.trentreed.net/blog/qt5-opengl-part-3b-camera-control). Im Prinzip hilft es sich vorzustellen, dass die Kamera ein positioniertes und ausgerichtetes Objekt selbst ist. Nun wollen wir dieses Kamera-Objekt nicht mittels einer Model2World-Transformationsmatrix in das Weltenkoordinatensystem hieven, sondern uns eher aus der Weltsicht in die lokale Sicht des Kamera-Objekts bewegen. Dies bedeuted, wir müssen alle Weltkoordinaten mittels der Inversen der Kamera-Objekt-Model2World-Matrix multiplizieren. Das macht dann die entsprechend spezialisiert toMatrix()-Funktion:

const QMatrix4x4 & toMatrix() const {if (m_dirty) {m_dirty = false;m_world.setToIdentity();m_world.rotate(m_rotation.conjugated());m_world.translate(-m_translation);}return m_world;}

Daneben bietet die Kameraklasse noch 3 interessante Abfragefunktionen, welche die Koordinatenrichtungen des lokalen Kamera-Koordinatensystems im Weltenkoordinatensystem zurückliefern:

// negative Kamera-z-AchseQVector3D forward() const {const QVector3D LocalForward(0.0f, 0.0f, -1.0f);return m_rotation.rotatedVector(LocalForward);}// Kamera-y-AchseQVector3D up() const {const QVector3D LocalUp(0.0f, 1.0f, 0.0f);return m_rotation.rotatedVector(LocalUp);}// Kamera-x-AchseQVector3D right() const {const QVector3D LocalRight(1.0f, 0.0f, 0.0f);return m_rotation.rotatedVector(LocalRight);}

Die eigentliche Arbeit macht hier die Klasse QQuaternion, welche man dankenswerterweise nicht selbst implementieren muss.

5.7.1. Effizientes Zeichnen großer Geometrien

Es gibt eine wesentliche Grundregel in OpenGL:

Ein Beispiel: wenn man 2 Würfel zeichen möchte, hat man folgende Möglichkeiten:

Die oben angegebene Anzahl der Vertexes gilt natürlich nur für einfarbige Würfel. Sollen die Seitenflächen unterschiedlich gefärbt sein, braucht man natürlich für jede Seite 4 Vertices, also bspw. bei GL_TRIANGLES brauch man für die 2 Würfel 2*6*4 Vertices.

Wenn man Objekte mit gemischten Flächenprimitiven hat (also z.B. Dreiecke und Rechtecke, oder Polygone), dann kann man entweder nach Flächentyp zusammenfassen und je Flächentyp ein glDrawXXX Aufruf ausführen, oder eben alles als Dreiecke behandeln und nur einen Zeichenaufruf verwenden. Kann man mal durch Profiling ausprobieren, was dann schneller ist. Der Speicherverbrauch spielt auch eine Rolle, da der Datentransfer zwischen CPU und GPU immer auch an der Geschwindigkeit der Speicheranbindung hängt.

Die Gruppierung von Zeichenelementen erfolgt im Prinzip nach folgenden Kriterien:

Das Ganze hängt also stark von der Anwendung ab. Im Tutorial 05 gibt es zwei Arten von Objekten:

5.7.2. Verwaltung von Zeichenobjekten

Eine Möglichkeit, die für das Zeichnen derart gruppierter Daten benötigten Objekte, d.h. VertexArrayObject (VAO), VertexBufferObject (VBO) und ElementBufferObject (EBO), zu verwalten, ist eigene Datenhalteklassen zu verwenden. Diese sehen allgemein so aus:

class DrawObject {public:DrawObject(); // create native OpenGL objects void create(QOpenGLShaderProgram * shaderProgramm); // release native OpenGL objectsvoid destroy(); // actual render objectsvoid render(); // Data members to store state .... QOpenGLVertexArrayObjectm_vao;QOpenGLBufferm_vbo; // Vertex bufferQOpenGLBufferm_ebo; // Element/index buffer// other buffer objects....};

Die drei wichtigen Lebenszyklusphasen der Objekte sind durch die Funktionen create(), destroy() und render() abgebildet.

Am Besten wird das Datenmanagement in einer Beispielimplementierung sichtbar.

5.7.3. Zeichenobjekt #1: Gitterraster in X-Z Ebene

Beginnen wir mit einem einfachen Beispiel: Ein Gitterraster soll auf dem Bildschirm gezeichnet werden, sozusagen als "Boden". Es werden also Linien in der X-Z-Ebene (y=0) gezeichnet, wofür der Elementtyp GL_LINES zum Zeichnen verwendet wird.

Für jede Linie sind Start- und Endkoordinaten anzugeben, wobei die y-Koordinate eingespart werden kann.

Wir stellen also den Vertexpuffer mit folgendem Schema zusammen:

x1sz1sx1ez1ex2sz2sx2ez2e... also jeweils x und z Koordinatentuple für je Start- (s) und Endpunkt (e) einer Linie nacheinander.

Diese Geometrieinformation wird in der Klasse GridObject zusammengestellt:

class GridObject {public:void create(QOpenGLShaderProgram * shaderProgramm);void destroy();void render();unsigned intm_bufferSize;QOpenGLVertexArrayObjectm_vao;QOpenGLBufferm_vbo;};

Die Implementierung der create() Funktion ist das eigentlich Interessante:

void GridObject::create(QOpenGLShaderProgram * shaderProgramm) {const unsigned int N = 100; // number of lines to draw in x and z direction// width is in "space units", whatever that means for you (meters, km, nanometers...)float width = 500;// grid is centered around origin, and expands to width/2 in -x, +x, -z and +z direction// create a temporary buffer that will contain the x-z coordinates of all grid linesstd::vector<float>gridVertexBufferData;// we have 2*N lines, each line requires two vertexes, with two floats (x and z coordinates) each.m_bufferSize = 2*N*2;gridVertexBufferData.resize(m_bufferSize);float * gridVertexBufferPtr = gridVertexBufferData.data();// compute grid lines with z = constfloat x1 = -width*0.5;float x2 = width*0.5;for (unsigned int i=0; i<N; ++i, gridVertexBufferPtr += 4) {float z = width/(N-1)*i-width*0.5;gridVertexBufferPtr[0] = x1;gridVertexBufferPtr[1] = z;gridVertexBufferPtr[2] = x2;gridVertexBufferPtr[3] = z;}// compute grid lines with x = constfloat z1 = -width*0.5;float z2 = width*0.5;for (unsigned int i=0; i<N; ++i, gridVertexBufferPtr += 4) {float x = width/(N-1)*i-width*0.5;gridVertexBufferPtr[0] = x;gridVertexBufferPtr[1] = z1;gridVertexBufferPtr[2] = x;gridVertexBufferPtr[3] = z2;}

Im ersten Teil wird ein linearer Speicherbereich (bereitgestellt in einem std::vector) mit den Liniendaten gefüllt. Das Raster besteht aus Linien in X und Z Richtung (2), jeweils N Linien, und jede Linie hat einen Start- und einen Endpunkt (2) und jeder Punkt besteht aus 2 Koordinaten. Dies macht 2*N*2*2 floats (=NVertices).

Im zweiten Teil der Funktion werden dann wie gehabt die OpenGL-Pufferobjekte erstellt:

// Create Vertex Array Objectm_vao.create();// create Vertex Array Objectm_vao.bind();// and bind it// Create Vertex Buffer Objectm_vbo.create();m_vbo.bind();m_vbo.setUsagePattern(QOpenGLBuffer::StaticDraw);int vertexMemSize = m_bufferSize*sizeof(float);m_vbo.allocate(gridVertexBufferData.data(), vertexMemSize);// layout(location = 0) = vec2 positionshaderProgramm->enableAttributeArray(0); // array with index/id 0shaderProgramm->setAttributeBuffer(0, GL_FLOAT, 0 /* position/vertex offset */, 2 /* two floats per position = vec2 */, 0 /* vertex after vertex, no interleaving */);m_vao.release();m_vbo.release();}

Die Aufrufe von shaderProgramm->enableAttributeArray und shaderProgramm->setAttributeBuffer definieren, wie der Vertexshader auf diesen Speicherbereich zugreifen soll. Deshalb muss die Funktion create() auch das dazugehörige Shaderprogramm als Funktionsargument erhalten.

Nachdem nun die Puffer erstellt und konfiguriert wurden, ist der Rest der Klassenimplementierung recht übersichtlich:

void GridObject::destroy() {m_vao.destroy();m_vbo.destroy();}void GridObject::render() {m_vao.bind();// draw the grid lines, m_bufferSize = number of floats in bufferglDrawArrays(GL_LINES, 0, m_bufferSize);m_vao.release();}

Die Funktion destroy() ist sicher selbsterklärend. Und die Render-Funktion ebenso.

Die Funktion render() wird direkt aus SceneView::paintGL() aufgerufen. Hier ist der entsprechende Abschnitt aus der Funktion:

void SceneView::paintGL() { ...// set the background color = clear colorQVector3D backColor(0.1f, 0.15f, 0.3f);glClearColor(0.1f, 0.15f, 0.3f, 1.0f);QVector3D gridColor(0.5f, 0.5f, 0.7f); ...// *** render grid ***SHADER(1)->bind();SHADER(1)->setUniformValue(m_shaderPrograms[1].m_uniformIDs[0], m_worldToView);SHADER(1)->setUniformValue(m_shaderPrograms[1].m_uniformIDs[1], gridColor);SHADER(1)->setUniformValue(m_shaderPrograms[1].m_uniformIDs[2], backColor);m_gridObject.render(); // render the gridSHADER(1)->release(); ...

Hier sieht man auch, wie die Variablen an die Shaderprogramme übergeben werden. In Abschnitt "Shaderprogramme" oben wurde ja gezeigt, wie die IDs der uniform Variablen ermittelt werden. Nun müssen diese Variablen vor jeder Verwendung des Shaderprogramms gesetzt werden. Dies erfolgt direkt vor dem Aufruf der GridObject::render() Funktion.

Das Ergebnis dieses Zeichnens (mit uniformer Gitterfarbe) ist zunächst ganz nett:

Aber schöne wäre es, wenn das Gitter mit zunehmender Tiefe verblasst.

#version 330// GLSL version 3.3// vertex shaderlayout(location = 0) in vec2 position; // input: attribute with index '0' // with 2 floats (x, z coords) per vertexout vec4 fragColor; // output: computed vertex color for shaderconst float FARPLANE = 50; // thresholdfloat fragDepth; // normalized depth valueuniform mat4 worldToView; // parameter: the view transformation matrixuniform vec3 gridColor; // parameter: grid color as rgb tripleuniform vec3 backColor; // parameter: background color as rgb triplevoid main() { gl_Position = worldToView * vec4(position.x, 0.0, position.y, 1.0); fragDepth = max(0, min(1, gl_Position.z / FARPLANE)); fragColor = vec4( mix(gridColor, backColor, fragDepth), 1.0);}

#version 330// GLSL version 3.3// vertex shaderlayout(location = 0) in vec2 position; // input: attribute with index '0' // with 2 floats (x, z coords) per vertexuniform mat4 worldToView; // parameter: world to view transformation matrixvoid main() { gl_Position = worldToView * vec4(position.x, 0.0, position.y, 1.0);}

#version 330out vec4 fColor;uniform vec3 gridColor; // parameter: grid color as rgb tripleuniform vec3 backColor; // parameter: background color as rgb tripleconst float FARPLANE = 150; // thresholdvoid main() { float distanceFromCamera = (gl_FragCoord.z / gl_FragCoord.w) / FARPLANE; distanceFromCamera = max(0, min(1, distanceFromCamera)); // clip to valid value range fColor = vec4( mix(gridColor, backColor, distanceFromCamera), 1.0 );}

5.7.4. Zeichenobjekt #2: Viele viele Boxen

Um die Performance der Grafikkarte (und der Anwendung) zu testen, kann man sehr viele Boxen modellieren und dann mittels eines einzigen glDrawElements()-Aufrufs zeichnen lassen. Bei modernen Grafikkarten sollten locker Millionen von Boxen flüssig gezeichnet werden können.

Die Aufgabe besteht nun darin, die Vertexdaten aller Boxen und die dazugehörigen Elementindexe in die zwei Puffer (VBO und EBO) zu stecken, und den Quelltext auch noch einigermaßen verstehen zu können.

Zunächst wird wie beim Gitter ein Boxen-Zeichenobjekt erstellt:

class BoxObject {public:BoxObject(); void create(QOpenGLShaderProgram * shaderProgramm);void destroy();void render();std::vector<BoxMesh>m_boxes;std::vector<Vertex>m_vertexBufferData;std::vector<GLuint>m_elementBufferData; QOpenGLVertexArrayObjectm_vao;QOpenGLBufferm_vbo;QOpenGLBufferm_ebo;};

Sieht erstmal fast genauso aus wie bei der Klasse GridObject.

Vielleicht noch ein Hinweis zu den Puffern. Neben OpenGL-Pufferobjekten m_vbo und m_ebo sind die ursprünglichen Datenpuffer m_vertexBufferData und m_elementBufferData dauerhaft als Membervariablen vorhanden. Dies ermöglicht eine nachträgliche Aktualisierung eines Teils der Daten (z.B. Farben einer einzelnen Box oder einer Seite), ohne dass neu Speicher reserviert werden muss und die Puffer erneut aufgebaut werden.

Die eigentliche Geometrie, d.h. Größe und Position der Boxen wird durch die BoxMesh-Objekte bereitgestellt, welche im Vektor m_boxes vorgehalten werden.

Die Implementierung der 3 Funktionen ist dann auch recht ähnlich wie beim GridObject.

void BoxObject::destroy() {m_vao.destroy();m_vbo.destroy();m_ebo.destroy();}void BoxObject::render() {m_vao.bind();glDrawElements(GL_TRIANGLES, m_elementBufferData.size(), GL_UNSIGNED_INT, nullptr);m_vao.release();}

Die Funktionen destroy() und render() sind selbsterklärend (wie schon beim GridObject. Zur Vollständigkeit sei nocheinmal der Aufruf der Zeichenfunktion gezeigt:

void SceneView::paintGL() { ...// *** render boxesSHADER(0)->bind();SHADER(0)->setUniformValue(m_shaderPrograms[0].m_uniformIDs[0], m_worldToView);m_boxObject.render(); // render the boxesSHADER(0)->release(); ...

void BoxObject::create(QOpenGLShaderProgram * shaderProgramm) {// create and bind Vertex Array Objectm_vao.create();m_vao.bind();// create and bind vertex bufferm_vbo.create();m_vbo.bind();m_vbo.setUsagePattern(QOpenGLBuffer::StaticDraw);int vertexMemSize = m_vertexBufferData.size()*sizeof(Vertex);m_vbo.allocate(m_vertexBufferData.data(), vertexMemSize); // create and bind element bufferm_ebo.create();m_ebo.bind();m_ebo.setUsagePattern(QOpenGLBuffer::StaticDraw);int elementMemSize = m_elementBufferData.size()*sizeof(GLuint);m_ebo.allocate(m_elementBufferData.data(), elementMemSize); // set shader attributes// index 0 = positionshaderProgramm->enableAttributeArray(0); // array with index/id 0shaderProgramm->setAttributeBuffer(0, GL_FLOAT, 0, 3, sizeof(Vertex));// index 1 = colorshaderProgramm->enableAttributeArray(1); // array with index/id 1shaderProgramm->setAttributeBuffer(1, GL_FLOAT, offsetof(Vertex, r), 3, sizeof(Vertex));m_vao.release();m_vbo.release();m_ebo.release();}

struct Vertex {Vertex() {}Vertex(const QVector3D & coords, const QColor & col) :x(float(coords.x())),y(float(coords.y())),z(float(coords.z())),r(float(col.redF())),g(float(col.greenF())),b(float(col.blueF())){}float x,y,z;float r,g,b;};

BoxObject::BoxObject() :m_vbo(QOpenGLBuffer::VertexBuffer), // actually the default, so default constructor would have been enoughm_ebo(QOpenGLBuffer::IndexBuffer) // make this an Index Buffer{// create center boxBoxMesh b(4,2,3);b.setFaceColors({Qt::blue, Qt::red, Qt::yellow, Qt::green, Qt::magenta, Qt::darkCyan});Transform3D trans;trans.setTranslation(0,1,0);b.transform(trans.toMatrix());m_boxes.push_back( b);const int BoxGenCount = 10000;const int GridDim = 50; // must be an int, or use cast below// initialize grid (block count)int boxPerCells[GridDim][GridDim];for (unsigned int i=0; i<GridDim; ++i)for (unsigned int j=0; j<GridDim; ++j)boxPerCells[i][j] = 0;for (unsigned int i=0; i<BoxGenCount; ++i) {// create other boxes in randomize grid, x and z dimensions fixed, height varies discretely// x and z translation in a grid that has 500 units width/depths with 5 m grid line spacingint xGrid = qrand()*double(GridDim)/RAND_MAX;int zGrid = qrand()*double(GridDim)/RAND_MAX;int boxCount = boxPerCells[xGrid][zGrid]++;float boxHeight = 4.5;BoxMesh b(4,boxHeight,3);b.setFaceColors({Qt::blue, Qt::red, Qt::yellow, Qt::green, Qt::magenta, Qt::darkCyan});trans.setTranslation((-GridDim/2+xGrid)*5, boxCount*5 + 0.5*boxHeight, (-GridDim/2 + zGrid)*5);b.transform(trans.toMatrix());m_boxes.push_back(b);}unsigned int NBoxes = m_boxes.size();// resize storage arraysm_vertexBufferData.resize(NBoxes*BoxMesh::VertexCount);m_elementBufferData.resize(NBoxes*BoxMesh::IndexCount);// update the buffersVertex * vertexBuffer = m_vertexBufferData.data();unsigned int vertexCount = 0;GLuint * elementBuffer = m_elementBufferData.data();for (const BoxMesh & b : m_boxes)b.copy2Buffer(vertexBuffer, elementBuffer, vertexCount);}

Vertex * vertexBuffer = m_vertexBufferData.data();unsigned int vertexCount = 0;GLuint * elementBuffer = m_elementBufferData.data();for (const BoxMesh & b : m_boxes)b.copy2Buffer(vertexBuffer, elementBuffer, vertexCount);

BoxMesh::BoxMesh(float width, float height, float depth, QColor boxColor) {m_vertices.push_back(QVector3D(-0.5f*width, -0.5f*height, 0.5f*depth)); // a = 0m_vertices.push_back(QVector3D( 0.5f*width, -0.5f*height, 0.5f*depth)); // b = 1m_vertices.push_back(QVector3D( 0.5f*width, 0.5f*height, 0.5f*depth)); // c = 2m_vertices.push_back(QVector3D(-0.5f*width, 0.5f*height, 0.5f*depth)); // d = 3m_vertices.push_back(QVector3D(-0.5f*width, -0.5f*height, -0.5f*depth)); // e = 4m_vertices.push_back(QVector3D( 0.5f*width, -0.5f*height, -0.5f*depth)); // f = 5m_vertices.push_back(QVector3D( 0.5f*width, 0.5f*height, -0.5f*depth)); // g = 6m_vertices.push_back(QVector3D(-0.5f*width, 0.5f*height, -0.5f*depth)); // h = 7setColor(boxColor);}

void BoxMesh::transform(const QMatrix4x4 & transform) {for (QVector3D & v : m_vertices)v = transform*v;}

void BoxMesh::copy2Buffer(Vertex *& vertexBuffer, GLuint *& elementBuffer, unsigned int & elementStartIndex) const {std::vector<QColor> cols;Q_ASSERT(!m_colors.empty());// three ways to store vertex colorsif (m_colors.size() == 1) {cols = std::vector<QColor>(6, m_colors[0]);}else {Q_ASSERT(m_colors.size() == 6);cols = m_colors;}...

void BoxMesh::copy2Buffer(Vertex *& vertexBuffer, GLuint *& elementBuffer, unsigned int & elementStartIndex) const {...// front plane: a, b, c, d, vertexes (0, 1, 2, 3)copyPlane2Buffer(vertexBuffer, elementBuffer, elementStartIndex,Vertex(m_vertices[0], cols[0]),Vertex(m_vertices[1], cols[0]),Vertex(m_vertices[2], cols[0]),Vertex(m_vertices[3], cols[0]));// right plane: b=1, f=5, g=6, c=2, vertexes// Mind: colors are numbered upcopyPlane2Buffer(vertexBuffer, elementBuffer, elementStartIndex,Vertex(m_vertices[1], cols[1]),Vertex(m_vertices[5], cols[1]),Vertex(m_vertices[6], cols[1]),Vertex(m_vertices[2], cols[1]));// back plane: g=5, e=4, h=7, g=6copyPlane2Buffer(vertexBuffer, elementBuffer, elementStartIndex,Vertex(m_vertices[5], cols[2]),Vertex(m_vertices[4], cols[2]),Vertex(m_vertices[7], cols[2]),Vertex(m_vertices[6], cols[2]));// left plane: 4,0,3,7copyPlane2Buffer(vertexBuffer, elementBuffer, elementStartIndex,Vertex(m_vertices[4], cols[3]),Vertex(m_vertices[0], cols[3]),Vertex(m_vertices[3], cols[3]),Vertex(m_vertices[7], cols[3]));// bottom plane: 4,5,1,0copyPlane2Buffer(vertexBuffer, elementBuffer, elementStartIndex,Vertex(m_vertices[4], cols[4]),Vertex(m_vertices[5], cols[4]),Vertex(m_vertices[1], cols[4]),Vertex(m_vertices[0], cols[4]));// top plane: 3,2,6,7copyPlane2Buffer(vertexBuffer, elementBuffer, elementStartIndex,Vertex(m_vertices[3], cols[5]),Vertex(m_vertices[2], cols[5]),Vertex(m_vertices[6], cols[5]),Vertex(m_vertices[7], cols[5]));}

void copyPlane2Buffer(Vertex * & vertexBuffer, GLuint * & elementBuffer, unsigned int & elementStartIndex, const Vertex & a, const Vertex & b, const Vertex & c, const Vertex & d){// first store the vertex data (a,b,c,d in counter-clockwise order)vertexBuffer[0] = a;vertexBuffer[1] = b;vertexBuffer[2] = c;vertexBuffer[3] = d; ...// advance vertexBuffervertexBuffer += 4;// we generate data for two triangles: a, b, d and b, c, delementBuffer[0] = elementStartIndex;elementBuffer[1] = elementStartIndex+1;elementBuffer[2] = elementStartIndex+3;elementBuffer[3] = elementStartIndex+1;elementBuffer[4] = elementStartIndex+2;elementBuffer[5] = elementStartIndex+3;// advance elementBufferelementBuffer += 6;// 4 vertices have been added, so increase start number for next planeelementStartIndex += 4;}