Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 15:22

Foren-Übersicht » Programmierung » OpenGL
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 28 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
BeitragVerfasst: Do Aug 15, 2013 17:16 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Hallo,
ich komme hier seit Stunden nicht weiter mit einem Fehler, bei dem ich mir nicht 100%ig sicher bin, ob er an meinem Code liegt. Folgendes tut mein Programm:
- OpenGL 3.3-Core Kontext erstellen
- glewInit() aufrufen
- VertexShader und FragmentShader laden und kompilieren
- die beiden zu einem Programm Linken
- glUseProgram()
- Vertex Array Object aufsetzen und binden
- Uniform(s) setzen
- VBO erstellen, füllen und binden
- das selbe mit einem IBO
- Rendern mit glDrawElements(GL_TRIANGLES, 36, GL_UNSIGNED_SHORT, 0);

Und an dieser Stelle crasht das Programm (Zugriffsverletzung, Lesen von Adresse 0x00000000) in der Library ig7icd32.dll, welche zum Grafiktreiber meiner integrierten Intel-Grafik gehört. Dank Optimus kann ich aber auch auf die Nvidia-Grafik umschalten, dann passiert das selbe in grün (nvoglv32.dll). Ich hatte beim Aufruf von glDrawElements schon einmal einen Crash in diesen DLLs. Dank dieses Foren-Posts konnte das aber behoben werden. Zusammenfassung: Man muss erst glBindVertexArray() und dann glBindBuffer() aufrufen, nicht umgekehrt. Ob dies von der OpenGL-Spezifikation gefordert wird, oder ob es ein Bug im (Notebook-)Treiber ist, weiß ich nicht. Jedenfalls kommt es nun wieder zur Access Violation, obwohl ich die "richtige" Reihenfolge einhalte.

Es ist bekannt, dass glew (ich benutze Version 1.9.0) ein Problem hat mit Core-Contexts > 3.0. Deswegen setze ich auch glewExperimental auf true. Dennoch meldet gDEBugger einen deprecated function call kurz nach dem Programmstart (glGetString()). Ob es damit zu tun hat? Wenn ja: Wie kann ich das fixen?

Ansonsten meldet gDEBugger keine Fehler. Der Shader-Code wird korrekt übergeben. Auch den Buffers (VBO, IBO) bescheinigt gDEBugger den korrekten Inhalt. (Es soll nur ein einfacher Würfel mit Kantenlänge 1.0 gerendert werden, daher ist es leicht zu kontrollieren.) Die Größe der Buffer habe ich auch mehrfach überprüft - es kommt hier nicht zu einem Überlauf. Auch hat der Function-Pointer zu glDrawElements nicht den Wert NULL. Interessantes Detail: Wenn ich mit meiner C++ IDE debugge, gibt es die Zugriffsverletzung direkt beim ersten Aufruf von glDrawElements. Setze ich die Breakpoints dagegen mit gDEBugger, kann die Funktion genau 2 mal ohne Access Violation aufgerufen werden. Beim dritten Mal kracht es dann.

Vielen Dank an dieser Stelle fürs durchlesen. Und wenn ihr mir jetzt noch antworten könntet, wäre ich natürlich noch dankbarer! :)

PS: Auf Wunsch poste ich natürlich gerne auch (Shader-)Code, ich wollte meinen ersten Post nur nicht überfluten.

Edit: Ein Update auf die aktuelle Version 1.10.0 von GLEW, ändert nichts (auch glGetString wird noch aufgerufen).

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Zuletzt geändert von glAwesome am Fr Aug 16, 2013 11:57, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Aug 16, 2013 10:06 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Kannst du evtl. mal eine kleine Beispielanwendung mit dem Code hochladen? Und wenn nicht, hast du es schonmal auf einer Desktop-GPU geteset? Von deiner Beschreibung her klingt das alles erstmal OK, und wenn der glDebugger auch keine Fehler anzeigt wirds schwierig da den Grund zu finden.

Zum depcrecated call : Das dürfte nicht tragisch sein. glew nutzt hier noch eine alte Methode zum Ermitteln der Extensionstrings, die man ab 3.0 so nicht mehr nutzen soll (haben wir vor kurzem für unseren Header auch angepasst). Das dürfte also eigentlich nicht zu einer Zugriffsverletzung führen.

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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Aug 16, 2013 11:55 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
An glew liegt es offenbar tatsächlich nicht. Ich habe mal testweise auf gl3w umgestellt, was am Problem nichts ändert. Einen Desktop-Rechner habe ich leider gerade nicht zur Verfügung. Den gesamten Code posten kann ich jetzt schlecht (kleinere Ausschnitte natürlich schon) - ich habe praktisch alles (Shader, VBOs, Mesh-Teile, Uniforms, VAOs usw.) in Klassen gekapselt, die wiederum in verschiedenen Units deklariert / definiert sind. Da kämen tausende Zeilen Code zusammen.

Binaries lade ich gerne Mal hoch, damit ihr testen könnt, ob es ebenfalls zur AV kommt (war leider zu groß für den Anhang):
edit: Link entfernt, da Problem gelöst.

Ich habe versucht, alles statisch zu linken. Falls doch irgendeine DLL fehlt, bitte melden. Wichtig: Vor dem Programmstart muss in der ini-Datei als ShaderPath der Pfad eingetragen werden, in dem die glsl-Datei liegt und zwar mit abschließendem Backslash (\). Nach dem Programmstart einfach auf "Laden" klicken und die ms3d-Datei auswählen. Dann sollte die Exception kommen.

Vielen Dank für die Hilfe.

Edit: SHA-1, Namen und Größe der Datei hinzugefügt.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Zuletzt geändert von glAwesome am Mo Aug 26, 2013 12:48, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Aug 16, 2013 18:46 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich hab zufälligerweise seit letzter Woche das gleiche Problem mit meinem Projekt.
Mein Programm nutzt auch OpenGL 3 Context, erstelle VBO's und nutzte auch normale VA und es crasht jedes mal bei glDrawElements.
glDebugger findet keine Fehler, Warnungen, Memory Leaks.
Die App schmiert in glDrawElements, beim löschen eines pointers, welcher datenmüll aus einem 0 Pointer ist.
Aktuell versuche ich ein Weg zu finden, um raus zu bekommen woran es wirklich liegt.

Es ist extrem selten, dass die Treiber Bugs solchen Ausmaßes enthalten und daher such ich eher für Threading, Memory managment Fehler, da die auch Einfluss solchen Ausmaßes haben können.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Aug 16, 2013 21:08 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich habe vor einiger Zeit ein Demoprogramm für OpenGL3 geschrieben, welches das OpenGL-Dreieck zeichnet, habe aber glDrawArrays benutzt. Jetzt habt ihr mich neugierig gemacht, und das Demo auf glDrawElements zu ändern ist ja nicht wirklich viel Arbeit.

Tja: hier in Ubuntu mit FreePascal ist es dasselbe: während glDrawArrays anstandslos zeichnet, crasht glDrawElements mit einem SigSegV.

Aber ich habe vor einiger Zeit beim Herum-Googeln Folgendes entdeckt: http://stackoverflow.com/questions/8973690/vao-and-element-array-buffer-state

Dort behauptet jemand, dass das VAO den Indexbuffer ignoriert. Also habe ich es ausprobiert und zusätzlich den IBO neuerlich gebunden:

Code:
  1. // Activate Shape
  2. glBindVertexArray(VAOID);
  3. glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,IBOID);


Und siehe da, es funktioniert, aber ist eigentlich gegen die Specs.

Meine Karte: Nvidia GeForce GTX 550 Ti
Betriebssystem: Ubuntu 12.04, Nvidia Driver Version 304.88

Viele Grüße,
Traude


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Aug 16, 2013 23:28 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Danke für eure Posts, insbesondere der von Traude hat mich stutzig gemacht. Offenbar habe ich das, was hier (und im nachfolgenden Abschnitt zu VBOs) ganz offiziell steht, noch nicht vollständig verstanden (wovon ich bisher ausgegangen war). Da steht einerseits, dass der Buffer, aus dem die Vertexdaten gelesen werden, bereits im VAO festgelegt werden:
Zitat:
These functions [e.g. glVertexAttribPointer​] say that the attribute index index​ will get its attribute data from whatever buffer object is currently bound to GL_ARRAY_BUFFER​. It is vital to understand that this association is made when this function is called.
Andererseits wird ein Aufruf von glBindVertexArray​ nicht bewirken, dass das (*) zugehörige VBO gebunden wird:
Zitat:
Note: The GL_ARRAY_BUFFER​ binding is NOT part of the VAO's state!

Heißt das nun, es ist völlig egal, welches VBO beim Rendern gebunden ist, solange beim Setup des VAOs alles richtig gebunden war? In diesem Zusammenhang fände ich es übrigens unsinnig, falls der IndexBuffer zum VertexFormat gehören sollte (keine Ahnung, ob er das laut Spezifikation nun tut). Wie habt ihr das verstanden?

(*) Vermutlich ist es hier auch falsch, von "dem" VBO zu sprechen, da mehrere VBOs gleichzeitig als Quelle dienen können? Wobei es "schade" ist, dass nicht "das" aktuell gebundene VBO mit im VAO gespeichert wird, denn das hätte u.a. das Phänomen mit der Reihenfolge von glBindVertexArray und glBindBuffer erklärt.

So, nun muss ich erstmal Gedanken sortieren.
Gute Nacht!

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 17, 2013 08:53 
Offline
DGL Member
Benutzeravatar

Registriert: Di Sep 06, 2005 18:34
Beiträge: 362
Wohnort: Hamburg
Ich bin mir auch nicht sicher wann welcher State im VAO gespeichert wird. Der IBO state wird gespeichert sobald man das IBO bindet glaub ich. Deswegen ist es wichtig das IBO erst zu releasen wenn das VAO NICHT mehr gebunden ist.

Um auf Nummer sicher zu gehen verschiebe ich ALLE glBindBuffer(..., 0) Aufrufe immer HINTER den Aufruf von glBindVertexArray(0).
Mit einem VAO zu rendern, dass kein IBO hat ist ein fehler glaube ich und könnte evtl zu so etwas führen.

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 17, 2013 09:40 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Shaijan hat geschrieben:
Mit einem VAO zu rendern, dass kein IBO hat ist ein fehler glaube ich und könnte evtl zu so etwas führen.

In meinem Demoprogramm geht das, denn er zeichnet ganz normal, wenn ich glDrawArrays benutze:
Code:
  1.    glBindVertexArray(VAOID);
  2.    glDrawArrays(GL_TRIANGLES,FirstVertex,VertexCount);
  3.    glxSwapBuffers(XDisplay,DemoWindow.Identity);
  4.    glBindVertexArray(0);

Wenn ich glDrawElements benutze, muss ich den IBO beim Rendern zusätzlich binden und entbinden, obwohl ich bei der Initialisierung des VAO sowohl den VBO als auch den IBO gebunden habe:
Code:
  1.    glBindVertexArray(VAOID);
  2.    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,IBOID);
  3.    glDrawElements(GL_TRIANGLES,3,GL_UNSIGNED_INT,NIL);
  4.    glxSwapBuffers(XDisplay,DemoWindow.Identity);
  5.    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0);
  6.    glBindVertexArray(0);

Das VAO merkt sich in meinem Demoprogramm eindeutig zwar den VBO, aber nicht den IBO. Find ich ehrlich gesagt suboptimal. :evil:


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 17, 2013 12:37 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich hab nun schon AMD CodeAnalyst und Application Analyzer probiert und bin auf ein Problem gestoßen.

Der NV OpenGL Treiber ruft GetThreadTimes auf und das wohl mit 0 parametern.
Zitat:
StopCode="0x303"
NULL handle passed as parameter. A valid handle must be used
<avrf:parameter1>0 - Not used.</avrf:parameter1>
<avrf:parameter2>0 - Not used.</avrf:parameter2>
<avrf:parameter3>0 - Not used.</avrf:parameter3>
<avrf:parameter4>0 - Not used.</avrf:parameter4>


Der NV Treiber scheint aktuell sehr schlampig geschrieben zu sein, denn der macht ne menge Fehler.
Das Log sagt 6Fehler und 46Warnings und grob 90% sind vom NV Treiber.
So versucht der Treiber z.B. im Lokalen verzeichnis die aurora.dll zu laden, statt zu prüfen ob die dort überhaupt existiert(liegt im system) und geht mutwillig in nen Fehler. Dazu hab ich gelesen, dass einige nutzter deswegen recht lange Startupzeiten für ihre Anwendungen haben, weil das System-Log schreiben ein bisschen Zeit dauert.

Dann erzeugt der Treiber Resourcen und versucht auf Registry Keys zu zu greifen, wo er wohl keine Rechte drauf hat und dann z.B. kein Mutex erzeugen kann.

Mal gucken ob ich da was reparieren kann.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 17, 2013 12:46 
Offline
Compliance Officer
Benutzeravatar

Registriert: So Aug 08, 2010 08:37
Beiträge: 460
Programmiersprache: C / C++ / Lua
Vor den 3XX Treibern geht bei mir noch alles. Danach nicht mehr.

EDIT:

Du nutzt ein AMD Tool auf einer NVIDIA? das geht oO?

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 17, 2013 14:59 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
gDEBugger kann die Debug API von den einzelnen OpenGL Versionen nutzen und für weitere Infos, muss man PerfKit installieren und aktivieren, was bisher nie auf irgendeiner Kiste noch nutzbar war, weil es das System komplett ausgelastet hat und es hat nen mega memory leak.
Für AMD ist halt der ganze extra kram schon mit drin.

Bei CodeAnalyst ist es das gleiche, er kann die Basis sachen + CPU unabhängige sachen für Intel aber für Cache und DMA braucht man VTune und ich weiger mich so viel Geld für diese 2-3 Features aus zu geben.
Für AMD gilt hier wieder voller Extension support.

CodeXL hat dann noch OpenCL mit drin, was für beide Kartenhersteller gleiche Funktionalität bietet.

Da muss man einfach sagen, AMD hat NV und Intel mit ihrem Entwicklerfreundlichen Ruf mal gezeigt, dass man sich nicht auf alten Lobeeren ausruhen kann.
Microsoft wird da auch immer schlimmer. Mit VS2013 ist ein Memory, Thread und GPU profiler/debugger nur noch in der Ultimate + MSDN Version drin, die mal eben 13k€ kostet und das MSDN ABO Jährlich erneuert werden muss.

Ich fummeln nun schon über 1 Woche an dem Problem und finde es einfach nicht.
Mal sehen, wie lange es noch dauert, bis ich weiter an meinem Projekt Arbeiten kann :\

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 17, 2013 15:29 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Ich bin mir nicht mehr sicher, ob es noch allen in diesem Thread ums selbe Problem geht (bzw. ob das Problem bei allen die selbe Ursache hat). Mein Problem ist jetzt gelöst, es basierte offenbar auf einer falschen Vorstellung darüber, wie man VAOs anwendet. Hier die Reihenfolge, wie es bei mir funktioniert (sowohl mit Intel- als auch mit Nvidia-Grafik):

Init:
Code:
  1. // VBO erstellen:
  2. glGenBuffers(1, &VboID);
  3. glBindBuffer(GL_ARRAY_BUFFER, VboID);
  4. glBufferData(GL_ARRAY_BUFFER, vbo_size, NULL, usage);
  5. // VBO füllen...
  6. glMapBuffer(GL_ARRAY_BUFFER, access);
  7. glUnmapBuffer(GL_ARRAY_BUFFER);
  8.  
  9. // VAO erstellen, während der VBO noch gebunden ist:
  10. glGenVertexArrays(1, &VaoID);
  11. glBindVertexArray(VaoID);
  12. glEnableVertexAttribArray(...);
  13. glVertexAttribPointer(...);
  14.  
  15. // Hier kann beliebig oft glBindVertexArray(anderesVAO); aufgerufen werden
  16.  
  17. // IBO erstellen
  18. glGenBuffers(1, &IboID);
  19. glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, IboID);
  20. glBufferData(GL_ELEMENT_ARRAY_BUFFER, ibo_size, NULL, usage);
  21. glMapBuffer(GL_ELEMENT_ARRAY_BUFFER, access);
  22. // IBO füllen...
  23. glUnmapBuffer(GL_ELEMENT_ARRAY_BUFFER);

Rendern:
Code:
  1. glBindVertexArray(VaoID);
  2. glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, IboID);
  3. glDrawElements(...);

Man beachte, dass das VBO beim Rendern NICHT gebunden sein muss. Bevor hier weiter Fehler im Treiber gesucht werden, solltet ihr vielleicht checken, ob ihr auch so vorgeht. Wenn sich herausstellen sollte, dass dies der korrekte Weg ist, VAOs zu benutzen, werde ich nächste Woche vielleicht ein Tutorial zu Vertex Array Objects schreiben und ins Wiki stellen (siehe Diskussion hier).

Ich freue mich auf euer Feedback.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Zuletzt geändert von glAwesome am So Nov 17, 2013 20:24, insgesamt 2-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 17, 2013 16:55 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich hab mir nochmal angeguckt, wie ich VBO initialisiere und deinitialisiere und render und siehe da da waren 2 Fehler.
Hab den IndexBuffer nicht entbunden und GL_TEXTURE_2D hab ich nicht an und aus gemacht.
Es scheint nun erstmal zu funktionieren, ich hab ja schon in den Callstacks vom Kernel und Nvidia Treiber gesucht.
Ich hatte erwartet, dass glDEBugger und der Treiber solche Fehler erkennt :\

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 17, 2013 17:02 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Bei mir läuft es zwar auch immer noch, aber ich merke gerade, dass gDEBugger die Aufrufe von glDrawElements nicht mehr mitbekommt. Also wenn ich da einen Haltepunkt setze, wird dieser nie erreicht, obwohl die Funktion definitv aufgerufen wird. Auch wenn ich von einem OpenGL-Call zu nächsten steppe, lässt er die glDrawElements-Calls aus. Merkwürdig...

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Aug 17, 2013 18:25 
Offline
DGL Member

Registriert: Sa Apr 14, 2012 14:28
Beiträge: 52
Programmiersprache: c++
hmm... ich habe ja gestern erst ein Verständnisfred zu dem Thema VAO und VBO aufgemacht und nachdem ich das hier gelesen habe mußte ich doch etwas herumexperimentieren.

Bisher war mein Verständnis so, dass das VAO nur eine Lesevorschrift für das jeweils aktuell gebundene VBO ist. (Lies Daten an Stelle XY in Format soundso). D.h. ich könnte 2 VBOs haben, mit gleicher Datenstruktur, die aber was anderes verkörpern. Um beide zu rendern kann ich dann mein vorher definiertes VOA für beide VBOs nutzen. Das hieße weiterhin, dass mein VAO eigentlich unabhängig ist von den VBOs. Diese Annahme wurde durch die Tatsache gestützt, dass das Binden eines VAOs nicht automatisch das VBO bindet.

Jetzt habe ich spaßeshalber einfach mal ausprobiert ein VAO vollständig separat von einem VBO zu initialisieren. Also erst VAO Speicher reservieren, Binden, glEnableVertexAttribArray aufrufen und zum Schluss glVertexAttribPointer setzen. Danach wird dann das VBO initialisiert. Funktioniert auch erstmal, nur beim Aufruf von glDrawArrays gibt's dann den illegalen Speicherzugriff, aber warum? Setze ich glEnableVertexAttribArray und glVertexAttribPointer hinter die Initialisierung des VBOs läuft alles glatt. Warum muss ich nun ein VBO gebunden haben um den AttribPointer zu setzen? Merkt sich das VAO etwa die Atttribs nur für jeweils ein VBO und ich muss für jedes weitere VBO die Attribs in einem VAO neu initialisierenoder was genau ist da der Hintergrund... ich bin mal wieder etwas verwirrt.

MfG Der Troll


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 28 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 19 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.121s | 18 Queries | GZIP : On ]