Ich habe auf 2 Panels je ein OpenGLControl gesetzt.

Ich habe festgestellt, das es für jedes Fenster ein eigener Shader braucht.
Auch die Zeilen mit glGenVertexArrays, glGenBuffers, glBindVertexArray, etc muss ich doppelt aufrufen.

Komischerweise verwende ich bei beiden Aufrufen in glGenVertexArrays und glGenBuffers die gleichen Variablen, dies müsste doch einen Konflikt geben oder ?

Die Ausgabe ist im Anhang. Beim 2. Bild habe ich den 2. Shader modifiziert.

_________________
OpenGL

Deine Probleme liegen in der Context erzeugung.
Wenn du Resourcen teilen willst, dann musst du auch den Context mit entsprechenden Parameter erzeugen.
http://www.opengl.org/wiki/OpenGL_Context
Ich rate allerdings von ab dies zu machen, da kommst du in deine eigene Private OpenGL Hölle mit unerklärlichen Render Bugs, Performance einbrüchen und FPS Spikes.

glMakeCurrent hat nix mit mehreren OpenGL Context zu tun, das geht nur sicher, dass die single Threaded geschriebene OpenGL API die Befehle an den Thread-Lokalen Context schickt und nicht an wen anderes(was zu Fehlern führen wird).

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

Projekte: https://github.com/tak2004

Wie wir dann z.B. ein Rückspiegel von einem Auto programmiert ?

_________________
OpenGL

Du kannst 2 getrennte Contexte haben, beide nutzen den gleichen Szene Graphen aber haben eigene OpenGL Objekte für den gleichen Node.
Das sieht am Anfang ungewohnt aus aber eigentlich muss man für sein Scenegraph nur einbauen, dass man mehrere OpenGL Objekt ID's, statt eine zu hinterlegen und diese in Korrelation mit den Context zu bringen.
Ach und du hast dann 2 Kameras, je für eine View.

Wenn man z.B. auf Monitor Wände rendert, dann hat man mehrere PC's, ein Master mit dem Scenegraph und jeder Slave hat dann sein eigenen Render Context und interpretiert den SceneGraph aus der Sicht seines Kamera ausschnitts.
Also es gibt eine Kamera aber mit viewport wird dann jeden Slave ein Teil dieser zugewiesen.

Wenn man ein System hat, welches z.B. 3 Monitore ansprichts dann kann man folgende 2 Wege gehen.

Man benutze ein shared Context und muss darauf achten, dass sämtliche OpenGL Befehle thread safe verarbeitet werden, also mit Mutex auf ein Imaginäres Render Device, damit jede Gameloop, von jeden Fenster, nicht auf den OpenGL Context zugreift, wenn der andere das auch tut. Es gibt ein Mutex, der in der Main erzeugt und an beide Fenster übergeben wird, nun kann jedes Fenster für sich selbst sauber rendern und arbeiten, wenn man den Mutex Locked. Allerdings muss man auch die Resourcen ausserhalb der Fenster Logik handhaben, sonnst werden die Resourcen nicht geshared. Den Mutex braucht man, weil OpenGL kein Multithreaded Support hat.

Wie vorige Variante, allerdings kein shared Context und die benötigten Ressourcen werden innerhalb des Fensters erzeugt und verwaltet. Das hab ich z.B. hier gemacht.
Das benötigt wesentlich mehr VRAM aber ist wesentlich einfacher zu programmieren und zu debuggen.

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

Projekte: https://github.com/tak2004

Render-to-Texture, allein schon deshalb weil Rück- und Seitenspiegel im Auto eher selten rechteckig sind und gerne auch mit einer niedrigeren Frequenz aktualisiert werden. Also einfach z.B. ein Framebufferobjekt in dass die rückwärtige Szene dann gerendert wird. Das wird dann als Texture an den Spiegel gebunden und in der finalen Szene gerendert.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Wen ich es richtig verstanden habe, werden mehrere OpenGL-Fenster in der Praxis nie verwendet.

_________________
OpenGL

Naja, eigentlich nicht.
Sie werden halt dazu verwendet wozu sie gedacht sind: Mehrere unabhängige Grafikcontrols. Die sind schlicht nicht für Effekte gedacht sondern für mehrere Fenster. Ein CAD Programm mit mehrere Views in eigenen Fenstern zum Beispiel oder so. Der Context-Wechsel ist übrigens angeblich zum Teil sogar so leistungsfressend, das es alleine deshalb schwer möglich ist, flüssige Bilder zu rendern.

Ich würde in der Regel ein Thread für einen Context verwenden und das nie ändern.

Für einen Rückspiegel der spiegelt wäre auch der Stencil Buffer eine Option. Der kleine Vorteil davon ist die Pixel exakte Darstellung ohne richtig zu bemessende verzerrende Texturen. Dafür kann man zwar kaum Verzerrungen realisieren, Rückspiegel sollten das jedoch eigentlich nicht notwendig haben.

ja ich kenns eigentlich nur von Programmen die sowas wie MDI machen wollen. Aber da koennte man eventuell auch besser mit dem Viewport und Scissor rumspielen. Nehe haben dazu nen schoenes Tutorial.

_________________
Meine Homepage

Blender und co benutzen ein OpenGL/DX11 Context für je ein Fenster und innerhalb des Fensters wird dann mit Viewport und Scissor gearbeitet, um verschiedene Ansichten zu realisieren.

Für Materials würde ich auf FBO's setzen, weil man die nicht jeden Frame neu zeichnen muss und sich dann eine Menge Arbeit spart.

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

Projekte: https://github.com/tak2004

Achtung! VBO kann man sharen, VAO aber nicht. Eine mögliche Abhilfe: nur ein Kontext für mehrere OpenGL-Fenster.