Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
Guten Abend an alle, Ich möchte gerne FBO's bei mir installieren. Dazu hab ich mich ein wenig über die Benutzung schlau gemacht. Aber die unten zitierte Passage hat mir einen ganz schönen Schlag versetzt (Auszug aus der OriginalSpec):
Special precautions need to be taken to avoid attaching a texture image to the currently bound framebuffer while the texture object is currently bound and potentially sampled by the current vertex or fragment shader. Doing so could lead to the creation of a "feedback loop" between the writing of pixels by rendering operations and the simultaneous reading of those same pixels when used as texels in the currently bound texture. In this scenario, the framebuffer will be considered framebuffer complete, but the values of fragments rendered while in this state will be undefined. The values of texture samples may be undefined as well.
Vielleicht reicht mein Englisch ja nicht aus, aber ich interpretiere das so, dass man - während man in die FrameBuffer-Texture-Objekte zeichnet - keine normale Textur gebunden haben darf. Ist das wirklich so? Da könnt ich ja doch nie etwas Texturiertes in den Framebuffer zeichnen? Das kann ich eigentlich nicht glauben.
Wenn das so ist, welche Alternativen hab ich dann? Mir gehts um RenderToTexture und Post-Processing. Traude
Du hast das nicht ganz verstanden Da steht das du die Textur in die du mittels FBO gerade renderst nicht gebunden haben darfst, da der Inhalt in diesem Moment logischerweise nicht definiert ist.
Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
Ach so, sie wollen offenbar sagen, dass man streng unterscheiden muss zwischen glTexImage2D(= Input) und glFramebufferTexture2D (=Output), sonst liest und schreibt man die gleiche Textur. Auf so eine seltsame Idee wär ich gar nicht gekommen. Danke jedenfalls für Deine Antwort. Viele Grüße Traude
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Ich hab mich geärgert, als ich das gehört habe … Schließlich wäre FBO + Textur doch der ideale Workaround, um einfach eigene Blendfunktionen zu implementieren. So abwegig ist die Idee nicht .
greetings
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
Ich hab mich vielleicht falsch ausgedrückt, also ich meine, es sollte funktionieren. Erinnerst Du Dich vielleicht an ein Dokument, das Sascha Willems vor ca. einem Jahr vorgestellt hat? KillZone glaub ich hieß das Spiel. Die machen genau das. Sie schreiben alle für das Zeichnen/Beleuchten/Schattieren nötigen Daten in die Texturen, die dem FBO beigegeben sind - als Rohdaten. Das ergibt mehrere ziemlich seltsam aussehende Bilder, die auch GLEICHZEITG gerendert werden können. Daraus wird ein Bild zusammengesetzt, das dann noch mittels Postprocessing zum endgütigen Bild führt. Da bist Du ganz frei, wie Du das handhabst, und ja, klar, Blending könnte man dabei auch machen.
Das ergibt mehrere ziemlich seltsam aussehende Bilder, die auch GLEICHZEITG gerendert werden können.
Öh, ich hab das jetzt nur überflogen, aber ich würde mich doch sehr wundern wenn das gleichzeitig ginge. Was die da machen ist doch nur Deferred Shading mit ein paar Extras? Da erzeugt man zuerst den G-Buffer (ein Haufen Texturen) und nutzt diesen dann um das eigentliche Bild zu rendern. Aber das geht nicht gleichzeitig, sondern nacheinander.
Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
Mit "gleichzeitig" meine ich: in einem einzigen Renderpass (soll heißen: der Geometry-Buffer wird in einem einzigen Renderpass erzeugt). Und "nur" deferred shading? Das ist doch eine geniale Rendermethode: aus Schichten aufgebaut. Wusste ich garnicht, dass Ihr das schon ins Wiki aufgenommen habt. Ist dort aber weit und breit kein OpenGL-Code zu sehen.
Registriert: Di Okt 03, 2006 14:07 Beiträge: 1277 Wohnort: Wien
Zitat:
Ja, aber um den G-Buffer dann letztlich zu verwenden brauchst du einen zweiten Pass.
Öhm, Ja.
Zitat:
Ich denke mal wer die Idee verstanden hat braucht kein OpenGL-Code mehr dafür. Es hindert dich aber niemand daran das zu übersetzen.
Ich wollte nur darauf hinweisen, dass es sich um ein OpenGL-Wiki handelt. Und es ist ja in Ordnung, dort Pseudocode zu schreiben, aber nicht dann, wenn es völlig unsinnig ist, das zu tun.
OpenGL ist sowohl plattformunabhängig, als auch in jeder Programmersprache praktisch gleich. In einem OpenGL-Wiki macht OpenGL Pseudocode *grundsätzlich* gar keinen Sinn.
Und außerdem möchte ich auch darauf hinweisen, dass meine Frage beantwortet ist.
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Das Wiki ist nicht für OpenGL allein gedacht. Wir haben ja auch OpenAL, SDL und Tutorials die sich mit Programmierung im allgemeinen beschäftigen. Da sollte man also nicht zu starke Filterkritierien aufbauen. Unser Wiki ist mehr eine Art "Community Gedächtnis".
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Mitglieder in diesem Forum: 0 Mitglieder und 5 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.