Posts by 2#4u

    Naja, wenn man das nicht macht, bekommt man garantiert keinen Platz. Also die Unsicherheit hat man so oder so.
    Eines was man bedenken muss, sind Auswirkungen auf mögliche Stipendien. Studien inskribieren und dann abbrechen, hat vielleicht Konsequenzen. Kommt aber sicher auf das Stipendium an.

    Könnte man nicht einfach einen zB Chemie Bachelor inskribieren und sich dann (als Freifach) für die Informatik LVAs anmelden? Es geht ja schließlich nur darum Zugang zu bekommen und sich für VUs zu registrieren.

    Das was du tbo nennst ist laut deinem Code aber kein Transform-Feedback-Buffer, sondern ein weiteres VBO (GL_ARRAY_BUFFER). Somit hast du schon mal 2 VBOs, was gut ist, aber sonst stimmt halt nicht so viel mit dem Code. glBindTransformFeedback wird zum Beispiel gar nicht gemacht (ist auskommentiert) ?


    Warum es von allem 2 geben soll, ist weil man nicht in den selben Buffer reinschreibt aus den man rausliest UND zu jedem VBO gibt es hier genau ein TFB, da die TFB nur Mittel zum Zweck sind um überhaupt in VBOs reinschreiben zu können.

    Also, um es kurz zu machen: Ich denke du brauchst als Setup 2 VBOs und 2 Transform-Feedback-Buffer (TFB). Der erste TFB hängt mit dem ersten VBO zusammen und schreibt dort hinein. Der zweite TFB hängt mit dem zweiten VBO zusammen. Initial haben beide Buffer die selben Daten.


    Dann wird das erste VBO gebindet (glBindBuffer) und der zweite (!) TFB (glBindTransformFeedback) und der erste Rendercall (glBeginTransformFeedback) ausgeführt. Somit steht das Ergebnis im zweiten VBO. In der nächsten Iteration/Rekursion wird dann das zweite VBO gebindet und der erste TFB. Dazwischen wird nichts mit glGetBufferSubData gemacht, sonst ja, wird zwischen GPU und CPU kopiert.


    Beschrieben ist das unter anderem hier: http://ogldev.atspace.co.uk/www/tutorial28/tutorial28.html

    Ok. Auf meinem Laptop hab ich jetzt laut meinem fps Counter ca. 40fps?


    Ich seh keine 40 FPS in den Screenshots. Ich seh ~ 40 ms bzw. 6.5 ms. Das sind 25 FPS bzw 150 FPS.



    Also sollt ich am Abgaberechner > 60 fps haben (?)


    Ausprobieren. Anders kann man das nicht wissen.



    Der Zweite wichtige Punkt ist das viel Zeit in der ig75...dll verbracht wird. Das ist mein Graphiktreiber. Ich hab nur einen Laptop.
    Das ist ein Zeichen dafür das wird unsere Shader optimiern müssen?


    Ich vermute es, ja. Es wäre aber wichtig rauszufinden welcher Shader das ist.


    -------------


    Wie ich in der ersten Antwort schon geschrieben habe, könnt ihr versuchen eure glUniformLocation() Aufrufe nur einmal pro Shader zu machen und nicht ständig beim Rendern.
    Man sieht in einem Screenshot zB dass glGetUniformLocation() mit 3.3 % mehr Resourcen verbraucht als das darauf folgende setzen der 4x4 Matrix mit glUniformMatrix4fv mit 2.7 %.


    Das sind einzeln gesehen nur Peanuts, aber ihr ruft das so oft auf und es ist so einfach vermeidbar, wenn man die location einmalig holt und zB auf eine Membervariable zwischenspeichert, dass es einen Versuch wert ist.

    Eure Szene ist wirklich überschaubar. Ihr habt nicht viel Geometrie, eure Haupteffekte sind Omni-directional Shadow Mapping und SSAO. Da gibt es nicht viel zu optimieren, da läuft was falsch, wenn das auf den Abgaberechnern mit zB einer GTX 960 nicht auf 60 FPS kommt.


    Ich weiß nicht genau was du mit VBO optimieren und Texturen komprimieren meinst, aber sei's drum.


    Dass es die Anzahl der uniforms betrifft glaub ich auch nicht. Im Allgemeinen sind uniform buffers schneller, aber den Weg würde ich an eurer Stelle jetzt nicht mehr gehen.
    Ich rate euch zu folgender Vorgehensweise:
    - OpenGL Debug Context einbauen und prüfen, ob Fehler und/oder Performance Warnings gemeldet werden
    - Den Fehlerbereich einschränken
    - D.h. Rausfinden welcher Teil vom Code wie lange läuft
    - D.h. Code auskommentieren und messen was sich verändert
    - Das ihr werdet das vss. zuerst auf der C++ Seite machen
    - Und dann entsprechend Code auf der GLSL Seite auskommentieren


    Wenn ihr dann rausgefunden habt welche Zeilen Code dafür verantwortlich sind, dann kann ich euch hoffentlich Vorschläge machen wie ihr das verbessern könnt.
    Es ist eigentlich ganz einfach, ihr habt funktionierenden Code, der langsam ist, aber ihr wisst nicht warum.
    Daher Code entfernen, prüfen um wieviel es schneller wird und den größten Brocken bestimmen!

    Ihr könnt ein paar Millisekunden sparen, wenn ihr glGetUniformLocation() nur einmal macht und nicht in jedem Render-Durchlauf. Aber darauf würde ich mich nicht stürzen.
    Typischerweise spart man recht viel wenn man kleinere Framebuffer Texturen, Shadow Maps, etc. benutzt.
    Oder Modelle mit super vielen Polygonen oder super viele Modelle. Da kann man zB mit Culling nachhelfen.
    Ansonsten könnten es Schleifen im Shader sein (zB Anzahl von Samples reduzieren, etc.)


    Aber insgesamt, um unter 60 FPS zu bekommen, macht man etwas bestimmtes sehr falsch. Weil die Abgaberechner recht leistungsstark sind.
    Daher: Anstatt einfach zu raten, würde ich vorschlagen, dass ihr selbst im Code die Zeit misst und rausfindet zB welcher Render-Pass am meisten Zeit verbraucht. Oder welcher Teil des Programms besonders viel Zeit braucht.


    Es gibt hier kein Allgemeinrezept. Sehr spezifisch für euer Programm - daher messen und testen.


    Edit: ihr könnt auch einzelne Effekte ausschalten und die Framerateänderung beobachten


    Das ist eine Position, das meinte ich im ersten post mit "Eigentlich wollten wir ein directional light verwenden, aber das ist jetzt trotz anderen namens ein Punktlicht."


    Aja, sorry. Passt also.


    --------
    Ich hab noch mal drüber gesehen. Warum ist eure TBN Matrix eine NTB Matrix?
    Wenn's wahr ist, müsste es so sein:

    Code
    1. [COLOR=blue]mat3[/COLOR] TBN = transpose([COLOR=blue]mat3[/COLOR](
    2. vertexTangent_cameraspace,
    3. vertexBitangent_cameraspace,
    4. vertexNormal_cameraspace
    5. ));


    Danke für die Hilfe! Wir haben uns schon ein paar Tage schwarz gesucht und auch schon andere Fehler gefunden, keine Sorge


    Das war übrigens kein Angriff auf eure Person oder Leistung. Ich wollt nur sagen, dass ihr weiter suchen sollt, während ich auch weiter such...


    -----------
    EDIT:
    Ihr werdet die Texturkoordinaten dennoch fixen müssen, denn die Lichtrichtung in Tangent Space ist sonst "random" verdreht. Das mag sich beim diffusen Anteil nicht auswirken, aber beim spekularen schon.

    Das Problem ist meinem Kollegen und mir nicht bekannt. Wenn es sich ausschließlich auf die Benutzung von Nsight bezieht, ist das bitter, aber zumindest kein Weltuntergang, da euer Code funktioniert. Als workaround bleibt wohl nur, dass ihr jedes mal wenn ihr NSight benutzen wollt, das Partikelsystem ausschaltet.


    Sorry, dass das nicht hilfreicher ist..

    Ich hab mir das mal kurz angesehen. CodeXL (VS Plugin) funktioniert bei mir einwandfrei. D.h. das ist bei dir ein lokales Problem :-/ Da kann ich nicht viel dazu sagen.


    Die Shadow map ist leer weil ihr die falsche uniform location sucht.
    Ihr habt:

    Code
    1. GLuint depthMatrixID = glGetUniformLocation(depthMapShader, "MVP");


    glGetUniformLocation liefert eigentlich ein GLint zurück und dieses ist -1 falls es die location nicht gibt.
    Es macht Sinn entweder sicher zu sein, dass man die richtige Location hat oder zu prüfen ob es -1 ist.
    Und bei euch ist es -1, weil eurer uniform eigentlich "depthMVP" heißt.


    D.h. ihr könntet folgendes machen bei allen glGetUniformLocation() calls:

    Code
    1. [COLOR=#2b91af]GLint[/COLOR] depthMatrixID = [COLOR=#6f008a]glGetUniformLocation[/COLOR]([COLOR=gray]depthMapShader[/COLOR], [COLOR=#a31515]"depthMVP"[/COLOR]);
    2. [COLOR=#6f008a]assert[/COLOR](depthMatrixID != -1);


    Dann könnt ihr sicher sein, dass die Namen zumindest stimmen.
    --------------


    Wenn man die richtige Uniform-Location nimmt, dann ist auch was in der Depth Map drinnen. Shadows gibt's noch keine.
    Ich hab dann mal aufgehört Fehler zu suchen.


    Um das Shadow Mapping Problem zu finden, würde ich mal ganz simpel anfangen und einfach nur versuchen hard shadows anzuzeigen, keinen sampler2DShadow benutzen, sondern nur einen normalen sampler, etc. Natürlich alle uniforms überprüfen und vielleicht auch einen Debug Context einbauen.
    Und vielleicht startet einmal mit diesem Tutorial. Wenn ihr dann einmal korrekt Shadows angezeigt habt, dann könnt ihr das auf effizient umbauen mit der Bias Matrix und den shadow-sampler und PCF, ...


    -------------------------
    @CodeXL Vielleicht statt CodeXL Nvidia NSight benutzen, oder nach dem Fehler googlen - wie gesagt bei mir funktioniert's. Zum Debuggen kann man auch einfach die Textur auf dem Screen ausgeben.

    Ich korrigiere mich.


    Hab die Assimp generierten Tangenten/Bitangenten versucht - Selbes Phänomen.
    Es sind die Texturkoordinaten:
    textures.jpg
    Die sind mal so, mal so gedreht. Darum ist der Boden auch so fleckig, wenn man die Tangenten visualisiert oder eine Beleuchtung berechnet.
    Das solltet ihr im Modellierungsprogramm noch mal korrigieren, das ist ein Designfehler.

    Also... Ich hab mir das Projekt mal angesehen..


    Eure Tangenten:
    tangents.jpg
    und Bitangenten:
    bitangents.jpg
    sind kaputt.


    Um den Fehler in eurer Berechnung zu finden, brauch ich eine Weile.
    Ihr könntet ja daweil Assimp das Berechnen erledigen lassen und natürlich auch selbst ein wenig suchen :)


    Außerdem:
    Ihr habt beim Importen des Meshes folgendes Flag: "aiProcess_FlipUVs"
    Gibt's einen besonderen Grund dafür? Ich hab mir noch notiert bei meinem Projekt, dass es bei mir die Texturkoordinaten kaputt gemacht hat und hab's dann explizit nicht benutzt. Überlegt euch halt ob ihr das braucht.


    Außerdem (2):
    Shader "basic.vert":


    Ergibt wenig Sinn für mich:


    vec3 LightPosition_cameraspace = ( view * vec4(lightDir,1)).xyz;
    vec3 LightDirection_cameraspace = LightPosition_cameraspace + EyeDirection_cameraspace;


    "lightDir" wird zu einer Position?
    Oder ist lightDir eh eine Position nur falsch benannt?
    LightDirection_cameraspace ist dann in welche Richtung nach der Addition der Vektoren?
    Verwirrt mich sehr...

    Ok. Also es ist grundsätzlich kein Problem mit den Worldspace Daten zu arbeiten. Aber, dir muss bewusst sein, was SSAO überhaupt macht...
    Es werden nämlich Tiefenwerte aus Sicht der Kamera miteinander verglichen.


    Du kannst nicht einfach deine Textur mit world space positions samplen und davon den z-Wert extrahieren und sagen, dass ist mein Tiefenwert. Weil das ist nur die Z-Koordinate von einer Position im Weltkoordinatensystem! Das hat nichts mit Tiefe zu tun.


    D.h. du musst immer noch die Tiefenwerte aus Sicht der Kamera miteinander vergleichen.
    Das einfachste für dich ist: Jedes mal wenn du auf die scenePosWorldSpaceTextur zugreifst, hol dir die xyz Koordinaten raus und dann konvertier sie mit der View Matrix in den View Space. Wie du es bereits vor der Schleife gemacht hast, musst du es auch in der Schleife machen.. Nachdem du konvertiert hast, kannst du die z-Koordinate nehmen. Bzw. richtiger wäre wahrscheinlich die Länge des View-Vektors als Tiefe heranzuziehen.


    Hm, ich wundere mich nur, weil wenn ich zuvor

    Code
    1. fragColor = vec4(vec3(closestDepth / near_far.y), 1.0);


    aufrufe, dann wird mir die depth ganz normal ausgegeben (so wie im screenshot im letzten Posting), deshalb bin ich davon ausgegangen, dass alle Parameter (uniforms) stimmen.


    Ich hab mich auf currentDepth bezogen.. Stimmt die garantiert?


    Edit: Könnt ihr auch mal prüfen, ob currentDepth und closestDepth NaN oder Inf sind? Und ggf. Farben ausgeben. Sowas wie if isnan(currentDepth) -> Farbe rot?