DEV Community: alphanine

Turing Sim: Making the USD Schemas Inspector Readable

alphanine — Tue, 29 Sep 2026 04:31:32 +0000

The running editor shows separate USD schema cards, UR10 articulation settings and the source asset window. 运行中的编辑器展示分开的 USD schema 卡片、UR10 关节体设置及源资产窗口。

Each USD schema on the selected cube (Collision, Mesh Collision, Rigid Body, Mass) now sits in its own card with its USD schema name.

The selected UR10 shows Translate, Rotate, Scale and Articulation Root settings in the running editor. / 运行中的编辑器展示 UR10 的平移、旋转、缩放及 Articulation Root 设置。

The source asset window shows a hierarchy, preview and Properties/Raw USD tabs. / 源资产窗口展示层级、预览及 Properties/Raw USD 标签。

Situation

Turing Sim is an experimental OpenUSD editor and robotics simulation workbench. Its Schemas tab lists every schema on the selected prim, including physics APIs, and every edit goes through the document's undo history. On September 28 the tab worked, but it was hard to read. A viewport tool section sat between the name and the Transform, schemas without properties printed "No additional properties", and the Rigid Body and Mass fields ran together with no visible boundary. Transform showed only the transform parts already stored in the file, so the UR10 showed Position but no Rotation or Scale.

Task

The goal was to make the tab read the way USD is structured, following the conventions of Isaac Sim's Property panel. Every property should clearly belong to one schema, Transform should own translate, rotation and scale, and the Articulation Root should expose settings such as self collision. The difficulty was doing this without hardcoding robot or schema names, which the project rules forbid, and without breaking undo.

A second problem appeared during testing. After moving the UR10 with the gizmo, the Transform section switched to "custom transform stack" and the position fields went stale.

Action

One card per schema. Each schema is now a bordered card. Its header shows a readable name on the left, the USD schema identifier (for example PhysicsRigidBodyAPI) on the right, and a remove button for applied APIs. Removing a schema also clears its values in the current edit layer, as one undo step. Cards that are mostly arrays, such as mesh topology, start collapsed.
Isaac Sim-style rows. Rows are two columns, label and value, and stack when the panel is narrow. Labels come from the schema's own displayName metadata, such as "Center of Mass". A dot at the end of each row shows whether the value is authored: hollow for the schema default, blue when set in the current edit layer (click to revert), grey when set in another layer. Booleans are checkboxes, and physics fields whose USD default is infinity read as "Auto".
Transform owns position, rotation and scale. Translate, Rotate (or Orient) and Scale always appear, named after their USD transform ops. Rotation switches between Euler degrees and a quaternion. Either input is converted to whichever form the prim already stores, so Isaac-style orient quaternions stay quaternions.
The gizmo edits the real transform. The cause of the stale fields was that drags wrote a separate matrix op instead of changing the prim's own translate and rotate values. Drags now update those values directly. The matrix op remains only as a fallback for transforms that position/rotation/scale cannot represent. Older matrix ops are merged back on the next edit.
Articulation Root settings. The card counts the rigid bodies and joints found under the root and offers the PhysX articulation settings: enabled, self collisions, solver iterations, and sleep and stabilization thresholds. Editing one writes the value and applies the PhysX articulation schema in the same undo step.
Source asset editor. The separate editor for referenced assets now uses the same glass cards and segmented tabs as the main window. A user-provided screenshot of the native editor shows the revised layout; editing behavior in that window has not been checked in a headed session.

Regression tests cover each new edit path with undo and redo, plus a check of all six Euler axis orders against USD's own rotation ops. The full offscreen suite gave 525 passed, 3 failed and 6 skipped. The three failures were older tests still looking up the field by its previous name, "Position X". After updating them, the affected test files pass (61 tests). The whole suite has not been re-run since that fix. The three screenshots at the top show the running app after the changes: separate schema cards, the UR10 Transform and Articulation Root panels, and the source asset editor. They show visible layout and values, not an end-to-end edit or save. The other checks were headless, and today's changes are not yet committed.

Result

In the running editor, a cube with collision, rigid body and mass now shows four clearly separated cards, and each field sits under the schema that owns it. Gizmo moves now show up in the Transform fields, and the UR10's articulation settings can be edited in place.

Next steps are to commit and push these changes, re-run the full suite, test the gizmo against real robot assets in the native viewport, and check the Translate fields at narrow panel widths.

背景

Turing Sim 是一个实验性的 OpenUSD 编辑器和机器人仿真工作台。Schemas 页会列出所选 prim 上的所有 schema（包括物理 API），所有修改都进入文档的撤销历史。9 月 28 日时，这个页面能用，但很难读：视口工具区夹在名称和 Transform 之间；没有属性的 schema 显示“No additional properties”；刚体（Rigid Body）和质量（Mass）的字段之间没有边界，混在一起。Transform 只显示文件里已写入的部分，所以 UR10 只有位置，没有旋转和缩放。

目标与难点

目标是让这个页面按 USD 的结构来呈现，并参考 Isaac Sim 属性面板的做法：每个属性都明确属于一个 schema；Transform 负责位置、旋转和缩放；Articulation Root 能设置自碰撞等参数。难点在于不能硬编码机器人或 schema 名称（项目规则禁止），也不能破坏撤销。

测试时又发现一个问题：用 gizmo 移动 UR10 后，Transform 变成“custom transform stack”，位置数值不再更新。

解决思路与行动

每个 schema 一张卡片。 每个 schema 现在是一张带边框的卡片。标题栏左边是易读的名称，右边是 USD schema 标识（例如 PhysicsRigidBodyAPI），已应用的 API 还有删除按钮。删除 schema 时会一并清除它在当前编辑层的数值，整体是一步撤销。以数组为主的卡片（如网格拓扑）默认折叠。
Isaac Sim 风格的属性行。 每行左边是标签、右边是数值，面板较窄时自动上下排列。标签来自 schema 自带的 displayName 元数据，例如“Center of Mass”。行尾的圆点表示数值是否已写入：空心是 schema 默认值；蓝色表示已写入当前编辑层（点击可恢复默认）；灰色表示写在其他层。布尔值改为复选框；USD 默认值为无穷大的物理字段显示为“Auto”。
Transform 负责位置、旋转和缩放。 Translate、Rotate（或 Orient）和 Scale 始终显示，名称与 USD 变换操作一致。旋转可在欧拉角和四元数之间切换，任一种输入都会转换成 prim 原本使用的形式，因此 Isaac 风格的 orient 四元数仍保持为四元数。
gizmo 直接修改真实变换。 数值不更新的原因是：拖动时写入的是一个额外的矩阵操作，而不是修改 prim 自身的平移和旋转值。现在拖动直接更新这些值。只有位置/旋转/缩放无法表示的变换才保留矩阵操作作为后备；旧的矩阵操作会在下次编辑时合并回去。
Articulation Root 设置。 卡片会统计根节点下找到的刚体和关节数量，并提供 PhysX 关节体设置：启用、自碰撞、求解器迭代次数、休眠阈值和稳定阈值。修改其中一项时，会在同一步撤销里写入数值并应用 PhysX 关节体 schema。
源资产编辑器。 引用资产的独立编辑器改用与主窗口相同的玻璃卡片和分段标签。用户提供的原生编辑器截图展示了新版布局；该窗口中的编辑操作尚未经过有界面验证。

每条新的编辑路径都有带撤销/重做的回归测试，另外还用 USD 自身的旋转操作验证了全部六种欧拉轴顺序。完整的离屏测试结果为 525 项通过、3 项失败、6 项跳过。3 项失败都是旧测试仍按原名称“Position X”查找字段；更新后，相关测试文件（61 项）全部通过，但此后尚未重新运行整套测试。文章顶部的三张截图均展示改动后运行中的应用：分开的 schema 卡片、UR10 的 Transform 与 Articulation Root 面板，以及源资产编辑器。它们证明的是可见布局与数值，并不能证明完整的编辑或保存流程。其余检查均为无界面运行，今天的改动也还没有提交。

结果与下一步

在运行中的编辑器里，一个带碰撞、刚体和质量的立方体现在显示为四张清晰分开的卡片，每个字段都在它所属的 schema 下面。gizmo 的移动会直接反映在 Transform 字段里，UR10 的关节体设置也可以直接编辑。

下一步：提交并推送这些改动，重新运行整套测试，在原生视口中用真实机器人资产测试 gizmo，并检查窄面板下的 Translate 字段。

From Localhost to a Built-In Tab: Keeping Story Engine Beside the Conversation

alphanine — Mon, 28 Sep 2026 05:31:04 +0000

Situation

Story Engine began with a review page opened through a local website. It provided a place to browse drafts, read an article and edit it before publication. The project conversation lived elsewhere.

Embedding the entire review page directly in the conversation introduced another layout problem. A long article could occupy most of the chat, making it awkward to move between discussing a change and reviewing the draft.

Task

The goal was to give Story Engine its own review Tab beside the conversation, while preserving the existing interface and local drafts. The chat needed a small entrance; the article needed enough room to read.

This also required a clear boundary between the application and its host. Story Engine could request a presentation mode, while the client controlled where and how that workspace appeared.

Action

The implementation packages the existing page, styles, scripts and brand assets as an MCP UI resource. In the hosted interface, actions go through the same business service used by the browser version. This MCP route serves the interface without starting a localhost HTTP listener and continues using the local data store.

On initialization, the entrance requests the host's expanded presentation once. In this client, that presentation provides the built-in Tab. The inline conversation keeps a compact launcher, with an “Open Tab” button available if the automatic request does not switch the view. Closing the Tab does not start an automatic reopening loop.

The move also exposed a resource-version problem. A newer page could otherwise reach an older process whose registered tools had not changed. Each new server process now retains its bundled UI snapshot alongside its tool registrations. Loading newly added tools still requires the client to reload the updated server.

Result and next steps

The accompanying user-provided screenshot shows Story Engine's draft library in a named Tab on the right, with the project conversation still visible on the left. It provides direct evidence of the opened workspace in this client. The opening transition itself was not recorded, so the image does not establish whether that particular Tab opened automatically.

Source inspection and simulated-host tests cover the compact entrance, the presentation request, fallback behavior and shared operations. The screenshot complements those checks by showing the actual host layout. It does not establish that every review action has been exercised inside that Tab.

The practical improvement is that the conversation and draft workspace can remain visible together. Story Engine still runs locally on the user's Mac. The next step is to verify the complete opening, review and return journey across supported clients and a clean installation, including the behavior of older running plugin processes.

从 localhost 到内置 Tab：让 Story Engine 审稿区留在对话旁

背景

Story Engine 最初通过本地网站打开审稿页，用户可以在里面浏览草稿、阅读文章，并在发布前编辑。项目讨论则留在另一处对话中。

后来把完整审稿页嵌进对话，又产生了布局问题：长文章会占据大部分聊天空间，在讨论修改和阅读草稿之间切换变得不够顺手。

目标与难点

目标是让 Story Engine 在对话旁拥有独立的审稿 Tab，同时保留已有界面和本地草稿。对话只需要一个紧凑入口，文章则需要足够的阅读空间。

应用与宿主之间的职责也需要明确：Story Engine 可以请求一种呈现方式，工作区最终放在哪里、怎样出现，由客户端决定。

解决思路与行动

当前实现把原有页面、样式、脚本和品牌素材打包为 MCP UI 资源。在宿主内打开时，界面操作通过与浏览器版相同的业务服务处理。这条 MCP 路径不需要启动 localhost HTTP 监听，仍然使用原来的本地数据存储。

入口初始化后，会请求一次宿主的展开呈现方式；在这个客户端中，它对应内置 Tab。对话内保留紧凑的启动入口，如果自动请求没有切换视图，用户仍可点击“打开 Tab”。关闭 Tab 后，也不会进入反复自动打开的循环。

这次迁移还暴露了资源版本问题：新页面可能连接到仍注册着旧工具的进程。现在，每个新启动的服务进程都会固定保存与自身工具注册配套的界面快照。新增工具要真正进入当前客户端，仍需重新加载更新后的服务。

结果与下一步

附图由用户提供，真实显示了右侧名为 Story Engine 的 Tab 和草稿列表，左侧项目对话仍然可见。这直接证明了该客户端中已经打开的工作区。打开过程没有录制，因此这张静态截图不能确定当时是否自动切换到了 Tab。

源码核对和模拟宿主测试覆盖了紧凑入口、呈现请求、回退行为，以及共用的业务操作。真实截图补充了实际宿主布局的证据，但不能据此认定所有审稿操作都已在这个 Tab 中逐项验证。

实际变化是：项目讨论和草稿工作区可以同时留在视野内。Story Engine 仍在用户的 Mac 上本地运行。下一步需要在支持的客户端及干净安装环境中，验证打开、审稿和返回对话的完整路径，并继续检查旧插件进程的兼容行为。

Turing Sim: Turning a UI Refresh into a Shareable Milestone

alphanine — Mon, 28 Sep 2026 05:15:31 +0000

Turing Sim: Turning a UI Refresh into a Shareable Milestone

Situation

Turing Sim is an experimental OpenUSD editor and robotics simulation workbench. Its interface needs to keep the 3D viewport central while giving scene editing, inspection, and simulation controls a coherent place to live. The project also has a strict rule for interactive USD edits: they must enter the document command history so users can undo and redo them.

The project owner reported a much better interface after work with Claude Code. On September 27, the immediate need was to capture that work in a reviewable Git commit and make it available on GitHub. The commit includes more than visual changes, so this is a record of the milestone rather than a claim that every feature was built that day.

Task

The goal was to preserve the current application work without sweeping generated output into source control, check what could be verified headlessly, and synchronize it with the published repository. A second challenge was communicating the limits of that verification: the local Python environment does not include every binding used by the full desktop editor.

Action

The recorded changes establish a shared Qt design system with appearance modes, reusable controls, icons, and glass surfaces. The accompanying screenshot shows the newer glass treatment across the window chrome, dock tabs, panels, and viewport tools. The UI work also spans dock tabs, workspace layout, editor chrome, viewport controls, and robot panels. Separately, the commit adds a common runtime contract for Genesis and MuJoCo, a MuJoCo conversion path, and physics authoring through the undoable document command flow. These are distinct areas of work collected in one milestone commit.

The full headless test command completed with 372 passing tests and 14 skips. It also reported 12 failures and 3 errors. Several editor tests could not import pxr.Usdviewq; native schema subprocess tests crashed in the local macOS/OpenUSD environment. Those outcomes prevent a clean-suite claim and call for validation in the intended runtime. The generated MuJoCo warning log was left out of the commit.

GitHub authentication was refreshed. The remote repository had separate commit history but the same pre-change file tree, so the new commit was replayed onto the remote main and pushed without replacing its existing history. The resulting commit is 5881d6f.

Before and after: the interface

Earlier interface: flat charcoal panels and underlined tabs.

Current interface: glass surfaces and grouped controls around the viewport.

The earliest UI capture available for this comparison shows a flatter, mostly charcoal workspace: underlined Objects/Layers tabs, a fixed Inspector, and a small floating tool strip. The current capture shows blue-tinted glass around the viewport, capsule-shaped dock tabs and toolbar groups, a searchable scene tree, and more prominent floating viewport controls. The 3D canvas remains the visual center in both.

These screenshots use different selection and camera states. They illustrate changes in layout and visual language, not a controlled rendering-quality or performance comparison.

Result

The UI and simulation work is now recorded and available for review on GitHub. The design system documentation gives future panels a consistent visual vocabulary, while the engine adapter documentation lays out a path for comparable runtime checks. It explicitly treats benchmark numbers as unmeasured until the benchmark scripts are run and recorded.

The next validation step is to run the editor and schema checks in the supported macOS launch environment, investigate the observed failures, and record measured engine results before drawing performance conclusions.

Turing Sim：将界面更新整理成可分享的里程碑

背景

Turing Sim 是一个实验性的 OpenUSD 编辑器和机器人仿真工作台。界面需要让三维视口保持中心地位，同时清晰地组织场景编辑、属性检查和仿真控制。项目还有一条重要约束：交互式 USD 修改必须进入文档命令历史，才能可靠地撤销和重做。

项目负责人反馈，经过与 Claude Code 协作，界面已有明显改善。9 月 27 日的直接目标是把当前工作保存为可审查的 Git 提交，并同步到 GitHub。本次提交不仅包含视觉更新；提交日期并不能证明每项功能都是当天实现的。

目标与难点

这次需要完整记录应用代码，避免把生成的运行日志混入版本库，完成可在无界面环境运行的验证，并与已发布的仓库同步。另一个难点是准确说明验证边界：本地 Python 环境缺少桌面编辑器所需的部分绑定。

解决思路与行动

提交中的界面工作建立了共享的 Qt 设计系统，包括外观模式、可复用控件、图标和玻璃质感表面。配图展示了新版玻璃效果在窗口工具栏、停靠标签、面板和视口工具上的应用；还覆盖了停靠标签、工作区布局、编辑器工具栏、视口控件和机器人面板。另一部分工作加入了 Genesis 与 MuJoCo 的统一运行接口、MuJoCo 转换路径，以及通过可撤销文档命令进行的物理属性编辑。这些不同方向的改动被整理进同一个里程碑提交。

完整的无界面测试运行结果为 372 项通过、14 项跳过，同时有 12 项失败和 3 项错误。部分编辑器测试无法导入 pxr.Usdviewq；原生 schema 子进程测试在本地 macOS/OpenUSD 环境中崩溃。因此目前不能声称整套测试通过，仍需在目标运行环境继续验证。生成的 MuJoCo 警告日志没有纳入提交。

刷新 GitHub 登录后，发现远端仓库具有独立的提交历史，但变更前的文件树与本地一致。于是将新提交接到远端 main 的历史之后再推送，保留了远端已有历史。最终提交为 5881d6f。

初版与现在：界面变化

早期界面：深灰色平面面板与下划线标签。

当前界面：视口周围采用玻璃质感与分组控件。

目前能找到的最早界面截图以较平面的深灰工作区为主：Objects/Layers 使用下划线标签，Inspector 固定在右侧，视口中只有较小的浮动工具条。新版截图则展示了视口周围的蓝色玻璃质感、胶囊形停靠标签与工具栏分组、可搜索的场景树，以及更醒目的浮动视口控件。两版都把三维画布放在视觉中心。

两张截图的选择状态和相机视角不同，因此这里只比较布局与视觉语言，不据此判断渲染质量或性能。

结果与下一步

这批界面与仿真工作现已记录在 GitHub，供团队审查。设计系统文档为后续面板提供统一的视觉语言；引擎适配文档则定义了比较不同运行后端的方式。文档明确指出，基准测试数值仍需实际运行并记录，当前不能据此得出性能结论。

下一步是在受支持的 macOS 启动环境中验证编辑器和 schema，调查已观察到的失败，并在比较引擎性能前取得真实测量结果。

From Hello World to Project Retrospectives: Bringing Codex Work into a Publishing Workflow

alphanine — Tue, 08 Sep 2026 05:15:09 +0000

English

S · Situation

We are building Story Engine: a product that turns the process of working on a project with AI into an article, making the outcomes easier to share. Our earlier exploration of publishing platforms exposed a problem: successfully verifying an account does not necessarily mean that publishing through its API will work.

Today, our first Hello World post went live on DEV.to. This small milestone lets us move on to the core experience: finishing a project without having to reconstruct the entire story from memory before writing a retrospective.

T · Task and Challenges

The next goal is to say “summarize today's or this week's project progress” in Codex and receive a STAR draft covering progress, challenges, solution approaches, and results.

The main challenge is the scope of the evidence. Code can show what changed, but not necessarily why; the current discussion may not cover the entire week. Another challenge is review consistency: the text the user approves should be exactly the text that gets uploaded.

A · Actions and Approach

We implemented the first version as a project-level Codex skill. It uses the current project's discussions and verifiable materials, defines the reporting period, and distinguishes plans from verified results and unfinished work. STAR provides the narrative structure; missing facts are not filled in with invented details.

Generated articles first enter a local draft store. The web app provides a dedicated “Codex Progress Drafts” view showing the article, source coverage, and supporting notes. Those notes remain local; the publishing request contains only the title and article body.

The publishing flow checks the reviewed draft version and the target account. If the text changes, it must be reviewed again. We also retain the existing duplicate-publication protection: when a request's outcome is uncertain, automatic retries stop so the platform's actual state can be checked first.

R · Results and Next Steps

The user has confirmed that Hello World was successfully published. We have also implemented the progress-drafting instructions, local import, web review, and DEV.to publishing entry point. All 13 automated tests passed, including checks for custom article request formatting and draft-change detection.

These tests use a simulated remote service; they do not establish that this progress article has been published. The next step is to review a real project draft, check its narrative and factual accuracy, and complete a live publication. Coverage across multiple tasks still depends on the project materials Codex can access at the time.

中文

S · 背景

我们在做 Story Engine：把与 AI 一起推进项目的过程整理成文章，让项目成果更容易被分享。此前的发布渠道探索暴露了一个问题：能验证账号，并不意味着就能顺利通过 API 发文。

今天，第一篇 Hello World 已在 DEV.to 发布。这个小里程碑让我们可以继续验证更核心的体验：项目做完后，不再从头回忆如何写一篇复盘。

T · 目标与难点

接下来的目标是，在 Codex 中说一句“总结今天或本周的项目进度”，就得到一份包含进度、难点、解决思路和结果的 STAR 待审稿。

难点在于证据边界。代码能说明改了什么，却不一定能说明为什么改；当前讨论也未必覆盖整个星期。另一个问题是审阅一致性：用户批准的正文，应当就是最终上传的正文。

A · 解决思路与行动

我们将第一版做成项目内的 Codex 技能。它以当前项目的讨论和可核对材料为依据，明确时间范围，并把计划、已验证结果和仍未完成的内容分开。STAR 结构负责组织叙事，缺失的事实不会靠补写来填满。

生成后的文章先进入本地草稿库。网页提供独立的“Codex 进度稿”入口，展示正文、覆盖范围和依据。依据留在本地，发布请求只携带标题与正文。

发布流程会核对审阅时的草稿版本与目标账号；正文变化后需要重新审阅。我们沿用已有的重复发布保护：请求结果不确定时停止自动重试，先核实平台状态。

R · 结果与下一步

Hello World 的真实发布已由用户确认。项目进度稿的生成规范、本地导入、网页审阅与 DEV.to 发布入口也已完成实现，13 项自动测试通过，包括自定义文章请求格式和草稿变化检测。

这些测试使用模拟远端，不代表这篇进度文章已经发布。下一步是审阅一份实际项目稿，检查叙事和事实是否准确，再完成一次真实发布。跨任务记录的完整覆盖仍取决于 Codex 当时可访问的项目资料。

Hello World

alphanine — Tue, 08 Sep 2026 04:55:32 +0000

Hello, world!

This is a test post from Story Engine, a project that turns AI-assisted project discussions into blog posts.

This first post is here to verify the publishing connection. More project stories will follow.