Copy English

Why

The interesting word is procedural, and it is not a synonym for generated. A generated model is a mesh: a bag of vertices that arrived somehow and can now only be edited by hand. A procedural model is code that produces geometry when run, so its subject is an argument, its proportions are variables, and changing it means changing a line rather than re-sculpting a surface. That is why the post can say the tank can be swapped out for anything else — if the tank is a function, the tank is a parameter.

This repository already made the same move, one domain over. Nothing in docs/topics/ is written by hand; every page is produced from lib/poc-cards.ts by a generator. The consequence showed up concretely this week: when two workspaces both regenerated those pages, the fifty resulting conflicts were not resolved by merging HTML — they were resolved by merging the source and re-running the generator, because a conflict in a derived file is never fixed in the derived file. An LLM that emits the generator instead of the artifact inherits exactly that property, and it is worth more than the visual: code can be diffed, reviewed and parameterized; a mesh can only be looked at.

And the claim has a direction problem worth catching. 2D schematics into 3D models says the drawing is the input. But the demo's own buttons — FRONT, PLAN, ISO — are the standard orthographic projections that CAD software produces from a 3D model, and the blueprint aesthetic is the cheapest of those views to render. So the arrow may point the other way: one parametric model, six camera angles, one of which looks like a schematic. That is not an accusation; it is the first thing to check, and it is checkable in a single attempt.

How it works

Three things that get called the same thing

The post claims the third. The demo is consistent with the second. The difference is invisible in a video and obvious in one experiment.

The experiment, in full

One attempt, one input: a schematic of something from a domain it has never rendered — not a vehicle, not military, ideally something with an irregular shape rather than boxes and cylinders. Then read the result against three outcomes:

• A model appears and is roughly right — the claim holds, and the interesting question moves to how the code represents shape.
• A model appears but is a tank with different proportions — it is a parameterized generator. Still useful, differently framed.
• Nothing usable appears — the schematic was never the input; the blueprint was an output view all along.

Why it belongs in this catalogue at all

Not for the tank. For the shape of the output. The recurring difficulty with model-produced artifacts is that they cannot be checked — a paragraph, an image, a mesh all arrive as finished surfaces with no seam to inspect. A model that emits a program instead moves the artifact into a form that already has review tooling around it: version control, diffs, tests, parameters with names. That is the same reason this repo keeps card data as the source of truth and treats every page under docs/topics/ as disposable output, and it generalizes far past 3D.

Honesty about the source

This is a social post with no repository, no paper and no primary link, forty-two minutes old at capture, carrying 19 likes against 16,000 views — engagement that says seen rather than verified. Nothing here should be repeated as fact. The card exists because the distinction is worth holding, not because the demo is established.

Where it lands in Jayverse

• Game: prefer parametric, code-driven assets over static meshes for anything verex markets attach to. A market board that needs to swap per-market should be built as a function with named variables (size, label, state), not a hand-sculpted mesh, so changing it is a diff rather than a re-sculpt.
• gitboard: keep dashboard pages as generated output from one source, never hand-edited. Treat gitboard's views the way this project already treats docs/topics — regenerate from source on conflict or change, don't patch the derived page, since a conflict in a derived artifact is never fixed in the derived artifact.
• Personas: test the arrow direction before trusting "generative" persona art. If persona NFT traits are ever claimed to be procedurally generated, confirm with an unseen input that the traits are genuinely parametrized code rather than a fixed set of pre-rendered images relabeled as generative.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

생성이 아니라 절차적 — 모델이 프로그램일 때

Kimi K3가 2D 도면을 완전 절차적 3D 모델로 바꾸는 앱을 만들었고, 코드로 생성된 전차를 무엇으로든 교체할 수 있다는 게시물입니다. 하중을 받는 단어는 절차적입니다 — 산출물이 메시가 아니라 기하를 만드는 코드입니다. 화살표가 정말 2D → 3D 를 가리키는지는 한 번의 실험으로 갈립니다.

아직 범위 미정 — 첫 단계 전부가 만들기가 아니라 반증 가능한 실험 하나입니다. 한 번도 본 적 없는 도면을 넣습니다 — 차량이 아닌 것, 데모가 보여준 적 없는 분야의 그림으로. 화살표가 2D → 3D 를 가리킨다면 모델이 나옵니다. 쓸 만한 것이 안 나오면, 그 앱은 청사진 뷰가 달린 파라미터 생성기입니다 — 그것도 다르고 여전히 흥미롭지만, 주장된 그것은 아닙니다. 출처: @RoundtableSpace 의 2026-08-26 X 게시물. 뷰 버튼(ISO·3/4·SIDE·FRONT·PLAN)과 동작 버튼(RUN·DRIVE·FIRE·EXPLODE)이 있는 브라우저 앱의 55초 영상. 저장소도 논문도 1차 링크도 없습니다 — 여기의 모든 주장을 미검증으로 다룰 것.

왜

흥미로운 단어는 "절차적"이고, 이것은 "생성된"의 동의어가 아닙니다. 생성된 모델은 메시입니다 — 어떻게든 도착한 정점 덩어리이고, 이제는 손으로만 고칠 수 있습니다. 절차적 모델은 실행하면 기하를 만들어내는 코드입니다. 그래서 대상이 인자가 되고, 비율이 변수가 되며, 바꾼다는 것이 표면을 다시 깎는 게 아니라 한 줄을 고치는 일이 됩니다. 게시물이 전차를 무엇으로든 교체할 수 있다 고 말할 수 있는 이유가 그것입니다 — 전차가 함수라면, 전차는 파라미터입니다.

이 저장소는 한 분야 건너에서 이미 같은 수를 뒀습니다. docs/topics/ 의 어떤 페이지도 손으로 쓰지 않습니다 — 전부 lib/poc-cards.ts 에서 생성기가 만듭니다. 그 결과가 이번 주에 구체적으로 드러났습니다: 두 작업 공간이 같은 페이지들을 재생성했을 때 생긴 50개의 충돌은 HTML을 병합해서 푼 게 아니라, 소스를 병합하고 생성기를 다시 돌려서 풀렸습니다. 파생 파일의 충돌은 결코 파생 파일에서 고쳐지지 않기 때문입니다. 산출물 대신 생성기를 내놓는 LLM은 정확히 그 성질을 물려받고, 그것이 보기 좋은 화면보다 값이 큽니다 — 코드는 diff 하고 리뷰하고 파라미터화할 수 있지만, 메시는 쳐다볼 수만 있습니다.

그리고 주장에는 잡아 둘 만한 방향 문제가 있습니다. 2D 도면을 3D 모델로 는 그림이 입력이라는 뜻입니다. 그런데 데모의 버튼들 — FRONT·PLAN·ISO — 은 CAD 소프트웨어가 3D 모델로부터 만들어내는 표준 정투영이고, 청사진 스타일은 그 뷰들 중 렌더링이 가장 싼 축입니다. 그러니 화살표가 반대일 수 있습니다 — 파라메트릭 모델 하나, 카메라 각도 여섯, 그중 하나가 도면처럼 보이는 것. 고발이 아닙니다. 가장 먼저 확인할 것이고, 한 번의 시도로 확인됩니다.

동작 방식

같은 이름으로 불리는 서로 다른 셋

게시물은 세 번째를 주장합니다. 데모는 두 번째와도 모순되지 않습니다. 그 차이는 영상에서는 안 보이고 실험 한 번이면 드러납니다.

실험, 전체

시도 한 번, 입력 하나 — 한 번도 렌더한 적 없는 분야의 도면. 차량이 아니고, 군사가 아니며, 상자와 원기둥이 아닌 불규칙한 형상이면 더 좋습니다. 결과를 세 갈래에 대고 읽습니다:

• 모델이 나오고 대체로 맞다 — 주장이 성립하고, 흥미로운 질문은 코드가 형상을 어떻게 표현하는가로 옮겨간다.
• 모델이 나오는데 비율만 다른 전차다 — 파라미터 생성기다. 여전히 쓸모 있지만 프레임이 다르다.
• 쓸 만한 게 안 나온다 — 도면은 애초에 입력이 아니었고, 청사진은 처음부터 출력 뷰였다.

애초에 왜 이 카탈로그에 두는가

전차 때문이 아닙니다. 산출물의 모양 때문입니다. 모델이 만든 결과물의 반복되는 난점은 검사할 수 없다는 것입니다 — 문단이든 이미지든 메시든, 이음매 없는 완성된 표면으로 도착합니다. 대신 프로그램을 내놓는 모델은 결과물을 이미 리뷰 도구가 갖춰진 형태로 옮깁니다 — 버전 관리, diff, 테스트, 이름 있는 파라미터. 이 저장소가 카드 데이터를 정본으로 두고 docs/topics/ 전부를 버려도 되는 출력으로 다루는 것과 같은 이유이고, 3D를 훨씬 넘어 일반화됩니다.

출처에 대한 정직함

저장소도 논문도 1차 링크도 없는 소셜 게시물이고, 캡처 시점 42분 경과, 조회 1.6만에 좋아요 19 — "봤다"는 말이지 "검증됐다"는 말이 아닌 반응입니다. 여기의 어떤 것도 사실로 옮겨 적으면 안 됩니다. 이 카드가 존재하는 이유는 데모가 확립돼서가 아니라 그 구분이 들고 있을 값어치가 있기 때문입니다.

Jayverse에서의 위치

• Game: verex 마켓이 붙는 모든 것에는 정적 메시보다 파라메트릭한 코드 기반 에셋을 우선한다. 마켓마다 바뀌어야 하는 보드는 손으로 조각한 메시가 아니라 이름 붙은 변수(크기, 라벨, 상태)를 가진 함수로 만든다. 그러면 바꾸는 일이 재조각이 아니라 diff가 된다.
• gitboard: 대시보드 페이지를 손으로 고치지 않고 하나의 소스에서 생성된 결과물로 유지한다. 이 프로젝트가 이미 docs/topics를 다루는 방식처럼, 충돌이나 변경이 생기면 소스에서 재생성하고 파생된 페이지를 패치하지 않는다. 파생 산출물의 충돌은 파생 산출물 안에서 고쳐지지 않기 때문이다.
• Personas: "생성형" 페르소나 아트를 믿기 전에 화살표 방향을 검증한다. 페르소나 NFT 특성이 절차적으로 생성된다고 주장된다면, 본 적 없는 입력으로 그 특성이 진짜 파라미터화된 코드인지, 아니면 미리 렌더링된 고정 이미지 집합에 생성형이라는 라벨만 붙인 것인지 확인한다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑