Jetzt mal ganz ehrlich: Manche Projekte macht man, weil sie nötig sind. Dieses hier haben wir gemacht, weil jemand Sneaker liebt und wir ein Museum dafür bauen sollten. Im Browser. In 3D. Mit Unity. Und ich habe unterschätzt, was das heisst.
Das Storyboard, September 2020
Bevor eine Zeile Code existierte, gab es ein Storyboard. Fünf Seiten, gezeichnet, mit Bildunterschriften, wie in einem Film. Ich habe es noch, datiert 22. September 2020.
So ging es weiter, Panel für Panel. Macht der Besucher einen Schritt, läuft ein Basketballspieler von hinten an ihm vorbei und wirft Körbe, in einer Endlosschleife. Wände fahren hoch, an jeder Wand fünf Dunks. Klickt man einen Schuh an, löst er sich von der Wand und dreht sich langsam um 360 Grad, daneben die wichtigsten Fakten. Und wenn man weiter will, bewegt sich der Boden, biegt sich, und eine Wendeltreppe erscheint, die nach unten führt. Bevor man sie nimmt, taucht ein Skater auf, fährt das Geländer runter, und man kann ihm folgen.
Am Anfang des Storyboards steht ein Video: Morgengrauen, ein Tempel auf einem Hügel, moderne, saubere Säulen, die nicht ganz in die Landschaft passen. Auf dem Tempel eingraviert: „Dunk Museum". Titolo. Das war der Kunde, der Sneaker-Laden, und das war die Idee: keine Produktseite, sondern ein Ort.
Die Idee
Titolo verkauft Sneaker, und Sneaker sind Objekte, die man anschauen will. Von allen Seiten, im Detail. Ein Foto zeigt eine Seite. Wir wollten, dass man um den Schuh herumgeht, dass er auf einer Säule steht, dass der Raum etwas erzählt.
Das Museum sollte im Browser laufen. Kein Download, keine App, kein Store. Link anklicken, Tür aufstossen, drin sein. Und wer eine VR-Brille hat, sollte richtig drin sein, per WebXR. Wer keine hat, klickt und zieht mit der Maus, um sich umzuschauen. So steht es heute noch auf der Seite unter devpoint.org/dunk.
Unity im Browser
Wir haben Unity genommen. Nicht, weil es die leichteste Wahl war, sondern weil es die einzige war, mit der wir Physik, Animation, Licht und ein 3D-Modell mit hunderttausenden Vertices in einem Werkzeug hatten. Unity kann nach WebGL exportieren. Das klang nach einem Häkchen. Es war ein Projekt für sich.
Ein Unity-Build für den Browser ist ein Paket aus WebAssembly, Daten und Shadern, das beim Aufruf komplett geladen werden muss, bevor irgendetwas passiert. Was auf dem Rechner in Unity in Sekunden läuft, muss durch das Netz, in den Speicher eines Browser-Tabs, und dann auf einer Grafikkarte laufen, die man nicht kennt. Ein Laptop, ein altes Handy, ein Firmenrechner mit gesperrtem Treiber. Alles gleichzeitig.
Grösse, Speicher, Physik, Vertices
Das war der eigentliche Kampf, und er hatte vier Fronten.
Grösse. Ein Sneaker in guter Auflösung, mit Texturen für Leder, Stoff, Sohle, ist gross. Fünf davon, plus Raum, plus Kuppel, plus Spieler, plus Skater. Jedes Megabyte, das im Build steckt, ist eine Sekunde, in der der Besucher „Loading" liest und überlegt, ob er den Tab schliesst.
Speicher. Ein Browser-Tab hat eine Grenze. Wird sie überschritten, stirbt der Tab, ohne Fehlermeldung, ohne Log. Wir haben Texturen verkleinert, Modelle zusammengelegt, Dinge nur dann geladen, wenn man sich ihnen nähert. Und trotzdem sind Tabs gestorben, auf Geräten, die wir nicht hatten.
Physik. Ein Ball, der springt. Ein Boden, der sich biegt. Ein Skater auf einem Geländer. Physik in Unity ist einfach. Physik in Unity, die im Browser auf jedem Gerät gleich schnell und gleich aussieht, ist nicht einfach. Zu viele Schritte pro Sekunde und alles ruckelt. Zu wenige und der Ball fliegt durch den Boden.
Auflösung und Vertex-Zahl. Ein Schuh, der sich langsam um 360 Grad dreht, bei dem man die Nähte sehen soll, braucht Vertices. Viele. Fünf Schuhe an einer Wand, zwanzig im Museum, und die Grafikkarte im Browser gibt auf. Also weniger Vertices, wo man nicht hinschaut. Mehr, wo man hinschaut. Und jedes Mal die Frage: Sieht man den Unterschied? Meistens ja.
Der grösste Aufwand war das Budget
Und jetzt der Teil, den ich am wenigsten gern erzähle und der am wichtigsten ist.
Fakt ist: Der grösste Aufwand war nicht die Technik. Es war das Budget. Nicht, weil es zu klein war, sondern weil damals niemand wusste, was so etwas kostet. Es gab keinen Vergleich. Eine Website, das kannten alle. Eine App, das kannten alle. Ein begehbares Museum in 3D im Browser, mit Physik und Animation, das auf jedem Gerät läuft: Das hatte niemand vorher bestellt, und niemand hatte es vorher verkauft.
Also haben wir erklärt. Warum ein Schuh nicht einfach ein Foto ist. Warum „läuft im Browser" mehr Arbeit ist als „läuft auf meinem Rechner". Warum jede Wand, jeder Skater, jede Treppe nicht nur gezeichnet, sondern gebaut, optimiert und getestet werden muss. Und warum ein Gerät, das wir nicht haben, trotzdem funktionieren muss.
Das Erklären hat fast so lange gedauert wie das Bauen. Und es war die eigentliche Lektion: Wer etwas macht, das es noch nicht gibt, muss zuerst erklären, warum es so viel kostet. Sonst baut man es und zahlt selber.
Was man heute anders machen würde
Das Storyboard zuerst, immer noch. Die fünf Seiten vom September 2020 waren das Beste am Projekt. Bevor Code existiert, weiss jeder, was passiert, wenn man die Tür öffnet. Das würde ich heute genauso machen, nur mit einem Aufwand daneben, pro Panel.
Grösse und Geräte am ersten Tag festlegen. Wie gross darf der Build sein, auf welchem schlechtesten Gerät muss er laufen. Das sind zwei Zahlen, und sie bestimmen alles danach. Wir hatten sie nicht am Anfang. Wir hatten sie, als die Tabs gestorben sind.
Modelle mit Budget pro Vertex. Jeder Schuh bekommt eine Zahl, die er nicht überschreiten darf. Wer ein Modell liefert, liefert es in dieser Grösse. Das ist unromantisch und spart Wochen.
Und das Budget erklären, bevor man anfängt. Mit einem Storyboard, einer Liste der Fronten, Grösse, Speicher, Physik, Vertices, und einem Satz pro Front, warum sie Arbeit ist. Das hätte damals die Hälfte der Gespräche gespart.
Und trotzdem: Wenn ich das Video anschaue, die Kuppel, das Licht, den Schuh, der sich dreht, dann war es das wert. Es lief. Im Browser. Ohne Download. Und es hat Spass gemacht, was für ein Projekt in einer Bank oder bei einem Telekom-Anbieter selten der Punkt ist.
Ein Museum im Browser ist kein Häkchen in Unity. Es ist Grösse gegen Qualität, Speicher gegen Detail, Physik gegen Geräte, die man nicht hat. Und davor ein Budget, das man erklären muss, weil es niemand kennt. Das haben wir gelernt. Und der Schuh dreht sich immer noch.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert unser eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal bleibt ein Hüpfer drin. Das ist dann auch von mir.