[Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Danke für deine beruhigenden Worte Chromanoid. :)
Und besten Dank für das Kompliment bezüglich der Screens!! :D

Ob die Technik einzigartig ist und das bisher niemand gemacht hat, kann ich leider nicht sagen, dafür müsste ich erst danach recherchieren.
Chromanoid hat geschrieben:Mit einer Veröffentlichung kannst du wenigstens sicherstellen, dass du als Erfinder der Technologie gesehen wirst...
Sofern es auch zählen würde, wenn ich das hier "veröffentliche", statt als Paper, dann wäre ich durchaus bereit dazu.
Wenn ich das aus einem Paper gehabt hätte, dann versichere ich, hätte ich da natürlich auch als Quelle drauf verwiesen.
Dass der Schatten selbst grundlegend über PCSS realisiert ist, dass hatte ich ja schon geschrieben. Um das auf Entfernung etwas unter Kontrolle zu bekommen, hab ich da dieses Cascading Shadow Mapping benutzt. Aber diese beiden Dinge eleminieren leider dieses Sprunghafte umspringen der Pixel in der Shadowmap nicht.


Diese "Busenwunderkatze" ist eigentlich ne Fledermausmensch-Mischung :D
Allerdings gibt es bisher nur das eine Modell, dass hatte ich noch in Blender gemacht. Diese "Garvoks" gehören zu einer der drei Hauptrassen in meinem zukünftigen Spiel. Die brauchen allerdings noch was anzuziehen, so ganz nackelig ist auch nicht gut. Allerdings weiß ich noch nicht ganz, ob man das hinterher lieber über Kleidungssimulation oder über Texturen löst.


Und hier hab ich noch einen Trick. Bei meiner Schattenrumtesterei ist diese Technik eigentlich durch einen Fehler entstanden. Aber wenn dieser richtig interpretiert wird, kann man damit schön so ein wenig indirektes Licht faken. Der Vorteil gegenüber dem SSAO ist, das es nicht sichtabhängig ist. :D
20090714.jpg
20090714b.jpg
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4019
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Chromanoid »

Zudomon hat geschrieben:Sofern es auch zählen würde, wenn ich das hier "veröffentliche", statt als Paper, dann wäre ich durchaus bereit dazu.
Du könntest das ganze ja mal aufschreiben und dann mit Namen und Datum in den Ressourcen-Bereich posten (bspw. so wie Krishty (muss natürlich nicht so ausgefeilt sein)). Das gilt auf jeden Fall erst mal als Sicherstellung deiner Rolle als Erfinder... Und wenn der Trick noch nicht veröffentlicht wurde, kann daraus ja später noch ein einreichbares Paper werden... Und nicht das nachher noch ein Patent auf die Technik in Amerika oder so angemeldet wird und du das dann nur mit Vorbehalt benutzen kannst, weil dir niemand abnimmt, dass du das selbst erfunden hast... Daher lieber früh veröffentlichen und die Technik der Allgemeinheit zur Verfügung stellen...
Benutzeravatar
Schrompf
Moderator
Beiträge: 4181
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Schrompf »

Nebenbei: es ist mir wirklich schnuppe, ob jemand den Splitterwelten-Code haben will. Den geb ich gerne raus. im Gegenteil: ich würde mich sogar freuen, wenn es noch andere Nutzer für die Engine gibt. Nur entspricht der Code halt nicht den Anforderungen an eine öffentliche Codebase - allen voran die Tatsache, dass wir komplett auf Deutsch programmieren. Und dass ich keinen Support auf dem Niveau bieten kann, was man von Ogre und Konsorten erwartet. Die Models und Texturen dagegen sind größtenteils nicht mein Werk, und ich weiß von einigen der Macher, dass sie der Teil-Idee eher skeptisch gegenüberstehen. Nichtsdestotrotz habe ich auch Assets bereits geteilt, z.B. an Ingrater und seine Walddemo damals. Auf meinen Artikel zu räumlich komprimierten ShadowMaps brauche ich auch nicht mehr hinzuweisen, vermute ich.

Zur Veröffentlichung Deiner Technik: mach, wie Du magst. Ein Forum lebt vom Austausch von Wissen, das ist keine Einbahnstraße. Aber ganz am Ende ist es Deine Entscheidung.

Ich gehe davon aus, dass Deine Technik auf einem Filtering-Trick oder ähnlichem basiert. Man kann nämlich relativ einfach mathematisch nachweisen, dass die ShadowMap-Texelkanten nach der Rotation der Lichtquelle gar nicht mehr mit den vorherigen Texelkanten deckungsgleich sein können. Anders formuliert: Kantenflimmern bei rotierender ShadowMap ist unvermeidlich. Ich vermute da eher, dass wir einfach von verschiedenen Effekten reden.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
BlueShark
Beiträge: 79
Registriert: 28.02.2009, 19:55
Alter Benutzername: BlueShark

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von BlueShark »

Moinsen,
erst einmal, tolle Bilder, man sieht, dass du viel Herzblut und Arbeit in dein Projekt steckst, zeigt sich auch an der Anzahl an Posts, die dieser Thread zusammenbekommt. Ich muss mich heute ein wenig kurz fassen, deswegen nur eine kurze Bitte:

ICH WILL NEE DEMO! SOFORT!! UND SEI ES NUR NEE KLEINE TECH-DEMO!!!

Mfg
BS
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Hallo!

Erstmal @Schrompf
Ich glaube, dann hab ich dir Unrecht getan! Stimmt, ich erinnere mich an den Schattenartikel, den du geschrieben hast. Und wenn du echt den Splitterwelten-Code teilen willst, dann ist das doch sehr ehrenhaft und dann muss ich sagen, habe ich dich da doch falsch eingeschätzt.
Ich frage mich allerdings, ob du das genauso sehen würdest, wenn es sich hier ebend nicht um ein Hobbyprojekt ( nicht abwärtenend verstehen ) handeln würde. Die Nahe Zukunft ist bei mir sehr ungewiss und ich weiß ebend nicht, ob ich das, was ich hier leichtsinnig verbreite, mir auf der anderen Seite noch nützen könnte. Vor allem musst du auch beachten, dass wir zwar eine kleine Gemeinde sind, aber mitlesen kann schließlich jeder.

Innerlich stehe ich in einem Konflikt. Und es ist Gewiss nicht so, dass ich nicht gerne einfach schreiben würde, wie das gemacht ist. Das Problem ist ebend ich nicht finanziell unabhängig bin. Ich würde sogar, wenn ich wüsste, dass es mir finanziell nie schlecht gehen würde, mein Spiel frei verfügbar machen, weil ich es ja letzten Endes nicht aus der Motivation heraus mache, steinreich zu werden, sondern was großes zu schaffen, an dem andere Freude haben.
Und ich möchte nochmal betonen, dass ich hier auch Helfe, sofern ich es selbst kann! Ich mache da ebend nur einen Unterschied, wenn es sich um selbst ausgedachte Dinge handelt.
Also bitte stellt mich nicht als jemanden hin, der hier nur Informationen sammelt und nicht austeilt.
Ich hoffe, ihr versteht mich und meine Ansicht.


Danke an BlueShark für das Kompliment!!
Ihr könnt euch garnicht vorstellen, wie sehr ihr mich alle durch das viele Lob motiviert weiter zu machen!!
Bezüglich der Techdemo, ich würde da gerne in sehr sehr naher Zukunft eine veröffentlichen. Allerdings sind im Moment noch die Texturen das Problem. Da diese zum Teil aus Duke und Doom sind. Ich hatte bisher noch nicht die Möglichkeit, mich auch darum zu kümmern. Und mit schnell dahingemalten Texturen würde das Ergebnis schnell zu wünschen übrig lassen. Große Bedenken hatte ich schon, überhaupt die Screens hier zu veröffentlichen.
Ich bemühe mich also schnellstmöglichst, diesen Misstand zu beheben und euch eine ganze kleine Minitechdemo bereitzustellen. Aber erwartet wirklich nichts überragendes.

Hab nun aber mal ein kleines Video von dem bewegten Schatten gemacht. Ohne Musik wirkt das allerdings relativ langweilig.
http://www.youtube.com/watch?v=yaMDm_Af5kc


Gruß
Zudo

PS: Gibt es eine Möglichkeit, das Video hier so einzubinden, dass man es direkt hier abspielen kann?
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4019
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Chromanoid »

Wäre super wenn du mal einen Schatten auf einer flachen Fläche zeigen könntest (mit unterschiedlichen Licht veränderungsgeschwindigkeiten)... bei dem Pflanzenwirrwar erkennt man das so schwer...
Ansonsten *Daumen hoch* :D
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Okay, kein Problem, das neue Video müsste gleich verfügbar sein.

Ich mach mir hier immer nen Kopf, weil ich denke, wenn jemand anderes in der Lage ist, den gleichen Effekt zu machen, es dann in meiner Engine nichts mehr Wert ist. Aber eigentlich ist es dumm, so zu denken.
Deswegen werde ich nun doch verraten, welcher kleine Trick dahinter steckt:
Ich rendere 4 Shadow maps, in dem letzten Video jede halbe Sekunde eine. Dann brauch ich noch ne Zeitvariable um zwischen zwei Maps zu überblenden. Damit das nicht so auf die Geschwindigkeit geht, wird einfach bei jedem Pixel anhand der Zeit entschieden, ob aus der alten oder neuen Map gelesen wird.

Hier das neue Video:
http://www.youtube.com/watch?v=M1GyE1-4j4E
Benutzeravatar
Schrompf
Moderator
Beiträge: 4181
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Schrompf »

Ok, das zweite Video erklärt einiges. Zum einen veränderst Du die Schattenprojektion sowieso nur aller einer halben Sekunde, das reduziert das Gefrickel auf maximal einmal pro halber Sekunde :-) Das tun wir auch, nur halt deaktiviert für die Promo, damit die Sonne keine solchen Sprünge machen. Zum zweiten ist Deine Schattenauflösung viel höher als unsere - Du benutzt CSSM, wir die eigene Krümmtechnik, Du auf wasweißichwieviele Meter Sichtweite, wir auf einen 1km. Und dann kommt drittens noch Dein kleiner Trick mit den multiplen ShadowMaps - das ist in der Tat eine clevere Idee, aber das scheidet für uns aus, fürchte ich. Wenn ich nochmal 32MB für die Sonne verbrate, bekomme ich Dresche von den Grafikern mit ihren Radeon1800ern.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Die 4 Shadowmaps sind auf den RGBA Channel verteilt. Das wirklich wirklich blöde an der ganzen Sache ist, dass man nicht so einfach Objekte bewegen lassen kann, weil man dann die Shadowmap neu berechnen müsste. Dann müsste er zudem beide betroffenen Shadowmaps updaten. Ne, also es sieht zwar im moment ganz gut aus, aber ob das wirklich brauchbar ist, weiß ich nicht.
Grundlegend ist euer Perspektivenschatten auch sehr gut. Nur irgendwie habe ich das Gefühl, das letztlich die Auflösung noch zu gering ist.
Bei mir hab ich ne 4096er Textur, die dann für das CSSM in jeweils 4 2048er unterteilt wird. Wollte das eigentlich auch halbieren, aber dann siehts zu mies aus.
Mich kotzt dieses Shadowmapping eh ziemlich an. Würde da viel lieber Stencil nehmen, weil der Pixelgenau ist und man damit auch Punktlichter und sonstwas realisieren kann, ohne endlos tricksen zu müssen. Was mich davon aber abhält, sind dann die beiden Gewichtigen Punkte:
Keine Alphatesttexturen und zu langsam, wenn man weiche Schatten haben möchte.
Außerdem ist es bei mir jetzt nicht so einfach Möglich, noch einen Schatten da hin zu machen etwa durch ne zweite Lichtquelle.

Naja, immerhin ist heute das Avi aufnehmen reingekommen.

Wegen dem Schatten kämpfe ich schon seid Anfang an. Hab ich Stencil drin, denke ich, ne, doch lieber Shadowmaps. Hab ich die drin, dann will ich doch lieber wieder Stencil haben. Das ist auf dauer sehr frustrierend. Beides zugleich implementieren hat eigentlich auch keinen Sinn, weil man dann soweit ich mir das vorstellen kann, nicht gut optimieren kann.
Alles Dreck. Bleibt höchstens noch die Idee, die Schatten zu Raytracen. Aber ob das klappt, weiß ich nicht.

Edit:
Nein, Raytracen kann man bei genauerer Betrachtung auch abhacken. Dann müsste man nämlich Transformationen, die man im Vertexshader macht, etwa bei Skelettanimationen auch im Pixelshader für das Schattensampel durchführen und zwar dann auch immer wieder und nicht nur einmal für das komplette Rendering. Also somit sehe ich keinen Weg, wie man heutzutage anständige scharfe und auf Abstand weich werdende Schatten rendern kann.
Achso, das krisseln finde ich auch schäbig, aber scheinbar kann man das ja noch wegfiltern. Kann das aber nicht so ohne weiteres bei mir mal selbst testen. Bin also sehr auf die TGGC Demo gespannt um mal zu sehen, wie das letztlich dann da aussieht.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4181
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Schrompf »

Neenee, lass mal. Shadow Mapping ist meiner Meinung nach momentan die einzig taugliche Schattentechnik. Eben, weil man sie auch weich bekommt, und weil sie mit AlphaTest-Geometrie zusammenspielt. Ich würde mich da auch nicht verzetteln, um auch noch Shadow Volumes zu implementieren - der Pflegeaufwand fliegt einem schnell um die Ohren. Du wirst sowieso regelmäßig wieder was an den Schatten machen müssen - wir haben auch noch ein Jahr nach der Implementation auf manchen Grafikkarten manche Szenen entdeckt, die Selbstschattenprobleme hatten. Der Kampf hört nie wirklich auf.

Wir berechnen bei uns jedes Frame alle ShadowMaps neu. Ich habe es nie hinbekommen, vernünftig abzuschätzen, wenn sich nun was im Lichtfrustum geändert hat, so dass die ShadowMap neu berechnet werden müsste. Mir war die Rechenzeit zu schade, um jede Bewegung gegen jedes Licht zu prüfen, und alle shaderbasierenden Anims wie das wiegende Gras oder die Billboard-Bäume wären dabei ignoriert worden. Nur bei Punkt- und Kegellichtern betreiben wir Lichtvolumen-Tests gegen das Kamerafrustum, um evtl. ein paar Passes einsparen zu können. Für die Sonne nehmen wir übrigens nur eine einzelne 2048er - eine 4096er ist mal als UltraHighQuality-Konfig angedacht, aber bislang bin ich dazu nie wirklich gekommen. Damit und mit ein bisschen mehr Mathezauber bei der Texturkoord-Kompression müssten wir eigentlich auch bei einer Qualität ankommen, die mit Deiner vergleichbar ist... allerdings sind wir dann auch bei ähnlichen Kosten.

Nebenbei: warum muss man bei Punktlichtern so "endlos tricksen"? Eine R32F-CubeMap, sechs Renderpasses, fertig. Die waren die ersten, die bei uns liefen... bis zur schattenwerfenden Sonne hat es dagegen noch ewig gedauert, u.a. auch wegen der ewigen Frustum-Kämpfe dafür. Ich vertrete hier also mit gewissem Nachdruck, dass Punktlichtquellen für Dich ein Heimspiel werden müssten. Du musst nur die Abstraktion in Deine bestehende Renderpipeline hinbekommen.

[edit] Abhaken, nicht abhacken! Ihr seid immer so brutal zu untauglichen Rendertechniken... :-)
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 20:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Aramis »

Also somit sehe ich keinen Weg, wie man heutzutage anständige scharfe und auf Abstand weich werdende Schatten rendern kann
Naja, ein Screenspace-Blur schafft im Prinzip die Möglichkeit dazu. Wie komplex man den Blurshader gestalten kann ohne die Grafikkarte zum Brennen zu bringen (z.B. für entfernungsabhängigen Blur), ist dann wieder eine andere Frage :-)

Leider hab ich noch nie die Zeit gehabt das mal auszuprobieren.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Das "endlos tricksen" war auf Shadowmapping allgemein bezogen. Aber letztlich muss man beim Stencil auch tricksen, um den dann schneller zu bekommen. War also übereilt geschrieben.
Vom Prinzip her hast du Recht, da sind Punktlichter einfach, über so eine Cubemap. Das Problem sehe ich in den 6 Renderpasses, die zusätzlich kommen. Wenn dass dann schnell sein soll, dann muss es ne kleine Shadowmapauflösung sein. Also bei 512 ist da eigentlich schon Schluss. Dadurch wird das ganze aber auf relativ kleine Lichtquellen beschränkt, weil sonst die Artefakte wieder so groß werden.
Pixelgenau Schatten ist eigentlich das absolute ProArgument für Stencil. Deswegen würde ich den nicht so direkt ausschließen.
Aramis hat geschrieben:
Also somit sehe ich keinen Weg, wie man heutzutage anständige scharfe und auf Abstand weich werdende Schatten rendern kann
Naja, ein Screenspace-Blur schafft im Prinzip die Möglichkeit dazu. Wie komplex man den Blurshader gestalten kann ohne die Grafikkarte zum Brennen zu bringen (z.B. für entfernungsabhängigen Blur), ist dann wieder eine andere Frage :-)

Leider hab ich noch nie die Zeit gehabt das mal auszuprobieren.
Wenn es aber korrekt sein soll, muss man ja bestimmen, wie weit der Lichtblocker von der Fläche entfernt ist, und dann im Verhältnis zum Lichtabstand setzen. Ich sehe da keine Möglichkeit, das nur über das normale Rendern + Tiefenbuffer zu bestimmen.
Benutzeravatar
Krishty
Establishment
Beiträge: 7414
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Krishty »

Schrompf hat geschrieben:Eine R32F-CubeMap, […]
Muss es eigentlich immer 32-Bit-Präzision sein? Ich spreche da als jemand, der Shadow-Mapping noch nie implementiert hat – also nicht direkt hauen – aber früher kam man doch auch mit 16 Bits aus, und soviel komplexer ist die Geometrie seitdem nicht geworden (die Polygonzahlen sind in die Breite, in hohe Tesselierung und weiche Formen gewachsen, nicht so sehr in die Tiefe, zu mehr Overdraw). Außerdem gibt es eine Menge Tricksereien (z.B. Gleitkommazahlen besser auszunutzen indem man die Tiefe invertiert) die zu Zeiten von 24-Bit-GPUs und UNorm-Texturformaten noch unmöglich waren.
Schrompf hat geschrieben:[…]sechs Renderpasses[…]
An der Stelle dürfte es Zudomon ärgern, von D3D10 wieder auf 9 zurückgegangen zu sein ;)
Zudomon hat geschrieben:Pixelgenau Schatten ist eigentlich das absolute ProArgument für Stencil. Deswegen würde ich den nicht so direkt ausschließen.
Ich weiß nicht, was daran pro sein soll. Stencil-Schatten sehen nur in einer einzigen Situation gut aus: Wenn das Antialiasing zufällig genau so stark ist, wie die Schatten in Wirklichkeit unscharf würden (z.B. in Driv3r 50 bis 200 m vor dem Auto auf der Straße) – aber das wird, außer in Rennspielen mit ihrer Weitsicht und den flachen Schatten, nie erreicht. Außerdem reißen dann die vielen Subsamples und der Overdraw die Performance in den Keller. Stencil-Schatten sind von allen Schattenalgorithmen wahrscheinlich der, der am weitesten von jeder realen Entsprechung entfernt ist.
Zudomon hat geschrieben:Wenn es aber korrekt sein soll, muss man ja bestimmen, wie weit der Lichtblocker von der Fläche entfernt ist, und dann im Verhältnis zum Lichtabstand setzen.
Wohl eher ins Verhältnis zur Fläche / zum Volumen der Lichtquelle setzen, sonst gibt man der Lichtquelle so esoterische Pseudo-Eigenschaften wie „Schattenblur pro Meter Entfernung“ …
Zudomon hat geschrieben:Ich sehe da keine Möglichkeit, das nur über das normale Rendern + Tiefenbuffer zu bestimmen.
Genau. Man stelle sich ein Hochhaus vor, das über viele hundert Meter Schatten wirft, so dass der Schatten am Ende über 3 × 3 m geblurt wird. Laufen nun Menschen über die Schattenkante, verpuffen ihre Schatten einfach – man kann nämlich nicht sagen, ob der Blocker nun das 200 m entfernte Hochhausdach oder der zwei Meter entfernte Mensch ist, und blurt beides gleich viel. Ich meine sowas auch in Zudomons Screenshots erkennen zu können (in der Mitte, die entfernten Äste des Baums verwirbeln die nahe Kante der Mauer) … aber Szenen mit sehr langen Schattenwürfen (wie Häuserschluchten) treiben generell jede nicht-Global-Illumination-Technik über ihre Grenze.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Krishty hat geschrieben:
Schrompf hat geschrieben:[…]sechs Renderpasses[…]
An der Stelle dürfte es Zudomon ärgern, von D3D10 wieder auf 9 zurückgegangen zu sein ;)
Ja, das ist echt blöde. Auch wenn man es doch nochmal mit Stencil probieren würde, würde ich das gerne mal über Geometrieshader probieren, statt für jede Kante zwei extra Dreiecke zu verschwenden.
Krishty hat geschrieben:
Zudomon hat geschrieben:Pixelgenau Schatten ist eigentlich das absolute ProArgument für Stencil. Deswegen würde ich den nicht so direkt ausschließen.
Ich weiß nicht, was daran pro sein soll. Stencil-Schatten sehen nur in einer einzigen Situation gut aus: Wenn das Antialiasing zufällig genau so stark ist, wie die Schatten in Wirklichkeit unscharf würden (z.B. in Driv3r 50 bis 200 m vor dem Auto auf der Straße) – aber das wird, außer in Rennspielen mit ihrer Weitsicht und den flachen Schatten, nie erreicht. Außerdem reißen dann die vielen Subsamples und der Overdraw die Performance in den Keller. Stencil-Schatten sind von allen Schattenalgorithmen wahrscheinlich der, der am weitesten von jeder realen Entsprechung entfernt ist.
Wenn man das ganze mal logisch von etwas weiter Weg betrachtet, dann hat hier das gleiche Phänomen wie bei meiner Texturatlas-Lösung. Bei der wurden die Sprites erst in die Textur gerendert und dann aufgetragen. Hinterher hatte ich die Sprites direkt auf das Objekt aufgetragen, statt den Umweg über die Textur zu nehmen, welche von der Auflösung her beschränkt ist. Bei Shadowmapping hat man das gleiche Problem, dadurch, dass die Werte erst in eine Textur laufen, ist man von der Qualität her begrenzt. Man müsste direkt ermitteln können, welche Tiefenwerte wo vorliegen. Nicht über eine Textur sondern über die Geometrie. Und genau das kann Stencil ja. Es wird anhand der Geometrie ermittelt, welcher Pixel schattiert ist oder nicht. Grundlegend ist Shadowmapping ja das gleiche, nur quantisiert. Der Vorteil, den man bei Shadowmaps dann allerdings wieder hat, ist, dass sie sehr einfach weichgezeichnet werden können. Das ist bei Stencil nicht möglich, weil man keinen Zugriff auf die Umgebung eines Pixels hat. Aber weicher Stencil ist der beste Schatten, der meiner Meinung nach, zur Zeit möglich ist, abgesehen vom Raytracing, was aber genau das gleiche Ergebnis wie Stencil liefern würde, mit dem Vorteil, das auch Alphatexturen möglich wären. Außerdem könnte man den dann auch so gekrisselt weich machen. Beim Stencilschatten geht das nicht, da entstehen streifen.

Wenn man mal so einen Vergleich hat, dann sieht man doch, was pixelgenauer Schatten bedeutet.

Hier nochmal ein Bild aus meiner alten Engine mit Stencilschatten.
stencil.jpg
Dagegen der aktuelle Schatten. Die Shadowmap selbst hat 256MB. Vielleicht kann man da echt die Hälfte sparen, wenn man das nun auf 16 Bit runterbrechen würde. Und wenn man das Cascading durch so eine Perspektivische Lösung wie in Splitterwelten austauscht, kann man eventuell nochmal gut sparen. Aber Pixelgenau wird es wohl dennnoch nicht werden.
shadowmap.jpg
Krishty hat geschrieben:
Zudomon hat geschrieben:Wenn es aber korrekt sein soll, muss man ja bestimmen, wie weit der Lichtblocker von der Fläche entfernt ist, und dann im Verhältnis zum Lichtabstand setzen.
Wohl eher ins Verhältnis zur Fläche / zum Volumen der Lichtquelle setzen, sonst gibt man der Lichtquelle so esoterische Pseudo-Eigenschaften wie „Schattenblur pro Meter Entfernung“ …
Ich weiß jetzt die richtige Formel nicht und eigentlich gibt es ja auch keine richtige Formel. Denn das ausgesendete Licht richtig sich ja nach der Fläche. Klar könnte man nun eine Formel benutzen, die die Lichtquelle als Kugel darstellt. Aber wenn man mal einen leuchtenden Schriftzug hat, muss man andere Wege gehen.
Krishty hat geschrieben:
Zudomon hat geschrieben:Ich sehe da keine Möglichkeit, das nur über das normale Rendern + Tiefenbuffer zu bestimmen.
Genau. Man stelle sich ein Hochhaus vor, das über viele hundert Meter Schatten wirft, so dass der Schatten am Ende über 3 × 3 m geblurt wird. Laufen nun Menschen über die Schattenkante, verpuffen ihre Schatten einfach – man kann nämlich nicht sagen, ob der Blocker nun das 200 m entfernte Hochhausdach oder der zwei Meter entfernte Mensch ist, und blurt beides gleich viel. Ich meine sowas auch in Zudomons Screenshots erkennen zu können (in der Mitte, die entfernten Äste des Baums verwirbeln die nahe Kante der Mauer) … aber Szenen mit sehr langen Schattenwürfen (wie Häuserschluchten) treiben generell jede nicht-Global-Illumination-Technik über ihre Grenze.
Hast recht. Da liegt auf jeden Fall eine Schwäche. Bei der Methode ist es so, dass zuvor der Blocker gesucht wird. Daraus wird der Blurradius bestimmt. Es wird einfach der Mittelwert aller Blocker genommen.
Benutzeravatar
Krishty
Establishment
Beiträge: 7414
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Krishty »

Bevor wir aneinander vorbei reden – was für eine Implementierung von Soft Stencil Shadows ist das, die du benutzt? Umbra und Penumbra mit Gradient, Screen-Space-Blur, Brute-Force viele Lichter?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Krishty hat geschrieben:Brute-Force viele Lichter
Benutzeravatar
Schrompf
Moderator
Beiträge: 4181
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Schrompf »

Krishty hat geschrieben:Muss es eigentlich immer 32-Bit-Präzision sein? Ich spreche da als jemand, der Shadow-Mapping noch nie implementiert hat – also nicht direkt hauen – aber früher kam man doch auch mit 16 Bits aus, und soviel komplexer ist die Geometrie seitdem nicht geworden (die Polygonzahlen sind in die Breite, in hohe Tesselierung und weiche Formen gewachsen, nicht so sehr in die Tiefe, zu mehr Overdraw). Außerdem gibt es eine Menge Tricksereien (z.B. Gleitkommazahlen besser auszunutzen indem man die Tiefe invertiert) die zu Zeiten von 24-Bit-GPUs und UNorm-Texturformaten noch unmöglich waren.
Für eine Parallellichtquelle: ja, es muss 32Bit-Float sein. Ein Invert dürfte daran nichts ändern, soweit ich das überschaue. Ich hab's mal mit 16Bit-Ints probiert, aber auch die reichten von der Genauigkeit her nicht für unsere Szenen. Das Licht-Frustum erstreckt sich je nach Blickwinkel bei uns über bis zu 1800m, über die wir gleichmäßig verteilt die Genauigkeit brauchen. Da ist auch ein 16Bit-Integer nur mit ~3cm Genauigkeit dabei. Und die drei Zentimeter plus das übliche Offset gegen Selbstschatten sieht man schon recht schnell bei bodenberührenden Schattenwerfern.

Für eine Punkt- und Kegellichtquelle: ja, da könnte man 16Bit-Floats benutzen. Hier kommt jetzt aber eine Eigenheit der modernen Grafikkartenwelt zum Tragen: NVidia-Karten können keine Rendertargets mit 16Bit pro Pixel benutzen. Wenn Du ein 16Bit-Float-Rendertarget haben willst, musst Du ein G16R16F-Format wählen, also eins mit zwei Kanälen. Damit ist der Pixel dann wieder bei 32Bit und NVidia ist glücklich. Reproduzierbar bis zur Geforce8800, neuere habe ich nicht mehr probieren können. Und wenn man da sowieso nix spart, kann man auch einen Kanal mit ordentlich Präzision nehmen.
Krishty hat geschrieben:An der Stelle dürfte es Zudomon ärgern, von D3D10 wieder auf 9 zurückgegangen zu sein ;)
Weiß nicht... das, was ich bisher von der Verteilung auf Rendertargets im GeometrieShader gelesen habe, sprach davon, dass es bislang eher langsamer als die 6Pass-Lösung sei. Scheint wohl eine Eigenheit der aktuellen GeometrieShader-Implementationen zu sein. Hat da jemand Erfahrungswerte aus erster Hand dazu?

Ok, inzwischen sind wir ganz schön weit weg vom Thema. Aber es würde mich halt interessieren.

bye, thomas

[edit]
Zudomon hat geschrieben:
Krishty hat geschrieben:Brute-Force viele Lichter
Aua. Die Performance davon muss doch abartig sein... und der gleiche Trick geht ja auch mit ShadowMaps :-)
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Also mir macht das nichts, wenn das hier Offtopic wird... das sind ja interessante Themen! Spätestens, wenn ich die nächsten Versionen poste, dann ist es ja wieder Ontopic :D

Die vielen Lichter drücken übelst auf die Performance. Deswegen ist es keine alternative. Klar, bei Shadowmaps würde der Trick auch gehen, aber solange der so große Artefakte hat, bringt es ja nichts.
Allerdings wenn ich mir diese beiden Vergleichsbilder anschaue, dann ist der Stencilschatten qualitativ um Welten besser. Man müsste nur einen Weg finden, Alphatexturen zu realisieren und eine Möglichkeit, den schnell weich zu bekommen.
Benutzeravatar
Krishty
Establishment
Beiträge: 7414
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Krishty »

Woah, tatsächlich Brute-Force drauf los? Die SDK-Demo geht bei mir schon bei acht simultanen Stencil-Schatten in die Knie, dann möchte ich von der Performance garnichts hören :D Dann sind es aber auch keine Soft-Shadows mehr, sondern einfach nur viele viele Lichtquellen mit Hard-Shadows. So kann das ja jeder ;)

Nagut, dann mal zurück zum ursprünglichen Problem. Schatten, deren Schärfe man als pixelgenau bezeichnen würde, sind in der Realität kaum anzutreffen, denn die meisten Lichtquellen sind großflächige Strahler (die Sonne ist noch die Lichtquelle mit der größten Schärfe, also dem höchsten Verhältnis von Helligkeit zu scheinbarer Größe, alle anderen sind noch verschwommener!). Leider sind immernoch alle Engines darauf getrimmt, ausschließlich die Sonne und künstliche Lichtquellen zur Beleuchtung zu nutzen. Fenster und Türen als Lichtquellen wären für Indoor-Szenen ein gewaltiger Fortschritt, und da sind die Schatten nochmals viel, viel weicher – oft so weich, dass man nicht einmal mehr direkt am Berührungspunkt des Occluders mit dem Boden sowas wie einen harten Schatten erkennen kann. Indoor-Szenen mit fünf bis zehn weichen Lichtquellen auszustatten kann einen netten Global-Illumination-Look erzeugen, nur viel günstiger – da liegt der größte Nutzen von Soft-Shadows. Mit Stencils dürfte das aber problematisch werden.

In diesem Zusammenhang wäre es interessant zu wissen, wieviele Texel einer Shadow-Map weniger als einen Pixel geblurt werden (also wirklich pixelgenau gefordert sind) – ich wette, es sind höchstens um die fünf Prozent. Das sieht man auch gut an deinen Beispielen – die Schattenkante, die vielleicht fünfzig Meter lang ist, ist nur auf den ersten beiden Metern so scharf, dass Stencils sich lohnen würden. Wann immer man einen oder mehr Texel in jede Richtunng blurt, ist die Shadow-Map nicht mehr als quantisiert zu identifizieren (Shannon-Nyquist?), und ich würde darauf tippen, dass darunter ein Großteil aller Schattenflächen fällt.
Zudomon hat geschrieben:Man müsste nur einen Weg finden, Alphatexturen zu realisieren und eine Möglichkeit, den schnell weich zu bekommen.
Und für Shadow-Mapping müsste man nur einen Weg finden, unendlich hoch aufzulösen … das ist eine Schwäche des Konzepts und nichts, was man mal schnell durch eine besonders kluge Implementation aus dem Weg räumen kann. Für sowas gibt es nichts anderes als Hybridansätze und viel, viel Trickserei.
Schrompf hat geschrieben:Für eine Parallellichtquelle: ja, es muss 32Bit-Float sein.
Stimmt, drei Zentimeter sind bei sowas wirklich viel zu grob. Aber bei Floats habe ich da immer Skrupel – man verschenkt ein ganzes Bit wegen dem verdammten Vorzeichen … :/
Schrompf hat geschrieben:Für eine Punkt- und Kegellichtquelle: ja, da könnte man 16Bit-Floats benutzen. Hier kommt jetzt aber eine Eigenheit der modernen Grafikkartenwelt zum Tragen: NVidia-Karten können keine Rendertargets mit 16Bit pro Pixel benutzen.
Ich weiß, dass ihr mich dafür hasst, aber: D3D9 gehört nicht zur „modernen Grafikkartenwelt“ ;)
Schrompf hat geschrieben:Weiß nicht... das, was ich bisher von der Verteilung auf Rendertargets im GeometrieShader gelesen habe, sprach davon, dass es bislang eher langsamer als die 6Pass-Lösung sei. Scheint wohl eine Eigenheit der aktuellen GeometrieShader-Implementationen zu sein. Hat da jemand Erfahrungswerte aus erster Hand dazu?
Würde mich auch mal interessieren … schließlich sollten die Kinderkrankheiten langsam ausgemerzt sein. Bei meinen Sternen funktioniert „aus eins mach sechs“ sehr gut, aber das ist wohl leicht was Anderes. Übrigens hat D3D10 mit Stream-Out einen weiteren Vorteil für das Rendern von Schatten.
Zudomon hat geschrieben:Ich weiß jetzt die richtige Formel nicht und eigentlich gibt es ja auch keine richtige Formel. Denn das ausgesendete Licht richtig sich ja nach der Fläche. Klar könnte man nun eine Formel benutzen, die die Lichtquelle als Kugel darstellt. Aber wenn man mal einen leuchtenden Schriftzug hat, muss man andere Wege gehen.
Die richtige Formel lautet „projeziere die Welt aus Sicht des Pixels auf eine Halbkugel und intergriere darüber“ ;) Es wäre ein Anfang, Lichtquellen als Kugeln darzustellen. Rechtecke wären auch nützlich, dann hätte man 95% der Fälle (von Glühbirnen über Neonröhren bis zu Türen und Fenstern) abgedeckt. Letzten Endes braucht man aber ein Abbild der Lichtquelle, das man als Filter benutzt, am besten nicht auf eine einzelne Map, sondern auf viele verschiedene. Das nähert sich Global Illumination an, aber wenn ich sehe wieviele Lichtquellen du für den Stencil-Screenshot platziert hast, ist das schon garnicht mehr soo abwegig ;)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4181
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Schrompf »

Krishty hat geschrieben:
Schrompf hat geschrieben:Für eine Parallellichtquelle: ja, es muss 32Bit-Float sein.
Stimmt, drei Zentimeter sind bei sowas wirklich viel zu grob. Aber bei Floats habe ich da immer Skrupel – man verschenkt ein ganzes Bit wegen dem verdammten Vorzeichen … :/
Hmm... ich habe noch eine Weile darüber gegrübelt und bin nicht mehr ganz so sicher. Theoretisch bedeutet diese Quantisierungsgenauigkeit ja nur, dass man ein (festes) Offset von 3cm auf alles draufrechnen muss. Verglichen damit, dass wir in unseren Szenen 1 bis 20cm Offsets haben, in der Entfernung auch gern einige Meter, klingt das eigentlich vernachlässigbar.
Krishty hat geschrieben:Ich weiß, dass ihr mich dafür hasst, aber: D3D9 gehört nicht zur „modernen Grafikkartenwelt“ ;)
Der Spruch ist hier unpassend, glaube ich. Auch DX9 hat entsprechende Pixelformate definiert. Da gibt es R16F, G16R16F und auch A16B16G16R16F. Das Problem ist nur, dass NVidia-Karten die Texturerzeugung verweigern, wenn man R16F mit dem Rendertarget-Flag kombiniert. ATI-Karten machen das dagegen stressfrei mit. Ich vermute mal, unter DX10 würde man das selbe Verhalten beobachten...

Bye, Thomas
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Krishty
Establishment
Beiträge: 7414
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Krishty »

Schrompf hat geschrieben:Das Problem ist nur, dass NVidia-Karten die Texturerzeugung verweigern, wenn man R16F mit dem Rendertarget-Flag kombiniert. ATI-Karten machen das dagegen stressfrei mit. Ich vermute mal, unter DX10 würde man das selbe Verhalten beobachten...
Da D3D10 jede Unterstützung vorschreibt und die MSDN nur Typeless-Formate als explizit nicht-Render-Target-kompatibel nennt dachte ich, dass der Rest automatisch unterstützt werden müsste – aber das müsste dann ja auch auf Block-Compressed-Formats zutreffen, was ja eindeutig nicht der Fall ist … eine Liste der zwingend kompatiblen Formate finde ich tatsächlich nicht :/ Dann sollte ich es vielleicht auch nochmal überdenken, in 8-Bit-Texturen zu rendern.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Die Vorbereitungen laufen. Ich versuche in Kürze eine Demo bereit zustellen. Habe dafür angefangen, ein kleines Level zu machen. Eigentlich wird es sich nur um einen Raum handeln. Damit es etwas interessanter wird, habe ich auch versucht, da Wasser einzubauen.

Hier könnt ihr schonmal einen kleinen Blick riskieren :D
20090718e.jpg
20090718f.jpg
BlueShark
Beiträge: 79
Registriert: 28.02.2009, 19:55
Alter Benutzername: BlueShark

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von BlueShark »

Sieht ganz nett aus, jedoch sehen die Texturen ein wenig wischi-waschi aus, vor allem die Pfeiler im 2ten Bild, aber das wird ja sicher noch überarbeitet. Die Wasserreflexionen sehen übrigens gut aus.

Mfg
BS
Benutzeravatar
Schrompf
Moderator
Beiträge: 4181
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Schrompf »

Die Bilder sehen echt Klasse aus! Leider nur als Preview. Wenn man sie dann neugierig großklickt, fallen z.b. die extrem niedrig aufgelösten Texturen auf. Die Farne finde ich irgendwie optisch "flach": einheitsgrün mit seltsam schwarzen Rändern und irgendwie zerdrieselt. Der Boden ist anscheinend wortwörtlich zusammengesteckt :-) Vermutlich ein Ersatz für noch nicht funktionierende Überblendungen zwischen den Terrain-Materialien. Und ich vermisse jedesmal irgendwas Ambient Lightiges - AO würde es für den Anfang ja tun. Das verleiht Screenshots erst die richtige Tiefe.

Der Wassershader ist sehr schön! Den würd ich gern live sehen.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Krishty
Establishment
Beiträge: 7414
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Krishty »

Half-Life² mit Bunny im Abwasser :) BlueShark hat vollkommen recht, da hat mal wieder jemand den anisotropen Filter vergessen … ;) Die Übergänge vom grünen zum grauen Abfall sind mir auch etwas zu hart … ansonsten sehr ansehnlich und ich freue mich schon auf Normal-Mapping und indirekte Beleuchtung :)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Danke an euch für eure konstruktive Kritik! Ich werde versuchen, zumindest einige Sachen davon in den Griff zu kriegen.
Allerdings verzögert sich die Demo dann dementsprechend... muss auch schauen, wie ich zeitlich hinkomme.

Edit:
Schrompf, du hast recht... weil ich die Materialien nicht überblenden kann, und die Textur sich sonst so schäbig wiederholen würde, war das eine Notlösung.
Die schwarzen Ränder der Farne muss ich mal genauer schauen.
Die Texturen sind jetzt erstmal von einer Seite, wo es frei verfügbare gibt, die Quali ist dementsprechend.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

Konnte es nicht lassen, noch weiter am Wasser rumzuspielen... habe das Bild diesmal senkrechter gemacht, damit man den Refractionpart besser sieht. Was ganz explizit dazu gekommen ist, ist die Wassertrübung, also das die Sichtstrahlen unter Wasser gestreut werden. Es muss auch beachtet werden, dass eigentlich noch kein richtiger Himmel existiert, der sich da nun direkt spiegeln könnte.

Lange Rede kurzer Sinn... ich hoffe es sieht somit noch etwas echter aus.

An der Wand sind noch schäbige Shadowmapartefakte, aber da ich da eh nochmal ran will, ist es hoffentlich erstmal egal.
20090718h.jpg
Benutzeravatar
Zudomon
Establishment
Beiträge: 2171
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Zudomon »

20090721.jpg
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 238
Registriert: 05.07.2003, 11:17

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Lord Delvin »

sieht imho viel besser aus, und ist interessant zu sehen, dass du die selben Schattenbugs hast wie Splitterwelten.
Gruß
Benutzeravatar
Schrompf
Moderator
Beiträge: 4181
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] .: AsTrAl-TrAnSmIsSiOn :.

Beitrag von Schrompf »

Welche Bugs wären das denn? Ich seh auf den Bildern keine.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Antworten