Schatten !!

In den letzten 2 ½ Monaten habe ich für einen Auftraggeber über 34 Hintergrundbilder gezeichnet, bin also „back to the roots“ geschritten und dabei fiel mir ein uraltes Buch aus dem Schrank in die Hände

„Burne Hogarth: Dynamic Light and Shade“.

Dabei wurde mir nach Ewigkeiten wieder bewusst, wie wichtig diese Eigenschaften sind.
Neben den neuen Lichteigenschaften im WED, dem supertollen Decal-Management und auch dem neuen Befehle „target_map“, der uns es jetzt ermöglicht, richtig geile Cockpits zu machen. – sollte jetzt unbedingt ein neues Schattensystem her.

Nicht mit irgendwelchen Shadern aus der Community sollten Landschaften besser darstellbar sein, sondern zumindest die Terrains brauchen eine Schattenberechnung als Standarteinstellung.

Schaut man sich z.B. „Prava“ an, ein Spiel, das wirklich spieltechnisch verdammt viel hergibt – wie geil würde es aussehen, wenn die Landschaftsflächen einen ordentlichen Schatten werfen würden.

Wir brauchen also bitte, bitte ein ordentliches Schattensystem. Das würde der A7 momentan einen ganz fetten Feinschliff verpassen!

Ich weiß, dieses Feature wurde schon 100x gefordert, steht auch auf der forecast-Liste als "hoch eingestuft", aber hier klaffen noch im direkten Bezug zu anderen Engines für den Hobby-Sektor unschätzbare Distanzen.

und es wird auch jetzt nicht früher kommen... conitec kümmert das feature einfach nicht, musst du dich damit abgeben. Neue schatten können frühestens mit A8 wenn nicht, sogar erst später.

Meinst Du das jetzt zynisch oder sarkastisch??

Entschuldigt, wenn ich Euch jetzt nicht im Detail folgen kann:

Geht es um dynamische Schatten oder um gebackene Schatten, denn, wenn du vom Terrain und von Landschaft sprichst, nehme ich an, dass Du eher gebackene Schatten meinst.

von der Betaseite:
V7.08.7b beta - released 4-Jun-2008:


Ich habe es noch nicht ausprobiert, aber wenn es richtig funktioniert, müßte man mit dem Code aus dem Wiki recht schnell ein Ingameshadowmapping hinbekommen.
Kann sein, dass das dann furchtbar langsam wäre, das kann ich nicht beurteilen.

Slin und ventilator hatten ja mal Beispiele von älteren Betaversionen gezeigt, wäre schön, wenn man jetzt mal sehen könnte wie die gleichen Level mit der neuen Version berechnet aussehen würden.

Naja, gebackene Terrain-Shadows sollten wirklich der Vergangenheit angehören. Wie willst Du mit gebackenen Texturen eine Sonne aufgehen lassen?

Trotzdemm, schau Dir mal dieses uralte Spiel an. Beachte, wie die Standart-Texturen mit dem Schattenwurf harmonieren!

think tanks


Ordentliche Schatten sollten gerade in Kombination mit der A7-Shader-Sammlung doch so sebstverständlich. sein.

weder noch...

das wird alles schon seit 2006 gefordert! Und bis jetzt hat sich großartig nichts getan...

Im Forecast steht dieses, und ich würde das so verstehen, dass damit statische Schatten gemeint sind, wahrscheinlich könntest Du über ein Tauschen der 2. UV-map den Schattenwurf eines Tageslaufs simulieren, aber Echtzeitschatten ist das ja nicht.



Welche Engine, außer vielleicht die von FarCry hat denn dynamische Schatten für ein ganzes Terrain?

einfach nur realistisch. dank der JCL-Quotes haben wir das versprechen sogar mit datum,

Alpha_Strike: Bist du dir ganz sicher das Think Thank dynamische Terrain-Schatten wirft? Denn in den Movies sieht das nicht so aus. Das Terrain wirft zwar Schatten, sowie alle statischen Objekte. Aber die dynamischen Objekte haben alle keinen Schatten.

Ich kenne ohnehin nur sehr wenige Spiele die einen echten dynamischen Schatten auf dem Terrain werfen. Wahrscheinlich aus Performencegründen. Spontan fällt mir Spellforce ein, hat aber geruckelt wie sau. Selbst Far Cry (bei Cryisis weiß ich es nicht) hat keinen dynamischen Terrain Schatten. Ist alles vorberechnet.

Was ich persönlich mir im Bezug auf Schatten wünschen würde wäre wie im CryEngine Sandbox Editor die Möglichkeit, Radiosity-Lightning für ein Terrain vorberechnen lassen zu können. Diese vorberechneten Schatten dort sehen einfach nur genial aus und kosten Null Performence da vorberechnet. DAS wäre wirklich mal ein nützliches Feature (für WED bzw MED).

Wie dem auch sei. Meine Freizeit verbringe ich derzeit mit 2D-Grafiken für DS-Spiele. Ich hätte aber gerade nach dem neuen Update (target_map) dermaßen Bock ein Mech-Spiel anzugehen! Aber dafür sollte man einfach eine gute Landschaftsdarstellung haben. Terrain-Schatten sind das mindeste Feature, das man hierfür bieten sollte.

>>
... Terrain shadows are of course possible with any hardware, and have nothing to do with the shader templates. They are on our high priority list as you can see in the forecast page. #94937 - 10/24/06 11:56 AM
<<

Beten wir zu Gott, daß JCL dieses Vorhaben endlich angeht.

Wenn ich Populist wäre, müsste ich mich jetzt sofort hinsetzen und das Feature programmieren. Gut, dass ich kein Populist bin.

Wie Sie im Forecast sehen, stehen Terrain-Schatten seit letztem Jahr mit höchster Priorität auf unserer Liste. Sie sollen als allererstes Feature in den neuen Shadow-Mapper implementiert werden. Mit dem alten Mapper war es nicht zu machen, da dieser dafür zu langsam und unpräzise arbeitete. Da der neue Mapper erst seit Kurzem fertig ist, kann Alexej die Terrain-Schatten erst jetzt implementieren. Es gibt vorher noch ein paar kleinere Modifikationen zu tun, dann geht es los mit den Schatten.

" Da der neue Mapper erst jetzt fertiggeworden ist, kann Alexej die Terrain-Schatten auch erst jetzt implementieren."

Tja,... in der Regel hilft Beten immer.

Also, "Think Tanks" wurde mit der Torque Game Engine (TGE) gebastelt. Und deren Terrain wird via Lightmapping schattiert.

Dynamische Objekte werfen allerdings, sofern denn gewünscht, einen dynamischen und recht weichen Schatten auf das Terrain.

Aber nicht alle Modelle. In Torque gibt es verschiedene Klassen/Modelltypen. Jede hat ihre Eigenart.

softshadows kann jeder selbst programmieren. klar, es gibt engines, die das schon von haus aus können, aber glaubt nicht, dass die es dann besser machen oder irgendeine magische engine-optimierung besitzen.

also, ich kann es nicht, und 99% aller user hier im forum sicher auch nicht. und ich will es auch gar nicht, da ich mich im jahr 2008 es gar nicht einsehe, den engineprogrammierern die arbeit abzunehmen. ich will einfach einen schalter umlegen, damit ein schatten fällt. professionelle und semiprofessionelle engines, die das nicht können, kann man an einer hand abzählen. 3dgs gehört dazu. was ich damit sagen will: es is einfach ein standardfeature.

ich weiß auch nicht, wann "eingehen auf userwünsche, die seit jahren wiederholt gestellt wurden" auf "populismus" umgetauft wurde. wenn sie es einfach nicht können, und die vermutung liegt ja nahe, da das feature schon so lange auf der liste ganz oben residiert, sei es magels wissen oder aus technischer unmöglichkeit, wie von ihnen ausgeführt, dann versprechen sie den usern doch bitte nicht das blaue vom himmel, herr lotter. das mag zwar ein toller marketing-schachzug sein, bilder von radiosity-lightgemappten WED-maps ins netz zu stellen und von schatten auf terrain zu schreiben, fakt ist, dass diese features einfach nicht existieren.

Die Tage habe ich folgendes erfahren:

Man starte WED, nutze den "Project Wizard" und erstelle einen Outdoor-Level.
In diesem Level befindet sich ein Windrad, welches sich dreht und einen weichen Schatten auf das Terrain legt. Soweit so gut.

Schaut man aber genauer hin, entpuppt sich das alles als Mogelpackung. Der weiche Schatten ist nichts weiter als ein Sprite mit Alphakanal, welches sich dreht. Also von dem Windrad-Modell völlig unabhängig.

Sobald das Terrain aber eine kleine Unebenheit aufweist, was ja für Terrains normalerweise auch üblich ist, verpufft der Effekt.
Verschiebt man das Sprite etwas nach oben, sieht es aus wie ein Propeller ohne Hubschrauber dran.

Als ich das gehört habe, konnte ich mir ein Schmunzeln nicht verkneifen.

Klar, jeder kann alles programmieren. Und sicher gibt es hier ganz dufte Progger, die jedem zeigen, wie man den nächsten Overkill programmieren kann. Doch leider haben die wenigsten dieser ganz tollen Progger mit dem GS ein Spiel auf den Markt gebracht.

Scheinbar sind es in den meisten Fällen eher die Skripter und Zeichner, die mit Hilfe von Herrn Lotters Arbeit ihr Gesamtwerk zusammenbasteln.

Ich zähle mich auch zu den Skriptern und Zeichnern, die bislang mit den fixen Features der Engine ihre Ergebnisse auf die Menschheit losgelassen haben.
Und darum finde ich es nach wie vor ganz superdufte, wenn JCL uns mit der Weiterentwicklung seiner Ideen konfrontiert.

Könnte ich selbst so eine Engine programmieren, dann hätte ich hier im Forum nichts verloren. Wozu auch?

Ich schließe mich vollkommen Brooza an.
Von der Engine erwarte ich den "magischen Schalter", der mir ein zufriedenstellendes Ergebnis liefert.

@Brooza:
Ich denke, wenn JCL schreibt, daß das neue System abgeschlossen ist und bald in die Beta-Phase kommt, dann dürfen wir ihm sicherlich Glauben schenken.

Nur wäre es nicht das erste Mal dass Herr Lotter verspricht sich um diese Features zu kümmern, weshalb diese Aussage ohne konkreten Ergebnisse in meinen Augen auch nicht viel mehr als heiße Luft ist.

okayokay, manchmal vergesse ich einfach den markt, den 3dgs ansteuern soll. klar ist es nicht jedermanns sache, aber was mir auch schon aufgefallen ist, dass andere communities viel schneller mit gangbaren lösungen auf der stelle ist. hier sind wir irgendwie etwas... faul.

Trozt allem ist das GS eine der stabilsten Hobby-Engines, die es auf dem Markt gibt. Negative Kritik habe ich für meine Spiele nur für die scheiß Grafik und unfaire Stellen bekommen. Niemals für irgendwelche Engine-Abstürze o.ä.
Schau Dir doch mal die Spiele der letzten Monate an.
Kritiken wegen Abstürzen und Rucklern bekommen eigenltich nur die Leute, die noch irgendwelche selbstgebauten Erweiterungen beifügen müssen.

@MS: Wenn JCL schreibt, daß der neue Mapper jetzt fertig ist, dann glaube ich kaum, daß er uns damit anschummelt.
Ich denke, das Teil kommt in einer brauchbaren Version bis Ende des Jahres raus.

@ Joey: Bist du dir da so sicher? Ich zähle mal auf, was ich so mitbekomme:

1: Slin arbeitet seit Monaten an Softshadows bzw. Shadowmapping Techniken die sich als Softshadows eignen könnten.

2: Chris3D arbeitet an PSSM Techniken

3: Ventilator hat zumindest einmal daran gearbeitet.

4: Ich selbst habe mich an die Tutorials von jcl gehalten und versucht ein allgemein taugliches Ergebnis damit zu erzielen. Sprich eine Methode, die auch für Terrains und größere Landschaften mit weit entfernten Lichtquellen noch anwendbar ist, durch z.B. Auflösungsoptimierungstechniken. Leider kein brauchbares Ergebnis bisher.

Das Problem ist denke ich, dass die Implementierung von einer wirklich guten Schattentechnik überhaupt und ganz und gar nicht leicht ist. Ich glaube nicht, dass das etwas mit unserer Faulheit zu tun hat, es dauert eben einfach ziemlich lange und frustet ziemlich, nie zu einem zufriedenstellenden Ergebnis zu kommen. LiteC ist in dieser Hinsicht leider auch kein positiver Faktor, und legt noch zusätzlich mit so kleinen Sachen -kein support von signed unsigned keywords- Steine in den Weg, die dann ein Ausweichen auf dll Basis nötig machen.

ich würde es schon auch gut finden, wenn es wirklich brauchbare schatten templates von conitec gäbe.

meine PSSM schatten funktionieren zwar, aber ich hatte noch keine zeit mich mit gutem filtering zu beschäftigen. es waren bis jetzt (mit 7.10 habe ich es noch nicht probiert) wegen einigen kleinen engine bugs auch immer workarounds notwendig.

@redphoenix: ja, so wie sehr viele arbeite ich auch an softshadows und ssao, außerdem an einem wassershader der dem aus farcry in nichts nachsteht. das problem an der sache ist, dass wir alle daran arbeiten - getrennt und meist noch mit der auflage von firmen, die uns verbieten, den code zu veröffentlichen. wir haben eben keinen "pool" an guten programmierern, die der engine zuschaffen und einheitliche schnittstellen für alle anderen anbieten - kostenlos, ähnlich der open source bewegung. das macht für 3dgs nur conitec. hier fuchsen tausende scripte rum, die sehr guten programmierern erleichtern, soetwas in 3dgs zu implementieren, allerdings unvollständig, zu speziell oder man sieht nur einen screenshot. für den "normalen" benutzer bleiben diese sachen außen vor und deswegen schreien sie immer, conitec solle dies und das und jenes implementieren. ich meine, die a7 ist so eine art weiteres abstaktionslayer über directx und hat nur wirklich grundlegende funktionen eingebaut, diese allerdings ziemlich gut verknüpft. ohne die templates wäre 3dgs kein toolkit für anfänger sondern eher für erfahrene programmierer.

und natürlich ist das alles ganz und gar nicht einfach. schattenberechnungen sind ein sehr komplexes thema - shader im allgemeinen sind ein sehr komplexes thema. von dieser seite verstehe ich den schrei nach "softshadows" oder "diesem über-engine-feature", obwohl es eigentlich schon machbar ist.

joey.

Naja, ich glaube, daß GS ein grundsätzliches Problem hat: Es ist keine klare Richtung erkennbar.

Dynamische, evtl. weiche, Schatten verbraten immer ordentlich Rechenleistung. Auch wenn die Algorithmen stark optimiert wurden. Von daher sollte man immer, wirklich immer, Lightmaps bei gewissen Bereichen in Betracht ziehen. Die sind nunmal vorberechnet und werden auf bestehende Texturen überblendet. Das macht sich in der Framerate deutlich bemerkbar. Ihr wisst ja selbst, welche höllischen Hardwareanforderungen Crysis hat.

Ich vergleiche jetzt mal mit Torque, da ich ja damit mittlerweile arbeite.
Ihr glaubt nicht, was es für einen Spaß macht, direkt bei laufender Engine Level zu bauen. Terrain formen und texturieren, Objekte platzieren und statische Schatten berechnen. Der Vorteil ist z.B., daß man sofort merkt, ob irgendwo ein Frameratenkiller dabei ist oder nicht. Klar, logisch. Man spielt ja sozusagen während dem Leveldesign. Sogenannte Interiors, vergleichbar mit Map-Entities in GS, kann man mit Portalen versehen, sodaß wirklich nur der Teil gerendert wird, der tatsächlich im Sichtbereich bzw. im näheren Sichtbereich ist. Statische Modelle werden in diesen Interiors (z.B. Tische, Stühle, Gitter, Fässer usw.) ebenfalls mit Lightmaps versehen.

Was ich damit sagen will ist, daß man nicht immer nur auf dynamische Schatten achten sollte. Statische Schatten sehen ebenfalls sehr gut aus und ziehen viel weniger Leistung. Nur an bestimmten Stellen sind weiche dyn. Schatten tatsächlich sinnvoll. Schaut Euch mal Doom 3, Quake 4 und F.E.A.R. an. Die ständige Flickerei und Flackerei ging mir mit der Zeit auf den Geist. Wohingegen Half-Life 2 fantastisch aussah. Die haben viel mit Lightmaps gearbeitet und dyn. Schatten nur dort verwendet, wo das auch Sinn ergab.

GS sollte also im Moment eher darauf abzielen, ein richtig schönes und durchdachtes Entwicklersystem zu sein. Wo wirklich jeder seinen Spaß hat.
PSSM und Shader XY sind eher Leckerlis, die zukünftig die Engine aufwerten sollten. Bis dahin aber ist Basisarbeit angesagt.

Torque selbst ist übrigens auch keineswegs perfekt. Dort ärgern mich auch diverse Dinge. Nur ist es eben so, daß grundlegende Features vorhanden sind und damit die Arbeit an einem Projekt deutlich mehr Spaß macht.

Diesen Satz müsste man 10mal goldig einrahmen und jedem vor die Nase halten der auch nur mit dem Gedanken spielt 3D GS zu benutzen. Den jeder der die Templates sch**se findet (so wie ich), steckt in dieser Situation diesen Rat gebrauchen zu können. Wollte ich nur mal schnell gesagt haben

fragt sich nur warum manche leute die templates scheiße finden.

Gerade das neue Templatesystem macht doch eigentlich einen guten Eindruck...

Trotzdem wäre es mir lieber, wenn man statt den Templates lieber neue Engine Features programmieren würde. Denn für die meisten von uns und alle die ernsthaft etwas mit der Engine machen wollen sind die templates vollkommen nutzlos!

[Edit] Auch der neue Treegenerator der im Forecast steht ist in meinen Augen total unnötig, denn 1. wir dieser sowieso nie so qualitativ hochwertig sein wie z.B. treemagik und außerdem kosten solche tools sowieso nicht die welt. Wenn man sich also mehr um Features kümmern würde, die nicht so einfach durch third party tools ersetzt werden können würde das der Engine sicher gut tun!

Schaut mal auf die Webseite von Conitec. Die Engine wurde 125 Tausend mal verkauft. Die "meisten von uns" sind aber nur eine recht kleine Zahl alter Kunden, die mehr rumnörgeln, als dass sie Geld in die Kassen von Conitec spülen. Damit scheint gerade die Anfängerfreundlichkeit der Tools und der Templates der Grund für den kommerziellen Erfolg zu sein. Ob diese Anfänger tatsächlich Projekte zu Ende bringen, ist da eine ganz andere Frage.

Allerdings muss ich als "nörgelnder Altkunde" betonen, dass für ein optisches Ergebnis Licht und Schatten die aller erste Voraussetzung sind. Selbst schlecht texturierte Level können mit dem richtigen Licht interessant aussehen. Umgekehrt wird es schwerer. Für visuelle Ergebnisse ist das entscheidend.

Die Templates sind, abgesehen von reinen Marketingplänen, völlig nutzlos.
Ganz toll. Man klickt sich in 2 Minuten einen Shooter zusammen. Eine Heldentat ohnegleichen.

Stattdessen wäre es viel sinnvoller, anhand von wirklich kleinen, allerdings sinnvoll angeordneten, Tutorials den Anfänger Schritt für Schritt anzuleiten.
So sind ebenfalls schnelle Erfolgserlebnisse gegeben und Anfänger verlieren nicht gleich die Lust. Nach und nach wird man immer besser und fängt automatisch an, selbst zu experimentieren.

Die Templates sind sicherlich nicht der richtige Weg.

Soweit ich das gesehen habe, kann man die neuen Templates besser als Basis für weitere Entwicklungen nutzen, als die alten. Sie könnten tatsächlich auch als Grundlage dienen.

Gerade beim Prototyping könnte das interessant sein. Eine total Abneigung gegen solche Techniken würde ich nicht aufbauen wollen. Immerhin ist Komponenten-basiertes Arbeiten in Java, Delphi oder anderen Umgebungen sehr beliebt.

Die Frage ist halt nur, wie leistungsfähig und flexibel eine Komponente ist und wie gut sie dokumentiert wurde.

Wenn, dann nur objektorientiert. Davon ist aber GS meilenwert entfernt.

Wir weichen etwas vom Schatten-Thema ab. Allerdings plant Conitec tatsächlich, Klassen einzuführen:



Weiter oben wurde erwähnt, dass es nicht besonders leicht ist, GS zu programmieren. Demnächst ähnelt es dem C++ Niveau. Zumindest liefert es einige der C++ Features. Die Frage, die sich mir stellt: Warum nicht einen C++ Wrapper schreiben? Die Time-Schleife könnte man auch mit einer Timer-Klasse lösen, die Timer-Events auslöst.

Aber all das ändert nichts daran, dass die Schattendarstellung verbessert werden muss (und scheinbar gerade in Arbeit ist, also lassen wir uns überraschen).

Die Templates sind per XML konfigurierbar und können in iegene Projekte eignebunden werden.
Ich halte das alles andere als verkehrt oder gar nutzlos.

Über Klassen kann man streiten. Sicher einfacher für den Anfänger ist die prozedurale Programmierung - und sie sind auch keine Notwendigkeit an der das Projekt scheitert.
Wer richtig OOP haben will, benutzt sowieso C++ und den Engine SDK.

Es ist also für jeden was dabei. Lite-C ist Lite-C und nicht C++...


Das Zusammenklicken innerhalb weniger Minuten mag in usneren Augen Unsinn sein und eingeschränkt wirken - aber viele wollen einfach genau das mal machen. Ein bissl rumbasteln, rumspielen OHNE sich monatelang einarbeiten zu müssen. Dieses Klientel soll mit den Templates bedient werden und ich denke sie sind auch ein durchaus wichtiges Kaufargument. Sonst würden sie nicht weiterentwickelt werden...
Nicht zuletzt wird 3dgs als Toolkit der keine Programmierkenntnisse voraussetzt beworben - anderenfalls wäre es mehr eine reine 3D Engine, die man wie die meisten anderen halt in seine C++ Umgebung einbettet.
Das tolle ist doch, daß 3dgs sowohl als auch kann - das hat man nicht sooo oft auf dem Markt - klar daß man dadurch auch mit Einschränkugnen leben muß. Aber das hätte sich jeder vorher denken können, wenn er sich schon so gut mit der Materie auskennt.

@Firoball:
Sehe ich nicht so. Kleine Tutorials helfen wesentlich mehr als einige wenige Mausklicks. Eine 3D-Engine legt man sich doch deswegen zu, um sein eigenes individuelles Spiel zu bauen. Ansonsten kann man sich ja gleich z.B. Doom 3 kaufen und mit dessen Editor spielen.

Übrigens ist OOP sehr leicht zu lernen und auch übersichtlicher als normale prozedurale Programmierung. Außerdem ist OOP nicht nur an komplexe Sprachen wie C++, Java oder ObjectPascal gebunden. Auch Scriptsprachen können das.

Nebenbei ist es höchst sinnvoll, das GS auf so eine breite Zielgruppe anzulegen.
125000 Käufer halten ja immerhin den Preis auf einem erträglichen Niveau.
Bei einer zu spezifischen Weiterentwicklung würden wahrscheinlich breitere Gruppen abspringen, was die Kosten der Engine in die Höhe treiben würde.

...naja... irgendwie haben wir alle was zu motzen, aber Hauptsache, der Laden geht weiter.

So ist der Standpunkt aus Programmiererrichtung - völlig richtig.
Ich selbst kann OOP, hab sowohl privat als auch beruflich damit zu tun und benutze auch keine Templates, also mir brauchst du das nicht zu erzählen.

Aber der gemeine User will auch mal ein Spiel basteln, und dazu möglichst wenig Tutorials wälzen, sondern gleich loslegen können (vergleiche zahllose Newbie Posts in beliebigen Foren die sich mit spieleentwicklung befassen).
Dazu ist so ein kurzes vorgekautes Startup Tutorial mit Templatesystem DER Weg.
Mal ganz abegsehen davon gibt es die von dir angesprochenen Tutorials z.B. in Form vom Lite-C Workshop. Der sit aufgeteilt in viele kleine Häppchen, und das ist imho schon ein recht guter Start.

Viele Leute wollen garnicht erst wissen was OOP ist.
Klar könnten sie einfach für ein Spiel modden - das haben vermutlich auch viele getan bzw. tun viele. Aber irgendwann will man etwas mehr (am besten ohne zusätzlichen Aufwand), und vor allem will man nicht mehr an ein fertiges Spiel gebunden sein.