AI & Rendering | Ein Haus aus Python: Vom Bauplan zur 3D-Szene mit einem Coding-Agenten
Ich hatte nie zuvor ein 3D-Modell erstellt. Ein Coding-Agent machte aus Bauplänen und offenen Geodaten eine Blender-Szene. Teil 1: Aufbau, Prüfungen, Fehler.
Wir planen eine Doppelhaushälfte auf einem Eckgrundstück in einer kleinen Stadt. Auf dem Grundstück stehen alte Bäume, und einer davon steht im Baufeld. Daraus ergibt sich eine schlichte Frage, die ich anderen Menschen beantworten muss: Wie sieht dieses Haus auf diesem Grundstück aus, wenn der eine Baum fehlt und alle anderen bleiben?
Mit Grundrissen und einem Lageplan im Maßstab 1:250 lässt sich das kaum vermitteln. Eine professionelle Visualisierung hätte ich für ein privates Vorhaben trotzdem nie beauftragt. Der Nutzen war mir die Kosten nicht wert.
Vor diesem Projekt hatte ich noch nie ein 3D-Modell erstellt. Blender hatte ich als Kind vielleicht einmal geöffnet, um ein Spiel zu verändern. Eine Woche nach Projektbeginn gibt es eine bearbeitbare Szene mit Haus, Grundstück und Nachbarschaft, zehn Präsentationsbilder, einen Kamerarundgang und am Ende sieben Außenbilder, mit denen ich sehr zufrieden bin.
Dies ist der erste von drei Teilen: der Aufbau. Teil 2 behandelt den Weg vom korrekten Modell zum guten Bild, Teil 3 die Arbeitsweise dahinter.
Eine Einordnung vorab. Das hier ist ein privates Projekt, ein Wochenendprojekt auf meinem Laptop. Spannend finde ich trotzdem, wie viel dabei möglich ist.
Der erste Versuch scheiterte an der Geometrie
Der naheliegende Weg war ein Bildmodell. Ich nahm ein einfaches Foto des Grundstücks und ließ die Bildgenerierung von ChatGPT ein Haus hineinprojizieren, mit zwei Fassadenzeichnungen als Referenz und einer Beschreibung.
Das Ergebnis sah auf den ersten Blick plausibel aus und war in fast jedem Punkt falsch. Es fing bei den Bäumen an. Sie standen an den falschen Ecken des Grundstücks, und damit war der Versuch schon gescheitert, bevor es überhaupt um das Haus ging. Das Haus selbst war um mehr als 90 Grad verdreht, die Gartenseite mit den Terrassentüren zeigte zur Straße.
Für meine Frage ist das wertlos. Wer beurteilen will, wie ein Baukörper zu sieben Bäumen steht, braucht Abstände, Höhen und Himmelsrichtungen, die stimmen.
Die Schlussfolgerung stand danach im Briefing für den nächsten Versuch: Die Geometrie muss explizit kontrolliert werden. Das Haus wird als 3D-Körper aus den Planmaßen konstruiert, und erst danach entsteht daraus ein Bild.
Warum Blender
Ich habe Codex gefragt, einen Coding-Agenten von OpenAI, der mit dem Modell GPT-Astra lief. Ein Coding-Agent ist ein AI-System, das selbst Programme schreibt, sie ausführt und das Ergebnis prüft. Meine Frage war, welches Werkzeug sich lokal auf einem Mac für eine solche Visualisierung eignet. Meine einzige Bedingung war, dass ein Agent damit gut arbeiten kann. Die Anregung kam von Alejandro Saucedo, der kurz zuvor ein 3D-Experiment mit demselben Modell gezeigt hatte.
So eine Frage ist fast immer der beste erste Schritt. Wer nicht weiß, wie sich ein Problem lösen lässt, klärt zuerst den Stand der Technik. Sehr wahrscheinlich hatte schon jemand ein ähnliches Problem. Ein wirklich neues Problem muss man nur selten lösen.
Die Empfehlung war Blender, ein freies 3D-Programm, mit dem sich Modelle erstellen und daraus Bilder berechnen lassen. Blender lässt sich vollständig über die Programmiersprache Python steuern. Geometrie, Materialien, Kameras, Licht und die Berechnung der Bilder, das Rendering, lassen sich als Skript beschreiben und wiederholbar ausführen. Für einen Coding-Agenten ist ein Haus damit ein Programm. Das ist ein Heimspiel, denn wenn Sprachmodelle eine Sache gut können, dann ist es Programmieren. Der Agent schreibt Code, führt ihn aus, betrachtet das gerenderte Bild und korrigiert den Code.
Ich hatte dem Agenten einen Beitrag gezeigt, der empfahl, das Modell einfach vier bis sechs Stunden an vorgefertigten 3D-Modellen und Materialien arbeiten zu lassen, sogenannten Assets. Die Antwort war nüchtern: Zeit allein stelle keine Qualität her. Gebraucht würden ein konkretes Briefing, ein Abgleich gegen die Pläne und visuelle Tests. Wenige Minuten später schrieb er sinngemäß:
Erst diese visuelle Rückkopplung macht den Ablauf brauchbar. Dass der Code fehlerfrei durchläuft, heißt noch nicht, dass das Gebäude richtig aussieht.
Die Einrichtung dauerte eine Viertelstunde. Gearbeitet hat der Agent danach im Hintergrund: In meinem offenen Blender-Fenster passierte nichts, das Modell entstand in einem anderen Prozess.
Für mich ist das völlig in Ordnung. Aus der Programmierung bin ich es inzwischen nicht anders gewohnt. Für den Code darunter interessiere ich mich nicht mehr. Er ist zur Nebensache geworden, das Ergebnis zählt.
Das Briefing
Bevor der Agent eine Zeile Blender-Code schrieb, bekam er ein Briefing als Datei. Es hatte sieben Abschnitte:
- Ziel. Wofür das Bild gebraucht wird und was es aussagen soll: ein zurückhaltendes weißes Haus, ein Baum fehlt, alle anderen bleiben.
- Technik. Freie Wahl, aber mit dem Befund aus dem gescheiterten Versuch: Geometrie explizit kontrollieren.
- Das Haus. Verbindliche Fakten aus den Plänen: Gebäudeabmessungen und Dachneigung, Fassadenmaterial, Anzahl und Lage der Photovoltaikmodule sowie die Lage der drei Eingänge.
- Das Grundstück. Form, Lage zur Straße, Grenzabstände, Baumstandorte mit Stamm- und Kronendurchmessern aus der Vermessung.
- Materialinventar. Jede Datei mit Pfad: Grundrisse, vier Ansichten, Schnitt, Lageplan, Gesprächsnotiz, fünf Grundstücksfotos.
- Regeln. Keine kostenpflichtige Bildgenerierung, nichts verlässt den Rechner.
- Erste Aufgaben. Orientierung klären, Fotos den Standorten zuordnen, Daten- und Arbeitsplan vorlegen, offene Fragen stellen. Danach anhalten.
Der letzte Punkt war der wichtigste. Der Agent sollte vier Vorarbeiten erledigen und dann auf meine Freigabe warten. Mit dieser Stoppregel wollte ich verhindern, dass er sofort modelliert und fehlende Angaben durch eigene Annahmen ersetzt.
So kam stattdessen eine Liste von Widersprüchen zurück, die in meinen eigenen Unterlagen steckten. Zwei Pläne nannten unterschiedliche Abstände zur Straße, einmal vier Meter, einmal drei. Das Dachmaterial war nirgends belegt. Ich habe jede Frage einzeln entschieden.
Eine meiner Rückfragen hat den Maßstab für den Rest gesetzt. Ich wollte wissen, ob er die korrekten Maße nicht ohnehin aus den Planungsunterlagen habe und deshalb gar keine Näherungen brauche. Die Antwort trennte beides sauber. Die Gebäudemaße stammen aus dem Plan und werden nicht geschätzt. Geschätzt wird nur dort, wo die Unterlagen nichts hergeben, und jede Schätzung wird als solche markiert.
Offene Geodaten für die Nachbarschaft
Ein Haus im leeren Raum beantwortet meine Frage nicht. Das Bild braucht die reale Nachbarschaft.
Unser Bundesland stellt dafür erstaunlich viel frei zur Verfügung. Der Agent nutzte die digitale Flurstücksgrenze aus dem Liegenschaftskataster, amtliche Luftbilder und 3D-Gebäudemodelle mit Höhe und Dachform. Die Grundstücksgrenze im Modell ist damit die amtliche Grenze und keine Abzeichnung aus einem fotografierten Plan. Eine Viertelstunde nach meiner Freigabe gab es das erste Rendering, und der Agent nannte es selbst nicht vorzeigbar.
Prüfungen als Code
An dieser Stelle bat ich den Agenten, das Modell per Code gegen die Zeichnungen aus den Planungsunterlagen zu prüfen, damit auch alle Fenster und Außenbereiche stimmen.
Der Agent schrieb daraufhin Prüfskripte, die das Modell mit der Geometrie in den Plan-PDFs abgleichen. Der erste Lauf fand echte Fehler. Eingänge und Fenster saßen einige Zentimeter zu hoch. Die Ursache war ein Bezugsfehler, den ich selbst nie gefunden hätte: Die Ansichten im PDF messen ab der Rohdecke, also der nackten Betondecke. Das Modell rechnete ab dem fertigen Fußboden, der darüber liegt.
Nach der Korrektur bestanden alle 23 Fenster und Türen der Fassaden den Vergleich, mit einer größten Abweichung von 8,1 Millimetern zur Linienführung im PDF. Der Agent legte zusätzlich die gerenderte Ansicht halbtransparent über die Planzeichnung. Diese Überlagerungen fanden zwei Fehler, die kein Maßtest zeigt: überlappende Wandflächen an den Gebäudeecken und eine Dachfläche, deren Außenseite nach innen zeigte.

Das Muster hat sich durch das gesamte Projekt gezogen. Fehler, die im Bild auffielen, wurden danach zu Prüfungen. Nachdem Möbel über der Terrasse geschwebt hatten, ergänzte der Agent eine Bodenkontaktprüfung. Eine Kamera stand in einem Nachbargebäude und lieferte ein schwarzes Bild, seitdem prüft ein Skript jedes gerenderte Bild auf Schwarz. Und als alle vier Terrassenstühle mit dem Rücken zum Tisch standen, kam eine Prüfung hinzu, die die Ausrichtung jedes Stuhls zu seinem Tisch misst. Später verglich der Agent vor jedem größeren Umbau mehrere tausend geschützte Objekte mit einem Referenzstand, damit eine Änderung am Rasen nicht unbemerkt ein Fenster verschiebt.
Darin liegt der eigentliche Vorteil des Ansatzes. Code ist wiederholbar und prüfbar. Dieselbe Prüfung läuft nach jeder Änderung noch einmal und liefert ein eindeutiges Ergebnis.
Bildkritik per Bildschirmfoto
Meine Steuerung in dieser Phase bestand fast vollständig aus Bildschirmfotos mit ein paar Sätzen in Alltagssprache. Getippt habe ich keinen dieser Sätze. Ich habe alles mit Wispr Flow diktiert, einem Diktierprogramm. Die Spracherkennung machte aus „Render“ gern „Ränder“ und einmal einen „Rohr-Render“. Die Agenten haben es jedes Mal verstanden.
Auf dem Bild ganz oben enden die Zufahrten vor dem Gehweg. Mein Kommentar dazu war, dass das Pflaster bis zum Gehweg reichen muss, weil dort Autos fahren.
Ich habe mir dabei auch selbst widersprochen. Erst sollte die Hecke vor dem Haus weg, drei Nachrichten später wollte ich sie doch behalten. Einen sachlichen Grund gab es dafür nicht, mit Hecke gefiel es mir einfach besser. Der Agent setzte beides kommentarlos um. Die Korrektur kostete wenige Minuten.
Das kürzeste Feedback des Projekts kam am zweiten Morgen und wirkte sofort. Ein Bildschirmfoto der Terrasse und ein Satz: Die Stühle stehen falsch herum. Vier Stühle, vier Fehler, immerhin konsequent. Ein Mensch hätte eine Terrasse nie so eingerichtet, höchstens jemand, der mit seiner Partnerschaft unglücklich ist. Dem Agenten ist so etwas egal.

Der Rundgang
Am zweiten Tag wollte ich eine Kamerafahrt durch die Szene. Einen Qualitätsanspruch hatte ich dabei nicht. Ich wollte sehen, ob es funktioniert, und das Ergebnis auf LinkedIn zeigen.
Der Agent plante sechs Fahrten und rechnete nach dem ersten Testbild hoch: rund neun Stunden Renderzeit. Neun Stunden für Bilder in dieser Qualität waren abstrus. Wozu der Aufwand, wenn das Modell so schlecht aussieht? Auf meine Frage, warum so lange, kam die ehrliche Antwort, dass er Qualitätseinstellungen gewählt hatte, ohne vorher die Gesamtlaufzeit zu messen. Mit kleinerer Auflösung und gemessenen Zeiten je Bild wurden aus neun Stunden 40 bis 50 Minuten.
Der Vorteil einer Szene zeigt sich an dem Bild, das meine Ausgangsfrage am direktesten beantwortet. Eine senkrechte Draufsicht zeigt die Kronen der verbleibenden Bäume in Grün und die Krone des Baums im Baufeld in Rot. Ihre Durchmesser stammen aus der Vermessung. Aus einem generierten Bild lässt sich so etwas nicht ableiten. In einer Szene braucht es dafür eine weitere Kamera und ein kurzes Skript.
Was schiefging
Die Fehlerliste der ersten vier Tage umfasst 28 Einträge. Zwei davon:
- Fahrradstellplatz und Weg ragten über die Grundstücksgrenze hinaus.
- Ein Aufräumskript versteckte die fertigen Bilder, sodass mein Finder einen leeren Ordner zeigte.
Auffällig ist, wie die Fehler gefunden wurden. Die meisten fand der Agent selbst, beim Betrachten eines Renderings oder durch eine seiner Prüfungen. Die übrigen habe ich im Bild gesehen. Dass ein Skript ohne Fehlermeldung durchlief, hat in keinem dieser Fälle etwas bedeutet.
Der erste vorzeigbare Stand

Die aktive Arbeitszeit des Agenten lag nach den Protokollen bei gut sechs Stunden, verteilt auf drei Tage. Der erste vorzeigbare Stand entstand an einem halben Nachmittag.
Meine Frage war damit beantwortet. Ich konnte sehen, wie das Haus zwischen den Bäumen steht, aus der Luft, von der Straße und aus dem Garten.
Für mich war das Projekt an diesem Punkt eigentlich erledigt. Die Qualität entsprach dem, was ich von typischen Immobilien-Renderings kenne: lieblos auf ein Bauschild geklatscht, wo man sie dann jahrelang ansehen kann, weil das Bauvorhaben nicht vorangeht.
Für ein ähnliches Vorhaben würde ich mit einer Geometrie aus den Planmaßen beginnen, mit einem Briefing, das Fakten von Annahmen trennt, und mit einer ausdrücklichen Pause für Rückfragen. Danach würde ich Prüfungen als Code verlangen, trotzdem jedes Bild ansehen und die Renderzeit messen, bevor ein langer Lauf startet.
Den Kamerarundgang habe ich auf LinkedIn gezeigt. Die Reaktionen aus der Visualisierungsbranche, von Architekten und aus der Baubranche waren deutlich. Ein 3D-Artist schrieb, 1990 lasse grüßen. Andere nannten das Ergebnis sinnlos, peinlich und dürftig, und ich solle den Feed damit verschonen. Ein Teil dieser Kritik war angreifend und im Ton unter aller Sau.
In der Sache hatten sie recht. Die geprüften Maße stimmten, aber die Bilder sahen schlecht aus. Und einen besseren Ansporn als „Das Ergebnis ist scheiße, mach es besser“ kenne ich nicht. Mein Ziel war längst erreicht, alles danach ist für mich reiner Bonus. Es wurde eine Achterbahnfahrt durch das 3D-Modellieren mit AI. Davon handelt Teil 2.
Stehen Sie vor einem komplexen Problem? Vor jeder Zeile Code: ein Gespräch. Kein Pitch, keine Verpflichtung.
Gespräch buchen