Ich muss zugeben, beeindruckt zu sein. Du stellst mit diesem Artikel ein Niveau vor, welches für Developia in keinster Weise alltäglich ist. Auch scheint mir, werden sich zukünftigt Fachartikel mit deinem vergleichen lassen müssen.

Der Text selbst ist klar, übersichtlich und durchdacht strukturiert. Du führst logisch durch das Thema, ohne dass Gedankensprünge oder Unklarheiten auftreten würden. Auch die Darstellung simpler mathematischer Formeln kann ich an dieser Stelle nur begrüßen, da dies doch recht stark von den meisten bisherigen Artikeln alà "es ist eben so" abweicht und eine tiefere Materievertrautheit des Autors bestätigt.

Persönlich hätte ich mir abschließend einen Performancevergleich für diverse Referenzimplementierungen entsprechend gleichartiger Algorithmen gewünscht, um eine Deutung von "kleine zusätzliche Belastung" vornehmen zu können.

Zur Erheiterung und Auflockerung haben deine kleinen, wenngleich aber sehr amüsanten Rechtschreibfehler begetragen, wobei dies in diesem Falle nichtens negativ zu verstehen ist. " Integratierbarkeit" ist doch ein wunderbares Wort. Entsprechend ist bei einem solchen Thema ein derartiger Fehler aber mehr als zu verzeihen.

Im Fazit also ein überdurchschnittlich guter Artikel, welcher eine angemessen hohe Wertung verdient. Man würde sich wünschen mehr dergleichen auf Developia zu sehen, was aber wohl aufgrund der Klientel in keinster Weise umsetzbar ist.

Danke für Deine Anmerkungen. Die genannten Rechtschreibfehler sind etwas peinlich, aber nach dem xten Durchlesen wird man irgendwann betriebsblind.

Zur Performance: die "kleine zusätzliche Belastung" ist leider sehr stark von System und Szenario abhängig. Ein exemplarischer Vergleich war in den Beispielbildern zu sehen: 344fps ohne Verzerrung, 341 fps mit Verzerrung. Auf Grafikkarten mit 128Bit-Speicherbus oder mit langsameren Speicher wird der Unterschied wahrscheinlich größer sein. Falls eine sehr hoch unterteilte Szene zum Einsatz kommt, sodaß nicht mehr die Fragmentverarbeitung, sondern die Vertexverarbeitung der limitierende Faktor ist, werden die zur Verzerrung benötigten zusätzlichen VertexShader-Befehle ein Problem. Ich vermute für diesen Fall Performance-Einbußen von 10 bis 15%, je nach Komplexität der restlichen Vertexverarbeitung.

Einen direkten Vergleich zu den in der Einleitung genannten anderen Shadow Map-Methoden kann ich leider nicht bieten, da ich keine der Methoden implementiert hatte. Es wäre zwar schön zu wissen, ist mir aber momentan zuviel Arbeit.

Nochmals Danke für die guten Bewertungen.

Bye, Thomas

Wirklich interessanter Artikel. Leider fehlen mir noch die Grundlagen zum Shadow Mapping. Sobald ich in meinem Projekt so weit bin, dass ich mich an Schatten heranwagen kann, werde ich ihn mir sicher nochmal zu Gemüte führen.

Ansonsten muss ich sagen: Schade, dass der Developiabilderkompressionsteufel wieder zugeschlagen hat, und die Formeln recht häßlich aussehen lässt, aber das kann man wohl kaum dir zur Last legen.

Danke für den Artikel.

Ich habe allerdings noch folgendes "Verständnisproblem":

Du beschreibst eine Vorgehensweise, Schattentexturen auf eine gebene Betrachterperspektive zu optimieren.

Einer der Hauptvorteile von Schattentexturen im Vgl. zu Schattenschablonen ist aber ja, daß man sie unabhängig von der Betrachterperspektive verwenden kann, also eben auch nicht bei jedem Bildaufbau erneut berechnen muss, solange die schattenspendende Geometrie sich nicht verändert.

Die von Dir vorgeschlagene Methode zwingt zwar nicht zu einer frameweisen Neuberechnung, erhöht aber sicherlich die benötigte Updatefrequenz.

Insofern stellt sich natürlich die Frage, wie hoch diese benötigte Updatefrequenz nun letzlich sein mag. Wie weit darf sich die Kamera vom Berechnungszentrum entfernen, bis deine Methode kontraproduktiv wirkt?

nice :)

Ich habe noch nie mit Shadern gearbeitet, aber dafür kenn ich jetzt eine neue Methode, Schatten zu rendern und ich weiß auch gleich noch wie man das optimieren kann :D

Ich bin auf euer Projekt echt gespannt, wenn ihr dort schon so nette Techniken einbaut!