Suchergebnisse
Suchergebnisse 1-18 von insgesamt 18.
Zitat von »David Scherfgen« Das würde ich mir auch wünschen (direktes Rendern in eine Cube-Map). Es gibt die Möglichkeit, mit Geometry Shadern zumindest jedes Dreieck nur einmal an die Karte schicken zu müssen, im Prinzip ist das nur 1 Pass. Im Shader musst du dann schauen, welche Faces ein Dreieck abdeckt. Hab ich auch schon von gelesen, allerdings hat man immer noch 6 Pässe beim Fragmentshader, was glaub ich das rechenintensivste ist. Ist die Frage welche Methode effektiver ist, mit der Metho...
Zitat von »David Scherfgen« Nice Ich wollte auch immer mal Cube-Shadow-Maps implementieren. Planst du auch selektive Updates einzelner Faces, z.B. wenn sich nur in einer Richtung etwas verändert, was ein neues Rendern der Shadow-Map erfordern würde? Hab ich noch nicht wirklich drüber nachgedacht. Für Lichter mit statischen Positionen könnte sich das ja durchaus lohnen. Da ich voraussichtlich eine statische Map mit dynamischen Entitäten verwenden werde, könnte man eventuell für die Lichter die i...
Zitat von »David Scherfgen« Cool Aber eigentlich hast du dir ja selbst geholfen Zeig doch nochmal einen Screenshot! ok, da hast du recht Dann aber auf jeden Fall danke für eure Hilfsbereitschaft Hier mal noch die 2 Test-Szenarios mit nun funktionierenden (aber noch ungefilterten) Schatten: <!--splitLinkBegin--><!--splitLinkEnd--><!--noLinkBegin-->ExternesOriginalbildanzeigen(Link)<!--noLinkEnd--> <!--splitLinkBegin--><!--splitLinkEnd--><!--noLinkBegin-->ExternesOriginalbildanzeigen(Link)<!--noL...
omg, es funktioniert endlich! Ich kanns kaum glauben xD Folgender fießer Fehler war dran Schuld: C-/C++-Quelltext 1 glUniformMatrix4fv(m_shadow_shader.get_uniform_location("light_pos"), 1, false, (GLfloat*) &light_position); sollte eigentlich C-/C++-Quelltext 1 glUniform3fv(m_shadow_shader.get_uniform_location("light_pos"), 1, (GLfloat*) &light_position); heißen. Danke für eure Hilfe!
Hab die Engine.cpp nochmal geupdated, die Render-Methode ist nun besser strukturiert und kommentiert. http://dl.dropbox.com/u/12845003/ShadowTest.zip
Zitat von »David Scherfgen« Das liegt daran, dass es "standard" heißt lulz I haz failed
Hier die Standalone-Version des Tests: http://dl.dropbox.com/u/12845003/ShadowTest.zip Sieht auf den ersten Blick etwas durcheinander aus, da ich 2 eigene Libraries + die verschiedenen Module meiner Engine zerstückeln und zusammenschmeißen musste Einzige Abhängigkeiten sind GLEW und SDL (core-libs sollten ausreichen). Sourcen: ClientMain.cpp enthält die main()-Funktion. Client.cpp/h initialisiert SDL, managed Keyboard/Mouse-Input und beinhaltet den SDL-Mainloop der die Engine clockt. Engine.cpp/...
kann ich machen, allerdings kann ich nur ein Projekt mit Unix-Makefiles zur Verfügung stellen, da ich bisher nur auf Linux programmiert habe. Die libs die ich verwende sind allerdings alle Crossplatform-tauglich, Abhängigkeiten würden wenn ich boost.serialization aus meinen Matheklassen entferne, dann eigentlich nur SDL sein.
So, ich habe nun mein Testszenario etwas vereinfacht, so dass man das ganze optisch besser analysieren kann. Den gDebugger muss ich mir bei Zeiten auch mal anschauen aber ich glaub dafür brauch ich noch etwas Zeit. <!--splitLinkBegin--><!--splitLinkEnd--><!--noLinkBegin-->ExternesOriginalbildanzeigen(Link)<!--noLinkEnd--> Eine Lichtquelle die sich im Moment in der Mitte der Debug-Skybox befindet und sich hin und her entlang der Achse bewegt in der sich die beiden großen Ebenen schneiden. Dann zw...
Nochmal zussammenfassend, vielleicht wird es dadurch jemandem klarer wo das Problem genau liegt: Beim Shadow-Map berechnen mach ich effektive folgendes: (sowohl (var_)vertex_pos als auch light_pos sind hierbei in Worldspace) C-/C++-Quelltext 1 2 gl_Position = light_viewprojection_matrix * vertex_pos; // Für die viewprojection-matrix siehe letztes Codesnippet. gl_FragDepth = length(var_vertex_pos - light_pos) / max_distance; max_distance ist hier die maximal mögliche Entfernung zwischen Lichtposi...
Zitat von »David Scherfgen« Warum dividierst du an einer Stelle durch 40? Da dies die maximale Entfernung vom Licht zu einer Vertexposition ist. Beim Erstellen der Cubemap verwende ich eine Projektionsmatrix mit einem Far-Plane bei 40 um das Fragment auf eine Cubemapfläche zu projizieren. Ich versuche damit die Entfernung vom Licht zur Vertexposition auf [0, 1] zu normieren.
Zitat von »Schrompf« Das kann ich im Detail nicht bewerten, da ich keine Ahnung von OpenGL habe. Normalerweise sind floats aber 32bit und doubles sogar 64bit. RGBA ist aber auf jeden Fall falsch - Du brauchst für eine einfache ShadowMap nur einen Kanal. Ähh, ja natürlich 32 bzw. 64bit Die RGBA-Cubemap stammt noch aus Debugzeiten. Ich hab im Moment sowohl einen Depthbuffer als auch einen Farbbuffer, die beide mit Tiefenwerte beschrieben werden. Später werde ich natürlich nur Depthbuffer verwende...
ok, vielen Dank für eure Antworten. Sehr beruhigend zu hören, dass meine Shadowmap normal aussieht Das Format das ich verwende ist GLfloat der ja eigentlich 2Byte groß ist oder? bzw das ist meine Textureinitialisierung: C-/C++-Quelltext 1 glTexImage2D(GL_TEXTURE_CUBE_MAP_POSITIVE_X + face, 0, GL_RGBA, width, width, 0, GL_RGBA, GL_FLOAT, 0); Sind das nicht für jeden Kanal 16bit-Fließkommazahlen? Werde mal GL_DOUBLE versuchen. edit: @David: Falls du mit Floating-Point-Rendertarget menst, dass ich ...
Ich hab nun herausgefunden, dass die komischen Streifen von Rundungsfehler beim Cubemaplookup stammen. Zeigt ein Richtungsvektor genau auf die Kante eines Objektes, so kann durch Rundungsfehler das falsche Pixel ausgewählt werden -> der Texturelookup liefert den Wert des Objekts dahinter. Aber selbst wenn man von den Streifen absieht stimmen die Schatten nicht
Zitat von »David Scherfgen« Vielleicht eine dumme Frage, aber wo setzt du denn überhaupt gl_FragColor? Der Aufruf für gl_FragColor steht eigentlich in dem Shader der das Terrain beleuchtet und ist mit dem ... rausgekürzt. Dachte ich schneide den Code nur auf das potentiell problematische zu. Beleuchtung und Texturierung funktionieren. Wenn is_in_light = 1.0 ist wird auf die Lichtfarbe der Diffuse-Anteil draufaddiert. In meinem letzten post überspringe ich dies und setzte die Fragmentfarbe direk...
Zitat von »Kippstrahl« Moin, ich sitze gerade an meinem MC-Klon ( siehe meinen andere Thread ). Ich stehe momentan vor dem Problem, einen VertexBuffer zu aktualisieren. Derzeit schreibe ich in den VertexBuffer nur die Vertices, die auch sichtbar sind (ich dachte am Anfang, dass es Overhead wäre, den man vermeiden könnte). Nun möchte ich aber geziehlt einzelne Seiten der Würfel verändern (z.B eine Textur draufblenden), ohne den gesamten VertexBuffer neu zu erstellen. Dies ist jedoch mit meinem s...
Das Problem scheint auf jeden fall mit dem Cubemap-Texture-Lookup zusammenzuhängen. Das hier kommt dabei raus wenn ich die Fragmentfarbe auf vec3(1.0, 1.0, 1.0)*shadow_map_depth setzte: <!--splitLinkBegin--><!--splitLinkEnd--><!--noLinkBegin-->ExternesOriginalbildanzeigen(Link)<!--noLinkEnd--> Ich kann mir nur leider nicht erklären was falsch läuft edit: eigentlich sollte das Bild wie der Cubemap-Würfel ein Bild drüber aussehen, also ohne die komischen Striche und plötzlichen Farbunterschiede.
Seid gegrüßt werte Entwickler, ich versuche nun seid mehreren Tagen vergeblich meiner in C/-++ geschriebenen 3D-Engine die Kunst der Schatten zu lehren. Ich verwende OpenGL 3.3 mit eigenen Shadern und bin dabei Shadowmapping mit Cubemaps für omnidirektionale Lichtquellen (Punkt-Lichter) zu implementieren. Als Testszenario verwende ich ein generiertes Terrain über welchem eine einzige Lichtquelle schwebt. Dabei gehe ich folgendermaßen vor: 1) Ich initialisiere ein Framebufferobjekt (FBO) mit jewe...
29.05.2024, 01:27
Zum Seitenanfang
