Posts by 2#4u

    Das ist normalerweise ein struct. Wenn ich mir das 'stride' Attribut von 'glVertexAttribPointer' beim ihm ansehe ist das 16, daher kann es ein struct der folgenden Form sein:

    Code
    1. struct ParticlePod
    2. {
    3. vec3 position;
    4. float time;
    5. vec3 velocity;
    6. }


    Auf der Seite ist auch Code verfügbar. Der ist zwar anders aufgebaut, aber sollte helfen das ganze zu verstehen.

    Zum zweiten hätte ich schon versucht MipMapping zu implementiert (mittels GL_LINEAR_MIPMAP_LINEAR) da geht aber irgendwas mächtig schief. Kann mir jemand empfehlen welche Filtering-Methoden leicht/schnell oder auch am erfolgreichsten sind, vll auch mit einem link zu einem tutorial?


    Zu dem Fehler bei den Kanten der Objekte kann ich nicht viel sagen. Vielleicht ist das ein self-shadowing Artefakt und kann mit einem Bias korrigiert werden?
    Zu MipMapping: Habt ihr die MipMaps generiert (glGenerateMipmap) nachdem ihr die Shadow-Map gerendert habt?
    Bezüglich Filtering: Der oben verlinkte GPU Gems Artikel gibt einen Überblick. Seht euch mal die implementation notes an.

    Die Szene aus Sicht der Lichtquelle ist derzeit so groß, dass der Bär nur ein paar wenige Pixel groß ist. Das heißt der Schatten vom Bären wird ebenso nur sehr sehr klein sein.
    Auch wenn ihr eine sehr hohe Shadow-Map-Resolution habt (2048^2), gehen euch hier einfach die Details verloren.


    Nachdem ihr ein directional light habt, könnt/müsst ihr die Ansicht aus Sicht der Lichtquelle so anpassen, dass es einen möglichst großen Bereich um den Player herum umfasst, ohne dass ihr Details in den Schatten verliert. Das heißt ihr müsst die Position der Lichtquelle beim Erstellen des orthogonalen Frustums so berechnen, dass ihr auf den Bären schaut (look-at point), die Lichtrichtung (die ihr derzeit nicht definiert habt) benutzt, und die Kamera entgegengesetzt zu der Lichtrichtung so positioniert, dass ein "sinnvoller" Bereich um den Bären abgedeckt wird für die Schattenberechnung.


    Ein directional light hat eigentlich keine Position, sondern nur eine Lichtrichtung. Für die Shadow-Map generierung braucht ihr halt trotzdem irgendeine. Die Position selbst ist nicht so wichtig (die liegt irgendwo entlang des Vektors Bär + light-direction), aber die Frustum-Grenzen (near, far, left, right, top, bottom) sind schon wichtig.


    Sinnvoll heißt hier, der Bereich der ShadowMap sollte ungefähr den Bereich eures View-Frustums des Players abdecken. Das müsst ihr experimentell herausfinden, was hier sinnvoll gut aussieht.


    Übrigens hoffe ich irgendwann darauf, dass eure Szene sinnvoll ausgeleuchtet ist. Derzeit ist alles sehr finster...

    Ich hab versucht mich in die Thematik einzulernen und den besten Ansatz den ich finden konnte ist jener den Geometry Shader für die Sillhouette Edge Berechnung einzusetzen.
    Referenzen:
    http://ogldev.atspace.co.uk/www/tutorial40/tutorial40.html (Wichtig: Zuerst in Tutorial 39 einlesen)


    Meiner Meinung nach muss man mit diesem Tutorial aber vorsichtig sein. Der Autor benutzt (im Geometry Shader) lokale Objektkoordinaten und die Lichtposition scheint relativ zum Objekt zu sein statt im World-Space (??) - Hab ich nicht ganz durchschaut. Gleichzeitig ist der Code auf der Homepage tlw. fehlerhaft (Variable WorldPos gibt es nicht) und unterscheidet sich vom Code den man runterladen kann.


    Aber der Ansatz ist schon vielversprechend und sollte schneller sein als auf der CPU Seite die Silhouette zu errechnen.
    Es sollte dann auch egal sein, ob sich die Lichtquelle und/oder die Objekte bewegen.

    Ich hab mal kurz reingesehen in euer Projekt.
    Rendert die Szene einmal aus Sicht der Lichtquelle. Ich hab das gemacht und komm auf keinen grünen Zweig, da die Position und/oder das orthogonal Frustum nicht auf die Szene passt.
    Folgender Testcode hat mich dann die Szene zumindest erahnen lassen können:


    Das heißt: Passt eure view und projection Matrix der Lichtquelle an die Szene an und testet danach (mit CodeXL), ob in der Tiefentextur der Shadow-Map etwas sinnvolles drinnen steht.
    Außerdem ist mir noch aufgefallen, dass eure clear-color immer 0.1 ist?
    Bevor ihr die Shadow-Map erstellt, sollte die clear-color wohl auf 0 gesetzt werden.

    Es ist meistens hilfreich sich die ganze Szene aus Sicht des Lichtes anzusehen. D.h. statt der View-Projection Matrix des Players einmal die des Lichtes benutzen und schaun ob alles richtig ausgerichtet ist.
    Zusätzlich die Shadow-Map ansehen (d.h. die Tiefentextur) z.B. mit CodeXL.
    Wenn das richtig ist, dann kann man zumindest einmal den Fehlerbereich eingrenzen.

    Gut gemacht!


    Ich möchte nur kurz anmerken, dass die Pointer in eurem Header insofern ein Problem sind/waren, weil ihr euch die Adressen von lokalen Gluint Variablen gemerkt habt.
    Das wird aber nach kürzerster Zeit auf einen ungültigen Speicherbereich referenzieren bzw. da wird einfach etwas anderes drinnen stehen.


    Den Pointer benötigen wir für glDeleteFramebuffers, welche einen Pointer zum Löschen erwartet.


    Momentan habt ihr das auskommentiert.
    Warum nicht einfach glDeleteFramebuffers(1, &reflectionFrameBuffer) und dergleichen schreiben?
    D.h. einen Pointer auf eure Member-Variable beim Löschen angeben...

    Bezüglich dlls: Euch fehlen: freetype und zlib
    Bezüglich DebugContext: Der funktioniert nicht. Testen kann man den Context indem man bewusst einen Fehler provoziert. ZB mit glUseProgram(-1);
    Warum er nicht funktioniert: Der glfwWindowHint muss vor dem Fenster öffnen übergeben werden. D.h. zuerst glfwInit(..), dann die window hints und dann Fenster öffnen.


    Weiters: Gibt es einen bestimten Grund warum in WaterShader.h alle OpenGL ids const GLuint* sind? Warum nicht einfach GLuint?


    Fixed denn Debug Context, ändert die Ids, schaut euch alles noch einmal an und dann meldet euch wieder.

    Also, ich kann euer Projekt nicht starten weil einige dll's fehlen.
    Auch scheint das nicht der selbe Stand zu sein, den ihr hier gepostet habt.


    Aber unabhängig davon:
    1. Ich kann keinen Debug Context finden. Baut den mal ein und schaut euch etwaige Fehler an.
    2. Prüft, ob eure Plane überhaupt gezeichnet wird und die Texturkoordinaten Sinn machen. Z.B. einfach mal im water.frag nur reflectTexCoords als Farbe ausgeben.
    3. Prüft eure Reflection-Texture zB mit CodeXL, ob sie richtig ist.
    4. Nur die Reflection-Texture ausgeben (ohne mix) -> Was ergibt sich dann?


    Wenn du sagst das Reflektionsbild wird nur in der linken unteren Ecke angezeigt, hat das vielleicht etwas mit eurem viewport Einstellungen beim Rendern der Reflektion zu tun.

    Es stellt sich die Frage, ob schon die Textur so aussieht, oder ob es das Ergebnis vom Zeichnen ist..


    Ihr könnt mit dem Tool CodeXL die Textur ansehen. Bzw. müsst ihr halt überprüfen ob ihr glViewport() richtig setzt bevor ihr in die Textur schreibt.
    Die Umrechnung von position zu texcoord stimmt, sofern position zwischen [-1,1] ist.

    Naja, im Wesentlichen funktionieren hierarchische Animationen genau so..


    Im Allgemeinen ist es einfach so zu lösen:
    - Objekt A hat eine Modelmatrix M_A (z.B. Verschiebung)
    - Objekt B hat eine Modelmatrix M_B (z.B. Rotation um den Ursprung)


    Objekt B ist ein Child von Objekt A. Die 'neue' Modelmatrix für B unter Berücksichtigung von der Transformation von A ist dann:
    M_B_alles = M_A * M_B


    Wenn man nun für einen Vertex v jetzt diese Matrix anwendet:
    v_transformiert = M_B_alles * v
    Dann wird von rechts nach links gelesen zuerst alles angewendet was die Transformation von B betrifft (man kann sich das Objekt im Ursprung vorstellen und rotiert) und dann die Transformation von A (d.h. die Verschiebung in eurem Fall).
    Diese neue Matrix 'M_B_alles' wird dann in eurem Shader für Objekt B benutzt.


    Also: Einfach die Modelmatrizen in der richtigen Reihenfolge aufmultiplizieren und dann erledigt sich alles selbst. D.h. es ist dann egal ob sich das Objekt A nur bewegt oder auch rotiert oder skaliert, ...


    Wenn ihr das so macht, dann habt ihr allgemein das Problem gelöst und alles ist gut.

    CodeXL bzw. jetzt GPUOpen (?) kann man zum Debuggen benutzen.


    Ich find euer Ergebnis allerdings sehr verwirrend.
    Nachdem ihr aber nur gelb und rot am Screen habt, könnte es sein, dass ihr irgendwelche Berechnungen nicht auf allen Farbkanälen macht?


    An eurer Stelle würde ich einmal schauen, ob die Werte der Lichter im Shader richtig ankommen.
    Unter der Annahme, dass der Debug Context nichts meldet, einfach einmal auf der C++ Seite ein Licht (mit Index 0, 1, ..) übergeben mit bestimmten Werten.
    Z.B. ambient = (1, 0, 0) und im Shader für diese konkreten Lichter einfach nur mal den Wert als Farbe ausgeben. Z.B. return vec4(light[0].ambient, 1.0).
    Wenn der Screen dann rot ist, dann passt der Wert.


    Damit dann die einzelnen Attribute überprüfen und dann schrittweise das Beleuchtungsmodell checken für zuerst einmal ein Licht, dann 2 Lichter, ...

    1. Bitte Code aus dem Forum entfernen.


    Allerdings die Kantenfarbe passt nicht ganz, denn die Kanten schauen nicht genau so aus wie das Ergebnis auf der Aufgabenseite.


    2. Kannst du mal Bilder posten? Ich würde dir empfehlen noch einmal die anderen Funktionen zu überprüfen.

    Nun ja, das FBO ist gültig, aber laut OpenGL Specification gilt:

    Quote


    If the attachment sizes are not all identical, rendering will be
    limited to the largest area that can fit in all of the
    attachments (i.e. an intersection of rectangles having a lower
    left of (0,0) and an upper right of (width,height) for each attachment)


    Und bezüglich Textur verkleinern:
    Du könntest einen weiteren Renderpass machen in dem du von der großen Textur liest und mit einem Fullscreen-Quad in ein FBO mit kleinerer Textur renderst. Du kannst dabei noch weitere Schritte durchführen, wenn du die brauchst, damit der Renderpass ein wenig mehr tut.
    Oder eben mit Mipmaps.

    Mit linearer Interpolation ist folgende Form gemeint:

    , wobei

    die zu interpolierenden Werte sind und

    der Interpolationsparameter.


    Interpoliert werden soll zwischen Farbbild und Kantenbild unter Berücksichtigung der Kantenstärke (Das ist der Interpolationsparameter), die zuvor berechnet wurde und als Übergabeparameter vorliegt

    'newObst' ist eine locale Variable von dem struct. Wird daher irgendwann aufgeräumt/wiederverwendet/etc.
    Am Besten in eurem Fall ist wohl eine Kopie des structs in die Liste zu speichern und nicht die Adresse.
    D.h.
    'obstacleList->pushBack(newObst)'
    statt '&newObst'

    Ich kann nichts auf den Screenshots erkennen. Alle viel zu dunkel.
    Entweder eine andere Szene wählen oder die Helligkeit hochschrauben.



    Die erste Zeile des FBO-Fragment-Shaders habe ich gerichtet, also anstatt den Rot-Kanal der eigentlichen Textur verwende ich jetzt die übergebene Depth-Textur.


    Das reicht nicht!
    Die Depth-Textur, die du verwendest, ist nicht linear. Im Chapman Tutorial benutzt er eine lineare Textur.
    Das heißt du brauchst einen anderen Ansatz wie du die view-space position bzw. world-space position rekonstruierst.
    Chapman selbst verweist für einen Überblick auf diesen Blog.
    Ich hab dich vorher schon auf den GPU Gems Artikel hingewiesen.
    Versuch dich in die Thematik einzulernen und den Code zu verstehen. Vor allem von welchem Space in welchen umgerechnet wird.

    I assume you checked possible errors with the Debug Context? If not, do so now!


    Does the 'targets' array contain the correct values? (GL_TEXTURE_CUBE_MAP_POSITIVE_X, ...)
    Is the skybox at least at the right position and if so are the "TexCoords" plausible?
    This can be tested by rendering the TexCoords as color (e.g. color = vec4(TexCoords, 1.0))


    Is the texture loading working? Meaning: Did you use this texture loading successfully elsewhere in your code?
    If so: Try the successfully loaded texture instead of the cube-map and see if that's working.
    Are you loading the textures in the correct format? Check if the textures are RGB if you're loading with RGB format and not RGBA.


    If you're not doing that already: Orientate yourself on this tutorial. Try to identify differences in your code.