PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Thema "Softshadows"


Super-S
2006-06-06, 13:21:58
:rolleyes: Sufu habe ich genutzt.... aber für mich war nix Brauchbares dabei.

Kann mir jemand genau erklären, warum SS so Kacke aussieht in Spielen? Ich darf eine X1900XTX mein Eigen nennen. Somit kann ich SS aktivieren in Games...in Kombination mit AA+AF.

Soweit so Gut....

Nur sehen in FEAR & Hitman Blood Money, die SS so dermaßen Kacke aus.... ich kann es nicht beschreiben. Wenn ich "Harte" Schatten in Hitman aktiviere... bekomme ich richtig schöne Schatten... "In meinen Augen Weiche Schatten" ...alles sieht Gut aus. Wenn ich jedoch SS aktiviere...sehen die Schatten eklig Pixelig aus :|

In FEAR ist es genauso..... Mann spricht doch von weichen Schatten...oder?
Warum sehen die so schlecht aus?

Ist es HW-Bedingt, oder liegt in der Spiele-Implementierung?

Gast
2006-06-06, 13:24:20
Wenn ich mich nicht irre tritt dieser "Pixel-Fehler" mit aktivierten AA auf.

Gast
2006-06-06, 13:47:24
Gast[/POST]']Wenn ich mich nicht irre tritt dieser "Pixel-Fehler" mit aktivierten AA auf.Zumindest in Fear ist es so, dass die Softshadows mit aktiviertem AA ein wenig ausgefranste Ränder haben.

Super-S
2006-06-06, 13:48:49
Gast[/POST]']Zumindest in Fear ist es so, dass die Softshadows mit aktiviertem AA ein wenig ausgefranste Ränder haben.

wasn bockmist wenn dem so ist... :| ...werde es mal ausprobieren, den in Hitman ist es genauso.

:( Ich bin schwer Enttäuscht. Wisst ihr ob das HW-bedingt ist...oder per Software (Patch etc.) zu lösen ist?

Gast
2006-06-06, 13:51:50
Sehen die Softshadows bei dir ungefähr so aus? Ich zitiere mal aus einem anderen Thread...
Snoopy69[/POST]']@ tombman

So siehts mit ONLY Softshadows aus...

http://img72.imageshack.us/img72/1462/gut9fp.th.jpg (http://img72.imageshack.us/my.php?image=gut9fp.jpg)

Und so siehts mit Softshadows + AA 4x aus - einfach schrecklich ;(

http://img72.imageshack.us/img72/9631/sch6rf.th.jpg (http://img72.imageshack.us/my.php?image=sch6rf.jpg)

CCC (Cat. 6.2) steht auf default. Kann man da noch was schrauben?
Mit Softshadows + AA geht die oc´ec X1900 XT ganz schön in die Knie...
...

Gast
2006-06-06, 13:53:44
Die Softschatten in Hitman Blood Money sahen bei mir aber eigentlich ganz ok aus auf einer 7800GTX...

Super-S
2006-06-06, 13:57:54
Gast[/POST]']Die Softschatten in Hitman Blood Money sahen bei mir aber eigentlich ganz ok aus auf einer 7800GTX...

:cool: Ja, in FEAR ist es die Spitze! In Hitman sehen die HARTEN besser aus als die WEICHEN.... bei mir zu mindest :|

Coda
2006-06-06, 14:42:52
Es gibt nicht "die Softshadows". Da gibts tausend verschiedene Algorithmen.

Super-S
2006-06-06, 14:45:21
Coda[/POST]']Es gibt nicht "die Softshadows". Da gibts tausend verschiedene Algorithmen.

:) Das kann doch einem einfachen Gamer egal sein ;) ....mir gehts darum das sie so schlecht aussehen... wenn AA aktiv ist.

Warum ist das so?

Neomi
2006-06-06, 17:11:30
Super-S[/POST]']....mir gehts darum das sie so schlecht aussehen... wenn AA aktiv ist.

Warum ist das so?

Das liegt logischerweise an Problemen in der jeweiligen Implementierung der Softshadows. Es gibt keinen generellen Grund.

Super-S
2006-06-06, 17:20:55
Neomi[/POST]']Das liegt logischerweise an Problemen in der jeweiligen Implementierung der Softshadows. Es gibt keinen generellen Grund.

was denn genau? :) sry für meine Neugier.

Neomi
2006-06-06, 18:09:26
Super-S[/POST]']was denn genau? :)

Da ich nicht weiß, auf welche Art die Softshadows implementiert wurden, müßte ich mir das genauer ansehen. Da ich die genannten Spiele nicht habe, kann ich das nicht. Es gibt keinen "so und nicht anders"-Weg, deshalb gibt es keine generelle Ursache für solche Probleme.

Polydeukes
2006-06-07, 16:11:24
Wenn ihr schöne soft shadows sehen wollt dann kauft euch Condemned für die XBox 360.

Spasstiger
2006-06-07, 16:13:43
Polydeukes[/POST]']Wenn ihr schöne soft shadows sehen wollt dann kauft euch Condemned für die XBox 360.
Das ist auch nur die gleiche Engine wie in Fear, ergo werden dort auch die gleichen Softshadows verwendet.

Coda
2006-06-07, 16:17:12
Das ist nicht gesagt.

del_4901
2006-06-07, 16:19:04
Coda[/POST]']Das ist nicht gesagt.
Da kommt mir wieder mal einer zuvor ... Oller ForumJunkie ^^

*unterschreib*

Polydeukes
2006-06-07, 16:50:08
Spasstiger[/POST]']Das ist auch nur die gleiche Engine wie in Fear, ergo werden dort auch die gleichen Softshadows verwendet.

Thief III verwendet ja auch die Unreal II Engine, hat aber Effekte (Bloom, Normal Mapping etc.), die Unreal II nicht hat. Dass die gleiche Engine verwendet wird heisst nicht, dass alle Spiele die auf dieser Engine basieren gleich gut aussehen.

Gast
2006-06-07, 17:24:41
Spasstiger[/POST]']Das ist auch nur die gleiche Engine wie in Fear, ergo werden dort auch die gleichen Softshadows verwendet.Die ausgefransten Schattenränder bei Nutzung von MSAA sind dort aber nicht vorhanden.

Gast
2006-06-07, 17:33:22
Super-S[/POST]']:rolleyes: Sufu habe ich genutzt.... aber für mich war nix Brauchbares dabei.

http://www.forum-3dcenter.de/vbulletin/showthread.php?t=181705

tokugawa
2006-06-07, 19:58:39
Super-S[/POST]']:) Das kann doch einem einfachen Gamer egal sein ;) ....mir gehts darum das sie so schlecht aussehen... wenn AA aktiv ist.

Warum ist das so?

Nein, das ist eben nicht egal, weil die SoftShadow-Algorithmen in verschiedenen Spielen auch anders sind und verschieden-gute Resultate erzeugen.

Daher kann man eben nicht von "Warum schauen SoftShadows so schlecht aus" reden, weil man da eine ganze Gruppe an Algorithmen in einen Topf wirft, die komplett anders aussehen.


In der Regel gilt aber dass Softshadows bei Shadow Volumes (wie sie z.B. FEAR verwendet) schwerer zu implementieren sind und auch nicht so leicht "gut" ausschauen.

Bei Shadowmapping dagegen ist es relativ einfach, einen rudimentären Soft-Shadow-Algorithmus einzubauen. Will man's noch realistischer (verschiedener "Softing-Level" abhängig von der Distanz zum Shadow-Caster), kann man das auch hier relativ leicht einbauen (auch wenn's sehr viel Performance kostet bei den derzeitig bekannten Algorithmen).


Wenn man so eine Frage stellt, dann muß man sich darauf einstellen dass man auch eine technisch versierte Antwort bekommt - die Ausrede "ich bin gamer, ich will von technik nix wissen aber sagt mir trotzdem warum die Softshadows so sch* aussehen" ist ganz einfach... ungültig :)

Polydeukes[/POST]']Thief III verwendet ja auch die Unreal II Engine, hat aber Effekte (Bloom, Normal Mapping etc.), die Unreal II nicht hat. Dass die gleiche Engine verwendet wird heisst nicht, dass alle Spiele die auf dieser Engine basieren gleich gut aussehen.

Yep, und was hier noch dazukommt ist dass Thief III eigentlich die Deus Ex 2 Engine benutzt, die wiederum eine modifizierte Unreal II Engine ist. Der Schattenalgorithmus in Deus Ex 2 und Thief III wurde extra für diese Spiele implementiert und sind nicht von der Unreal II Engine.

del_4901
2006-06-07, 22:11:31
Softshadows mit Stencil Shadow Volumes sind praktisch für eine SW wie Spiele performancetechnisch nicht tragbar, da man ettliche Readbacks aus dem Stencilbuffer machen müsste. Mal ganz abgesehen davon das die Volumes eine Speziallität für sich darstellen.

Mit einem GS kann ich mir gut vorstellen, das sich die Situation ändern wird, aber zurzeit wage ich zu bezweifeln das Softshadows irgendwo auf SS-Volumes basieren.

IceLord
2006-06-07, 22:25:55
Was ist eigentlich mir der Technik? Rendering Fake Soft Shadows with Smoothies (http://people.csail.mit.edu/ericchan/papers/smoothie/) Warum wird die noch nicht eingesetzt? Scheint ja recht schnell zu sein und sieht echt gut aus. Ausserdem ist der Schatten näher beim Objekt auch schärfer und es wird nicht einfach der ganze Schatten 'geblurt'.

Gast
2006-06-07, 22:47:44
AlphaTier[/POST]']Mit einem GS kann ich mir gut vorstellen, das sich die Situation ändern wird, aber zurzeit wage ich zu bezweifeln das Softshadows irgendwo auf SS-Volumes basieren.In Fear und Condemned tun sie dies aber. Allerdings kostet sie dort auch wirklich pervers viel Leistung.

del_4901
2006-06-07, 22:59:06
Gast[/POST]']In Fear und Condemned tun sie dies aber. Allerdings kostet sie dort auch wirklich pervers viel Leistung.

Nur weil einige andere Shadows SS-Volumes sein mögen heißt das noch lange nicht das es auch die SoftShadows sind. Softshadows mit Volumes sind zum jetzigen Zeitpunkt einfach nicht tragbar, da man entweder Redbacks auf den Stencilbuffer machen muss, oder man ettliche Zusatzpasses fährt, das macht kein Dev, auch nicht zum Spass. (noch nicht)
Softshadows mit Shadowmaps sind um ein vielfaches leichter zu implementieren und auch wesentlich schneller. Zudem sieht es (wenn man es richtig anstellt) genausogut aus.
Also entweder du lieferst mir Fakten, bevor ich dir glaube, oder du wirst wohl mir glauben müssen.

tokugawa
2006-06-08, 16:32:41
AlphaTier[/POST]']Softshadows mit Stencil Shadow Volumes sind praktisch für eine SW wie Spiele performancetechnisch nicht tragbar, da man ettliche Readbacks aus dem Stencilbuffer machen müsste. Mal ganz abgesehen davon das die Volumes eine Speziallität für sich darstellen.

Mit einem GS kann ich mir gut vorstellen, das sich die Situation ändern wird, aber zurzeit wage ich zu bezweifeln das Softshadows irgendwo auf SS-Volumes basieren.

Ich wiederhole mich, aber selbst für Shadow Volumes gibt es nicht nur einen SoftShadow-Algorithmus, und auch nicht "DEN" SoftShadow-Algorithmus.

Es lassen sich bei Shadow Volumes auch Techniken einsetzen wo man ohne Readbacks aus dem Stencil Buffer auskommt.

Etwa wenn man im Image-Space blurrt - was nicht korrekt ist natürlich, aber die wenigsten in Echtzeit vernünftig schnell laufenden Softshadow-Algorithmen - auch nicht die Shadowmapping-basierten - sind wirklich korrekt.

Andere Möglichkeit (die ich in FEAR vermute), ist ein Rendern von leicht versetzten Schattenvolumen, und Zusammenblenden der Ergebnisse im Image-Space. Dadurch sind die Softshadows in FEAR nicht wirklich "Soft", aber zumindest haben sie eine Penumbra.

Es gibt ein NVIDIA-Paper von der I3D wo die einen ziemlich guten Soft-Shadow-Algorithmus für Shadowmapping präsentieren, bei dem abhängig von der Distanz zum Schattenwerfer geblurrt wird. Das schaut ziemlich überzeugend aus, braucht aber wahnsinnig viele Texel-Lookups (und eventuell sogar Dynamic Branching, wenn ich mich nicht irre), und ist in einem Spiel-Szenario eher selten einsetzbar, da es zuviel Performance frißt. Aber irgendwann mal...

Egal, was der Punkt ist, das in FEAR sind Softshadows mit Shadow Volumes, nur halt womöglich nicht der Softshadow-Algorithmus den du meinst, aber es gibt halt viele verschiedene in verschiedener Qualität. Dass mit SVs Softshadows prinzipbedingt schwerer sind, ist ja klar.

del_4901
2006-06-08, 20:57:38
Dann liefer mir Fakten ... wo man nachforschen kann.

- Image Space bluren ist ja wohl mal lol ... vorallem bei Volumes

- versetzte Lichter ... das Ding ist so alt das hat schon nen Bart ... schneller wirds dadurch auch nicht, weil es extremes Multipassing vorraussetzt.

- der Algo von Yury (Nvidia) basiert auf Shadowmaps. Den hab ich hier sogar vor mir in meinen Gems2 liegen. Der ist ganz ok... aber wie du schon sagtest Shadowmaps ... nicht Volumes

Vermuten bzw. glauben kannst du in der Kirche ... ich will harte Fakten!

tokugawa
2006-06-08, 22:34:57
AlphaTier[/POST]']Dann liefer mir Fakten ... wo man nachforschen kann.

- Image Space bluren ist ja wohl mal lol ... vorallem bei Volumes



Image Space blurren ist durchaus eine valide Technik. Natürlich renderst du dann den Schatten in einen reinen Schattenbuffer, und blurst das dann.

Natürlich gibt's da ein paar Probleme (shadow bleeding), aber nichts was man nicht lösen könnte.

Im Übrigen ist das Shadow-Buffer-blurren im Image-Space eine Technik die auch bei Shadowmapping vorgeschlagen wird ([1]). Das kann man für alle Schattentechniken einsetzen, denn wie der Schatten generiert wurde, ist für den Image-Space-Blur egal.



- versetzte Lichter ... das Ding ist so alt das hat schon nen Bart ... schneller wirds dadurch auch nicht, weil es extremes Multipassing vorraussetzt.


Wer redet von schnell? Aber das ist die Technik die FEAR meines Wissens nach einsetzt. Sieht zumindest so aus.

Langsamer als non-soft-Shadows werden Softshadows immer


- der Algo von Yury (Nvidia) basiert auf Shadowmaps. Den hab ich hier sogar vor mir in meinen Gems2 liegen. Der ist ganz ok... aber wie du schon sagtest Shadowmaps ... nicht Volumes


Worum es mir ging ist, dass auch bei Shadowmapping Softshadows sehr sehr viel kostet


Vermuten bzw. glauben kannst du in der Kirche ... ich will harte Fakten!

Sh. auch [1] und die Referenzen darin. Daniel Scherzer hat zusammen mit Michael Wimmer (sieh mal in GPU Gems 2 bei den Autoren nach) auch das Paper über Light-Space-Perspective-Shadowmaps geschrieben. Ich glaub die zwei können durchaus davon reden, Kenner von Schattentechniken zu sein.

Die einzige Vermutung meinerseits war die genaue Soft-Shadow-Technik, die FEAR verwendet. Das wirst auch du nur vermuten können, außer du hast Zugang zum Source Code (oder sie haben es in einem Paper publiziert, obwohl diese häßlichen Softshadows meiner Meinung nach nicht publikationswürdig sind).

Also bevor du hier irgendwen beschuldigst "zu glauben" oder "zu vermuten", täte ich dir empfehlen ein bisserl selbst Recherche zu machen (= wissenschaftliches Arbeiten, zumindest ein Teil davon). Ich denke, dass das, was ich im vorigen Posting schrieb, sicher nicht falsch ist.

Was genau willst du eigentlich? Es ist doch klar dass Softshadows eine Schwachstelle von Shadow Volumes sind (deren Domäne sind harte Schatten). Trotzdem verwendet FEAR Shadow Volumes, und versucht sich daran, Softshadows dort hinzukriegen mit einer Brute-Force-Methode.


[1] Daniel Scherzer: "Robust shadowmapping of large environments"

del_4901
2006-06-08, 22:42:58
tokugawa[/POST]']Image Space blurren ist durchaus eine valide Technik. Natürlich renderst du dann den Schatten in einen reinen Schattenbuffer, und blurst das dann.

Natürlich gibt's da ein paar Probleme (shadow bleeding), aber nichts was man nicht lösen könnte.

Im Übrigen ist das Shadow-Buffer-blurren im Image-Space eine Technik die auch bei Shadowmapping vorgeschlagen wird ([1]). Das kann man für alle Schattentechniken einsetzen, denn wie der Schatten generiert wurde, ist für den Image-Space-Blur egal.




Wer redet von schnell? Aber das ist die Technik die FEAR meines Wissens nach einsetzt. Sieht zumindest so aus.

Langsamer als non-soft-Shadows werden Softshadows immer



Worum es mir ging ist, dass auch bei Shadowmapping Softshadows sehr sehr viel kostet



Sh. auch [1] und die Referenzen darin. Daniel Scherzer hat zusammen mit Michael Wimmer (sieh mal in GPU Gems 2 bei den Autoren nach) auch das Paper über Light-Space-Perspective-Shadowmaps geschrieben. Ich glaub die zwei können durchaus davon reden, Kenner von Schattentechniken zu sein.

Die einzige Vermutung meinerseits war die genaue Soft-Shadow-Technik, die FEAR verwendet. Das wirst auch du nur vermuten können, außer du hast Zugang zum Source Code (oder sie haben es in einem Paper publiziert, obwohl diese häßlichen Softshadows meiner Meinung nach nicht publikationswürdig sind).

Also bevor du hier irgendwen beschuldigst "zu glauben" oder "zu vermuten", täte ich dir empfehlen ein bisserl selbst Recherche zu machen (= wissenschaftliches Arbeiten, zumindest ein Teil davon). Ich denke, dass das, was ich im vorigen Posting schrieb, sicher nicht falsch ist.

Was genau willst du eigentlich? Es ist doch klar dass Softshadows eine Schwachstelle von Shadow Volumes sind (deren Domäne sind harte Schatten). Trotzdem verwendet FEAR Shadow Volumes, und versucht sich daran, Softshadows dort hinzukriegen mit einer Brute-Force-Methode.


[1] Daniel Scherzer: "Robust shadowmapping of large environments"

Ähm ok, Du weißt aber das ich bei Shadowmaps .. den Schatten zeichne ... bei volumes aber das was nicht im Schatten liegt .... wie soll ich denn da bitteschoen im Imagespace was bluren? Soll mir schoen meine Grafik Matschig machen oder wie?

Und du hast immernoch nicht genannt, wo du das genau her hast das FEAR Shadow Volumes mit SoftShadows verwendet. Ich würde gern mal die Quelle haben, denn vermuten kann Jeder.

BTW: kewl du hast das Buch auch, wie findest du es?

tokugawa
2006-06-08, 22:49:43
AlphaTier[/POST]']Ähm ok, Du weißt aber das ich bei Shadowmaps .. den Schatten zeichne ... bei volumes aber das was nicht im Schatten liegt .... wie soll ich denn da bitteschoen im Imagespace was bluren? Soll mir schoen meine Grafik Matschig machen oder wie?


Du kannst den reinen Schattenanteil (ohne den Szeneanteil) in einen separaten Buffer rendern. Entweder über einen separaten Pass (nur Schatten rausschreiben), oder über Multiple Render Targets.

Das ist quasi eine Variante von Deferred Shading, da man die ganzen Sachen am Schluß dann im Image-Space kombiniert.


Und du hast immernoch nicht genannt, wo du das genau her hast das FEAR Shadow Volumes mit SoftShadows verwendet. Ich würde gern mal die Quelle haben, denn vermuten kann Jeder.


Das steht am Packungstext auf der FEAR-Verpackung:
Spektakuläre DirectX 9-Grafiktechnologie mit Per-Pixel-Lighting, Shadow Volumes, Normal Mapping und Shader-Nutzung.

Zufrieden?


BTW: kewl du hast das Buch auch, wie findest du es?

Für mich war's ein Pflichtkauf, da Michael Wimmer sozusagen mein Diplomarbeitsbetreuer ist (zumindest einer der offiziellen Betreuer). Der "Coherent Hierarchical Culling"-Algorithmus aus GPU Gems 2 stammt ja aus unserem Institut.

Ich find das Buch ziemlich gut, geht auf sehr viele verschiedene Arten der "GPU-Vergewaltigung" ein :) Die "Shader X" Serie find ich auch ziemlich gut (auch wenn sie weniger wissenschaftlich angelegt ist - dafür ist sie "praxisnaher").

del_4901
2006-06-08, 22:55:14
tokugawa[/POST]']Du kannst den reinen Schattenanteil (ohne den Szeneanteil) in einen separaten Buffer rendern. Entweder über einen separaten Pass (nur Schatten rausschreiben), oder über Multiple Render Targets.

Das ist quasi eine Variante von Deferred Shading, da man die ganzen Sachen am Schluß dann im Image-Space kombiniert.



Das steht am Packungstext auf der FEAR-Verpackung:


Ähm nur das ich dann eine Fehlerhafte Beleuchtung bekomme ... Ich bin auch schon auf die Idee gekommen, anstatt nicht zu zeichnen dunkelst du mal ab ... das sieht aber scheisse aus, weil man Glanzpunkte bekommt, wo keine sein sollten.

Und wenn ich den Schatten wie du vorschlägst in eine Textur oder Rendertarget rendere ... dann kann ich gleich Shadowmaps nehmen und mir die Volumes sparen ... das läuft dann nämlich aufs gleiche hinaus ... wobei ich mir eigendlich richtig ins Knie schieße, da ich die Textur von meinem Augpunkt auf alle Objekte Projektieren muss ... neue Texturen für jedes Objekt anlegen, damit ich in den Shadern was zum rechnen habe.


Naja da steht aber auch nicht SoftShadow Volumes.

tokugawa
2006-06-08, 23:56:08
AlphaTier[/POST]']Ähm nur das ich dann eine Fehlerhafte Beleuchtung bekomme ... Ich bin auch schon auf die Idee gekommen, anstatt nicht zu zeichnen dunkelst du mal ab ... das sieht aber scheisse aus, weil man Glanzpunkte bekommt, wo keine sein sollten.


Wovon sprichst du? Hast du etwa komplett schwarze Schattenbereiche?

AlphaTier[/POST]']
Und wenn ich den Schatten wie du vorschlägst in eine Textur oder Rendertarget rendere ... dann kann ich gleich Shadowmaps nehmen und mir die Volumes sparen ... das läuft dann nämlich aufs gleiche hinaus ...


Nicht wirklich. Ist ja nicht dasselbe wie Shadow Mapping, und läuft auch nicht auf's gleiche hinaus. Sondern ist ein einfacher Postprocess-Schritt, den du eigentlich überall in einer Render-Pipeline einführen kannst.

Shadow Mapping ist im Prinzip ein projektiver Lichtquellen-Occlusion-Check, das wovon ich rede ist ein echter Fullscreen-Quad-Postprocess.

AlphaTier[/POST]']
wobei ich mir eigendlich richtig ins Knie schieße, da ich die Textur von meinem Augpunkt auf alle Objekte Projektieren muss ... neue Texturen für jedes Objekt anlegen, damit ich in den Shadern was zum rechnen habe.


Häh? Du machst dasselbe wie Render-to-Texture, nur dass du die Beschattung als 0.0f..1.0f-Werte speicherst, und erst später mit der eigentlichen (unbeschatteten) Szene kombinierst. Da mußt du nichts projezieren, sondern die einzelnen Szenekomponenten hast du dann als Fullscreen-Quad. Das ist das gleiche Prinzip wie beim Deferred Shading (sh. den Artikel über Deferred Shading in Stalker in GPU Gems 2).

AlphaTier[/POST]']
Naja da steht aber auch nicht SoftShadow Volumes.

Du kannst mir glauben dass es keinen Spaß macht, Shadow Mapping UND Shadow Volumes in eine Engine zu quetschen (gut, ich hasse Renderpfad-artige Strukturen sowieso). Es macht keinen Sinn, wenn sie für die Soft-Shadows Shadowmapping verwenden, wenn sie schon Shadow Volumes haben (bzw. wär es einiges an Mehraufwand).

Es geht auch anders: schau dir einfach mal die Bilder von den sogenannten "Soft-Shadows" in FEAR an. Das Zeug sind Shadow-Volumes, das kann man mit ziemlicher Sicherheit aus den Bildern heraussehen.

del_4901
2006-06-09, 00:05:35
tokugawa[/POST]']Wovon sprichst du? Hast du etwa komplett schwarze Schattenbereiche?



Nicht wirklich. Ist ja nicht dasselbe wie Shadow Mapping, und läuft auch nicht auf's gleiche hinaus. Sondern ist ein einfacher Postprocess-Schritt, den du eigentlich überall in einer Render-Pipeline einführen kannst.

Shadow Mapping ist im Prinzip ein projektiver Lichtquellen-Occlusion-Check, das wovon ich rede ist ein echter Fullscreen-Quad-Postprocess.



Häh? Du machst dasselbe wie Render-to-Texture, nur dass du die Beschattung als 0.0f..1.0f-Werte speicherst, und erst später mit der eigentlichen (unbeschatteten) Szene kombinierst. Da mußt du nichts projezieren, sondern die einzelnen Szenekomponenten hast du dann als Fullscreen-Quad. Das ist das gleiche Prinzip wie beim Deferred Shading (sh. den Artikel über Deferred Shading in Stalker in GPU Gems 2).



Du kannst mir glauben dass es keinen Spaß macht, Shadow Mapping UND Shadow Volumes in eine Engine zu quetschen (gut, ich hasse Renderpfad-artige Strukturen sowieso). Es macht keinen Sinn, wenn sie für die Soft-Shadows Shadowmapping verwenden, wenn sie schon Shadow Volumes haben (bzw. wär es einiges an Mehraufwand).

Es geht auch anders: schau dir einfach mal die Bilder von den sogenannten "Soft-Shadows" in FEAR an. Das Zeug sind Shadow-Volumes, das kann man mit ziemlicher Sicherheit aus den Bildern heraussehen.

Wenn du den Schatten über das fertige Bild zeichnest, hast du vorher schon die Stellen beleuchtet, die eigendl. nicht beleuchtet werden sollen. Man muss die Beleuchtung abhänig vom Schatten machen den kann man nicht einfach Später drüber zeichnen, das wird immer falsch ... Sieht vllt. toll aus aber wenn man genau hinschaut sieht man, das hier was nicht stimmt.


Ich hab leider auf meinem Rechner hier kein FEAR installiert, um das jetzt nochmal nachvollziehen zu können. Ich hätte trotzdem aber gerne eine Aussage von den Entwicklern dazu.

BTW: jede gute Engine sollte alle zur Verfügung stehenden Schattentechniken miteinander komibieren, um ein Maximum an Quallität und Leistung rauszuhohlen. ... z.B sind nicht geblurte Shadowmaps meißens unschoen, und wenn man nicht mit einem Bias die Genauigkeit anpasst flimmert es auch geil. Wenn man die Maps aber schoen blurt, ist das nichtmehr so schlimm.

del_4901
2006-06-09, 00:16:33
BTW: geile Diskussion hier .... ich hatte grad eine gute Idee

*aufkritzel* Da muss ich gleich mal ausprobiern ... funktioniert aber weder nach deiner noch nach irgendeiner anderen Methode die mir bekannt währe.

tokugawa
2006-06-09, 00:18:37
AlphaTier[/POST]']Wenn du den Schatten über das fertige Bild zeichnest, hast du vorher schon die Stellen beleuchtet, die eigendl. nicht Beleuchet werden sollen. Man muss die Beleuchtung abhänig vom Schatten machen den kann man nicht einfach Später drüber zeichnen, das wird immer falsch ... Sieht vllt. toll aus aber wenn man genau hinschaut sieht man, das hier was nicht stimmt.


1. ist das kein Problem. Du kannst die Beleuchtung auch abhängig davon machen ob das Fragment beschattet ist oder nicht. Beim Deferred Shading kein Problem. Außerdem multiplizierst du sowieso im einfachsten Fall jeweils mit dem Shadow-Texel, da hast du schon eine "vom Schatten abhängige Beleuchtung". Im komplizierteren Fall kannst du das auch mit einer anderen Formel abhängig machen. Jedenfalls hast du einen Shadow-Factor per Pixel, es ist also kein Unterschied zu normalen Beschattungstechniken, außer dass du den Schattenterm in eine separate Textur renderst.

2. Wenn's toll aussieht -> Mission erfüllt. In der Echtzeitgrafik von Realismus zu sprechen finde ich sowieso verkehrt. Authentisch und gut muß es aussehen, "Realismus" ist sekundär. Aber das ist nur meine Meinung.


AlphaTier[/POST]']
Ich hab leider auf meinem Rechner hier kein FEAR installiert, um das jetzt nochmal nachvollziehen zu können. Ich hätte trotzdem aber gerne eine Aussage von den Entwicklern dazu.


Tja, über Google finde ich hier nichts. Kommt aber vielleicht eh noch.

AlphaTier[/POST]']
BTW: jede gute Engine sollte alle zur Verfügung stehenden Schattentechniken miteinander komibieren, um ein Maximum an Quallität und Leistung rauszuhohlen. ...


... jein, weil:

AlphaTier[/POST]']
z.B sind nicht geblurte Shadowmaps meißens unschoen, und wenn man nicht mit einem Bias die Genauigkeit anpasst flimmert es auch geil. Wenn man die Maps aber schoen blurt, ist das nichtmehr so schlimm.

Das ist ein schlechtes Beispiel, weil ich diese "Techniken" alle zu einer Technik (Shadowmapping) zähle. Das ist klar, dass man hier eine gewisse Skalierbarkeit hat und zuschaltbare Shadowmapping-basierte Tidbits.

Aber: Shadow Volumes und Shadow Mapping in eine Engine zu quetschen bedeutet eigentlich zwei verschiedene Renderpfade (bzw. verschiedene Multi-Pass-Abfolge). Klar wär eine Flexibilität super, aber in der Praxis reicht eine der beiden Algorithmen, und innerhalb dieser halt alles was man so kennt (z.B. Light-Space-Perspective-Shadowmapping).

Wenn man zuviel in eine Engine quetscht, wird diese sehr schnell unwartbar, wenn man nicht aufpasst.

Die meisten kommerziellen Engines benutzen sowieso nur entweder Shadowmapping oder Shadowvolumes, nicht beides.

Außerdem sehe ich die "Qualität" einer Engine sowieso eher im Content-Bereich, d.h. wie gut die Toolchain verzahnt ist, und wie benutzbar die Tools sind (weil das hat wirklich einen Einfluß auf die Qualität des Gesamtspiel - Grafiktechnik allein ist nutzlos wenn die Artists dieses Potential nicht bequem nutzen können). Aber das ist eine andere Geschichte.

del_4901
2006-06-09, 00:26:15
tokugawa[/POST]']1. ist das kein Problem. Du kannst die Beleuchtung auch abhängig davon machen ob das Fragment beschattet ist oder nicht. Beim Deferred Shading kein Problem. Außerdem multiplizierst du sowieso im einfachsten Fall jeweils mit dem Shadow-Texel, da hast du schon eine "vom Schatten abhängige Beleuchtung". Im komplizierteren Fall kannst du das auch mit einer anderen Formel abhängig machen. Jedenfalls hast du einen Shadow-Factor per Pixel, es ist also kein Unterschied zu normalen Beschattungstechniken, außer dass du den Schattenterm in eine separate Textur renderst.

2. Wenn's toll aussieht -> Mission erfüllt. In der Echtzeitgrafik von Realismus zu sprechen finde ich sowieso verkehrt. Authentisch und gut muß es aussehen, "Realismus" ist sekundär. Aber das ist nur meine Meinung.


Ja, du dunkelst den Pixel aber auch nur ab ... Speculare Glanzlichter eleminierst du damit nicht ... der Schatten ist so als währe er duch eine "Dunkele Scheibe" entstanden. Die Glanzlichter müssen weg also darf ich nur Beleuchten, nachdem ich weiß wo Schatten ist ... und nicht vorher.

So einen Postfilter könnte man Außerhalb des Sichtfeldes machen ... aber nicht mittig im Bild.

Neomi
2006-06-09, 00:33:59
AlphaTier[/POST]']Ja, du dunkelst den Pixel aber auch nur ab ... Speculare Glanzlichter eleminierst du damit nicht ... der Schatten ist so als währe er duch eine "Dunkele Scheibe" entstanden. Die Glanzlichter müssen weg also darf ich nur Beleuchten, nachdem ich weiß wo Schatten ist ... und nicht vorher.

Man kann machen, was man will, man ist nicht auf die schlechteste Möglichkeit angewiesen. Über MRTs kann man z.B. einmal die Szene voll beleuchtet in ein Rendertarget rendern, komplett im Schatten in ein anderes Rendertarget und den Schatten in ein weiteres. Dann bearbeitet man den Schatten passend und in einem weiteren Schritt (per Fullscreen-Quad) macht man pro Pixel einen Lerp zwischen den beiden unterschiedlich beleuchteten Szenen mit dem bearbeiteten Schatten als Lerpfaktor. Nur eine simple Möglichkeit, die mir auf Anhieb einfällt, die abgedunkelten Glanzlichter im Schatten gibt es dabei aber schon gar nicht mehr.

del_4901
2006-06-09, 00:37:40
Neomi[/POST]']Man kann machen, was man will, man ist nicht auf die schlechteste Möglichkeit angewiesen. Über MRTs kann man z.B. einmal die Szene voll beleuchtet in ein Rendertarget rendern, komplett im Schatten in ein anderes Rendertarget und den Schatten in ein weiteres. Dann bearbeitet man den Schatten passend und in einem weiteren Schritt (per Fullscreen-Quad) macht man pro Pixel einen Lerp zwischen den beiden unterschiedlich beleuchteten Szenen mit dem bearbeiteten Schatten als Lerpfaktor. Nur eine simple Möglichkeit, die mir auf Anhieb einfällt, die abgedunkelten Glanzlichter im Schatten gibt es dabei aber schon gar nicht mehr.

Und das für jede Lichtquelle ^^ Jeeppeeee

Neomi
2006-06-09, 01:49:10
AlphaTier[/POST]']Und das für jede Lichtquelle ^^ Jeeppeeee

Welche Komponenten des Bildes man jetzt in welches Rendertarget rendert, bleibt einem doch frei überlassen. Das Prinzip funktioniert jedenfalls.

Bei D3D10 sind 8 MRTs möglich. Damit könntest du 1x nur das Ambientlight rendern und 5x alleine den Anteil einer zusätzlichen Lichtquelle. Damit hättest du noch 2 RTs übrig, bei je 4 Komponenten sind also genug monochrome Kanäle für die Schatten der 5 Lichtquellen drin. Bei noch mehr Lichtern muß man dann auch Multipass umsteigen, das geht auch.

Ein weiterer Weg wäre Deferred Shading per G-Buffer, damit ist dann auch wirklich schon einiges machbar.

tokugawa
2006-06-09, 01:54:17
AlphaTier[/POST]']Ja, du dunkelst den Pixel aber auch nur ab ... Speculare Glanzlichter eleminierst du damit nicht ... der Schatten ist so als währe er duch eine "Dunkele Scheibe" entstanden. Die Glanzlichter müssen weg also darf ich nur Beleuchten, nachdem ich weiß wo Schatten ist ... und nicht vorher.


Überleg doch mal. Klar, wenn du den ENDPIXEL multiplizierst mit dem Schattenfaktor, dann dunkelst du nur ab.

Aber du hast diesen Schattenfaktor ja. Du kannst ihn genauso mit dem Spekulärterm multiplizieren. Dann hast du keine spekulären Glanzlichter im Schatten mehr.

Wenn der Schatten zwischen 0.0f (voll im Schatten) und 1.0f (total nicht im Schatten) kodiert ist, und du den Spekuläranteil damit multiplizierst, hast du im Schatten 0, also schwarz. Da du den Ambient-Anteil sowieso separat hast, kannst du damit genau das machen was du willst (also keine Specular Hightlights im Schatten).

Sprich: willst du keine specular highlights im Schatten, dann tu sie einfach nicht dazu :) Das ist trotz eigenem Shadowbuffer kein Problem.

AlphaTier[/POST]']
So einen Postfilter könnte man Außerhalb des Sichtfeldes machen ... aber nicht mittig im Bild.

Wovon redest du? Ein Postprocess-Filter/Effekt ist immer ein Ganzbildeffekt per Pixel im Image-Space.

EDIT: Ah, meinst du vielleicht mit "außerhalb des Sichtfeldes" = in einen Offscreen-Buffer? Ich mein, klar, was denn sonst.

AlphaTier[/POST]']Und das für jede Lichtquelle ^^ Jeeppeeee

Schatten mußt du sowieso für jede Lichtquelle einzeln rendern. Den Gesamt-Schattenanteil akkumulierst du im Schattenbuffer. Und erst dann wenn du das alles hast, machst du einen Postprocess-Blur drüber.

Der O-Aufwand ist jedenfalls derselbe: O( n) mit n... Anzahl der Lichtquellen

Das kann man außerdem noch optimieren indem man z.B. einen Depth-First-Pass macht und Early-Z ausnutzt (wenn möglich). Damit reduziert man dann effektiv den Overdraw (was man bei Deferred Shading sowieso gern hat, ist zumindest eines der Hauptziele).

del_4901
2006-06-09, 02:14:33
Wir reden gard ein bissel aneinander vorbei tokugawa, das was du da gerade beschreibst ist kein Postprocessing mehr wie anfangs beschrieben. Das fällt mehr in die Kategorie Pre-Processing oder Deferred Shading.

Jedenfalls hab ich gerade "Wissenschaftlich gearbeitet" Und alle meine dicken Schinken auf den Kopf gestellt. Und bin dabei in meiner letzten Anschaffung auf einen interessanten Artikel von Hugh Malan und Mike Weiblein gestoßen. Es handelt sich hierbei um einen Deferred Shading Ansatz zum Rendern von Softshadows mithilfe von Volumes. Es wird allerdings nicht der Imagespace geblurt (was bei Volumes wie ich bereits erwähnte keinen Sinn ergibt) sondern die "Weiche des Schattens" über eine LUT in 2 Passes ermittelt. Das Tolle dran ist, das ich alle Lightpasses zu einem verschmelzen kann.
Ich werde mich jetzt erstmal ranmachen und praktisch tätig werden. Um die Grenzen auszuloten. Ich hatte eine ähnliche Idee, weitaus weniger komplex, dafür aber nicht so akkurat und Ellegant wie hier beschrieben.

Mehr dazu findet ihr im "OGL Orange Book" as "OpenGL Shading Language SE"

Die beiden Ansätze in den letzten beiden Posts fressen mir zuviel GFX-Speicher ... nicht das er rar währe, aber ich habe besseres damit vor als alle meine FBOs zu befüllen.

tokugawa
2006-06-09, 02:23:40
AlphaTier[/POST]']Wir reden gard ein bissel aneinander vorbei tokugawa, das was du da gerade beschreibst ist kein Postprocessing mehr wie anfangs beschrieben. Das fällt mehr in die Kategorie Pre-Processing oder Deferred Shading.


"Post-Processing" vom Schattenpass in den Schattenbuffer. Klarerweise nicht der finale Szene-Post-Processing.

Also ja, wir können korinthenkacken und sagen es ist eigentlich "mid-processing". Aber das ist egal, weil es mir auf diese KLASSE an Filter-Blur-Techniken ankam.

Dass es eine Variante von Deferred Shading ist, schrieb ich in einer der ersten Postings.

AlphaTier[/POST]']
Jedenfalls hab ich gerade "Wissenschaftlich gearbeitet" Und alle meine dicken Schinken auf den Kopf gestellt. Und bin dabei in meiner letzten Anschaffung auf einen interessanten Artikel von Hugh Malan und Mike Weiblein gestoßen. Es handelt sich hierbei um einen Deferred Shading Ansatz zum Rendern von Softshadows mithilfe von Volumes. Es wird allerdings nicht der Imagespace geblurt (was bei Volumes wie ich bereits erwähnte keinen Sinn ergibt)


Du hast immer noch nicht bewiesen wieso es keinen Sinn ergeben sollte. Ich hab hier eine funktionierende Implementation. Es funktioniert, glaub mir. Wird in der Literatur auch mehrfach erwähnt.

Wieso sollte es nicht funktionieren? Wenn du den reinen Schattenanteil der Szene in einen Buffer renderst, und erst im finalen Kombinier-Pass den tatsächlichen Szene-Pixel auswirfst (und nämlich dort die Beleuchtungsberechnung machst -> d.h. du hast eben nicht die specular highlights im Schatten), dann ist das genau Deferred Shading.

Bloß dass Deferred Shading sich normal nicht auf die Schatten beziehen, aber Deferred Shading ist ja nur ein Oberbegriff.

AlphaTier[/POST]']
sondern die "Weiche des Schattens" über eine LUT in 2 Passes ermittelt. Das Tolle dran ist, das ich alle Lightpasses zu einem verschmelzen kann.


Sagte ich auch bereits, dass du den Schattenanteil von jedem Lichtpass immer in einen Offscreen-Rendertarget kombinieren kannst.

AlphaTier[/POST]']
Ich werde mich jetzt erstmal ranmachen und praktisch tätig werden. Um die Grenzen auszuloten. Ich hatte eine ähnliche Idee, weitaus weniger komplex, dafür aber nicht so akkurat und Ellegant wie hier beschrieben.


Ich hab dieses Jahr schon einige Demos geschrieben für Paper Submissions für Computergraphik-Konferenzen. Ich glaub du kannst mir schon vertrauen was ich sage :)

AlphaTier[/POST]']
Die beiden Ansätze in den letzten beiden Posts fressen mir zuviel GFX-Speicher ... nicht das er rar währe, aber ich habe besseres damit vor als alle meine FBOs zu befüllen.

Ein Schatten-Offscreen-Buffer in Bildschirmauflösung mehr und das war's. Dieser sammelt den Schattenanteil ALLER Lichtquellen.

Wenn du's geschickt anstellst, kannst du sogar denselben Offscreen-Buffer verwenden, den du für andere Effekte verwenden kannst (z.B. Postprocess-Glow/Depth-of-Field o.ä.).

Also, nein, verbraucht nicht wirklich mehr Speicher.

PS: (Ordentliches) Shadowmapping würde noch viel mehr Speicher verbrauchen, z.B. wenn man Virtual Cube Maps verwendet für omnidirektionale shadow maps.

del_4901
2006-06-09, 02:27:31
Das musst du dann aber ranschreiben das du das vorher sagtest. ^^
z.B. das mit der LUT hab ich jetzt zum ersten mal gesehen, und finde es "überzeugend"

Ja Ok, es gibt einige gute Ansätze ... sind die aber soweit in FEAR .. einsetzbar ... dieser Frage bist du mir immnoch schuldig geblieben. Das werden wir warscheinlich auch leider nie definitiv rauskiegen, oder lassen sich die Jungs da in die Karten schauen?

tokugawa
2006-06-09, 02:31:19
AlphaTier[/POST]']Das musst du dann aber ranschreiben das du das vorher sagtest. ^^
z.B. das mit der LUT hab ich jetzt zum ersten mal gesehen, und finde es "überzeugend"

Häh? Ich hab doch dazugeschrieben, was ich vorher sagte:



AlphaTier[/POST]']
sondern die "Weiche des Schattens" über eine LUT in 2 Passes ermittelt. Das Tolle dran ist, das ich alle Lightpasses zu einem verschmelzen kann.


Sagte ich auch bereits, dass du den Schattenanteil von jedem Lichtpass immer in einen Offscreen-Rendertarget kombinieren kannst.


Siehst du? Der Satz sagt aus: "ich sagte bereits vorher dass man von jedem Lichtpass die Schattenanteile in einen einzigen Offscreen-Rendertarget kombinieren kann"?

Also, inwiefern war ich undeutlich?

del_4901
2006-06-09, 02:37:55
tokugawa[/POST]']Also, inwiefern war ich undeutlich?

Du warst/bist sehr sehr reserviert ... ich musste dir alles "aus der Nase ziehen"
Aber wo wir gerade mal dabei sind. wie bestimmst du beim "Post-ShadowBuffer-Process" wie stark die Schatten geblurt werden müssen. Da feht doch noch eine kleine Zusatzinformation. Schatten die weiter von der Quelle entfernt sind haben eine größere Prenumbra.

tokugawa
2006-06-09, 02:43:30
AlphaTier[/POST]']Du warst/bist sehr sehr reserviert ... ich musste dir alles "aus der Nase ziehen"


Ja, ich bin nicht zu sehr ins Detail gegangen. Warum auch? Die Konzepte stimmen ja. Ich bin ja nicht hier um dir zu zeigen wie man das implementiert konkret :)

AlphaTier[/POST]']
Aber wo wir gerade mal dabei sind. wie bestimmst du beim "Post-ShadowBuffer-Process" wie stark die Schatten geblurt werden müssen. Da feht doch noch eine kleine Zusatzinformation. Schatten die weiter von der Quelle entfernt sind haben eine größere Prenumbra.

Ja. Außerdem kann es sein dass durch den Blur die Schatten in Bereiche ausbluten (Shadow Bleeding), wo sie nicht sein sollten.

Das alles hab ich in einer der ersten Postings gemeint mit "Image Space Blur hat zwar auch kleinere Probleme, aber die sind zu fixen".

Fixen kannst du es eben auch mit Zusatzinformation. Z.B. Tiefe und/oder Normalen per Pixel in den Shadow-Buffer mitrendern (oder in ein eigenes Render Target), Blur-Filterkernel abhängig von Tiefe, nicht über Edges drüberblurren, usw. Hier gibt's mehrere Varianten.

Das mit der Distanz zum Shadowcaster stimmt. Das geht mit dem Image-Space-Blur natürlich nicht so einfach (hab ich auch nie behauptet, im Gegenteil). Dieses Image-Space-Shadowbuffer-Blur ist eine billige Methode die "wahrgenommen bessere Bilder" erzeugt, nicht unbedingt "realistischere".

Aber: es ist einer der Möglichkeiten Soft-Shadows zu generieren, die auch gut mit Shadow Volumes funktioniert.

Mehr will ich dazu aber gar nicht sagen, außer dass ein stupider simpler Blur des Schattenbuffers schon einiges an wahrgenommener Qualität bringt. Und die ist die letztendlich entscheidende.

del_4901
2006-06-09, 02:47:12
Ich bin halt ein Perfektionist ... und kein Freund von halben Sachen. Weichspülen kann ja jeder, Aber die Richtige Menge Weichspüler zu finden ist eine Herrausforderung.

tokugawa
2006-06-09, 02:51:17
AlphaTier[/POST]']Ich bin halt ein Perfektionist ... und kein Freund von halben Sachen. Weichspülen kann ja jeder, Aber die Richtige Menge Weichspüler zu finden ist eine Herrausforderung.

Sind ja keine halben Sachen wenn einem die menschliche Wahrnehmung wichtiger ist als "Realismus".

Im Gegenteil, wenn man nur auf "Realismus" (und zwar physikalisch korrekten) schaut, aber den Menschen dabei vergißt, und vor allem wie er die Bilder wahrnimmt, DANN macht man halbe Sachen.

Die Kunst in der Echtzeitgrafik ist es, mit computational günstigen Methoden die maximale Wirkung (beim Menschen) zu erreichen. Rechenkraft in gesteigerte physikalische Genauigkeit ("Realismus", wenn man so will) zu stecken, die letztendlich dem Menschen nichts bringt, weil sie gar nicht wahrgenommen wird, ist reine Verschwendung. Und man ringt eh schon um jedes Quäntchen Performance in der Echtzeitgrafik.

Unter Forschern in der Echtzeitgrafik geht der Spruch mit Augenzwinkern um, dass Echtzeitgrafik die große Kunst des Betrügens ist, dem Betrachter der Bilder Authentizismus vorzugaukeln, billig hinzufaken.


Egal, jedenfalls hier eine kleine Referenzliste zu Schatten (obwohl diese Liste leicht überschwenkt zu Shadowmapping, sind viele Techniken eben auch für Shadow Volumes interessant):

[AL04] Timo Aila and Samuli Laine. Alias-free shadow maps. In Proceedings
of Eurographics Symposium on Rendering 2004, pages 161–
166. Eurographics Association, 2004.
[Ald04] Graham Aldridge. Generalized trapezoidal
shadow mapping for infinite directional lighting.
http://legion.gibbering.net/projectx/paper/ shadow%20mapping/,
October 2004.
[BAS02] Stefan Brabec, Thomas Annen, and Hans-Peter Seidel. Practical
shadow mapping. Journal of Graphics Tools: JGT, 7(4):9–18, 2002.
[BWPP04] Jiˇr´ı Bittner, MichaelWimmer, Harald Piringer, andWerner Purgathofer.
Coherent hierarchical culling: Hardware occlusion queries
made useful. Computer Graphics Forum, 23(3):615–624, sep 2004.
Proceedings EUROGRAPHICS 2004.
[CG04] H. Chong and S. J. Gortler. A lixel for every pixel. In Proceedings
of Eurographics Symposium on Rendering 2004, 2004.
[Cho03] Hamilton Chong. Real-time perspective optimal shadow maps.
Senior thesis, Harvard College, Cambridge, Massachusetts, April
2003.
[Cro77] Franklin C. Crow. Shadow algorithms for computer graphics. In
James George, editor, Proceedings of the 4th annual conference on
Computer graphics and interactive techniques, volume 11, pages
242–248. ACM Press, July 1977.
[FFBG01] Randima Fernando, Sebastian Fernandez, Kavita Bala, and Donald
P. Greenberg. Adaptive shadow maps. In Eugene Fiume, editor,
SIGGRAPH 2001 Conference Proceedings, Annual Conference Series,
pages 387–390. ACM SIGGRAPH, Addison Wesley, August
2001.
94 Bibliography
[Hec86] Paul S. Heckbert. Survey of texture mapping. IEEE Computer
Graphics and Applications, 6(11):56–67, November 1986.
[HLHS03] Jean-Marc Hasenfratz, Marc Lapierre, Nicolas Holzschuch, and
Franc¸ois Sillion. A survey of real-time soft shadows algorithms. In
Eurographics. Eurographics, Eurographics, 2003. State-of-the-Art
Report.
[JMB04] Gregory S. Johnson, William R. Mark, and Christopher A. Burns.
The irregular z-buffer and its application to shadow mapping. Research
paper, The University of Texas at Austin, 2004.
[Koz04] S. Kozlov. Perspective shadow maps - care and feeding. GPU Gems,
pages 217–244, 2004.
[MH02] Tomas M¨oller and Eric Haines. Real-Time Rendering, Second Edition.
A. K. Peters Limited, 2002.
[MT04] Tobias Martin and Tiow-Seng Tan. Anti-aliasing and continuity with
trapezoidal shadow maps. In Proceedings of Eurographics Symposium
on Rendering 2004, pages 153–160, 2004.
[O’R04] J. O’Rorke. Managing visibility for per-pixel lighting. GPU Gems,
pages 245–257, 2004.
[RSC87] William T. Reeves, David H. Salesin, and Robert L. Cook. Rendering
antialiased shadows with depth maps. Computer Graphics
(SIGGRAPH ’87 Proceedings), 21(4):283–291, July 1987.
[SD02] Marc Stamminger and George Drettakis. Perspective shadow maps.
In Siggraph 2002 Conference Proceedings, volume 21, 3, pages
557–562, July 2002.
[SKvW+92] Mark Segal, Carl Korobkin, Rolf vanWidenfelt, Jim Foran, and Paul
Haeberli. Fast shadows and lighting effects using texture mapping.
Computer Graphics (SIGGRAPH ’92 Proceedings), 26(2):249–252,
July 1992.
[WE03] D. Weiskopf and T. Ertl. Shadow Mapping Based on Dual Depth
Layers. In Procceedings of Eurographics ’03 Short Papers, pages
53–60, 2003.
[Wil78] Lance Williams. Casting curved shadows on curved surfaces.
Computer Graphics (SIGGRAPH ’78 Proceedings), 12(3):270–274,
Aug. 1978.
Bibliography 95
[WM94] Yulan Wang and Steven Molnar. Second-depth shadow mapping.
Technical report, University of North Carolina at Chapel Hill, 1994.
[Woo92] AndrewWoo. The shadow depth map revisited. Graphics Gems III,
pages 338–342, 1992.
[WSP04] Michael Wimmer, Daniel Scherzer, and Werner Purgathofer. Light
space perspective shadow maps. In Proceedings of Eurographics
Symposium on Rendering 2004, 2004.



Und als finales Wort: Selbst Blobschatten (Kugelschatten unter allen Objekten, auch nichtrunden) haben ihre Daseinsberechtigung.

del_4901
2006-06-09, 02:56:13
tokugawa[/POST]']Sind ja keine halben Sachen wenn einem die menschliche Wahrnehmung wichtiger ist als "Realismus".

Im Gegenteil, wenn man nur auf "Realismus" (und zwar physikalisch korrekten) schaut, aber den Menschen dabei vergißt, und vor allem wie er die Bilder wahrnimmt, DANN macht man halbe Sachen.

Die Kunst in der Echtzeitgrafik ist es, mit computational günstigen Methoden die maximale Wirkung (beim Menschen) zu erreichen. Rechenkraft in gesteigerte physikalische Genauigkeit ("Realismus", wenn man so will) zu stecken, die letztendlich dem Menschen nichts bringt, weil sie gar nicht wahrgenommen wird, ist reine Verschwendung. Und man ringt eh schon um jedes Quäntchen Performance in der Echtzeitgrafik.

Unter Forschern in der Echtzeitgrafik geht der Spruch mit Augenzwinkern um, dass Echtzeitgrafik die große Kunst des Betrügens ist, dem Betrachter der Bilder Authentizismus vorzugaukeln, billig hinzufaken.


Faken ist ein wichtiger Bestandteil. Schatten zerblürt im Realen Leben doch relativ schnell, das ist ein Feature was ich persöhnlich als essentiellen Bestandteil von SoftShadows ansehe. Wie man dieses Feature dann zurechtfaked ist die Kunst des Betrügens.

c0re
2006-06-09, 13:41:41
Gast[/POST]']Sehen die Softshadows bei dir ungefähr so aus? Ich zitiere mal aus einem anderen Thread...

Unabhängig davon, wieviel Performance diese Softshadows fressen, sieht es einfach schlechter aus als harte Schatten. Nimmt man dann noch die Tatsache, dass die Teile bei aktiviertem AA nicht richtig dargestellt werden, wird die Sache noch uninteressanter, als sie eh schon ist.

Gast
2006-06-09, 15:35:58
c0re[/POST]']Unabhängig davon, wieviel Performance diese Softshadows fressen, sieht es einfach schlechter aus als harte Schatten. Nimmt man dann noch die Tatsache, dass die Teile bei aktiviertem AA nicht richtig dargestellt werden, wird die Sache noch uninteressanter, als sie eh schon ist.Och, so schlecht finde ich sie jetzt auch nicht. Spiele ja zur Zeit mal wieder Fear und habe gestern sogar mal eine Weile komplett auf AA verzichtet um mit Softschatten zu spielen. Also schlechter als die harten Schatten sieht es auf keinen Fall aus, nur leider reicht die Leistung bei mir nicht für AA und Softshadows.

@tokugawa und alphatier: Sehr interessante Diskussion. Auch wenn ich nicht alles zu 100% verstehe, kann man doch ein wenig bei lernen.

tokugawa
2006-06-09, 19:28:37
Jo, Softshadows sind auf jeden Fall grad ein "heißes Thema" in der Echtzeitgrafik-Forschung. Da kommt als in nächster Zeit noch einiges, was dann auch für Spiele relevant ist.

Die SIGGRAPH sowie die "Eurographics 2006"-Konferenz (die zweitgrößte Computergrafik-Konferenz, die dieses Jahr in Wien stattfindet) stehen ja vor der Tür.

del_4901
2006-06-10, 04:48:35
Da ich seid 2 Tagen nicht richtig schlafen kann. Hab ich mir mal alles durch Kopf und Finger gehen lassen.
(Ich komm jetzt leider wieder mit der Praxis ... tut mir Leid is aber so)

Ich hab vieles durchdacht und ausprobiert ... vllt bin ich ja nicht auf die richtige Idee gekommen, aber ich glaube zu wissen alle erdenklichen Möglichkeiten durchgespielt zu haben.

Wenn ich bei Schatten allgemein die Lichtberechnung so verschieben will, das ich alles zusammen in einen Pass berechne, dann bringt mir das Vollgendes:
Ich spaare vielleicht 2-8 Passes .. und somit CPU Belastung.
(die Schreibzugriffe auf den Framebuffer/etc. tu ich mal als unerheblich ab)
Das kann ich aber minimieren wenn ich sehr stark auf VBOs setze.

Dafür muss ich aber Vollgende Sachen opfern:
Flexibilität ... wenn ich nicht gerade Cg und Shaderinterfaces verwenden kann brauch ich für jede Anzahl an Lichtquellen einen eigenen Shader.
Ich muss einen Großteil der Berechungen im Pixelshader durchführen oder ich mache die TextureLookUps im VS(noch mehr ihh)
Ich brauche eine Handvoll FBOs (Bool Arrays für Jede Lichtquelle) (unerheblich)
für einen AllInOne Shader muss im Pixelshader gebranched werden (Ihhhhh)

Die Vorteile und Leistung die mir Deferred Shading hier bringt, frisst es gleich an anderer Stelle wieder auf. Da ich eh für jeden Pixel und jedes Licht testen muss kann ich Multiple Passes verwenden. Es ist also unerheblich was ich nehme ... Multiple Passes sind bei mir etwas schneller ... flexibler ... und abwärtskompatibler. Sicherlich Setze ich auch hier Deferred Shading ein ... Aber das machen Stencil Shadow Volumes ja schon auf ihre Art und weise.

Das ändert sich vllt. in Zukunft.. aber zum jetzigen Zeitpunkt kommt man nicht drumrum.

tokugawa
2006-06-10, 05:40:42
AlphaTier[/POST]']
Die Vorteile und Leistung die mir Deferred Shading hier bringt, frisst es gleich an anderer Stelle wieder auf.


Könntest du bitte weniger vorurteilshaft rangehen? Du schaust dir einen Bruchteil an, siehst davon nur die Hälfte, ratest teilweise, bist an einigen Stellen einfach nur falsch, und dann bildest du dir eine Meinung in so einem firmen Ton - das ist irgendwie ganz einfach ... anstrengend (um's diplomatisch auszudrücken) zu lesen meinerseits, sorry :)


AlphaTier[/POST]']Da ich seid 2 Tagen nicht richtig schlafen kann. Hab ich mir mal alles durch Kopf und Finger gehen lassen.
(Ich komm jetzt leider wieder mit der Praxis ... tut mir Leid is aber so)


Leider mit einer Praxis die nicht ganz korrekt ist...

Ich hab schon erwähnt dass die Sachen die ich erwähnt hab "tried and tested" sind. Die funktionieren in der Theorie wie in der Praxis. Funktionierende Real-World-Implementierungen existieren, und hab ich teilweise vorliegen.

AlphaTier[/POST]']
Ich hab vieles durchdacht und ausprobiert ... vllt bin ich ja nicht auf die richtige Idee gekommen, aber ich glaube zu wissen alle erdenklichen Möglichkeiten durchgespielt zu haben.

Wenn ich bei Schatten allgemein die Lichtberechnung so verschieben will, das ich alles zusammen in einen Pass berechne, dann bringt mir das Vollgendes:
Ich spaare vielleicht 2-8 Passes .. und somit CPU Belastung.


Meinst du nicht GPU?

AlphaTier[/POST]']
(die Schreibzugriffe auf den Framebuffer/etc. tu ich mal als unerheblich ab)
Das kann ich aber minimieren wenn ich sehr stark auf VBOs setze.


Sorry, du vermischt hier einiges, und ich komm nicht dahinter, was du eigentlich meinst.

AlphaTier[/POST]']
Dafür muss ich aber Vollgende Sachen opfern:
Flexibilität ... wenn ich nicht gerade Cg und Shaderinterfaces verwenden kann brauch ich für jede Anzahl an Lichtquellen einen eigenen Shader.


Also, du hast es falsch verstanden. Ich vermute du glaubst dass ich meine, dass die Schattenberechnung auf einmal für N Lichtquellen gemacht wird - nein, so ist das nicht.

Das mit den mehreren Lichtquellenanzahlen für die reine Beleuchtungsberechnung ist allerdings schon ein grundsätzliches Problem das jede Engine hat. Und die meisten Engines haben tatsächlich einen eigenen Shader für jede Anzahl an Lichtquellen. In der Praxis.

Aber wie gesagt, das hat mit dieser Technik nichts zu tun.

AlphaTier[/POST]']
Ich muss einen Großteil der Berechungen im Pixelshader durchführen oder


Nona, klar. Aber bei Per-Pixel-Lighting hast du die Illuminationsberechnung sowieso immer im Pixelshader.

AlphaTier[/POST]']
ich mache die TextureLookUps im VS(noch mehr ihh)


WAS?

AlphaTier[/POST]']
Ich brauche eine Handvoll FBOs (Bool Arrays für Jede Lichtquelle) (unerheblich)
für einen AllInOne Shader muss im Pixelshader gebranched werden (Ihhhhh)


AllInOne-Shader verwendet in der Praxis kein Spiel, und keine kommerzielle Engine.

Hier hast du übrigens die oben von mir angesprochene "Halbinformation". Du hast anscheinend irgendwo einmal gelesen, dass Branching schlecht sei. Allerdings vergißt du zwischen static und dynamic branching zu unterscheiden. Dynamic Branching hat speziell auf NVIDIA-Karten einen erheblichen Penalty.

Aber die Lichtquellenanzahl würde ein statisches Branching bewirken. Du änderst die Lichtquellenanzahl ja nicht dynamisch im Pixelshader, sondern die ist fix statisch vorgegeben per Draw-Call.

AlphaTier[/POST]']
Die Vorteile und Leistung die mir Deferred Shading hier bringt, frisst es gleich an anderer Stelle wieder auf.


Das ist inkorrekt.

Klar muß man diese Form Deferred Shading sorgfältig implementieren, aber es ist wie gesagt ein in der Praxis funktionierender Ansatz.

AlphaTier[/POST]']
Da ich eh für jeden Pixel und jedes Licht testen muss kann ich Multiple Passes verwenden. Es ist also unerheblich was ich nehme ... Multiple Passes sind bei mir etwas schneller ... flexibler ... und abwärtskompatibler.


Wieweit abwärtskompatibel willst du sein? Ich hab bei mir Shader Model 2.0 als untere Grenze genommen.

AlphaTier[/POST]']
Sicherlich Setze ich auch hier Deferred Shading ein ... Aber das machen Stencil Shadow Volumes ja schon auf ihre Art und weise.


Häh?

AlphaTier[/POST]']
Das ändert sich vllt. in Zukunft.. aber zum jetzigen Zeitpunkt kommt man nicht drumrum.

Doch.

Ich glaube du hast es einfach nicht verstanden, irgendwie scheint es dir in einigen Dingen an Grundverständnis zu mangeln, in anderen Dingen wiederum scheinst du zumindest irgendwo was gelesen zu haben, und das wieder aufzusagen (und selbst das tw. falsch).

Prinzipiell glaub ich du weißt immer noch nicht was unter Deferred Shading verstanden wird, bzw. wie das mit dem Rendern in separate Buffer mit nachträglicher Kombination funktioniert.

Hier mal eine Variante etwas genauer:
1. Szene-Depth-rendern (für später early-Z und außerdem mal Tiefenwerte/Normals in einen Buffer)
2. SVs extruden: 1 Pass pro Lichtquelle -> rendern des Schattenterms (Schattenanteil der Szene) in einen Offscreen-Buffer
3. Diese Offscreen-Schatten-Buffer jeweils im Image Space blurren (mit Zuhilfenahme von Buffer aus 1. um Bleeding zu vermeiden)
4. Beleuchtung berechnen: mit deferred Shading bis zu 4 Lichtquellen pro Pass
5. die Buffers aus 3 benutzen um für jedes Pixel zu bestimmen welches Pixel im Schatten liegt und entsprechend die Buffer aus 4 damit modulieren

Das ist natürlich nicht die einzige Variante, da kann man noch viel mehr andere Sachen machen - z.B. könnte man wie ich erwähnt hab die mehrfachen Offscreen-Buffer aus 2. etwas einsparen, indem man jeweils die Schattenterme von 4 Lichtquellen in einen Offscreen-Buffer kombiniert (man hat ja r, g, b). Dann kann man in 3. quasi 4 Shadowbuffer in einem Pass blurren.

4. und 5. könnte man auch in einen Pass kombinieren.

Also, ich bin jetzt nicht da um dir das im Detail zu erklären, aber ich kann dir eins sagen: das funktioniert in der Praxis und wird dort auch angewandt.

Ist zwar gut wenn du skeptisch bist, und trotzdem nachdenkst darüber, aber du kommst ein bisserl zu schnell zu einer Konklusio wenn du bei einem niedrigen Informationsstand schon sagst "nein, das geht sicher nicht!", statt "so wie ich das durchgedacht hab, geht das nicht, kannst du's nochmal genauer erläutern".

BAGZZlash
2006-06-10, 11:09:54
Weiche Schatten? Gab's schon bei S.W.A.T. 4...

http://www.people.freenet.de/BAGZZlash/Swat4-Softshadows.jpg

Seraf
2006-06-10, 11:58:49
BAGZZlash[/POST]']Weiche Schatten? Gab's schon bei S.W.A.T. 4...



Das sind aber Fake-Schatten.
Rechts von den beiden ist Licht. Trotzdem gehen die Schatten nach rechts und nicht nach links, wie man es eigentlich erwarten würde. :tongue:

BAGZZlash
2006-06-11, 01:30:35
Ich weiß, deswegen hab' ich auch absichtlich nicht "soft shadows" geschrieben. Trotzdem ist das bei S.W.A.T. 4 schön anzuschauen, sind auch richtig animiert, die Dinger. Reagieren eben nur nicht richtig auf Licht... :-/

del_4901
2006-06-11, 01:45:08
BAGZZlash[/POST]']Ich weiß, deswegen hab' ich auch absichtlich nicht "soft shadows" geschrieben. Trotzdem ist das bei S.W.A.T. 4 schön anzuschauen, sind auch richtig animiert, die Dinger. Reagieren eben nur nicht richtig auf Licht... :-/
Da war bestimmt einer so clever und hat alles im Modelspace berechnet.
... Ich sehe das immer öfter ... und fass mir da immerwieder an den Kopp.

deekey777
2006-06-11, 01:49:18
Dass hier noch niemand die Softshadows in Doom 3 (besser gesagt die Möglichkeit in Doom 3 Softshadows zu nutzen), ist mir beinahe ein Rätsel.

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=208977

Spasstiger
2006-06-11, 04:39:35
deekey777[/POST]']Dass hier noch niemand die Softshadows in Doom 3 (besser gesagt die Möglichkeit in Doom 3 Softshadows zu nutzen), ist mir beinahe ein Rätsel.

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=208977
Es geht hier ja nur um Realtime-Softshadows. Die Softshadows der Doom-3-Engine funktionieren aber nur auf Screenshots. Die Ergebnisse sind natürlich recht beeindruckend, zumal man bei Screenshots sogar 128-faches SSAA und wahrscheinlich noch mehr anwenden kann. Ist halt je nach System und Einstellungen mit ein paar Minuten Rechenzeit für einen Screenshot verbunden.

Gast
2006-06-11, 11:52:36
tokugawa[/POST]']


AllInOne-Shader verwendet in der Praxis kein Spiel, und keine kommerzielle Engine.



verwendet nicht splinter cell 3 im prinzip nur einen "allinone-shader" mit static branching für das eigentliche rendering(im SM3-modus)? (eventuelle zusätzliche shader für postprocessing und dergleichen mal ausgenommen)

Gast
2006-06-11, 11:53:26
BAGZZlash[/POST]']Weiche Schatten? Gab's schon bei S.W.A.T. 4...

http://www.people.freenet.de/BAGZZlash/Swat4-Softshadows.jpg

dann könnte man HL2 aber auch schon als "soft-shadows" bezeichnen ;)

Spasstiger
2006-06-11, 12:46:51
Gast[/POST]']dann könnte man HL2 aber auch schon als "soft-shadows" bezeichnen ;)
Und sogar Max Payne 2, dort gefallen mir die Schatten sogar besser als in HL2.
Aber es geht selbstverständlich um ganzheitliche Softshadows-Verfahren.

Gast
2006-06-11, 13:12:39
Spasstiger[/POST]']Und sogar Max Payne 2, dort gefallen mir die Schatten sogar besser als in HL2.
Aber es geht selbstverständlich um ganzheitliche Softshadows-Verfahren.

stimmt in max payne ist das leveldesign wesentlich besser abgestimmt, so dass es nicht zu so komischen situationen wie in HL2 kommt.

tokugawa
2006-06-11, 17:27:22
Gast[/POST]']verwendet nicht splinter cell 3 im prinzip nur einen "allinone-shader" mit static branching für das eigentliche rendering(im SM3-modus)? (eventuelle zusätzliche shader für postprocessing und dergleichen mal ausgenommen)

Ich nehm mal an dass diese Visor-Modi auch Postprocessing-Effekte sind. Aber darum geht's mir, dass man keinen All-In-One-Shader hat, weil man eben sehr spezielle Dinge teilweise braucht, eben z.B. Postprocess-Filter. Static Branching funktioniert übrigens auch auf SM2-Hardware schon.

Das ist jedenfalls ein Software-Engineering-Problem. Es ist die Frage ob ein einzelner Shader der alle Varianten/Renderzustände abdeckt, wartbar genug ist in einem Team, oder ob man diese verschiedenen Varianten die im Spiel vorkommen nicht sauberer auftrennen sollte. Ich bin eher der Meinung dass eine saubere Trennung wartbarer ist (im Team), aber dass vereinzelte Spieleentwickler das anders sehen ist ja nichts schlimmes.

Aber wie gesagt, auch bei SC3 würd ich nicht von All-In-One-Shadern sprechen weil ich die Postprocess-Filter eben nicht ausnehme.

Gast
2006-06-13, 23:51:29
tokugawa[/POST]']Ich nehm mal an dass diese Visor-Modi auch Postprocessing-Effekte sind.

im SM3-modus mit HDRR afaik nicht. post-processing ist da imo nur mehr das tonemapping.


Static Branching funktioniert übrigens auch auf SM2-Hardware schon.



aber die shaderlänge dürfte wohl nicht für größeres reichen (zumindest nicht mit SM2.0, mit den erweiterungen natürlich eventuell schon)

Gast
2006-06-14, 08:27:12
Hi;

ich bin jetzt zu faul den ganzen Thread durchzulesen, aber habt ihr schon das hier diskutiert:

variance shadow maps:

http://www.punkuser.net/vsm/


Shadow Maps ohne Aliasing! Ich hoffe das passt zum Thread



grüsse

Manfred

Polydeukes
2006-06-14, 11:39:15
tokugawa[/POST]']



Yep, und was hier noch dazukommt ist dass Thief III eigentlich die Deus Ex 2 Engine benutzt, die wiederum eine modifizierte Unreal II Engine ist. Der Schattenalgorithmus in Deus Ex 2 und Thief III wurde extra für diese Spiele implementiert und sind nicht von der Unreal II Engine.

Eine modifizierte Unreal Engine II ist immer noch eine Unreal Engine II. Diese ist lediglich modifiziert, aber das Grundgerüst ist das gleiche.

Gast
2006-06-14, 12:24:05
Nein, denn die Unreal II engine ist auch nichts anderes als eine modifizierte Unreal I engine. Also kannst du gleich alles auf die Unreal I engine zurückführen.

Gast
2006-06-14, 13:30:41
Polydeukes[/POST]']Eine modifizierte Unreal Engine II ist immer noch eine Unreal Engine II. Diese ist lediglich modifiziert, aber das Grundgerüst ist das gleiche.

Es wurden lediglich dafür gezahlt das man die Unreal Engine 2 verwenden und modifizieren darf, halt also eigentlich nix mehr mit dem Produkt zu tun was Epic verkauft, das selbe sieht man/wird man sehen bei der spielen die UE3 nutzen, die ja im Grunde nur eine modifizierte UE2 ist...........

BAGZZlash
2006-06-14, 13:56:15
Hab' mal irgendwo gelesen, daß die Unreal-I-Engine eigentlich nur 'ne modifizierte Doom-Engine sein soll... :rolleyes:

Gast
2006-06-14, 16:57:34
Polydeukes[/POST]']Eine modifizierte Unreal Engine II ist immer noch eine Unreal Engine II. Diese ist lediglich modifiziert, aber das Grundgerüst ist das gleiche.Wenn du das so siehst, basiert COD2 auch noch auf der Q3A-Engine und Splinter Cell 3 auf der UE2.

Es ist schwierig zu sagen ab wann eine modifizierte Engine nun neu ist.

Gast
2006-06-14, 17:39:21
Polydeukes[/POST]']Eine modifizierte Unreal Engine II ist immer noch eine Unreal Engine II. Diese ist lediglich modifiziert, aber das Grundgerüst ist das gleiche.

jede engine ist lediglich ein "erweiterter rasterizer", natürlich stark unterschiedlich, aber die grundidee ist die gleiche.

Neomi
2006-06-14, 18:17:18
Gast[/POST]']jede engine ist lediglich ein "erweiterter rasterizer", natürlich stark unterschiedlich, aber die grundidee ist die gleiche.

Wie soll jede Engine ein erweiterter Rasterizer sein, wenn die meisten Engines (heutzutage) nichtmal einen Rasterizer haben? Da kann man auch gleich behaupten, eine Engine wäre eine erweiterte Integer-Addition. :rolleyes:

tokugawa
2006-06-14, 20:34:37
Polydeukes[/POST]']Eine modifizierte Unreal Engine II ist immer noch eine Unreal Engine II. Diese ist lediglich modifiziert, aber das Grundgerüst ist das gleiche.

Jein. Du mußt genau beleuchten welche Komponenten "das gleiche" sind.

Eine "Engine" enthält ja vieles, von Entity/Scene-Management/Szenegraphen über Scripting bis zum tatsächlichen Rendering.

Wenn wir aber eben vom Rendering sprechen, und genau dieser Teil ist komplett ausgetauscht, dann kann man eben davon sprechen dass dieser Rendering-Teil eben nicht mehr der Unreal-Engine II entspricht.

Die Schatten in Deus Ex 2 und Thief 3 sind eben nicht aus der Unreal Engine II, somit liegt auch nahe dass nicht die Unreal Engine II-Rendering Pipeline verwendet wird. Darum ging's. Ob es die gleiche Szenegraphen-Struktur verwendet oder dasselbe Scripting oder dasselbe Toolset, ist vom Rendering-Standpunkt aus egal.

Gast[/POST]']jede engine ist lediglich ein "erweiterter rasterizer", natürlich stark unterschiedlich, aber die grundidee ist die gleiche.

Eine Engine macht wesentlich mehr. Wobei man zwischen Grafik-Engine und Spiel-Engine unterscheiden muß.

Eine Grafik-Engine muß mindestens ein Szenemanagement bereitstellen (Szenegraph), sowie eine Render-Pipeline. Auch die Toolchain für Content-Erstellung könnte man noch dazuzählen.

Bei einer Spiele-Engine kommt dann noch dazu Scripting/AI, Input, Sound, sowie weitere Tools.

Ist also weit mehr als ein simpler "erweiterter Rasterizer". Es geht im Prinzip um die effiziente Aufbereitung von Szenedaten für die GPU, sowie um eine effiziente nahtlose Toolchain vom Artist über die Engine in diese Szenedaten.