Der Landvogt

[Schrompf]

Nagut, dann habe ich Dich wohl missverstanden.

[Alexander Kornrumpf]

Aber ich denke es ist ein Missverständnis die Kritik jetzt sinngemäß als "soviel Arbeit kann ich mir als Einzelkämpfer nicht machen" abzubügeln.
Die Sache ist halt, ein generischens Exclamation Mark Icon über dem Gebäude zusammen mit einer textuellen Beschreibung im Gebäude-Menü (das es ja bestimmt gibt? Schlimmstenfalls Mouseover) was denn genau das Problem ist, wäre weniger Arbeit, vielseitiger verwendbar und besseres UI gewesen.

Und es ist in einem Freizeitprojekt ja 100% OK, dass du das machst worauf du Bock hast (heute mal ein Tor modellieren) und nicht das was in einem Kosten-Nutzen Sinn optimal wäre.

[Jonathan]

Naja, ich dachte mir halt "hey ich mach jetzt ein neues Icon, vielleicht krieg ich ja was hübsches hin" und hab dann die erste Idee umgesetzt und dann vielleicht gemerkt, dass die erste Idee nicht die beste war, aber dann meine Priorität verlagert, anstatt es hübscher zu machen. Es ist also nicht wirklich "so simpel wie möglich" sondern eher "wir machen jetzt mal einen vernünftigen Versuch, und leben dann damit, was dabei heraus kommt".

[Schrompf]

Wahrer Pragmatismus :-)

Würdest Du eigentlich Code-Beiträge zum Landvogt akzeptieren? Ich würde gerne meine Height Based Ambient Occlusion in Deinen Renderer integrieren.

[Jonathan]

Würdest Du eigentlich Code-Beiträge zum Landvogt akzeptieren? Ich würde gerne meine Height Based Ambient Occlusion in Deinen Renderer integrieren.

Uhhh, nice :)

Das trifft auch so ein wenig einen wunden Punkt. Wenn man sich die letzten paar Screenshots anschaut - ich glaube nicht, dass es nur an den Modellen liegt, das Shading ist einfach nicht besonders hübsch. Gut, die Grastextur ist momentan wohl das größte Übel, aber selbst dann...

Aktuell verwende ich ein recht einfaches Modell: Diffuse Map, ggf. Normal Map, ein BRDF-Modell von Frostbite (den Code gabs irgendwo - im Prinzip ein etwas schickeres Phong) und das mit einer direktionalen (Sonne) und Ambienten Lichtquelle. Ich hatte schonmal überlegt, ob ich statt dem Ambienten Term einfach ein Gegenlicht nehmen soll, um dem ganzen mehr Struktur zu geben. Oder ob ich ein HDR/float Rendertarget nehmen sollte und noch irgendein Tone-Mapping machen müsste. Oder halt ein Screen-Space Ambient Occlusion. Oder noch ein bisschen Post-Processing. Oder alles zusammen...

Was benötigt das Height-based AO denn? Prinzipiell hätte ich kein großes Problem damit, den Code zugänglich zu machen, die Frage ist halt, ob jemand das Ding kompilieren möchte (da hängen einige Abhängigkeiten drin). Allerdings müsste ich da auch erst nochmal was überlegen, ich benutze "intern" ein Git-Repo, das ist aber tatsächlich schon ziemlich alt (seit 2009) und ich hab keinen Überblick, ob da irgendwo noch Peinlichkeiten oder Vertrauliches drin versteckt sind, und will das auch nicht händisch filtern.

Shader sind wesentlich einfacher zu modifizieren, das geht zur Laufzeit. Vielleicht kannst du ja mal kurz skizzieren, wie man das einbauen würde.

[scheichs]

Erm Jonathan. Du weisst doch dass du eigentlich ein super liebevoller Deseihna bist. Du hast ja schon oft ein tolles und aussergewöhnliches Design bei deinen Projekten gezeigt (Hoppelhase, das letzte ZFX Projekt, etc.)

Tatsächlich wollte ich hier ein dringendes Bedürfnis anmelden, dass du die Art der Warnhinweise nochmal überdenkst. Natürlich ist es Dein Projekt und man will da nicht von aussen reingquatscht bekommen, aber ich muss es gesagt haben.

Ausserdem muss ich mir auch immer eure Kackmeinungen anhören ... Spass!

EDIT: Ich find den Landvogt übrigens ein mega spannendes Projekt!

[Schrompf]

Was Dein Repos angeht, kann ich Dir natürlich nix sagen. Die Ambient-Technik rendert die Welt von oben mit der Ortho-Projektion aus und speichert pro Pixel die Höhe. Das wird dann weichgezeichnet. Und jetzt kannst Du aus dem Unterschied zwischen Oberflächenhöhe und Weichzeichner-Höhe eine einfache Himmels-Verdeckung ableiten. So wird es unter Dächern, Karren und Bäumen etwas dunkler, ebenso rund um Hindernisse je nach Größe und Höhe derselben.

Das ist aber nur ein schneller kleiner Trick für Outdoor-Szenen. Du hast, denke ich, außerdem das Problem, dass Deine Oberflächen weithin identisch aussehen. Du bräuchtest etwas Varianz in den Wiesentexturen, vielleicht ne bräunliche Waldboden-Textur unter Bäumen, kleine Instancing-Meshes wie Gräser, Gebüsch, Schilf, Goldrute, Farn. Da hab ich theoretisch aus 10 Jahren Splitterwelten noch einige Modelle und Texturen rumliegen, die man auf die Schnelle einpflegen könnte. Alles hoffnungslos veraltet, was Polycount und Texturauflösung angeht, aber aus der Vogelperspektive reicht es sicher noch. Gibt dann natürlich Folgeprobleme, wie dass man Instanzen dann wieder entfernen muss, wenn sie durch Häuser oder Wege verdeckt werden. Oder dass sie sich im Wind bissl bewegen und ein bissl mehr, wenn ein Lebenwesen durchstreift.

Tja. Nix kommt einfach so geschenkt. Aber könnte sich lohnen.

[joeydee]

Schade dass ich einen anderen Termin hatte beim letzten Stammtisch :) aber ein klein wenig bekommt man auch was hier aus der Unterhaltung mit. Jedenfalls interessante Entwicklung!

Weshalb ich schreibe: Der "schnelle kleine Trick" wurde in Assassins Creed 3/4 für den niedrigsten der Multifrequenz-Passes für Ambient Occlusion benutzt. Hatte Schrompf in seinem Thread ebenfalls erwähnt.
Hier mal das PDF zu dieser Präsentation, nicht erschrecken, da wird der ganze GI-Lighting-Abklatsch behandelt. Interessant für speziell diese Tech sind nur die Seiten 41-44 unter der Headline "World Ambient Occlusion", und das ist unabhängig von der restlichen Pipeline. https://bartwronski.com/wp-content/uplo ... _notes.pdf

Und die Idee in diesem alten Post war im Kern dieselbe (der letzte Schritt im Post), nur stark vereinfacht für statische Anwendung als Textur, auf Block-Tilemaps und im Beispiel nur auf 2 Höhen bezogen (weil es auch um einen rudimentären Renderer ging): viewtopic.php?p=54284#p54284
Jedenfalls, Topdown-Depthmap Wechzeichnen und mit den originalen Höhendaten entsprechend kombinieren sind genau das Prinzip.
Die Basis dafür ist sogar eine relativ alte Tech, das kommt aus den Anfängen der digitalen Bildbearbeitung, es ist ein Hochpass-Filter, und wird z.B. beim Scharfzeichner benötigt. Und in den Texturmacher-Zeiten vor den Normalmaps etc. hat man so auch gerne lichtrichtungsunabhängige Tiefe in Texturen gebracht, woher auch die "Idee" aus dem verlinkten Post stammt.

[Mirror]

Habe eben auch mal den Landvogt ausprobiert. Die Grafik ist auf dem Niveau von professionellen Spielen. Die Kamerarotation mit der Maus ist viel zu sensitiv. Leider konnte ich nix richtig bauen. Ist die Version auf deiner Homepage die Aktuelle ? In den Videos findet man auch Buttons zum Straßen/Weg bauen. Leider konnte ich nur Baustellen platzieren. Vielleicht stelle ich mich aber auch einfach nur viel zu dumm an.. Ich lese nicht immer Alles sondern überfliege teilweise auch Postings. Vielleicht habe ich deshalb nicht alles mitbekommen...

Auf jeden Fall ist das Game einen Blick wert.

[Jonathan]

Habe eben auch mal den Landvogt ausprobiert.

Ach, nice :)

Die Grafik ist auf dem Niveau von professionellen Spielen. Die Kamerarotation mit der Maus ist viel zu sensitiv. Leider konnte ich nix richtig bauen. Ist die Version auf deiner Homepage die Aktuelle ? In den Videos findet man auch Buttons zum Straßen/Weg bauen. Leider konnte ich nur Baustellen platzieren. Vielleicht stelle ich mich aber auch einfach nur viel zu dumm an.. Ich lese nicht immer Alles sondern überfliege teilweise auch Postings. Vielleicht habe ich deshalb nicht alles mitbekommen...

Auf jeden Fall ist das Game einen Blick wert.

Naja, wenn du nur Baustellen siehst, wirst du wohl zu wenig Arbeiter haben und daher vermutlich zu wenig Häuser haben. Das steht alles im Handbuch erklärt ansich, aber das liest ja niemand, weswegen ich jetzt an einem Tutorial arbeite...

Ansonsten: Die Version ist uralt. Es gibt seit dem super viel neues Features, unter anderem:

- Straßenbau
- viel viel mehr Gebäude (3x so viele, oder so)
- viel mehre Baustoffe und Waren
- komplett neues Bedürfnissystem
- Forschungsbaum
- stark erweiterte GUI
- Flüsse und Seen
- Größere Maps
- Animierte Gebäude (zumindest einige)
- etc...

Ich habe lange nichts hochgeladen, aus folgender prinzipiellen Überlegung: Ich möchte gerne auf möglichst viel Feedback optimieren. Erfahrungsgemäß haben die allerwenigsten hier Bock, alle 2 Wochen eine neue Version zu testen und ihre Eindrücke zu dokumentieren. Aufmerksamkeit hat man also hauptsächlich einmal beim Release (wie bei echten Spielen auch). Wenn ich eine halbfertige Version hochlade und dann jeder die 4 offensichtlichen Probleme kommentiert, an denen ich gerade eh schon arbeite, naja, was bringt mir das? Daher wollte ich es "fertig" machen und dann hochladen, und basierend auf dem Feedback vlt. eine "Enhanced Edition" oder so machen. Möglicherweise könnte es vorher eine Tech-Demo ohne viel Gameplay geben, um schonmal die Kompatibilität zu prüfen...

Keine Ahnung, ob das so sinnvoll ist, aber das waren zumindest meine Gedanken. Ich könnte aber auf meiner Webseite schonmal die neue Seite anlegen, damit klar ist, dass die Version online nicht die aktuelle ist.

[Jonathan]

Btw.: Die aktuelle ToDo-Liste für Version 2.0:

Dom
Neues Dom-Bausystem, mit mehr Baustufen die sich auch wirklich unterscheiden. Außerdem wird man den Grundstein jetzt schon viel früher legen, den Dom zu vollenden ist schließlich das zentrale Spielziel, und die ganze Stadt sollte danach ausgerichtet sein, mit dem Dom hübsch in der Mitte, etc.. Zuvor war es so, dass man erst eine große Stadt gebaut hat und danach den Dom anfing (wenn schon alles erforscht war) und der dann halt irgendwo in der Ecke stand wo noch Platz war, und man dann quasi gewartet hat, bis er fertig ist.

Toller wäre es, wenn der wirklich im Mittelpunkt steht. Erste Phase, Grundgerüst, braucht Holz. Kurze Zeit später kann man Steine abbauen und so mit dem Mauern anfangen. Später braucht es dann Glasscheiben und Bier für die Künstler, die die Verzierungen umsetzen sollen. Immer wenn sich die Stadt weiterentwickelt kann also auch der Dom weiter gebaut werden und das zentrale Ziel ist immer im Fokus. Jede abgeschlossene Baustufe erhöht zudem die Zufriedenheit, so hat man einen Grund tatsächlich von Anfang an Ressourcen in den Dom zu stecken, anstatt nur die Wirtschaft auszubauen.

Das Problem ist nur, die Reihenfolge der Baustoffe ist derzeit Holz, Lehm, Steine. Metall oder Glas kommt nicht als Ressource vor. Klar kann ich jetzt sagen "Stufe 4 von 7 braucht Schafe, weil Gründe", aber macht es das toll? Naja, es verbessert die Spielmechanik, aber schadet vielleicht der Immersion. Mal sehen...

Tutorial
Das technische Grundgerüst steht, Skripte laufen und ein Teil der Mechaniken wird auch schon nett erklärt. Aber da auch komplexe Wechselwirkungen zumindest kurz gezeigt werden sollen, muss ich daran noch arbeiten. Könnte man aber vermutlich in 2 Tagen fertig kriegen.

Asset-Kleinkram
Es fehlen einige GUI Icons, ein paar Modelle, die Terrain-Texturen würde ich gerne nochmal tauschen und ein paar Modelle müssten geändert werden (Straßen sind super hässlich). Nichts davon ist tragisch, aber in der Summe sicherlich 20 Punkte...

Optional: Ganz viel (Grafik)-Kram
- Gras und Steine und sonstiger Kleinkram wären cool und würde die Grafik aufwerten. Das Instancing-System dazu ist halb fertig, aber auch eben halb unfertig.
- Das oben angesprochene Ambient-Occlusion wäre toll, vielleicht auch ein wenig Post-Processing. Bloom, Farbanpassung, Unschärfe?
- Animationen: Windmühlen drehen sich schon, der Kran am Lagerhaus arbeitet auch. Pferdekarren sind sogar schon echt schick. Ein paar andere Gebäude hätten aber auch noch Potential für Animationen. Aber vor allen Dingen...
- ... Menschen. Arbeiter, die übers Feld laufen, Fischer in Boten, Dorfbewohner am Marktplatz. Schafe, die über die Weiden laufen. Rehe und Häschen im Wald? Das würde so so viel Atmosphäre erzeugen, aber das System, die Arbeitsschritte abzubilden ist etwas Arbeit und vor allen Dingen braucht es viele Figürchen und viele Animationen. Aktuell sind es 27 Gebäude, da kommt echt viel zusammen. Es wäre so ein cooles Feature, aber theoretisch ist es optional, und aufgrund der Komplexität sollte ich wirklich erst den anderen Kram machen...
- Mehr Karten,Schwierigkeitsgrade und verschiedene Spielmodi. Wobei mir zu letzterem noch nichts eingefallen ist. Um den Dom zu bauen braucht man quasi alle Technologien, und baut einen guten Teil der Karte voll. Für Endlosspiel gibt es danach quasi nichts neues mehr zu tun. Karten könnten das Balancing ändern, auf trockenen Regionen sind Felder nur halb so effizient. Eh, dann baut man halt doppelt so viele, an der Strategie ändert sich wenig, das ist eher ein anderer Schwierigkeitsgrad. Auf eine gewisse Art werden im Standardspiel schon alle vorhandenen Features ausgereizt, aber vielleicht braucht es ja auch keine Spielmodi. Eine Online-Highscore mit "kürzeste Spielzeit zum Dom" wäre aber denkbar.

[marcgfx]

Vielleicht ist der Dom schon im Bau wenn man anfängt? Der Geldgeber/Auftraggeber ist gestorben/verschwunden und der Spieler als Bauherr will sein Projekt nun mit eigenen Mitteln vollenden? Ziel wäre dem Zerfall entgegenzuwirken und schlussenlich den Bau zu vollenden. Nur damit man das kann, braucht man Ressourcen und eigentlich eine ganze Stadt. Ressourcen kann man selber holen oder teuer einkaufen? Dann kann ich voll auf Schafherden setzen und mir den Dom zusammenkaufen :)

[Jonathan]

Update! Aktuelle Baustelle: Der Dom.

Die "Bauanimation" im Landvogt für alle Gebäude ist, dass sie sich einfach "fertig" aus dem Boden schieben. Zweckmäßig, und die meisten benötigen eh nur 5 Sekunden oder so. Aber der Dom soll in mehreren Stufen errichtet werden, mit jeweils eigenen Anforderungen. Also soll es zumindest für jede Stufe ein eigenes, statisches Modell geben. Fundament, Grundmauern, Dach, Dekoration, etc..

Leider gibt es vom alten Modell keine blend-Datei mehr und es verwendet eine einzige Colormap für das komplette Modell, inklusive AO-baking. Darüberhinaus wurde die Dreiecksstruktur automatisch optimiert, weswegen das Modell komplett uneditierbar geworden ist (egal was man ändert bräuchte man ein komplett neues Material, und das Mesh lässt sich halt auch nicht besonders gut bearbeiten).

Also hab ich alles von grundauf neu gebaut. Diesmal dann auch gleich mit Proportionen, die eher dem Original entsprechen:

Altes Modell:

Neues Modell:

Ich dachte, ich könnte das an einem Tag bewerkstelligen, am Ende hat das Modellieren aber sicherlich 20+ Stunden gedauert, verteilt über einige Wochen, weil ich zwischendrin immer wieder von dem Aufwand genervt war.

Diesmal ist das Mesh nach Materialien aufgeteilt, die jetzt auch Tiling verwenden. Das alte Modell hatte eine 4096^2 Colormap (das sind schonmal gute 50 MB) und sah beim reinzoomen doch verwaschen aus.
Ohne Ambient Occlusion geht es aber nicht, nur leider brauchte ich dafür dann entsprechend einen zweiten UV Channel und musste entsprechend die Engine erweitern und dafür sorgen, dass die Lightmap korrekt von Blender nach GLTF exportiert und danach korrekt von Assimp geladen werden kann. Aber es hat sich gelohnt:

Die Lightmap hat noch ein paar Artefakte (muss nochmal besser verstehen, wie man das in Blender richtig macht), aber der Unterschied ist trotzdem enorm und es war definitiv die Mühe wert. Die Groundplane muss ich beim Baken wohl auch noch mit einbeziehen, damit der Übergang zum Gras netter ist.

Als nächstes muss das Dach jetzt in der Sonne prächtig funkeln, der Dom muss ja als Stadtmittelpunkt schließlich eine Menge her machen. Dazu wird es wohl einen eigenen Thread geben.

[Schrompf]

Wow, der ist ja echt nice geworden! Und ja, das Light Mapping macht echt nen Unterschied!

[Jonathan]

Eine weitere, wesentliche Neuerung: Ein komplett neuer Modelviewer:

Ein In-Engine Modelviewer ist einfach Pflicht um schnell zu sehen, ob Modelle korrekt exportiert wurden und Material und Rendering im Spiel vernünftig aussehen. Ein guter Modelviewer ist natürlich auch super praktisch, um schnell mal 3D Modelle anzuschauen, ohne sie in Blender zu importieren oder im Spiel einzubauen, aber das das ist mir fast weniger wichtig, als Punkt 1.

Es gab natürlich früher schon einen Viewer, allerdings verwendete der noch Qt, was eine einzige Katastrophe war. Die DLLs machten IMMER Probleme (überhaupt halte ich dlls mittlerweile insgesamt für ziemlichen Quatsch) und Qt ist einfach auch super krampfig zu benutzen. Das schlimmste Problem ist, dass das OpenGL Widget (für den Viewport...) zwingend seine eigenen GL Bindings mitbringt und es gehörig knallt, sobald ich irgendeinen meiner Engine-Header mit deren Bindings inkludiere. Die komplette Logik war damit auf 3 große Dateien verteilt, eins für das Hauptfenster und alle Kontrollelemente, eine für das Render-Widget, und eine Viewer-Klasse die als einzige Engine-Anbindung hat und alles kapselt. Eine Katastrophe.

Nach einigen Engine Änderungen konnte ich den ganzen Quatsch dann nichteinmal selber mehr kompillieren, und die nötigen Umbaumaßnahmen an der Struktur waren die Sache einfach nicht wert. Ich konnte den Viewer weiter benutzen, aber nur mit den alten Render-Features, Neuerungen auszuprobieren war unmöglich.

Der neue Viewer basiert komplett auf ImGUI. Ich finds hässlich und hätte viel lieber native Bedienelemente, aaaaaber man muss sagen, die Entwicklung ist echt raketenschnell. Schwuppdiwupp waren alle möglichen alten und neuen Features eingebaut und der Code ist nichteinmal besonders lang. Unter anderem kann man jetzt auch Shader-Komponenten einzeln aktivieren und deaktivieren, womit die AO-Vergleichsbilder oben entstanden sind. Ich kann Shader zur Laufzeit editieren und mit 2 Klicks aktualisieren, und kriege sogar in den meisten Fällen gute Fehlermeldungen im Shader-Source und hervorgehobenen Zeilen, wo es denn gerade knallte. Das waren jetzt schon auch wieder einige Tage Infrastrukturarbeit, aber das ist halt einfach ab und zu nötig.

[Jonathan]

Eines der letzten fehlenden großen neun Features ist eingebaut und muss nur noch ein wenig poliert werden! Baustufen für den Dom:

Die Modelle sind noch nicht final, weil ich erst wissen wollte, wie viele Stufen ich überhaupt brauche, und dafür musste ich die Logik implementieren um sie testen zu können.

Jetzt wird der Dom also in mehreren Stufen gebaut, wobei jede davon eine andere Menge an Ressourcen und Bauarbeitern benötigt. Das war früher schon ähnlich, bloß ergab sich da die Steigerung aus simplen Formeln (e.g. für jedes Level 15 zusätzliche Arbeitskräfte) und die Baustufenmodelle waren provisorisch (man konnte nichts vom Innenleben sehen).

Jetzt ist alles neu und sauberer umgesetzt. Es gibt 2 verschiedene Zustände, "Warten auf Ressourcen" und "Bauen". Während dem Warten werden nun keine Arbeiter mehr benötigt, früher war es sinnvoll den Dom stillzulegen, wenn man eh gerade keine Baumaterialien hat, jetzt geschieht das automatisch.

Da man jetzt auch Gebäude selektieren kann (Fenster unten links), musste das auch umgebaut werden. Es passt sich jetzt dem jeweiligen Zustand des Gebäudes an, während dem Errichten und dem Produzieren sieht man also unterschiedliche Anzeigen (was früher nicht so war). Jetzt ist also sehr viel klarer, was ein Gebäude gerade macht.

Die Idee ist auch, dass man den Dom jetzt schon gleich am Anfang bauen kann, damit die Stadt organisch drum herum wachsen kann. Ich hatte überlegt, interessantere Kriterien für den Bau zu haben (z.B. "für Stufe 5 braucht man 35 Bier um die Mönche bei Laune zu halten"), hab mich dann aber dagegen entschieden. Es wäre blöd eine Produktionskette aufzubauen, wenn man das Bier bloß ein einziges mal braucht. Jetzt braucht man einfach die passenden Baustoffe (die ja auch im Laufe der Entwicklung freigeschaltet werden) und genügend freie Arbeiter, was im wesentlichen auf eine große Siedlung hinaus läuft. Klar, es wäre irgendwie nett, wenn eine gute Stadt und eine gute Stadt die eine Dombaustelle unterhalten muss irgendwie wirtschaftlich anders aufgestellt sein müsste (und man entsprechend für andere Großbauprojekte andere Schwerpunkte setzen müsste), aber dafür schien mir die aktuelle Wirtschaft mit den verfügbaren Gebäuden und Waren einfach zu simpel und die entsprechend zu erweitern verschieb ich einfach mal auf später.


Die nächsten Schritte sind:

- Balancing: Inklusive Herausfinden, wie viele Domstufen es geben soll und was die Voraussetzungen dafür sein sollen.
- Mehr Karten : Es sollte vielleicht mindestens so 3 Karten geben, wobei der Schwierigkeitsgrad vom Bauplatz und den verfügbaren Ressourcen bestimmt wird.
- Polishing: Ein paar Modelle hübscher machen, die GUI hübscher Layouten, etc.
- Tutorial fertig bauen

Und das war es dann endlich :)

[Schrompf]

Sieht jedenfalls toll aus!

[Mirror]

Wäre schön, wenn ich eines Tages auch mal so etwas modelliert bekomme. Sieht echt nice aus.

[Jonathan]

Wäre schön, wenn ich eines Tages auch mal so etwas modelliert bekomme. Sieht echt nice aus.

Vielen Dank :)

Wie sich für mich herausstellt, sind schönere Grafiken in erster Linie auch nur Fleißarbeit. Jemand sehr talentiertes und gelerntes kriegt das vermutlich alles viel schneller hin, aber für mich sind das im Wesentlichen einfach eine Iteration nach der anderen. Ich guck mir das Modell an, überlege, was mir daran nicht gefällt, mache eine kleine Änderung und danach ist es etwas besser. Hundert mal wiederholen und das ganze ist schon ein gutes Stück besser. Was am Ende dann einfach nur bedeutet, dass wenn man etwas besseres machen will, der erste Schritt einfach ist, viel mehr Zeit darein zu investieren.

[Jonathan]

Ich mecker hier einfach mal ein wenig über die hundert kleinen Probleme die ich so habe und die mich ständig aufhalten.

Es ist wirklich keine super tolle Idee, die Grafikpipeline umzuschreiben, nachdem man schon die Assets erstellt hat. Ich hab irgendwann den Standard-Shader auf ein besseres Modell gewechselt und jetzt neulich dann HDR-Rendering und Bloom eingebaut, damit der Dom besser aussieht. Jetzt sieht die Lehmgrube aber so aus:

Die Ursache ist, dass dieses Modell als eines der wenigen eine Specular-Map hat. Das ist ansich sehr nett, der Lehm glänzt damit viel mehr und sieht richtig nett feucht aus. Hier nochmal direkt im Vergleich:

Diffuse

Diffuse + Normal

Diffuse + Normal + Specular

Wie man sieht, macht die Specularmap also sogar nochmal mehr aus, als die Normalmap.

Das Problem ist jetzt, dass es zu sehr glänzt. Das Modell ist ~4 Jahre alt, damals wurde die Specularmap von der Engine glaube ich sogar noch komplett ignoriert, die Textur wurde also damals also für irgendein Materialmodell in Blender erstellt, wo das Glänzen damals vermutlich gut aussah und das wars dann. Heute sieht es aber ganz anders aus und verstärkt wird das ganze noch durch den kürzlich eingebauten Bloom-Effekt, der eigentlich nur am Kirchendach auftreten sollte, jetzt aber auch hier viel zu stark auftritt, so dass man bald meinen könnte, das Gebäude stehe in Flammen.

Der simple Fix wäre, das Materialmodell an die alten Modelle anzupassen, z.B. "shininess = specular_map.x / 2.0;". Aber ich will eigentlich nicht das Engine-Standard-Modell auf so eine Weise verunstalten, viel besser wäre es also, die Textur entsprechend anzupassen. Bloß tritt das ja vielleicht auch noch bei einigen anderen alten Assets auf, d.h. ich muss jetzt die ganzen alten Modelle wieder anpassen und fixen. Was man sich halt hätte sparen können, wenn man erst die Engine fertig gemacht hätte und dann die Assets passend dazu erstellt hätte. Tja.

[mtorc1]

Jonathan, sehr sehr stark. Allein schon das viele Sitzfleisch, das du bei dem Projekt schon bewiesen hast. Das macht richtig Spaß, die Entwicklung als Beobachter zu begleiten.

[Jonathan]

Vielen Dank :)
Es macht auch Spaß, den Fortschritt hier zu dokumentieren und immer wieder ein bisschen Feedback zu kriegen. Ich hatte irgendwann auch mal überlegt einen Blog anzufangen, vlt. sogar zweisprachig, aber letztendlich würden den wohl kaum Leute lesen. Hier gibt es nicht nur Publikum, sondern auch qualifizierte Antworten, das hilft schon echt für die Motivation.

[NytroX]

Was man sich halt hätte sparen können, wenn man erst die Engine fertig gemacht hätte und dann die Assets passend dazu erstellt hätte

Vielleicht nicht. Meistens wenn man ein Update macht, muss man die Assets oder die Engine auch anpassen. Liegt einfach daran, dass man dazulernt.

Glaub mir, du hättest dann das Dom-Modell später gemacht und dann überlegt, ob man nicht was in der Engine ändern kann, damit es besser aussieht.
Und andersrum hättest du die Engine später gemacht, wäre dir aufgefallen, dass man die Modelle ja jetzt auch besser machen kann, wo die Engine nun Feature <X> unterstützt.
Ich denke also das wäre dir so oder so passiert, ist bei mir auch so :-P

Schön, dass du an dem Projekt noch weiter machst.