Hallo zusammen,

bei meinem aktuellen Programm nutze ich den Geometry-Shader zur Berechnung des Volumenschatten.

Leider wird der Geometry-Shader vor allem bei Laptops (aktuell Intel HD Chipsatz) nicht immer angezeigt.
Die OpenGl Version (4.0.0) und die Shading Version (4.0.0) sollten es eigentlich hergeben.
Eigenartig ist, dass weder beim kompilieren der shader, beim linken noch beim validieren (glValidateProgram)
ein Info-Log eingetragen wird?!

Auf einigen Seiten habe ich gelesen, dass zwecks Stromsparen die Shader deaktiviert werden.
Kann / muss man hierzu weitere OpenGl Register aktivieren?

Weiß vielleicht jemand wie man das am besten analysieren kann oder weiß wo man am besten nachschlägt?
Leider lande ich immer auf Seiten welche den Shader an sich erklären

Danke im vorraus für eure Infos

Christian

Woran sieht du, das der Geometrie-Shader nicht funktioniert ?
Ist die Darstellung fehlerhaft, oder kommt gar nichts ?

Geo-Shader stehen schon ab OpenGL 3.3 zur Verfügung.

Das wäre komisch.
Was passiert, wen du den Laptop ans Netzteil hängst ?

_________________
OpenGL

Hallo Mathias,

danke für deine Antwort.

Das der GS nicht läuft erkenne ich daran, dass das Schattenvolumen nicht gezeichnet wird.
Zum debuggen hab ich im FS dem Volumen eine Farbe zugewiesen, allerdings wurde nichts gezeichnet

Der Effekt ist mit oder ohne Netzteil derselbe. Leider mach das keinen Unterschied.

Glaub ich wende mich mal an den Intel-Support direkt. Allein das Thema, wann welche Shader deaktiviert werden müsste doch irgendow definiert sein

Gruß
Christian

Ich würde mal schauen, ob der Shader auch ohne Warnings auf der Hardware kompiliert wird, und dann ob Du etwas siehts, wenn Du im Fragmentshader, der an dem Geometryshader hängt was produzieren kannst mit einer simplen ausgaben wie vec4(1.).

Es kann aber an vielen andere Dingen liegen, z.B. das der Vertex irgendwo auf dem Weg 0 wird.
glGeterror hast Du schon gemacht? nach dem ausführen des Geometryshaderzeugs?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

Hallo Vinz,

beim kompilieren wie auch beim Ausführen wird kein Fehler eingetragen (weder als Fehler 'glGetError' wie auch im InfoLog).
Ich habe eben mit der ShaderVersion herumgespielt.
Wenn ich die Version auf 3.0 bzw. 3.2 (#130 bzw. #150) lege wird der Shader zwar ausgeführt aber nicht richtig.
Wahrscheinlich kommt der Treiber mit den BuildIn-Variablen nicht 100%ig zurecht.

Aber eigenartig ist der Unterschied zwischen PC (AMG) und Laptop (Intel HD).
Sobald ich mehr weiß, werde ich dies hier noch mal dranhängen.

Danke für eure Antworten
Christian

Den Shader habe ich als Anlage hinzugepackt ... falls es jemand interessiert

Hallo chrisfn, anbei ein paar Anmerkungen zu deinem Problem und dem, was weiter oben geschrieben wurde:

• Dass Geometry-Shader auf der selben GPU plötzlich nicht mehr funktionieren wegen Akkubetrieb, ist Humbug. So etwas gibt es nicht.
• Geometry-Shader gehen ab OpenGL 3.2 bzw. mit entsprechender Extension auch schon vorher. Du verwendest die Extension EXT_geometry_shader4. Gibt es einen Grund, warum du nicht die in OpenGL 3.2 bereits enthaltenen Geometry-Shader nimmst? Letztere erfahren nämlich bessere Treiberunterstützung.
• Wenn sich dein Programm je nach OpenGL-Version unterschiedlich verhält, wäre es interessant zu wissen, wie du deinen Kontext erstellst.
• Bekommst du eine Meldung im Info-Log, wenn du absichtlich einen Fehler im Shader einbaust? Wenn nicht, überprüfe/zeige uns deinen Code zum Abfragen des Logs.
• Solltest du Fehler oder Warnungen bekommen, wäre es sehr hilfreich, wenn du nicht den ganzen Shadercode in eine Zeile schreiben würdest. So kannst du den Fehler nämlich nicht einer bestimmten Zeile zuordnen. Am besten ist es, wenn du die Shader ordentlich formatiert in eine Textdatei schreibst und diese im Programm lädst.

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

Hallo glAwesome,

danke für deine Antwort. Vor allem das mit dem Hinweis auf die 'extension' bringt mich zum grübeln.

Ich kenne hierzu keine Unterschiede?! Um den GS zu aktivieren benötige ich doch den Eintrag.
Andere Versionen habe ich hierzu www.khronos.org/../GS_Examples und der verlinkten Spec.
nicht gefunden.
Alternativ finde ich unter Wiki Extensions nur die Extension 'GL NV geometry shader4'.
Meister Google sagt das er genausowenig dazu weiß wie ich

Im Header verwende ich folgenden Eintrag:


Bzgl. deinen Anmerkungen:
- In welchem Kontext: Meinst du wie ich die OpenGl-Register initialisiere?
Zwischen den OpenGl-Versionen ist vor allem die Verwendung der BuildIn-Variablen (gl_PositionIn, gl_NormalMatrix, gl_ModelViewProjectionMatrix,..) zu sehen.
Entweder beim kompilieren werden diese akzeptiert (kompilieren erfolgreich) oder eben nicht (error log beim komilieren).
Interessant ist hierbei, dass selbst bei der Version 3.3 die BuildIn-Matrizen nicht mehr akzeptiert werden :/

- Error bzw. Info Logs
Ich frage eigentlich immer alles ab um zu prüfen ob der Shader kompiliert wurde.
(CompileStatus -> glGetShaderiv, InfoLog -> glGetShaderInfoLog, LinkStatus -> glGetProgramiv und selbstverständlich den GlGetError)
Fehler zeigt er eig nur an, wenn code Fehler oder Probleme mit den BuildIn-Variablen bestehen.

- Alles in einer Zeile
Aktuell habe ich mit den üblichen Zeilenumbrüchen probleme beim kompilieren. Da ich mit C# programmiere könnte es viell. am C# string-Format liegen (16 Bit pro Zeichen).
Da der InfoLog aber immer recht genau ist hat mich das bisher nicht wirklich gestört

So wie es aussieht, muss ich mich mal mit den extensions und Versionen befassen. Dann könnte ich auch mal einen Shader-Beitrag veröffentlichen mit diesen Stolperfallen

Gruß
Christian

Hinter #version und #extension hast du ein \n dies frisst er anscheinend .
Somit sollte es beim restlichen Code auch gehen.

Wen du in der Einleitung liest, verhalten sich Grafikkarten recht unterschiedlich.
https://wiki.delphigl.com/index.php/Laz ... aten_laden

_________________
OpenGL

Hallo mathias,

waow... danke für den Hinweis auf das ausgiebige OpenGl 3.3 Tutorial.
Das werde ich die nächsten Tage mal durchgehen.

Ein Punkt hat mich jedoch sehr gewundert:


Ich war immer der Meinung, dass der installierte Treiber die OpenGl-Version bestimmt (außer speziellen Kommandos oder anderen Definitionen).
Das man diesen beim erzeugen des Kontextes beeinflussen kann war mir bisher nicht bewusst.
Da muss ich mal in den SourceCode von Tao schauen.

Nochmals 1000-Dank für die Hinweise

Christian

Das Tutorial ist noch in arbeit, aus diesem Grund gibt es auch noch keinen Link im Wiki. aber ich arbeite gegenwärtig daran.


Da gibt es leider rechte Unterschiede.

Mit meinem Intel Onboard 4000 konnte ich die Version unter Windows bei 0.0 belassen. Unter Linux musste zwingend 3.3 rein.
Bei NVidia hat es auch mit Linux mit 0.0 funktioniert.

Eines muss ich leider gestehen, das die Context-Erzeugung im Tutorial leider (noch) nicht perfekt ist.

Übrigens hat es im Tutorial ein Beispiel für einen Geometrieshader.

Die Sourcen sind (noch) hier: http://mathias1000.bplaced.net/Tutorial ... source.zip

_________________
OpenGL

Werd den shader nun überarbeiten und für die Version 3.3 ready machen.
Wollte hald nicht für jedes Objekt eine Transformationsmatrix per glUniform laden.

Werd versuchen alles im Speicher abzulegen. Die beste Lösung wäre anstatt glTranslate / glRotate gleich das VertexArray im Speicher zu verändern ... dann bräuchte auch die gl_ModelViewMatrix nimmer.

Würde das Ergebnis in die Shadersammlung aufnehmen. Denke bin nicht der einzige der darüber stolpert ... und würde gerne mal was zurückgeben

Das ist eigentlich nicht der Sinn von OpenGL, das man die Vertex-Daten modifizieren muss. Für dies sind Matrizen da.
Was mir noch auffällt, glTranslate/glRotate sind altes OpenGL und werden mit OpenGL 3.3 nicht mehr unterstützt.

Schau mal bei Matrizen und 3D nach, wie dies mit dem moderen OpenGL geht.
https://wiki.delphigl.com/index.php/Laz ... 3_Tutorial

_________________
OpenGL