rt-541

writing / 2026-09-26

A backyard, drawn from drone photos, rendered by the homelab

Five revisions of a deck, a stone patio and a fire ring in one day, with every drawing, check and quantity coming from one Python module, and photo-style views from a Blender worker on the NanoClaw fleet plus FLUX Kontext on a shared GPU.

The brief arrived as a sentence and a folder of eight drone photos: a composite deck with a stair at one corner and another down to a stone patio, a line of evergreens along the back fence, a French drain where the yard floods, and somewhere to grow vegetables. No tape measurements. The deliverable was the same shape as the other plans on this site: a drawing set someone could hand to contractors, a PDF, a 3D model, and a price list where every line is a listing that was actually read.

Reading the site from the air

Drone photos carry more than pictures. The flight heading in each frame’s metadata settled which way the house faces (the camera’s own gimbal yaw on this drone is not trustworthy; the flight yaw is), and a known width in frame gave a scale: the house came out about 52 ft across, the yard about 50 ft deep. Everything in revision A is marked as an estimate, and the first sheet lists the six measurements that turn it into revision B.

The photos also carry GPS coordinates. Those never leave the working copy; nothing published here says where the house is.

One module, many outputs

The plan lives in one Python file. Its DEFAULTS hold every number a person might change: lot, house, bay, chimney, deck, stair, patio, fire ring, trees, drain. Everything else derives from them, including the grade, which is a plane falling toward the back fence and toward the corner drain.

From that one module come:

  • the 3D model, exported to GLB, STEP and a Fusion 360 script;
  • the fifteen SVG drawings on the sheets (site plan, section, framing, elevations, stairs, patio, ring, seat wall, herb bed, AC screen, trees, drain);
  • the quantities the bids should match (boards, guard, piers, tons of flagstone, cubic yards of base, wall stone);
  • about forty checks that fail the export when a number stops working: stair risers over 7.75 in, a joist cantilever over a quarter of its span, a fire ring too close to the arborvitae, chairs that no longer fit on the stone.

That matters most when the design moves, and it moved a lot.

Five revisions in a day

Revision A put a garden terrace north of a wide deck, a fire circle to the west and nine staggered Green Giants along the fence. Then the owner looked at it.

  • A2. The deck shrank to the sliding door, the patio became a 16 ft square of dry-laid buff flagstone, the trees became five American Pillar arborvitae in one row, and the garden went away.
  • A3. The fire ring moved to the patio’s northwest corner, the herb bed became a stone raised bed standing off the brick, and the AC got a screen. The “door” I had drawn a landing for turned out to be a living-room window.
  • A4. One stair instead of two, the slider drawn as the angled bay it really is, the deck’s outer corners cut at 45 degrees, and a Blackstone griddle and a smoker along the east rail.
  • A5. A stone seat wall around the fire, the sofa set moved onto the patio, a vented skirt under the deck, and the AC screen opened on its west side. The owner asked whether a three-sided solid screen would hurt the condenser. It would: the unit pulls air in through its sides and pushes it out the top, and a box around it feeds it its own exhaust.

Every revision regenerated the model, the sheets, the quantities, the budget and a PDF, and republished the page. A change like “cut the corners” touched the deck outline, the joists, the guards, the fascia, the skirt and the stone walkway around the deck, and none of it was redrawn by hand.

Some of what the checks caught along the way: a fire pit that fit the yard only as a listed portable unit (the published code distance for an open wood fire is 25 ft; the owner set their own distances, and the plan records both), a deck that could not hang on the brick (a ledger may not go on veneer, so it stands on its own two beams), and a patio that stood higher than the lawn on its low side, which the seat wall now holds back.

Making the model look like a yard

The first renders were honest and ugly: stepped grass tiles, trees stacked like cakes, furniture as boxes. The CAD framework only knew boxes and cylinders, so it learned four more shapes: extruded polygons (irregular flagstones, curved seat walls, stair stringers), a slab with a sloped top (one smooth ground), cones (trees, umbrellas) and a hip roof. The flagstones come from a jittered grid clipped to the patio square and the round apron, so no two stones overlap.

Then photoreal. The first attempt was a one-off Blender install on the machine running the session, which is the wrong place for it. The better place is the NanoClaw fleet, which already runs job workers behind a small job service. So there is now a render tier:

  • a caller submits a JSON recipe (the model’s URL and the views) to the job service;
  • a NanoClaw agent group, jobs-render, wakes up with a blender-render skill, runs Blender headless, and writes the images to a per-job artifact folder;
  • the job service lists those files in the result and serves them to whoever submitted the job.

The plan module carries its own render recipe: which parts are brick, shingle, composite, flagstone, wall stone, grass or foliage, three camera views, the sun (low from the west-northwest, so the north faces are lit) and an endless ground plane that follows the grade. Materials are procedural, tinted by each part’s own colour, so no texture files travel with the model.

The backyard from the north, rendered in Blender by the render tier

Correct, lit, and still obviously a model. Better materials would only have made it a better model, so the last step hands the render to a tool that makes photographs: FLUX.1 Kontext, an image-editing model that takes a picture plus an instruction (“turn this 3D render into a real photograph; keep every object where it is”) and redraws the surfaces while keeping the layout and the camera.

It runs on the render host’s Intel B70, which normally holds the fleet’s language model (vLLM) and backs Plex. The two cannot share the card’s memory, so a small arbiter lends it out. Photo requests queue with it; when vLLM has been idle for a minute and nothing else is on the card, it stops vLLM, starts ComfyUI with Kontext, runs the whole queue, and hands the card back. Requests to the language model during a swap wait at its proxy instead of failing. A photo takes about 55 seconds, the swap back about a minute, and the render worker simply asks for a photo of each view and waits.

The same view as a photograph

From the northeast

From the west

The deck, the cut corners, the fire ring and seat wall, the screened AC and the five pillars are where the plan puts them. The woods and fields past the fence are the model’s invention.

What did not work

  • The local model could not drive it. The free tier’s qwen3-14b, behind its proxy, failed on the first tool-call turn (“Content block is not a text block”). Plain text jobs work; a job that has to write a file and run a command does not yet. The render worker runs on Sonnet instead, capped at 30 jobs a day, since each job is only three tool calls.
  • Blender cannot reach the GPU. NanoClaw’s container runner has no device passthrough, so the Blender step runs on the CPU (about 35 seconds a view at 128 samples). The photo step gets the GPU only because the arbiter runs outside NanoClaw, on the host.
  • The official Blender download sits behind a bot check. A university mirror serves the same archive.

What carries forward

The next physical plan gets photo-style views for the cost of a RENDER block in its module and one job with "photo": true. The render tier does not know anything about backyards; it takes any GLB and a recipe. And the lesson from the revisions is the same one as on the garage and the spool cabinet: when the drawings, the model, the checks and the shopping list all come from the same numbers, the owner can change their mind five times in a day and the plan keeps up.

The drawing set is at /plans/backyard/, and the project page at /projects/backyard.

ドローン写真から描かれた裏庭、homelabによってレンダリングされたもの

1日でデッキ、石製のパティオ、ファイアリングの5回の改訂版。すべての図面、チェック、数量は1つのPythonモジュールから出力され、NanoClaw艦隊上のBlenderワーカーと共有GPU上のFLUX Kontextから写真風のビューが生成される。

この記事はローカルモデルによる機械翻訳です。原文は英語です。

この依頼は、一文と8枚のドローン写真のフォルダとして届いた。複合デッキと、その片隅にある階段、もう一つは石のパティオへと下がる階段、後ろのフェンスに沿って並ぶ常緑樹、庭が浸水する場所にあるフランス排水溝、そして野菜を育てるスペースが描かれていた。測定用のテープは一切なかった。納品物は、このサイトにある他のプランと同じ形で、建設業者に渡せる図面セット、PDF、3Dモデル、そして各項目が実際に読まれたリストを含む価格表が含まれていた。

空から見たサイトの読み取り

ドローン写真には、単なる画像以上の情報が含まれている。各フレームのメタデータに記録された飛行方向は、家の向きを決定した（このドローンのカメラのジンバルのヨー角は信頼できないが、飛行のヨー角は信頼できる）。フレーム内に既知の幅があるため、スケールが得られた。家の幅は約52フィート、庭の奥行きは約50フィートとなった。リビジョンAのすべての項目は推定値としてマークされており、最初のシートにはリビジョンBにするために必要な6つの測定値がリストされている。

写真にはGPS座標も含まれている。これらは作業用のコピーにのみ残され、ここに公開されたものは家の位置を示していない。

1つのモジュール、多くの出力

プランは1つのPythonファイルに保存されている。このファイルのDEFAULTSは、人が変更できるすべての数値を保持している：ロット、家のサイズ、ベイ、煙突、デッキ、階段、パティオ、火の輪、木、排水溝。それ以外のすべての情報はこれらから導き出される。例えば、勾配は後ろのフェンスと隅の排水溝に向かって下がる平面として表現されている。

この1つのモジュールから生成されるものには：

  • 3Dモデルは、GLB、STEP、Fusion 360スクリプトにエクスポートされています；
  • シート上の十五枚のSVG図面（サイトプラン、断面図、フレーミング、立面図、階段、テラス、リング、座席壁、ハーブベッド、ACスクリーン、木々、排水）；
  • 入札が一致すべき数量（板材、ガード、ピア、フラグストーンのトン数、ベースの立方ヤード数、壁用石）；
  • 約四十のチェックが、数値が動作しなくなるとエクスポートに失敗する（階段の踏み面が7.75インチを超える、ジョイスのキャスリバーがその長さの四分の一を超える、火の輪がアーボリュータに近すぎる、石の上に収まらなくなった椅子）。

設計が変更されるときに最も重要で、この設計はかなり変更されました。

一日に五回の修正

修正Aでは、広いデッキの北側にガーデンテラスを設置し、西側に火の輪を配置し、フェンスに沿って九本のスタガードグリーン・ジャイアントを配置しました。その後、オーナーがそれを確認しました。

  • A2. デッキはスライディングドアに縮小され、テラスは16フィート四方のドライレイアウトのバフフラグストーンとなり、木々は一列に並んだ5本のアメリカン・ピラー・アーボリュータに変わり、ガーデンは消えました。
  • A3. 火の輪はテラスの北西隅に移動し、ハーブベッドはレンガから離れた石製の高床式ベッドとなり、ACにはスクリーンが追加されました。私がランディングを描いた「ドア」は、実際にはリビングルームの窓でした。
  • A4. 階段は一つに、スライダーは実際に角度の取られたベイとして描かれ、デッキの外角は45度に切断され、東側のレールにブラックストーンのグリドルとスモーカーが設置されました。
  • A5. 火の輪の周りに石製の座席壁を設置し、ソファセットはテラスに移動し、デッキの下には換気付きのスカートが設置され、ACのスクリーンは西側に開きます。オーナーは、三面の実体スクリーンがコンデンサーに悪影響を及ぼすかどうか尋ねました。そうでした：このユニットは側面から空気を取り込み、上部から押し出します。その周りに箱を設置すると、排出された空気を再び吸い込むことになります。

各リビジョンではモデル、シート、数量、予算、およびPDFが再生成され、ページが再公開されました。“角を切り取る”というような変更は、デッキの輪郭、ジョイスト、ガード、フェンス、スカート、およびデッキの周りの石の歩道に影響を与え、これらはすべて手で再描画されていません。

チェックで見つかったいくつかの問題点: 火のたまる場所は、庭に設置可能なポータブルユニットとしてのみリストされていました（オープンな木の火のための公的なコード距離は25フィートですが、オーナーが独自の距離を設定し、計画書には両方の距離が記録されています）、デッキはレンガの上に吊り下がってはいけません（ヴェニヤの上にリーダーは設置できないため、2本のビームの上に自立して設置されています）、そしてパティオは低側で芝生よりも高くなり、今では座りながらの壁がその高さを支えています。

モデルを庭のように見せる

最初のレンダリングは正直に言って醜く、階段状の芝生タイル、ケーキのように積み上げられた木、家具は箱のようでした。CADフレームワークは箱や円柱しか認識できなかったため、4つの新しい形状を学習しました: 押出されたポリゴン（不規則な石畳、曲がった座りながらの壁、階段の弦材）、上部が傾いているスラブ（1つの滑らかな地面）、コーン（木、傘）、および屋根の形状。石畳は、パティオの正方形と丸いアプローチに切り取られたジッタリンググリッドから来ていますので、2つの石が重ならないようにしています。

その後、写真リアリズム。最初の試みは、セッションを実行しているマシンにBlenderを一度だけインストールする方法でした。これは間違いの場所です。より良い場所はNanoClawの艦隊で、既に小さなジョブサービスの背後でジョブワーカーを実行しています。そのため、今やレンダリング用の階層があります:

  • 依頼者は、モデルのURLとビューを含むJSON形式のレシピをジョブサービスに送信します；
  • NanoClawエージェントグループ、jobs-render、blender-renderのスキルで起動し、Blenderをヘッドレスで実行し、画像をジョブごとのアーティファクトフォルダに書き込みます；
  • ジョブサービスは、そのファイルを結果として一覧表示し、ジョブを依頼した人に提供します。

プランモジュールは、独自のレンダリングレシピを持っています：どの部分がレンガ、スレート、コンポジット、フラクストン、壁の石、芝や植生、3つのカメラビュー、太陽（西北から低く配置されており、北面が照らされるように）、そして地盤の勾配に合わせて無限に続く地面の平面。マテリアルは手続き的であり、各部分の色によって塗り分けられており、モデルと一緒にテクスチャファイルは移動しません。

北から見た裏庭、レンダリング階層によってBlenderでレンダリングされた

正しい照明と、モデルであることが明らかです。より良いマテリアルを使用すれば、モデルとしてより良いものになります。そのため、最後のステップではレンダリングを、写真を作成するツールに渡します：FLUX。1 Kontext、これは画像編集モデルで、画像と指示（「この3Dレンダリングを現実的な写真に変換してください。すべてのオブジェクトの位置はそのままでください」）を受け取り、レイアウトとカメラの位置を維持しながら表面を再描画します。

レンダリングホストのIntel B70上で動作しており、通常は艦隊の言語モデル（vLLM）とPlexをバックアップしています。この2つはカードのメモリを共有できないため、小さな仲裁者（arbiter）がカードを貸し出しています。写真のリクエストはこの仲裁者を通じてキューイングされます。vLLMが1分間アイドル状態になり、カード上に他のものがなければ、仲裁者はvLLMを停止し、KontextとともにComfyUIを起動し、キュー全体を実行した後、カードを戻します。スワップ中の言語モデルへのリクエストは、そのプロキシで待機し、失敗しません。写真は約55秒かかり、スワップ戻しは約1分かかり、レンダリングワーカーは各ビューの写真を1つずつ要求し、待機します。

写真としての同じビュー

東北から

西から

デッキ、切り取られた角、火の輪と座席の壁、スクリーン付きのエアコン、そして5本の支柱は、計画通りに配置されています。フェンスの外の森や田園地帯は、モデルの独自の発明です。

うまくいかなかった点

  • ローカルモデルでは動かせなかった。 フリー・ティアのqwen3-14bは、プロキシの後ろにあり、最初のツールコールターンで失敗した（“Content block is not a text block”）。純粋なテキストのジョブは動作するが、ファイルを書き込み、コマンドを実行する必要があるジョブはまだ動作しない。レンダリングワーカーはSonnet上で動作しており、1日30ジョブに制限されている。各ジョブは3つのツールコールしか必要としないからである。
  • BlenderはGPUにアクセスできない。 NanoClawのコンテナランナーはデバイスパススルーができないため、BlenderのステップはCPU上で実行される（128サンプルで1ビューあたり約35秒）。写真のステップは、仲裁者がNanoClawの外、ホスト上で実行されているため、GPUを取得できる。
  • 公式のBlenderダウンロードはボットチェックの後ろにある。 大学のミラーが同じアーカイブを提供している。

今後も継続するもの

次の物理的なプランは、そのモジュール内に RENDER ブロックのコストで写真スタイルのビューを取得し、"photo": true と一つのジョブを伴います。レンダリング階層は裏庭のことは何も知りません；任意の GLB とレシピを取るだけです。そして、改訂から得られる教訓は、ガレージや巻き取りキャビネットと同じです：描画、モデル、チェック、買い物リストがすべて同じ数値から来ている場合、オーナーは一日に五回まで意見を変えることができ、プランはそれに合わせて更新されます。

図面セットは plans/backyard/ にあり、プロジェクトページは /projects/backyard にあります。

드론 사진에서 그려진 뒷마당, 홈랩에서 렌더링한 결과

하루 만에 테라스, 석재 베란다 및 화로 고리에 대한 다섯 개의 수정판, 모든 도면, 검사 및 수량은 하나의 Python 모듈에서 제공되며, NanoClaw 편대의 Blender 워커와 공유 GPU에서 FLUX Kontext를 통해 생성된 사진 스타일의 뷰를 포함합니다.

이 글은 로컬 모델이 기계 번역한 것입니다. 원문은 영어입니다.

간단한 설명과 함께 8장의 드론 사진이 함께 제공되었습니다: 한쪽 모서리에 계단이 있고, 다른쪽으로 돌출된 돌로 만든 베란다가 있는 복합형 테라스, 뒷 울타리에 줄지은 페레나, 정원이 물에 잠기는 곳에 위치한 프랑스 배수로, 그리고 채소를 재배할 수 있는 공간이 있습니다. 테이프 측정은 없었습니다. 제공된 결과물은 이 사이트의 다른 설계도와 동일한 형태로 구성되어 있습니다: 건설업체에게 전달할 수 있는 도면 세트, PDF, 3D 모델, 그리고 각 항목이 실제로 확인된 가격표입니다.

공중에서의 사이트 조사

드론 사진은 단순한 이미지 이상의 정보를 담고 있습니다. 각 프레임의 메타데이터에 포함된 비행 방향은 집이 어떤 방향을 향하고 있는지를 결정했으며, 사진 내부에 알려진 너비가 포함되어 있어 규모를 제공했습니다: 집은 약 52피트의 너비, 정원은 약 50피트의 깊이로 나타났습니다. 수정판 A의 모든 항목은 추정치로 표시되어 있으며, 첫 번째 시트에는 이 수정판을 수정판 B로 바꾸는 6개의 측정값이 나열되어 있습니다.

사진에는 또한 GPS 좌표도 포함되어 있습니다. 이 좌표는 작업용 사본에만 남아 있으며, 여기서 발표된 내용에는 집의 위치를 나타내는 것이 전혀 포함되어 있지 않습니다.

하나의 모듈, 다양한 출력

이 설계는 하나의 파이썬 파일에 저장되어 있습니다. 이 파일의 DEFAULTS은 사람이라면 바꿀 수 있는 모든 수치를 포함하고 있습니다: 부지, 집, 베이, 화로, 테라스, 계단, 베란다, 화로 고리, 나무, 배수로. 이 외의 모든 내용은 이 수치들로부터 유도됩니다, 예를 들어, 경사도는 뒷 울타리와 모서리 배수로 쪽으로 내려가는 평면입니다.

이 하나의 모듈로부터 다음과 같은 결과물이 생성됩니다:

  • 3D 모델, GLB, STEP 및 Fusion 360 스크립트로 내보내기;
  • 시트에 있는 15개의 SVG 도면 (평면도, 단면도, 지지대, 전면도, 계단, 파티오, 화로, 자리 벽, 허브 침대, AC 화면, 나무, 배수);
  • 견적서에서 일치해야 할 수량 (판, 보호장치, 기둥, 플래그스톤 톤, 기초의 입방야, 벽돌);
  • 수십 개의 검사 항목이 수치가 작동하지 않을 때 내보내기 실패: 계단의 높이가 7.75인치를 초과하는 경우, 지지대의��출 길이가 전체 길이의 4분의 1을 초과하는 경우, 화로가 아르보리타에 너무 가까운 경우, 돌 위에 더 이상 맞지 않는 의자.

이러한 점이 가장 중요하게 작용하는 것은 설계가 변경될 때이며, 이 설계는 매우 많이 변경되었습니다.

하루에 다섯 번의 수정

수정 A는 넓은 데크의 북쪽에 정원 테라스를, 서쪽에 화로 원을, 그리고 울타리에 따라 정렬된 아홉 개의 Green Giants 나무를 배치했습니다. 그런 다음 소유자가 그것을 보았습니다.

  • A2. 데크는 슬라이딩 도어로 축소되었고, 파티오는 16피트의 건조한 버프 플래그스톤 정사각형이 되었으며, 나무는 한 줄에 있는 다섯 개의 American Pillar 아르보리타가 되었고, 정원은 사라졌습니다.
  • A3. 화로 원은 파티오의 북서쪽 모서리로 이동했고, 허브 침대는 벽돌에서 떨어진 돌로 된 높은 침대가 되었으며, AC 화면이 추가되었습니다. 제가 창을 위해 그린 찍는 곳은 사실 거실의 창문이었습니다.
  • A4. 계단은 두 개 대신 하나로, 슬라이더는 실제로 각도 베이로 그려졌으며, 데크의 외부 모서리는 45도로 잘려졌고, 동쪽 레일에 Blackstone 그릴과 그릴이 추가되었습니다.
  • A5. 화로 주변의 돌 자리 벽, 소파 세트는 파티오로 이동했고, 데크 아래에는 통풍구가 있는 스커트가 추가되었으며, AC 화면은 서쪽으로 열렸습니다. 소유자는 세 측면의 고체 화면이 콘덴서에 해가 될지 물었습니다. 그렇습니다: 이 단위는 측면에서 공기를 끌어들이고 상단으로 밀어내며, 그 주변에 있는 상자에서는 자체 배기 공기를 공급합니다.

모델, 시트, 수량, 예산 및 PDF를 다시 생성하고 페이지를 다시 게시했습니다. “각을 자르다”와 같은 변경 사항은 덱의 외곽선, 지주, 난간, 펜스, 스커트 및 덱 주변의 돌 보행로에 영향을 주었고, 이 모든 것이 손으로 다시 그려지지 않았습니다.

중간 과정에서 검사가 잡아낸 몇 가지 사항: 화장대가 정확히 정원에 맞는 이동식 단위로만 적합한 경우(공개된 목재 화장로의 거리 기준은 25피트입니다; 소유자는 자신의 거리를 설정했으며, 계획서는 두 가지 거리를 모두 기록했습니다), 덱이 벽돌에 걸릴 수 없는 경우(리더가 베니어에 올라갈 수 없으므로, 자체 두 개의 빔에 서 있습니다), 그리고 정원의 낮은 쪽에서 테라스가 잔디보다 높게 서 있는 경우, 이젠 자리를 지키는 벤치 벽이 이를 방지합니다.

모델을 정원처럼 보이게 하기

첫 번째 렌더링은 솔직하고 추했습니다: 계단식 잔디 타일, 케이크처럼 쌓인 나무, 가구는 상자처럼 보였습니다. CAD 프레임워크는 오직 상자와 원통만 알고 있었기 때문에, 4가지 더 많은 형태를 배웠습니다: 확장 다각형(불규칙한 석판, 곡선 벤치 벽, 계단의 뼈대), 경사진 상단이 있는 판(하나의 매끄러운 지상), 원뿔(나무, 우산) 및 힙 지붕. 석판은 정원의 정사각형과 둥근 둘레에 잘려진 격자에서 나옵니다. 따라서 두 개의 석판이 겹치지 않도록 합니다.

그 후에 광학적 사실감을 위한 렌더링. 첫 번째 시도는 세션을 실행하는 컴퓨터에 한 번만 설치한 Blender를 사용했지만, 이는 잘못된 위치입니다. 더 나은 방법은 이미 작은 작업 서비스 뒤에서 작업자 프로세스를 실행하는 NanoClaw 대규모 클러스터를 사용하는 것입니다. 따라서 이제 렌더링 계층이 있습니다:

  • 호출자가 JSON 레시피(모델의 URL과 뷰)를 작업 서비스에 제출합니다;
  • NanoClaw 에이전트 그룹 jobs-render은 blender-render 기술을 가진 상태에서 깨끗한 환경에서 Blender를 실행하고, 이미지를 작업별 아티팩트 폴더에 작성합니다;
  • 작업 서비스는 결과에 해당 파일을 나열하고, 작업을 제출한 사람에게 제공합니다.

플랜 모듈은 자체 렌더 레시피를 가지고 있습니다: 벽돌, 지붕 조각, 복합, 석판, 벽 돌, 풀 또는 식물, 세 개의 카메라 뷰, 태양(서북쪽에서 낮게 떠 있어 북쪽 면이 조명됨), 그리고 지형에 따라 끝없이 이어지는 지면 평면. 재질은 절차적이고, 각 부품의 색상에 따라 색칠되어 모델과 함께 텍스처 파일이 이동하지 않습니다.

북쪽에서 바라본 뒷마당, 렌더 티어에서 Blender로 렌더링됨

올바르게 조명되고, 여전히 모델임이 분명합니다. 더 나은 재질이 있다면 모델을 더 현실적으로 만들었겠지만, 마지막 단계에서는 렌더를 사진으로 만드는 도구에 넘깁니다: FLUX.1 Kontext. 이는 이미지 편집 모델로, 사진과 함께 지시문(“이 3D 렌더를 실제 사진으로 바꾸어 주세요; 모든 물체의 위치는 유지하세요”)을 입력받아 표면을 다시 그려주되 레이아웃과 카메라 설정은 그대로 유지합니다.

이 시스템은 렌더 호스트의 인텔 B70 GPU에서 실행되며, 일반적으로 대규모 언어 모델(vLLM)과 Plex를 지원합니다. 두 프로그램은 GPU 메모리를 공유할 수 없기 때문에, 작은 중재자(arbiter)가 GPU를 대여합니다. 사진 요청은 이 중재자와 함께 대기하게 되며, vLLM이 한 번도 사용되지 않았고 GPU에 다른 작업이 없는 경우, vLLM을 중지하고 Kontext와 함께 ComfyUI를 시작하여 전체 대기 목록을 실행한 후 GPU를 다시 돌려줍니다. 스왑 중 언어 모델에 대한 요청은 대리자(proxy)에서 대기하게 되며, 실패하지 않습니다. 사진 생성에는 약 55초가 걸리고, 스왑 되돌리는 데는 약 1분이 소요되며, 렌더 워커는 각 뷰에 대한 사진을 요청하고 대기합니다.

사진으로 찍은 동일한 뷰

북동쪽에서 본 모습

서쪽에서 본 모습

데크, 잘려진 모서리, 화로 고리와 좌석 벽, 화면이 있는 에어컨과 다섯 개의 기둥은 계획에 따라 배치되었습니다. 울타리 너머의 숲과 들은 모델의 창작물입니다.

작동하지 않은 사항

  • 로컬 모델은 이를 실행할 수 없습니다. 프록시 뒤에 있는 무료 티어의 qwen3-14b는 첫 번째 도구 호출 턴에서 실패했습니다 (“Content block is not a text block”). 일반 텍스트 작업은 작동하지만, 파일을 작성하고 명령을 실행해야 하는 작업은 아직 작동하지 않습니다. 렌더 워커는 Sonnet에서 실행되며 하루에 30개의 작업으로 제한되어 있으며, 각 작업은 단지 세 개의 도구 호출만 필요하기 때문입니다.
  • Blender는 GPU에 접근할 수 없습니다. NanoClaw의 컨테이너 러너는 장치 전달이 없기 때문에, Blender 단계는 CPU에서 실행됩니다 (128 샘플 기준 약 35초당 뷰). 사진 단계는 GPU를 사용할 수 있는 이유는 중재자가 NanoClaw 외부의 호스트에서 실행되기 때문입니다.
  • 공식 Blender 다운로드는 봇 확인을 거칩니다. 대학 미러가 동일한 아카이브를 제공합니다.

앞으로 이어지는 사항

다음 물리적 계획은 모듈의 RENDER 블록 비용과 하나의 "photo": true 일자리에 대해 사진 스타일 뷰를 제공합니다. 렌더링 계층은 뒷마당에 대해 아무것도 모르며, 어떤 GLB와 레시피를 받습니다. 그리고 수정에서 얻은 교훈은 차고와 스폰 캐비닛의 것과 동일합니다: 그림, 모델, 점검 및 쇼핑 목록이 모두 동일한 숫자에서 오면, 소유자는 하루에 다섯 번 마음을 바꿀 수 있고 계획은 그에 따라 계속됩니다.

그림 세트는 /plans/backyard/에 있으며, 프로젝트 페이지는 /projects/backyard에 있습니다.

从无人机照片绘制的后院，由家庭实验室渲染

一天内完成甲板、石质露台和火坑的五次修订，所有图纸、检查和数量均来自一个 Python 模块，以及来自 NanoClaw 队列上 Blender 工作者和共享 GPU 上 FLUX Kontext 的照片风格视图。

本文由本地模型机器翻译，原文为英文。

这份简报以一句话和一个包含八张无人机照片的文件夹的形式出现：一个复合甲板，一角有楼梯，另一侧通往石制露台；后院围栏旁一排常绿树；院子积水处的法国排水沟；以及种植蔬菜的地方。没有卷尺测量数据。交付成果与网站上其他计划的形状相同：一套可以交给承包商的图纸、一个PDF文件、一个3D模型，以及一个价格清单，其中每一条都是实际读取过的条目。

从空中阅读网站

无人机照片携带的不仅仅是图片。每张照片的元数据中的飞行方向确定了房屋的朝向（这架无人机的相机自身云台的偏航角不可靠；飞行方向的偏航角是可信的），而照片中已知的宽度提供了比例：房屋大约宽52英尺，院子大约深50英尺。所有修订版A的内容都标记为估算，第一张图纸列出了六个测量值，这些测量值将其转化为修订版B。

这些照片还携带GPS坐标。这些坐标从未离开工作副本；这里发布的任何内容都不会说明房屋的位置。

一个模块，多种输出

这个计划保存在一个Python文件中。它的 DEFAULTS 包含了每个人可能更改的所有数字：地块、房屋、车位、烟囱、甲板、楼梯、露台、火坑、树木、排水沟。其他所有内容都由此衍生，包括地势，它是一个向后院围栏和角落排水沟倾斜的平面。

从这个单一模块中可以生成：

  • 3D模型，导出为GLB、STEP和Fusion 360脚本；
  • 十五张图纸上的SVG图纸（平面图、剖面图、结构图、立面图、楼梯、露台、火圈、座位墙、草药床、空调屏幕、树木、排水系统）；
  • 投标应匹配的数量（板材、防护栏、桥墩、吨数的铺路石、立方码的基层、墙石）；
  • 大约四十项检查在数字停止工作时会失败：楼梯踏步超过7.75英寸，梁的悬臂超过其跨度的四分之一，火圈离雪松树太近，椅子不再适合放在石板上。

当设计发生变化时，这一点最为重要，而设计确实发生了许多变化。

一天五次修改

修订版A将花园露台放在宽大的甲板北侧，火圈设在西侧，并沿围栏布置了九棵错开的Green Giants树。然后业主看了设计。

  • A2. 甲板缩小到滑动门的尺寸，露台变成了16英尺见方的干铺浅黄色铺路石，树木变成了排成一行的五棵美国柱形雪松，花园被取消了。
  • A3. 火圈移到了露台的西北角，草药床变成了一个从砖墙上独立出来的石制抬高花坛，空调增加了屏幕。我之前为“门”画的平台结果是一个客厅的窗户。
  • A4. 楼梯从两个变为一个，滑动门被画成它实际的斜角窗，甲板的外角被削去45度，并在东侧的栏杆上增加了Blackstone煎锅和烟熏炉。
  • A5. 火圈周围增加了石制座位墙，沙发组移到了露台上，甲板下增加了通风裙边，空调屏幕在西侧打开。业主询问是否三面实心屏幕会对冷凝器造成影响。会造成影响：该设备从侧面吸入空气并从顶部排出，而围绕它的盒子会将它自己的排气送回设备。

每次修订都会重新生成模型、图纸、数量、预算和一个 PDF，并重新发布页面。像“切去角落”这样的更改会影响甲板轮廓、搁栅、护栏、檐板、裙板和甲板周围的石板步道，而所有这些都没有手动重新绘制。

在检查过程中发现的一些问题：一个火坑只能作为列出的便携式单元适合院子（公开的木柴火距离为 25 英尺；业主自行设定了距离，计划中记录了两种距离），一个甲板不能挂在砖墙上（账目可能不能放在饰面砖上，因此它自己站在两个横梁上），以及一个露台在低侧比草坪高，现在座位墙将其支撑。

使模型看起来像一个院子

最初的渲染是诚实且丑陋的：分层的草坪瓷砖、像蛋糕一样堆叠的树木、家具作为盒子。CAD 框架只知道盒子和圆柱体，因此它又学习了四种形状：拉伸多边形（不规则的石板、弯曲的座位墙、楼梯的支撑梁）、顶部倾斜的板（一个平滑的地面）、圆锥体（树木、遮阳伞）和一个坡屋顶。石板来自一个带有抖动的网格，被裁剪到露台的正方形和圆形边缘，因此没有两个石板会重叠。

然后是照片级真实感。第一次尝试是在运行会话的机器上安装一次 Blender，这是错误的位置。更好的位置是 NanoClaw 队列，它已经在小作业服务后运行作业工作者。因此现在有一个渲染层：

  • 调用者向作业服务提交一个 JSON 食谱（模型的 URL 和视图）；
  • 一个 NanoClaw 代理组 jobs-render，拥有 blender-render 技能，启动后运行无头 Blender，并将图像写入每个作业的工件文件夹；
  • 作业服务在结果中列出这些文件，并将其提供给提交作业的用户。

渲染模块自带其渲染食谱：哪些部分是砖块、瓦片、复合材料、鹅卵石、墙石、草或植被，三个相机视角，太阳（从西北偏北低处照射，因此北面被照亮），以及一个根据地形变化的无限地面平面。材质是程序生成的，由每个部分自身的颜色进行染色，因此模型不会携带任何纹理文件。

从北面看的后院，由渲染层在 Blender 中渲染

正确、照明良好，但仍明显是模型。更好的材质只会让模型看起来更真实，因此最后一步将渲染交给一个制作照片的工具：FLUX.1 Kontext，这是一个图像编辑模型，它接收一张图片和一个指令（“将这个 3D 渲染转换成一张真实的照片；保持每个物体的位置”），然后在保持布局和相机视角的同时重新绘制表面。

它运行在渲染主机的 Intel B70 上，通常该主机上运行着舰队的语言模型（vLLM）并支持 Plex。这两者无法共享显卡的内存，因此一个小的仲裁者会将显卡借出。照片请求会排队等待；当 vLLM 空闲一分钟且显卡上没有其他任务时，它会停止 vLLM，启动带有 Kontext 的 ComfyUI，运行整个队列，然后将显卡归还。在交换期间对语言模型的请求会等待其代理，而不是失败。一张照片大约需要 55 秒，交换回来大约需要一分钟，渲染工作节点只需为每个视图请求一张照片并等待即可。

与照片相同的视图

从东北方向

从西边

甲板、切割的角落、火环和座位墙、带屏幕的空调和五根柱子都按照计划放置。围栏外的森林和田野是模型的创作。

未成功的工作

  • 本地模型无法驱动它。 免费版的 qwen3-14b 通过其代理在第一次工具调用时失败（“内容块不是文本块”）。纯文本任务可以工作；需要写文件并运行命令的任务目前还不能。渲染工作节点改用 Sonnet，每天最多 30 个任务，因为每个任务只有三个工具调用。
  • Blender 无法访问 GPU。 NanoClaw 的容器运行器没有设备直通功能，因此 Blender 步骤在 CPU 上运行（128 个样本每个视图大约 35 秒）。照片步骤之所以能获得 GPU，是因为仲裁者在主机上运行，而不是在 NanoClaw 内部。
  • 官方 Blender 下载需要通过机器人检查。 一个大学镜像提供了相同的存档。

前进的方向

下一个物理计划在模块中使用了一个 RENDER 块的成本，以及一个 "photo": true 的任务，就能获得照片风格的视图。渲染层对后院一无所知；它接受任何 GLB 和一个配方。从修订中得出的教训与车库和线轴柜相同：当图纸、模型、检查和购物清单都来自相同的数字时，业主可以在一天内改变主意五次，而计划仍能跟上。

图纸集位于 /plans/backyard/，项目页面位于 /projects/backyard。

Un jardín trasero, dibujado a partir de fotos tomadas con drones, renderizado por el homelab

Cinco revisiones de una terraza, un patio de piedra y un anillo de fuego en un día, con cada dibujo, verificación y cantidad proveniente de un solo módulo Python, y vistas en estilo de foto desde un trabajador de Blender en la flota NanoClaw más FLUX Kontext en una GPU compartida.

Este artículo es una traducción automática hecha por un modelo local. El original está en inglés.

El encargo llegó como una frase y una carpeta con ocho fotos tomadas por dron: una terraza compuesta con una escalera en una esquina y otra que lleva a un patio de piedra, una fila de coníferas a lo largo de la valla trasera, un drenaje francés donde el jardín se inunda, y un lugar para cultivar vegetales. No había mediciones con cinta. El resultado final tenía la misma forma que los otros planos en este sitio: un conjunto de dibujos que alguien podría entregar a los contratistas, un PDF, un modelo 3D, y una lista de precios donde cada línea es un ítem que realmente fue leído.

Leyendo el sitio desde el aire

Las fotos del dron llevan más que imágenes. La dirección del vuelo en los metadatos de cada imagen determinó hacia dónde se orienta la casa (el giro del giroscopio de la cámara en este dron no es confiable; el giro del vuelo sí lo es), y una anchura conocida en la imagen proporcionó una escala: la casa salió a unos 52 pies de ancho, el jardín unos 50 pies de profundidad. Todo en la revisión A está marcado como una estimación, y la primera hoja enumera las seis mediciones que lo convierten en revisión B.

Las fotos también llevan coordenadas GPS. Estas nunca dejan la copia de trabajo; nada publicado aquí dice dónde está la casa.

Un módulo, muchas salidas

El plan vive en un solo archivo de Python. Sus DEFAULTS contienen cada número que una persona podría cambiar: lote, casa, bay, chimenea, terraza, escalera, patio, anillo de fuego, árboles, drenaje. Todo lo demás se deriva de ellos, incluyendo el nivel del terreno, que es un plano que se inclina hacia la valla trasera y hacia el drenaje de la esquina.

Desde ese solo módulo surgen:

  • el modelo 3D, exportado a GLB, STEP y un script de Fusion 360;
  • las quince dibujos SVG en las hojas (plan del sitio, sección, estructura, elevaciones, escaleras, patio, anillo, pared de asientos, lecho de hierbas, pantalla del aire acondicionado, árboles, drenaje);
  • las cantidades que las cotizaciones deben coincidir (tablas, guardia, pilares, toneladas de pizarra, yardas cúbicas de base, piedra para muros);
  • sobre cuarenta verificaciones que fallan en la exportación cuando un número deja de funcionar: escalones de escalera superiores a 7,75 pulgadas, un voladizo de viga superior a un cuarto de su longitud, un anillo de fuego demasiado cerca del arborvitae, sillas que ya no caben en la piedra.

Eso importa más cuando el diseño cambia, y cambió mucho.

Cinco revisiones en un día

La revisión A colocó una terraza de jardín al norte de un amplio deck, un círculo de fuego al oeste y nueve árboles Green Giants desplazados a lo largo de la valla. Luego el propietario lo vio.

  • A2. El deck se redujo al umbral de la puerta corrediza, el patio se convirtió en un cuadrado de 16 pies de pizarra marrón seca, los árboles se convirtieron en cinco arborvitae American Pillar en una fila, y el jardín desapareció.
  • A3. El anillo de fuego se movió a la esquina noroeste del patio, el lecho de hierbas se convirtió en un lecho elevado de piedra que se separa del ladrillo, y el aire acondicionado obtuvo una pantalla. La “puerta” para la cual había dibujado una plataforma resultó ser una ventana del salón.
  • A4. Una escalera en lugar de dos, el corredor dibujado como el bayo inclinado que realmente es, las esquinas externas del deck cortadas a 45 grados, y una plancha de Blackstone y un ahumador a lo largo de la valla este.
  • A5. Una pared de asientos de piedra alrededor del fuego, el conjunto de sofá se trasladó al patio, una falda ventilada debajo del deck, y la pantalla del aire acondicionado se abrió en su lado oeste. El propietario preguntó si una pantalla sólida de tres lados afectaría al condensador. Sí lo haría: la unidad toma aire por sus lados y lo expulsa por la parte superior, y una caja alrededor de ella le proporciona su propia salida de aire.

Cada revisión regeneró el modelo, las hojas, las cantidades, el presupuesto y un PDF, y republicó la página. Un cambio como “cortar las esquinas” afectó el contorno de la terraza, los viguetas, los guardas, el fregadero, el vestíbulo y el sendero de piedra alrededor de la terraza, y nada de eso fue redibujado a mano.

Algunas de las cosas que los controles detectaron en el camino: un pozo de fuego que encajaba en el jardín solo como una unidad portátil lista (la distancia de código publicada para un fuego de leña abierto es de 25 pies; el propietario estableció sus propias distancias, y el plan registra ambas), una terraza que no podía colgar sobre el ladrillo (un ledger no puede ir sobre una capa, por lo que se apoya en sus propios dos viguetas), y un patio que se encontraba más alto que el césped en su lado bajo, lo cual ahora es sostenido por la pared de asientos.

Haciendo que el modelo se parezca a un jardín

Las primeras renderizaciones eran honestas y feas: baldosas de césped escalonadas, árboles apilados como pasteles, muebles como cajas. El marco CAD solo conocía cajas y cilindros, así que aprendió cuatro formas más: polígonos extruidos (piedras irregulares, paredes de asientos curvas, escaleras), una placa con una parte superior inclinada (una tierra lisa), conos (árboles, sombrillas) y un techo de dos aguas. Las piedras provienen de una cuadrícula con vibración recortada al cuadrado del patio y al vestíbulo redondo, por lo que ninguna de las piedras se superpone.

Luego, la fotorealidad. El primer intento fue una instalación única de Blender en la máquina que ejecutaba la sesión, lo cual es el lugar equivocado para ello. El mejor lugar es la flota de NanoClaw, que ya ejecuta trabajadores de tareas detrás de un pequeño servicio de tareas. Así que ahora hay una capa de renderizado:

  • un llamante envía una receta en formato JSON (la URL del modelo y las vistas) al servicio de trabajo;
  • un grupo de agentes NanoClaw, jobs-render, se despierta con una habilidad blender-render, ejecuta Blender en modo sin interfaz gráfica y escribe las imágenes en una carpeta de artefactos por trabajo;
  • el servicio de trabajo lista esos archivos en el resultado y los entrega a quien realizó la solicitud del trabajo.

El módulo de planificación lleva su propia receta de renderizado: qué partes son ladrillo, teja, compuesto, pizarra, piedra de pared, hierba o vegetación, tres vistas de cámara, el sol (bajo desde el noroeste-oeste, para que las caras norte estén iluminadas) y un plano de suelo infinito que sigue el relieve. Los materiales son procedurales, teñidos con el color de cada parte, por lo que no hay archivos de textura que viajen con el modelo.

El patio trasero desde el norte, renderizado en Blender por el nivel de renderizado

Correcto, iluminado y aún obviamente un modelo. Materiales mejores solo habrían hecho que el modelo fuera aún mejor, por lo que el último paso le pasa el render a una herramienta que hace fotografías: FLUX.1 Kontext, un modelo de edición de imágenes que toma una imagen más una instrucción (“convierte este render 3D en una fotografía real; mantén cada objeto donde está”) y redibuja las superficies manteniendo el diseño y la cámara.

Se ejecuta en el Intel B70 del host de renderizado, que normalmente aloja el modelo de lenguaje de la flota (vLLM) y respalda Plex. Los dos no pueden compartir la memoria de la tarjeta, así que un pequeño árbitro se la cede. Las solicitudes de fotos se filan con él; cuando vLLM ha estado inactivo durante un minuto y nada más está en la tarjeta, detiene a vLLM, inicia ComfyUI con Kontext, ejecuta toda la cola y le devuelve la tarjeta. Las solicitudes al modelo de lenguaje durante un intercambio esperan en su proxy en lugar de fallar. Una foto toma alrededor de 55 segundos, el intercambio de vuelta alrededor de un minuto, y el trabajador de renderizado simplemente pide una foto de cada vista y espera.

La misma vista como fotografía

Desde el sureste

Desde el oeste

La cubierta, las esquinas cortadas, el anillo de fuego y la pared de asientos, el aire acondicionado protegido y las cinco columnas están donde el plan las coloca. Los bosques y campos más allá de la valla son la invención del modelo.

Lo que no funcionó

  • El modelo local no puede manejarlo. El qwen3-14b de la versión gratuita, detrás de su proxy, falló en el primer giro de llamada a herramientas (“Content block is not a text block”). Los trabajos de texto plano funcionan; un trabajo que debe escribir un archivo y ejecutar un comando aún no lo hace. El trabajador de renderizado se ejecuta en Sonnet, limitado a 30 trabajos al día, ya que cada trabajo solo tiene tres llamadas a herramientas.
  • Blender no puede acceder a la GPU. NanoClaw no tiene paso directo de dispositivos, por lo que el paso de Blender se ejecuta en el CPU (alrededor de 35 segundos por vista a 128 muestras). El paso de foto obtiene la GPU solo porque el árbitro se ejecuta fuera de NanoClaw, en el host.
  • La descarga oficial de Blender está detrás de una verificación de bot. Un espejo universitario sirve el mismo archivo.

Lo que se lleva adelante

El siguiente plan físico obtiene vistas de estilo fotográfico al costo de un bloque RENDER en su módulo y un trabajo con "photo": true. La capa de renderizado no conoce nada sobre patios traseros; toma cualquier GLB y una receta. Y la lección de las revisiones es la misma que en el garaje y en el armario de bobinas: cuando los dibujos, el modelo, las verificaciones y la lista de compras provienen todos de los mismos números, el propietario puede cambiar de idea cinco veces al día y el plan sigue adelante.

El conjunto de dibujos está en /plans/backyard/, y la página del proyecto en /projects/backyard.

Ein Hinterhof, gezeichnet aus Drohnenfotos, gerendert vom Homelab

Fünf Überarbeitungen einer Terrasse, eines Steinpflasters und eines Feuerkreises an einem Tag, wobei jede Zeichnung, Prüfung und Menge von einem Python-Modul stammt, und photoartige Ansichten von einem Blender-Arbeiter auf der NanoClaw-Flotte plus FLUX Kontext auf einer gemeinsam genutzten GPU.

Dieser Beitrag ist eine maschinelle Übersetzung durch ein lokales Modell. Das Original ist auf Englisch.

Der Auftrag kam als Satz und als Ordner mit acht Drohnenfotos: ein Komposit-Deck mit einer Treppe an einer Ecke und einer weiteren zur Stein-Terrasse, eine Reihe von Nadelbäumen entlang der hinteren Zaunlinie, ein Französischer Abfluss, an dem der Garten überflutet, und einen Platz zum Anbauen von Gemüse. Keine Maßbandmessungen. Das Ergebnis hatte die gleiche Form wie die anderen Pläne auf dieser Seite: ein Zeichensatz, den man einem Auftragnehmer geben könnte, ein PDF, ein 3D-Modell und eine Preisliste, bei der jede Zeile eine tatsächlich gelesene Angabe ist.

Das Grundstück von oben betrachtet

Drohnenfotos enthalten mehr als nur Bilder. Die Flugrichtung in den Metadaten jedes Bildes bestimmte, in welche Richtung das Haus zeigt (der eigene Kippmechanismus der Kamera auf dieser Drohne ist nicht vertrauenswürdig; die Flugrichtung ist es), und eine bekannte Breite im Bild gab eine Skala: das Haus war ungefähr 52 Fuß breit, der Garten etwa 50 Fuß tief. Alles in der Version A ist als Schätzung markiert, und der erste Blatt listet die sechs Messungen auf, die es zur Version B machen.

Die Fotos enthalten auch GPS-Koordinaten. Diese verlassen nie die Arbeitskopie; nichts, was hier veröffentlicht wird, sagt, wo das Haus ist.

Ein Modul, viele Ausgaben

Der Plan lebt in einer einzigen Python-Datei. Seine DEFAULTS enthalten jede Zahl, die eine Person ändern könnte: Grundstück, Haus, Bucht, Schornstein, Deck, Treppe, Terrasse, Feuerkreis, Bäume, Abfluss. Alles andere leitet sich von ihnen ab, einschließlich der Geländekante, die eine Ebene ist, die zum hinteren Zaun und zum Eckenabfluss abfällt.

Aus diesem einen Modul entstehen:

  • die 3D-Datei, exportiert als GLB, STEP und ein Fusion 360-Skript;
  • die fünfzehn SVG-Zeichnungen auf den Blättern (Grundriss, Schnitt, Tragwerk, Ansichten, Treppen, Terrasse, Feuerkreis, Sitzwand, Kräutergarten, AC-Screen, Bäume, Abfluss);
  • die Mengen, mit denen die Angebote übereinstimmen sollten (Bohlen, Schutz, Pfeiler, Tonnen Flagstein, Kubikyard Unterlage, Wandstein);
  • etwa vierzig Prüfungen, die den Export verhindern, wenn eine Zahl nicht mehr funktioniert: Treppenstufen über 7,75 Zoll, ein Träger mit Überstand über ein Viertel seiner Spannweite, ein Feuerkreis zu nahe am Arborvitae, Stühle, die nicht mehr auf den Stein passen.

Das ist am wichtigsten, wenn sich das Design verändert, und es veränderte sich viel.

Fünf Überarbeitungen an einem Tag

Überarbeitung A platzierte eine Garten-Terrasse nördlich einer breiten Plattform, einen Feuerkreis im Westen und neun schräg gestellte Green Giants entlang der Zaunlinie. Dann sah der Eigentümer es an.

  • A2. Die Plattform wurde auf die Schiebetür reduziert, die Terrasse wurde zu einem 16 Fuß großen Quadrat aus trocken verlegtem Buff-Flagstein, die Bäume wurden zu fünf American Pillar Arborvitae in einer Reihe, und der Garten verschwand.
  • A3. Der Feuerkreis wurde in die nordwestliche Ecke der Terrasse verlegt, der Kräutergarten wurde zu einem Stein-Beet, das von der Ziegelwand abgestellt ist, und das AC erhielt einen Screen. Der “Tür” für den Landungssteg, den ich gezeichnet hatte, stellte sich als ein Wohnzimmerfenster heraus.
  • A4. Eine Treppe statt zwei, der Schieberegler wurde als der tatsächliche schräge Bucht gezeichnet, die Ecken der Plattform wurden in 45 Grad geschnitten, und ein Blackstone-Griddle und ein Rauchofen entlang der östlichen Leitstange.
  • A5. Eine Steinsitzwand um den Feuerkreis, der Sessel-Set wurde auf die Terrasse verlegt, eine entlüftete Schürze unter der Plattform, und der AC-Screen öffnete sich auf seiner westlichen Seite. Der Eigentümer fragte, ob ein dreiseitiger fester Screen den Kühler beeinträchtigen würde. Es würde: Die Einheit zieht Luft durch ihre Seiten an und drückt sie durch den oberen Teil aus, und ein Kasten um sie herum führt ihr eigene Abgasung zu.

Jede Überarbeitung regenerierte das Modell, die Zeichnungen, die Mengen, das Budget und ein PDF und veröffentlichte die Seite erneut. Eine Änderung wie „Ecken abschneiden“ beeinflusste den Grundriss der Terrasse, die Träger, die Geländer, die Kanten, die Sockelleiste und den Steinbelag um die Terrasse, und nichts davon wurde von Hand neu gezeichnet.

Einige der Dinge, die die Prüfungen entlang des Weges erfassten: ein Feuerkorb, der nur als aufgelistetes tragbares Gerät in den Garten passte (der veröffentlichte Abstandscode für ein offenes Holzfeuer beträgt 25 Fuß; der Eigentümer hat ihre eigenen Abstände festgelegt, und der Plan dokumentiert beide), eine Terrasse, die nicht an der Mauer aus Ziegelsteinen hängen konnte (ein Ledger darf nicht an einer Verkleidung befestigt werden, also steht sie auf ihren eigenen beiden Trägern), und ein Terrassenbereich, der auf der niedrigen Seite höher als der Rasen stand, den jetzt die Sitzwand abhält.

Das Modell so aussehen lassen wie ein Garten

Die ersten Renditebilder waren ehrlich und hässlich: Stufenweise Grasfliesen, Bäume, die wie Torten gestapelt waren, und Möbel als Kästen. Das CAD-Framework kannte nur Kästen und Zylinder, also lernte es vier weitere Formen: extrudierte Polygone (unregelmäßige Steinplatten, gekrümmte Sitzwände, Treppenlaufträger), eine Platte mit geneigter Oberseite (ein glatter Boden), Kegel (Bäume, Sonnenschirme) und ein Satteldach. Die Steinplatten stammen aus einem gestörten Gitter, das auf das Terrassenquadrat und den runden Abschlussbereich geschnitten wird, sodass keine zwei Steine sich überschneiden.

Dann Photoreal. Der erste Versuch war eine Einzelinstallation von Blender auf dem Rechner, der die Sitzung ausführte, was der falsche Ort dafür ist. Der bessere Ort ist die NanoClaw-Flotte, die bereits Jobarbeiter hinter einem kleinen Jobdienst ausführt. Also gibt es jetzt eine Renderebene:

  • ein Aufrufer sendet ein JSON-Rezept (die Modell-URL und die Ansichten) an den Job-Service;
  • eine NanoClaw-Agentengruppe, jobs-render, erwacht mit einer blender-render Fähigkeit, führt Blender headless aus und schreibt die Bilder in einen pro-Job-Artifact-Ordner;
  • der Job-Service listet diese Dateien im Ergebnis auf und liefert sie an die Person, die den Job eingereicht hat.

Das Plan-Modul trägt sein eigenes Rendite-Rezept mit sich: welche Teile Ziegel, Schiefer, Verbundmaterial, Steinplatten, Wandstein, Gras oder Laub sind, drei Kamera-Ansichten, die Sonne (niedrig aus dem Nordwesten, sodass die nördlichen Seiten beleuchtet werden) und eine unendliche Grundebene, die dem Gelände folgt. Die Materialien sind prozedural, gefärbt durch die eigene Farbe jedes Teils, sodass keine Texturdateien mit dem Modell reisen.

Der Hinterhof aus nördlicher Richtung, gerendert vom Render-Tier in Blender

Korrekt, beleuchtet und immer noch offensichtlich ein Modell. Bessere Materialien hätten es nur zu einem besseren Modell gemacht, daher übergibt der letzte Schritt das Rendern einem Tool, das Fotos erstellt: FLUX.1 Kontext, ein Bildbearbeitungsmodell, das ein Bild plus eine Anweisung (“wandle diese 3D-Rendite in ein echtes Foto um; behalte jeden Gegenstand an seinem Platz”) nimmt und die Oberflächen neu zeichnet, während die Anordnung und die Kamera erhalten bleiben.

Es läuft auf dem Intel B70 des Render-Hosts, der normalerweise das Sprachmodell der Flotte (vLLM) und Plex hostet. Die beiden können nicht gleichzeitig auf den Speicher der Grafikkarte zugreifen, also überlässt ein kleiner Arbitrierer sie zeitweise. Fotoanfragen warten in der Warteschlange; wenn vLLM eine Minute lang inaktiv war und nichts anderes auf der Grafikkarte läuft, stoppt es vLLM, startet ComfyUI mit Kontext, führt die gesamte Warteschlange aus und übergibt die Grafikkarte dann zurück. Anfragen an das Sprachmodell während eines Wechsels warten stattdessen an seinem Proxy, anstatt zu scheitern. Ein Foto benötigt etwa 55 Sekunden, der Wechsel zurück etwa eine Minute, und der Render-Worker fragt einfach für jedes Bild einer Ansicht nach einem Foto und wartet.

Die gleiche Ansicht als Fotografie

Aus der nordöstlichen Richtung

Aus der westlichen Richtung

Das Deck, die abgerundeten Ecken, der Feuerkreis und die Sitzwand, der gesicherte Lüftungskanal und die fünf Säulen sind an den Stellen, an denen sie im Plan vorgesehen sind. Die Wälder und Felder jenseits der Zaun sind die Erfindung des Modells.

Was nicht funktioniert hat

  • Das lokale Modell konnte es nicht antreiben. Das kostenlose Tier von qwen3-14b, hinter seinem Proxy, scheiterte beim ersten Tool-Call-Schritt (“Content block is not a text block”). Einfache Textaufgaben funktionieren; eine Aufgabe, die eine Datei schreiben und einen Befehl ausführen muss, funktioniert noch nicht. Der Render-Worker läuft stattdessen auf Sonnet, begrenzt auf 30 Aufgaben pro Tag, da jede Aufgabe nur drei Tool-Aufrufe erfordert.
  • Blender kann die GPU nicht erreichen. NanoClaw’s Container-Runner hat keine Gerätewechselung, also läuft der Blender-Schritt auf dem CPU (etwa 35 Sekunden pro Ansicht bei 128 Proben). Der Foto-Schritt erhält die GPU, weil der Arbitrierer außerhalb von NanoClaw, auf dem Host, läuft.
  • Die offizielle Blender-Download-Quelle ist hinter einem Bot-Check gesichert. Ein Universitäts-Spiegel bietet das gleiche Archiv an.

Was weitergeführt wird

Der nächste physische Plan erhält photo-stilisierte Ansichten zum Preis eines RENDER Blocks in seinem Modul und eine Aufgabe mit "photo": true. Die Render-Ebene weiß nichts über Hinterhöfe; sie nimmt jedes GLB und ein Rezept entgegen. Und die Lektion aus den Revisionen ist dieselbe wie bei der Garage und dem Spulenschrank: wenn die Zeichnungen, das Modell, die Prüfungen und die Einkaufsliste alle aus denselben Zahlen stammen, kann der Eigentümer fünfmal am Tag seine Meinung ändern und der Plan bleibt dabei.

Das Zeichnungsset ist unter /plans/backyard/ und die Projektseite unter /projects/backyard.