CGI Kosten: Was wirklich hinter dem Preis steckt

Das häufigste Missverständnis in der CGI-Kalkulation: dass die Kosten in der Software stecken.

Es kommt selten direkt als Satz. Öfter kommt es als Frage: „Kann das nicht einfach ein Student mit Blender machen?" Oder als Feststellung: „Ich dachte, Software ist heutzutage doch erschwinglich." Oder als Vergleichs-Anfrage: „Ich habe ein Angebot, das ist halb so teuer."

Die Antwort auf alle drei ist dieselbe. Software ist die kleinste Position in der CGI-Kalkulation — in manchen Projekten buchstäblich die kleinste. Die Kosten liegen nicht in den Werkzeugen. Sie liegen in der Zeit, die es braucht, um mit diesen Werkzeugen etwas zu produzieren, das funktioniert. In der Planungstiefe, die verhindert, dass die Hälfte dieser Zeit auf Korrekturen verwendet wird. Im Risiko-Puffer, der verhindert, dass unvorhergesehene Probleme das Budget auffressen, ohne dass jemand es benennt.

In diesem Text beschreibe ich drei Konstellationen, in denen dieses Missverständnis zu konkreten Kosten wird — nicht als Theorie, sondern aus meiner eigenen Erfahrung. Die letzte davon ist die teuerste.

Die Software kostet nichts. Die Zeit kostet alles.

Ein Werbefilm soll mit einem digital erstellten Hintergrund ausgestattet werden — eine CGI-Umgebung, die das Produkt in eine bestimmte Welt versetzt. Der Auftraggeber hat recherchiert. Er weiß, dass die gängigen 3D-Programme für einige hundert Euro pro Jahr zu haben sind. Er hat gesehen, dass es Tutorials gibt, in denen Privatpersonen ähnliche Environments in wenigen Stunden bauen. Er fragt sich, warum mein Angebot so weit darüber liegt.

Das ist eine nachvollziehbare Frage. Die Antwort liegt nicht in der Software.

Was ein CGI-Environment für einen Werbespot tatsächlich kostet, setzt sich aus mehreren Faktoren zusammen, von denen Software vielleicht fünf bis zehn Prozent ausmacht. Der Rest liegt in Artist-Zeit — und Artist-Zeit ist nicht Cursor-Bewegen-Zeit. Es ist Entscheidungs-Zeit. Jede Textur, jedes Lichtsetup, jedes geometrische Detail ist eine Entscheidung, die getroffen, bewertet und gegen den Gesamteindruck des Shots abgewogen werden muss. Diese Abwägungs-Arbeit ist es, die skaliert — nicht die Werkzeugkosten.

Dazu kommt Pipeline-Erfahrung. Ein Environment, das in einer nachvollziehbaren, dokumentierten Struktur aufgebaut ist, lässt Korrekturen in Stunden erledigen. Ein Environment, das ohne Struktur entstanden ist, wird bei jeder Korrektur zum Risiko — weil niemand vorhersagen kann, was eine Änderung an einer Stelle an einer anderen auslöst. Die Differenz zwischen beiden ist nicht sichtbar im ersten Render. Sie wird sichtbar in Runde drei, wenn etwas geändert werden muss.

Und dann ist da die Planung. Bevor eine einzige Geometrie modelliert wird, gibt es Fragen, die beantwortet sein müssen: Welche Kamera-Position? Welche Brennweite? Welche Beleuchtungs-Logik soll das Environment tragen? Welche Elemente sollen sich physisch korrekt verhalten, welche können vereinfacht werden? Diese Fragen klingen nach Overhead. In Wirklichkeit sind sie die Investition, die entscheidet, ob das Environment beim ersten Review überzeugt oder ob es drei weitere Runden braucht.

Was ich in solchen Gesprächen sage: Die Software ist der Herd. Was das Gericht kostet, hat mit dem Herd-Preis nichts zu tun. Es hängt davon ab, was gekocht werden soll, wie viele Personen essen, und wie viel Erfahrung in der Küche steht. Das Missverständnis ist menschlich — und ich erkläre es lieber einmal explizit, als es unausgesprochen stehen zu lassen. Denn unausgesprochen wird es zum Problem, wenn das Budget auf Basis des Werkzeug-Preises gesetzt wurde, und die eigentliche Arbeit dann irgendwo eingespart werden muss.

Was in der Kalkulation fehlt, holt es sich in der Post

Der zweite Fall ist subtiler, weil er nicht am Preis scheitert. Er scheitert an dem, was die Kalkulation nicht enthält.

Ein CGI-Projekt wird beauftragt. Das Budget ist vereinbart, die Laufzeit ist definiert, die Liefertermine sind gesetzt. Was nicht definiert ist: die Anzahl der Korrekturrunden. Was nicht bewertet ist: das Risiko-Profil des Projekts. Was nicht spezifiziert ist: welche Asset-Varianten geliefert werden sollen, was als „fertig" gilt, was passiert, wenn sich das Briefing während der Produktion verändert.

Diese Lücken sind in der Auftragserteilung oft unsichtbar. Sie werden sichtbar, wenn das Projekt läuft.

Was ich als Risiko-Profil eines CGI-Projekts meine: Wie präzise ist das Briefing? Gibt es eine klare Visual-Referenz, oder ist „dramatisch und modern" die Leitlinie? Wie viele Reviewer werden den Output beurteilen? Wie entscheidungsfähig ist die Auftragsseite? Gibt es externe Abhängigkeiten — Produktfotos, die noch nicht vorliegen, Packaging-Designs, die sich noch ändern könnten, Drehtermine, von denen VFX-Elemente abhängen?

Jede dieser Fragen trägt ein Risiko, das sich in Artist-Zeit materialisiert, wenn es nicht vorab bewertet und eingepreist wurde. Ein Projekt mit einer unklaren Visual-Referenz ist ein Projekt, das mehrere Stil-Iterationen braucht, bevor die Richtung feststeht. Das ist keine Inkompetenz des Artists — es ist das direkte Ergebnis fehlender Vorab-Definition.

In meiner Erfahrung fehlt der Risiko-Puffer in den meisten Kalkulationen, die ich sehe, die nicht von mir kommen. Nicht weil die Auftragnehmer ihn vergessen hätten, sondern weil ein Angebot mit Puffer auf dem Papier teurer aussieht als eines ohne. In einem kompetitiven Prozess verliert das Angebot mit Puffer. Also verschwindet der Puffer.

Was danach passiert: Das Budget ist aufgebraucht, bevor das Ergebnis stimmt. Es muss irgendwo gespart werden. Fast immer passiert das im Finish — in den letzten Detail-Entscheidungen, in den letzten Licht-Korrekturen, in den letzten Integrations-Anpassungen. Genau dort, wo der Shot von „fast fertig" auf „fertig" wechselt.

Wenn ich kalkuliere, ist der Risiko-Puffer eine eigene Position, die ich explizit benenne und erkläre — nicht als versteckte Sicherheitsmarge, sondern offen als Spielraum für das, was wir noch nicht wissen. Das macht das Angebot auf dem Papier teurer. Es macht das Projekt in der Ausführung planbarer — weil das, was wir noch nicht wissen, irgendwo bezahlt werden muss, ob es in der Kalkulation steht oder nicht.

Wenn der Preis stimmt — aber zu spät

Der dritte Fall ist der, den ich in meiner Praxis mehrfach erlebt habe. Er beginnt mit einer Anfrage.

Ein potenzieller Auftraggeber beschreibt sein Projekt. Ich höre zu, stelle Fragen, kalkuliere. Der Kostenvoranschlag geht raus. Dann passiert eines von zwei Dingen: Entweder meldet sich der Auftraggeber nicht mehr — die Stille ist die Antwort. Oder er meldet sich und sagt, es ist zu teuer. In beiden Fällen läuft das Projekt woanders hin, zu einem günstigeren Anbieter, der das Projekt zu einem Preis übernimmt, den mein Angebot nicht erreicht hatte.

Das ist eine legitime Entscheidung. Der Auftraggeber hat ein Budget, das Angebot passt nicht hinein, er sucht eine andere Lösung. Das ist normales Geschäftsleben — und ich habe gelernt, es ohne Bitterkeit stehen zu lassen.

Was danach kommt, ist es, das mich beschäftigt.

Einige Wochen später — manchmal Tage, manchmal einen Monat — kommt eine Nachricht. Der Auftraggeber ist wieder da. Der günstigere Anbieter hat das Projekt nicht liefern können: technische Probleme, Qualitätsprobleme, Kommunikationsprobleme, manchmal schlicht Überforderung. Das Ergebnis ist nicht brauchbar. Der Termin rückt näher.

Ich frage als erstes: Bis wann muss das Projekt fertig sein? Die Antwort ist meistens „Ende der Woche" oder „in zehn Tagen". Ich frage als zweites: Was ist das verbleibende Budget? Die Antwort ist meistens ein Betrag, der deutlich unter meinem ursprünglichen Angebot liegt — weil der andere Anbieter das Budget bereits verbraucht hat.

An dieser Stelle lehne ich ab.

Nicht aus Trotz, und nicht als Denkzettel. Ich lehne ab, weil die Bedingungen, die jetzt auf dem Tisch liegen — wenig Zeit, wenig Budget, ein Projekt in unbekanntem Zustand, dessen Probleme ich nicht einschätzen kann — die Bedingungen sind, unter denen ich nicht liefern kann, was das Projekt braucht. Ein Versprechen unter diesen Bedingungen abzugeben wäre unehrlich. Es wäre das, was der günstigere Anbieter getan hat.

Was mich an dieser Konstellation beschäftigt, ist nicht der einzelne Fall. Es ist das Muster dahinter. Die ursprüngliche Preisentscheidung — das Angebot ist zu teuer, ich nehme das günstigere — hat Konsequenzen produziert, die am Ende deutlich teurer waren als mein Angebot. Der Auftraggeber hat zweimal bezahlt: einmal den günstigeren Anbieter, der nicht liefern konnte. Und einmal den Terminzwang, das beschädigte Material, den Neustart unter schlechten Bedingungen.

Ich sage das nicht, um mein Preisniveau zu verteidigen. Ich sage es, weil es die Kalkulations-Logik der ersten beiden Abschnitte auf konkrete Weise illustriert: Ein Preis, der zu niedrig ist, um solide zu kalkulieren, spart am Anfang. Er verrechnet sich am Ende.

Was eine solide Kalkulation tatsächlich kauft

Drei Konstellationen, eine Grundstruktur. Die Kosten entstehen dort, wo sie nicht eingepreist wurden — in der Planungstiefe, im Risiko-Puffer, in der Qualitäts-Reserve für den finalen Finish. Werden diese Posten in der Kalkulation nicht sichtbar gemacht, verschwinden sie nicht. Sie tauchen später auf, zu einem ungünstigeren Zeitpunkt und zu einem höheren Preis.

Mein Punkt für Auftraggeber, die Angebote vergleichen: Ein günstigeres Angebot ist nicht dasselbe wie ein günstigeres Projekt. Es ist oft ein Angebot, das denselben Faktoren nicht Rechnung trägt — und diese Faktoren werden im Laufe des Projekts bezahlt werden, ob sie im Angebot stehen oder nicht. Die Frage ist nicht, welches Angebot billiger ist. Die Frage ist, welches vollständiger ist.

Was eine solide Kalkulation tatsächlich kauft, ist keine Garantie auf ein perfektes Ergebnis. Es kauft Planbarkeit. Es kauft ein Projekt, das die Dinge, die schieflaufen können, bereits eingepreist hat — und das deshalb, wenn etwas schiefläuft, nicht sofort in eine Notfall-Situation gerät.

Das Ergebnis einer Kalkulation ohne diese Posten ist meistens ein Shot, der fast funktioniert. Das ist kein technisches Versagen. Es ist das direkte Ergebnis eines Budgets, das für das vollständige Projekt zu klein war.