ZFX + Developia

Ich sehe die auch nicht.

und


Sieht so aus, als würdes relativ deutlich flimmern, wenn man das Licht oder Schatten werfende Objekte bewegt.
Wobei ich nach wie vor nicht verstehe, warum man keine cubische Interpolation für Shadowmaps verwendet...wäre zwar nicht richtig, aber man würdes denk ich kaum merken.

Gruß

EDIT: sagt mal irre ich mich oder führt das auch zu *Mustern* auf eigentlich hellen Flächen? Ist mir irgendwie grad erst beim vergrößern richtig aufgefallen. Also auf der Treppe und im Wasser zwischen den beiden Kisten ist so ein komisches gestreiftes Muster...im gegensatz zu den oben gezeigten Fehlern scheint dass aber zu verschwinden, wenn man auf 50% skaliert.

Nuja... dass ShadowMaps nur eine begrenzte Auflösung haben, ist kaum bestreitbar. Zudomon hat da schon ziemlich gute Arbeit geleistet bei der Feinabstimmung der ShadowMap-Filter. Eine Filterung der Tiefenwerte selbst würde exakt gar nix bringen.

Die sachten Verdunklungsmuster auf Oberflächen sind evtl. Selbstschattierungsprobleme. Bei weiter ausgreifenden Filterkerneln muss man ganz schön aufpassen, damit das Tiefenbias so gewählt ist, dass auch das entfernteste Sample auf geneigten Oberflächen nicht aus Versehen *vor* der Oberfläche landet.

Schrompf hat geschrieben:Eine Filterung der Tiefenwerte selbst würde exakt gar nix bringen.

So ist es.

Die Selbstschattierungsprobleme kommen allerdings dadurch, dass ich nochmal eine Auflösungsstufe runtergeschaltet hatte, nun sind die 512².
Hatte keine Lust, den Bias anzupassen.

Aber hier noch ein kleiner Trick, der mir eingefallen ist, für alle, die Probleme mit Selbstschattierung haben. Also t ist der Wert, der hinterher mit dem ShadowmapWert verglichen wird. z ist der hineinkommende Wert, auf den der Bias draufgerechnet werden muss.
Der Bias ist hier 0.00005 und zwar für Flächen, die Senkrecht zum Licht stehen. Nun wird noch ein zweiter Bias draufgerechnet, der maximal 0.0003 ist. Skaliert wird dieser Wert mit dem Einfallswinkel des Lichtes. nor ist die Normale der Oberfläche und LightPos die Lichtrichtung.
Muss man natürlich auch noch feintunen. Vielleicht hilft es.

Gruß
Zudo

Der Schatten wird immer schlechter... aber der ist im Moment noch nebensächlich.

+ DOF
+ SSAO
@Lord Delvin
Ich weiß nicht, ob man mit Raytracing wesentlich bessere Schattenqualität hinbekommt. Weil da jittert man auch die Schattenstrahlen um Bandings zu vermeiden, und bekommt dadurch ein ähnliches rauschen. Das einzigste dagegen sind mehr sampels oder ein Tiefenblur.
Aber du kannst mich gerne vom Gegenteil überzeugen... wenn du mal Dreiecke importieren kannst, dann sag bescheid, dann bekommste die Szene gerne zum testen.

Raytracing liefert weiche Schatten bei Flächenlichtquellen. Weiche Schatten bei Punktlichtern sind immer Hacks, und schauen auch so aus.

Aber die müssen ja immer gesampelt werden, ob Punkt oder Flächenlicht.

Ja, man braucht in jedem Fall dann ein ganzes Bündel Strahlen. Deswegen ist die Diskussion ja auch so sinnlos - Raytracing mit harten Schatten ist schon Meilen hinter der Performance entsprechender Rasterizing-Techniken hinterher, da braucht man keine Luxus-Anwendungen mit dem Vielfachen der Anforderungen in die Diskussion einbringen.

Aber bevor wir wieder völlig vom Thema abkommen: die neuen Bilder sind ein mächtiger Schritt nach vorn! Depth Of Field find ich immer störend in Spielen, aber das ist wohl Geschmackssache. Aber das SSAO wirkt beeindruckend. Subtil, so wie es sein sollte, und verpasst dem Bild doch eine enorme Tiefenwirkung. Find ich toll! Du könntest allerdings die Schattenqualität wieder etwas hochziehen... eine 2048er kannst Du schon investieren, egal wie Du sie aufteilst :-)

Zudomon hat geschrieben: @Lord Delvin
Ich weiß nicht, ob man mit Raytracing wesentlich bessere Schattenqualität hinbekommt. Weil da jittert man auch die Schattenstrahlen um Bandings zu vermeiden, und bekommt dadurch ein ähnliches rauschen. Das einzigste dagegen sind mehr sampels oder ein Tiefenblur.
Aber du kannst mich gerne vom Gegenteil überzeugen... wenn du mal Dreiecke importieren kannst, dann sag bescheid, dann bekommste die Szene gerne zum testen.

öhm ich mach das anders. ich rechne bis zum internen screenbuffer mit float³ als farbmodell und dann hast du da eigentlich keine probleme. wie man an den screenshots sieht hat man dann doch banding, aber das könnte man beheben, wenn man die transformation ins graka format selbst macht und dithert. Da waren wir aber wirklich zu faul zu, weils halt eigentlich n Treiberbug ist in meinen Augen...ich mein ich übergeb ja die floats an OpenGL, also hätte ich gedacht, dass GL_DITHER das macht, aber irgendwie nicht...is hier auch unwichtig.

Ansonsten würd ich mich Schrompf anschließen.
Gruß

Wirkt definitiv um einiges besser - gute Arbeit!

Leider aber immer noch der 'Vorschaubildchen-Effekt' - in groß sieht es nicht ganz so gut aus, weil die Geometrie und Texturierung zu grob ist.

bilder sind super... vielleicht könntest du mal einen wassershader machen, der einen ölfilm auf der wasseroberfläche simuliert, das würde in die szene passen ^^... für die übergänge von algen/moos und normalem stein könntest du vielleicht zumindest an den rändern eine art fur effekt oder so basteln.... ein mesh mit einer fransigen moostextur reicht da vielleicht schon... da du ja viel wert auf prozeduraler generierung legst, könntest du einen generator schreiben, der bei schnittkanten bestimmter meshes ein übergangsmesh baut...

Danke erstmal für das Kompliment!
Ein prozedurales Mesh an den Schnittkanten erzeugen hört sich aber sehr komplex an. Irgendwie bezweifle ich, dieses sinnvoll hin zu bekommen. Eine fransige Moostextur würde mir gefallen... das werde ich probieren. Ölfilm werde ich erstmal lassen, ich finde nicht, dass das nicht unbedingt in die Abflussszene passt.
Mein Hauptproblem ist, dass das alles so grottig langsam läuft. Also auf High-Detail, so wie es auf dem letzten Bild ist, hab ich 4 FPS... im moment weiß ich auch nicht, wie man das alles richtig schnell bekommt.

Und Du hast wirklich keinen Verdacht, weswegen das so langsam sein könnte? Bist Du CPU- oder GPU-begrenzt?

Falls Du eine NVidia-Karte hast, musst Du Dir unbedingt mal NVPerfHUD runterladen. Dann starte einfach mal Deine Exe aus dem NVPerfHUD heraus und schau Dir z.B. die GPU-Idle-Time an. Wenn die >0 ist, bist Du CPU-begrenzt. Von da aus entscheidet sich dann, wie Du weiterprüfen solltest.

NVidiaPerfHUD hab ich drauf. Laut deiner Aussage bin ich GPU begrenzt. Irgendwas stimmt da auch nicht, wenn ich das längere Zeit an habe, zumindest war es ebend so, stürzt der ab... also der Monitor bekommt kein Signal mehr... muss dann hard reset machen. Sehr eigenartig.
Es ist auch so, wenn das Renderfenster sehr klein ist, bekomme ich schon ein paar Frames mehr. Bei einem ganz winzigen Fenster bis zu 40 FPS. Das zeigt ja eigentlich, dass die Pixelshader viel ausmachen.

Hier wieder ein kleiner Erfolg.

Auf den ersten Blick nichts erstaunliches, außer ne Box mit Parallax Occlusion Mapping, welches ich ja auf dem anderen Screen schon hatte... Aber wenn die Texturkoordinaten nicht korrigiert werden, wird der Schwindel sichtbar. Benutze Fins an den Rändern. Durch ein bischen umrechnen, auf das ich durch stundenlanges Try&Error gekommen bin, werden nun die Texturkoordinaten der Fläche fortgeführt. Was das am Ende bringt kommt in ein paar Stunden...

So, hab es jetzt soweit... aber bin ehrlich gesagt, mit dem Ergebnis nicht zufrieden. Auf dem Bild sieht es einigermaßen in Ordnung aus, aber wenn man es bewegt sieht, erkennt man, dass es nicht exakt ist, und die Textur etwas "schwimmt". Naja, keinen Bock mehr, das bleibt jetzt erstmal so.

Interessant finde ich das ganze vor allem, wenn das ganze auch funktioniert, wenn als Basis keine Plane sondern zum Beispiel einen Sphäre benutzt wird... :)

Hab mal geschaut, ne also so richtig gehts nicht. Man sieht da dann auch schnell die ganzen Fehler und Macken... vielleicht sollte man das doch über Displacementmaps lösen... so oft kommen ja solche Materialien auch nicht vor...

Na super!
Hab mal probehalber displacementmapping über den VS gemacht und ( ist ja im moment alles ohne Effekte und Licht ) jetzt ist es nur eine Zeile Arbeit, statt ein ganzer Shader und um Fins oder sowas braucht man sich auch nicht kümmern und statt 200 FPS sind es jetzt um die 300... hmmm... da lohnt sich das Parallax Occlusion ja richtig.
(Die Risse innerhalb der Kugel kommen durch die Texturkoordinatensprünge an dieser Stelle)
@Schrompf
Ihr benutzt doch bei euch nur die normale Parallax Variante, oder war das auch Occlusion?

Mehrstufiges Parallax Mapping. Reicht aus für die meisten Blickwinkel und frisst keine Grafikkarten zum Frühstück

Displacement Mapping hat ein ganz schlechtes Kosten-Nutzen-Verhältnis. Man investiert Stunden in das Ding, und am Ende stellt man fest, dass in den meisten Fällen der Effekt ohnehin sehr subtil ist. Sogar einfaches Parallaxmapping genügt in den meisten Fällen.

Vor allem brauchte man damals im ASM-Code nur 3 Befehle fürs Parallax... also super Billig und hat dann auch schon einen sehr guten 3D-Effekt zur Folge.

Hallo euch allen!!

Ich möchte euch diesmal ein Video von dem Editor zeigen. Leider ist das Wasser und DOF vorerst nicht mehr drin... aber das kommt wieder. ;)
Bin auf eure Meinungen gespannt!!

http://www.youtube.com/watch?v=KiyA4hWHyBk

Gruß
Zudo

Sieht echt alles ganz nett aus, jedoch ist die Kameraführung zu hektisch.

Mfg
BS

Sehr nett, besonders die visuelle Gestaltung der Transformationsoperationen ist gut gelungen. Scalest du alle Texturen nach Weltausdehnung des Objekts anstatt vertexgebundener Texturkoordinaten? Ist mir bei der Mauer aufgefallen, dass die Texturausdehnung beim Scalen dieselbe bleibt, und die Textur stattdesen abgeschnitten wird.

@Kameraführung
Könnte sein, dass die etwas zu hektisch geworden ist. Wollte das nicht zu langsam machen, damit es nicht zu langweilig und träge wird. Ist mir wohl dann aber missglückt. :(

@Texturkoordinaten
Es ist für jedes Objekt wählbar, ob die Texurkoordinaten an der Welt ausgerichtet oder vom Objekt her benutzt werden.