Skip to content

feat(render3d): 打通三渲二的生产闭环 - #277

Open
johnnyzhang-eng wants to merge 9 commits into
1024XEngineer:mainfrom
johnnyzhang-eng:feat/render3d-engine
Open

feat(render3d): 打通三渲二的生产闭环#277
johnnyzhang-eng wants to merge 9 commits into
1024XEngineer:mainfrom
johnnyzhang-eng:feat/render3d-engine

Conversation

@johnnyzhang-eng

@johnnyzhang-eng johnnyzhang-eng commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Summary

把三渲二从「路线接好但走不到」补成一条可用的闭环:读路径、写路径、母版预检三段一起进。

拆开提会留下一条死代码路径。判据是 character_data.outfits[].model_3d_url,本 PR 的读侧按它决定走三渲二还是 i2v;但在写侧端点存在之前,该字段没有任何写入来源,恒为 None,所有动作请求静默回落 i2v,不报错也不告警。

变更

内容
common/models/character.py CharacterOutfit.model_3d_url:三渲二的开关,挂造型级而非角色级
ai_engine/ports generate_rendered:拿已绑骨模型套预设动作出帧,与 generate 并列
ai_engine/master_check MasterWarningCode:四肢粘连、独立色块两条警告。判据近似,故为警告不为拒绝
web/api/generation.py 请求增加 outfit_id_outfit_model_3d_url 读 DB 决定路线
web/api/render3d.py 5 个端点:master-precheck、查询、buildapprovediscard
orchestrator/render3d_service.py 建造流程与人工放行闸
openapi.json #334 第三节重新导出,含新增的 5 条路径

路线选择整个在 server:引擎不做「能不能用」的预查询,因为判据只有 DB 知道。rigged_model 传 bytes 不传 URL,ai_engine 只吃 bytes、不碰存储。

建 3D 资产是每造型一次性的按次计费,不在动作生成的请求路径上;buildapprove 分开,付费与放行不由同一个调用完成。

关联

Closes #352
Refs #192

Test plan

  • uv run ruff check . → All checks passed
  • uv run lint-imports → 2 kept, 0 broken
  • uv run python -m scripts.export_openapi && git diff --exit-code -- ../openapi.json → 无漂移
  • uv run pytest -q → 760 passed, 14 skipped
  • 接真实凭证后跑一遍:母版预检 → build → approve → 提交动作生成,确认走的是三渲二而不是回落 i2v

@vercel

vercel Bot commented Aug 13, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
windup Ignored Ignored Preview Aug 17, 2026 7:02am

fennoai[bot]

This comment was marked as outdated.

引擎契约与 server 编排的后半段。路线选择由 server 读 DB 决定:造型上有
model_3d_url 就调 CharacterGeneratorPort.generate_rendered,没有则照旧走 i2v。
三渲二不进 ROUTE_MATRIX —— 那张表的隐含前提是"路线由动作物理性质唯一决定",
而这条还取决于该造型有没有 3D 资产。

引擎侧新增 generate_rendered 而不另立 port,并补一项分区动量读数:整幅的
motion_scale 与死帧判据看不见"腿在迈、手臂僵成柱子",而那正是自动绑骨漏认
肢体的典型产物。

出帧台 provider 走函数内延迟 import,没装它时 i2v / 逐帧两条路线仍可用。

Refs 1024XEngineer#192 1024XEngineer#122 1024XEngineer#121
这两条只用 PIL 和 slicing.quality,与三渲二 provider 无关。留在
test_render3d_route_and_assets.py 里会被那个文件的整体 skip 一并带走,
于是本 PR 新增的这项读数在 provider 合入前一条断言都不跑。
1024XEngineer#241 合入后 rebase 撞出来的:它给装配表加了一条断言,要求每个 GenRoute 成员都被装配,
而本 PR 新增的 RENDER_3D 依赖 1024XEngineer#270 的 provider 模块——那个模块在这条分支上还不存在,
装配期就 import 会让本来走 i2v 的任务也起不来。

改成装配表里放一个惰性策略:真走到三渲二那条路线时才 import 出帧台依赖。
断言因此仍然成立(表里确实有这个键),而缺 provider 也不影响其余路线。

两个状态都验过:不带 1024XEngineer#270 时 496 passed / 2 skipped;把 1024XEngineer#270 的 provider 层铺进工作区
再跑,591 passed / 14 skipped,惰性策略能真的实例化出 RenderFrameStrategy。

Refs 1024XEngineer#192
@johnnyzhang-eng

Copy link
Copy Markdown
Contributor Author

已同步到含 #270 的最新 main(9b509f9)。之前 codecov 红是因为这个 PR 的 26 个测试整体 skip——它们要 #270 的 provider 层才跑得起来,而 #270 那时还没合。现在全部跑起来了,同步过程中暴露并修了两个测试桩的签名过期。708 passed。

@minorcell

Copy link
Copy Markdown
Member

/review

@fennoai fennoai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

审查结论

这组改动已经串起了 DB 选路、模型下载、引擎渲帧和质量读数,但与 #192 已定契约仍有两处关键偏差:多朝向产物被压成单朝向,渲染浏览器仍运行在 FastAPI 进程内。另外,人工驳回模型后当前缓存流程无法真正重新生成。

验证

  • 按固定范围 12793606d44bf3a089d4540c5e1c307cc94e6d25...9b509f9cfab91d9dba6ae889bca28879d17c3751 审阅全部 18 个变更文件。
  • git diff --check 与变更模块 compileall 通过。
  • 当前环境缺少 uv/pytest,未能本地复跑测试;GitHub 的后端、前端与 patch coverage 检查均为通过。

View job run

Comment thread backend/packages/app/src/windup_app/server/orchestrator/executor.py
@johnnyzhang-eng johnnyzhang-eng changed the title feat(render3d): 三渲二接进编排 feat(render3d): 三渲二接进编排并补上资产端点 Aug 17, 2026
@johnnyzhang-eng johnnyzhang-eng changed the title feat(render3d): 三渲二接进编排并补上资产端点 feat(render3d): 打通三渲二的生产闭环 Aug 17, 2026
@johnnyzhang-eng

Copy link
Copy Markdown
Contributor Author

这条是误报的一种:本 PR 关联的 #192 是三渲二路线的总纲,上面还挂着正面细节、头发刚体、非人形绑骨等未做的子项,写 Closes 会把没做完的一起关掉,所以正文用的是 Refs #192。按 #334 收敛 issue 颗粒度之后这种总纲型关联会变多,check-pr-issue 可以考虑把正文里的 Refs #N 也算作已关联。

@minorcell

Copy link
Copy Markdown
Member

这条是误报的一种:本 PR 关联的 #192 是三渲二路线的总纲,上面还挂着正面细节、头发刚体、非人形绑骨等未做的子项,写 Closes 会把没做完的一起关掉,所以正文用的是 Refs #192。按 #334 收敛 issue 颗粒度之后这种总纲型关联会变多,check-pr-issue 可以考虑把正文里的 Refs #N 也算作已关联。

@johnnyzhang-eng 你可以修一下这个 action 的情况;我记得记得脚本里面只判断了有没有 “Close” 字段;或许可以添加 “Refs” 等;

不过要看具体情况,是不是一个 issue 对应多个 PR 的场景(不建议这么做)?

@johnnyzhang-eng

johnnyzhang-eng commented Aug 17, 2026

Copy link
Copy Markdown
Contributor Author

我按它改了做法而不是改脚本:#192 保持 proposal 总纲,另开 #352 收窄到本 PR 真正交付的那一段,PR 正文改成 Closes #352 + Refs #192,现在关联是干净的。这和 #222 / #224 的分法一致,脚本不用动,一个 issue 对多个 PR 那个反模式也就不存在了。

@1024XEngineer 1024XEngineer deleted a comment from github-actions Bot Aug 17, 2026
@minorcell
minorcell requested a review from xiaocheny214 August 17, 2026 08:59
@minorcell

Copy link
Copy Markdown
Member

@xiaocheny214 一起来看下,会涉及到你的那部分。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat(render3d): 三渲二接入编排并补上造型级资产落点(Refs #192)

2 participants