1.) Nein

2.) Nicht aktiv, ab April wieder vielleicht - ist ja eher just for fun; wenn sich aber jemand findet, der darin investiert und ein eigenes Projekt damit verbindet, wäre das eine win-win Situation für alle Beteiligten

3.) ja, an der Qualität will ich feilen, SSAO sieht insbesondere auf hellen Flächen allgemein scheiße aus, wenn statische/dynamische Beleuchtung nicht berücksichtigt wird, aber dafür fehlt mir einfach die Zeit. Außerdem würde ich da wieder ein spezielles interface schreiben müssen, um die Standardfälle (static mesh lightmap, 8 dynamic lights) abfangen zu können, aber dennoch individuelle Lösungen zuzulassen. Auch wollte ich spezielle surfaces im Außenbereich unterstützen, beispielsweise terrains, wasser usw.; für Bäume usw. wollte ich das dynamische Einfügen von Vertexshader Anweisungen einbauen, um direkte Unterstützung von user-shadern zu ermöglichen, die über Vertexanimation arbeiten (Grass, foliage usw.)... mein Ziel ist es, das gesamte Unity-Featureset für SSAO abzudecken und dann noch ein paar Schritte weiterzugehen.

As soon as I have a million dollars .. .. investiere ich in eine awesome Schattenlösung von dir

Ich finde solche "Eins für alle Anwendungen" Komponenten sind Quark.
Im Endeffekt würde aus dem Versuch herraus eine Komponente (sei es Shader, KI, Level/Terraineditor, Animationslösung)
für alle möglichen Szenarien zu entwickeln, die Komponente selber
immer den kleinsten gemeinsamen Nenner suchen, oder im Featurecreep untergehen und schwer verständlich sein.

Was Ich für sinnvoller halte ist (bei open source Projekten) die Komponente gut dokumentiert und modular zu entwickeln.

So kann man, sagen wir mal bei einem Leveleditor, die Komponente "Terrain.mdl" exportieren später leicht herrauslösen, anpassen
und in seinem Projekteigenen tool einbauen.

Ich scheibe meinen eigenen Code nie architektonisch als "Widerverwendare" Komponente (und dem damit verbundenen Boilerplate Code).
Sondern speziell für ein Projekt. (und mit vielen Kommentaren..)
Beim nächsten Projekt schau ich dann bei spezialfällen (sagen wir mal einen fileimporter oder soundgenerator) die Codestelle an,
und mache copy-paste, und ein paar Frickeleien.
Die übergeordnete Architektur des Projektes wird aber neu und angepasst auf die Lösung geschrieben.


Ist der Code-Schnipsel gut dokumentiert geht das wesentlich schneller zu implementieren,
als erstmal zu lernen wie man die "all in one" fertiglösung passend einsetzt / zurechtbiegt.
ich hasse Workarounds die versuchen Features wieder "auszuschalten".
Und man macht sich bei Problemen abhängig von der Zeitplanung
des Komponentenentwicklers.

---

In anderen Worten: eine gut geornete Code-Snipplet sammlung
ist praktischer als monolitische Plugins.
..wenn man einen gewissen Grad an Erfahrung hat..

Genau das macht Shade-C ja zum Beispiel. Das ganze ist modular aufgebaut und dadurch nur eine Snippet-Sammlung. Wer keinen DOF braucht, inkludiert einfach den zugehörigen Snippet nicht. Wer keinen Terrain-Shader braucht, kommentiert den einfach aus. Das ist optimal und 50x besser als die Gamestudio mtlFX.c.

Genau so würde ich das auch als JCL zusammenstellen. Eine übergeordnete "shader_collection.c", wo dann die einzelnen Untershader inkludiert werden und ohne Probleme nach eigenen Bedürfnissen zusammengestellt werden können. Statt irgendwie alles wild in eine Datei zusammen zu pressen und die Hälfte auch noch von kruden Engine-Internas abhängig zu machen. Den PSSM aktiviert man zum Beispiel durch den shadow_mode. Dadurch ist eine Mischung von Verschiedenen Gamestudio-Schattenarten (zum Beispiel Blob-Schatten für Modell A, Stencil Schatten für Modell B und PSSM für den Außenbereich) in einem Level unmöglich. Völlig unpraktisch.

Ich hab zB gar keinen Plan von Shaders (auch mag ich viele der
ressourcenfressenden Shader einfach nicht)

Wenn ich zB einen Wasssershader bräuchte, fände ich es schön
eine Liste (Webseite) an 5/6 Wasser-Shadern mit Bildchen wie sie aussehen zu haben.
Und diesen dann einfach zu importieren. + ein paar veriable anzupassen.
Und dann nie wieder auf diesen Shader(Teufels)zeug schauen zu müssen.

Da ist mir Shade-C zu groß.

Ok. Wenn du sie nicht magst, kannst du sie in einer Lösung wie Shade-C einfach abschalten. Der DOF frisst Performance. Deshalb nehme ich nun der HDR. Und der ist super und zudem schnell. Wenn du nur Wasser willst, dann schmeißt du den Rest einfach raus.

Ein überarbeitetes, halbwegs zeitgemäßes Acknex Unlimited, von offizieller Seite gepflegt und gut präsentiert, hab ich schon vor Ewigkeiten vorgeschlagen.

Theoretisch gibts ja das Wiki. Problem ist nur, dass das so gut versteckt ist, dass es niemand findet. Ein 10x10 Pixel Link oben links auf einer Unterseite der Gamestudio Homepage ist halt etwas suboptimal.

Stimmt, das Wiki ist eigendlich der Anlaufpunkt
auf den man hier am meisten verweisen und in der Community mitarbeiten sollte.
(Neben dem Manual, welches durchaus gut gemacht ist)

Vielleicht sollte ich mal ein paar KI EinMalEins Schnipsel machen.

Das Wiki sollte man einfach mehr in den Mittelpunkt rücken und einen Link oben in der Hauptleiste platzieren. Dann würde es auch mehr Beachtung finden.

Übrigends wieder so ein offensichtlicher Punkt, der seit Jahren vorgeschlagen wird, aber trotzdem im Sande verläuft.