Sequence 13 - Vulkan / WebGPU / 3D 展示 / AI Blender 资产 Workflow 专项深挖
这一页讲你的 GPU-adjacent 项目。它们不是 CUDA production ownership,但能证明你有 GPU workload、graphics/compute pipeline、rendering performance、resource lifecycle、profiling 和 AI-assisted asset workflow 的经验。
本页覆盖三类项目:
1. Wuxia: Bevy + Rust 水墨 2.5D 武侠 ARPG
2. Diamond: Babylon.js / WebGL 3D 钻石展示,diamond.moxixii.com
3. Blender Agent Tool: AI workflow 在线/本地生成 3D 模型资源,并接入展示或游戏资产链路
1. 面试定位
一句话:
我的直接 GPU 项目主要是 Vulkan/WebGPU/WebGL/Bevy/Babylon.js 相关,而不是 CUDA kernel production ownership。它们的价值是证明我理解 GPU workload behavior、rendering/data pipeline、resource lifecycle、profiling timeline、memory/resource tradeoff,以及如何把 AI 生成资产接到 3D runtime 里。
English:
My direct GPU-related projects are mainly Vulkan/WebGPU/WebGL/Bevy/Babylon.js style projects rather than CUDA kernel production ownership. I use them to demonstrate transferable GPU systems experience: workload behavior, rendering and data pipelines, resource lifecycle, profiling timelines, memory/resource tradeoffs, and integrating AI-generated 3D assets into a runtime.
1.1 CV 实际口径:Rust+Vulkan、Diamond/WebGPU、Wuxia、Blender workflow
这一页要分清楚 CV 里写了什么、延伸项目是什么:
CV 明确写的项目:
1. Rust + Vulkan Rendering Pipeline:geometry processing、lighting、post-processing、PBR、deferred rendering、GPU-driven experiments、RenderDoc/Nsight。
2. Diamond Renderer / WebGPU Compute Experiment:real-time ray tracing / physical optics simulation、refraction、dispersion、TIR、performance-quality tradeoff。
本地可作为延伸讲解的项目:
1. Wuxia:Bevy + Rust 2.5D 武侠 ARPG,证明 real-time runtime、ECS、asset loading、shader/postprocess、debug overlay。
2. Blender Agent Tool:AI workflow 生成/修复 3D assets,证明 AI workflow + deterministic runtime + asset pipeline。
中文项目讲法:
我在 CV 里写的 GPU 项目,主线是 Rust+Vulkan rendering pipeline 和 Diamond WebGPU compute/rendering experiment。Rust+Vulkan 项目覆盖 geometry processing、lighting、post-processing、PBR、deferred rendering、GPU-driven rendering experiments,并用 RenderDoc/Nsight 看 GPU-side behavior、resource usage 和 performance hotspots。Diamond 项目更偏 WebGPU/WebGL 实时渲染和物理光学表现,涉及 refraction、dispersion、total internal reflection、render-to-texture、layered materials 和 performance-quality tradeoff。
Wuxia 和 Blender Agent Tool 是我最近的延伸项目。Wuxia 用 Bevy/Rust 把实时系统拆成 AppState、插件、map loading、ECS、HUD、debug overlay、水墨后处理;Blender Agent Tool 把 prompt 经过 planner/DAG/agent/DSL/Blender runtime 变成 3D asset。这些项目不是 CUDA production ownership,但能证明我能围绕 GPU workload、runtime resource lifecycle、profiling、asset pipeline 和 AI-generated 3D workflow 做系统设计。
English project story:
The GPU-related projects explicitly listed in my CV are the Rust + Vulkan rendering pipeline and the Diamond WebGPU compute/rendering experiment. The Rust + Vulkan project covered geometry processing, lighting, post-processing, PBR, deferred rendering, and GPU-driven rendering experiments, and I used RenderDoc and Nsight to inspect GPU-side behavior, resource usage, and performance hotspots. The Diamond project is more about real-time WebGPU/WebGL rendering and physical optics behavior, including refraction, dispersion, total internal reflection, render-to-texture, layered materials, and performance-quality tradeoffs.
Wuxia and Blender Agent Tool are recent extension projects. Wuxia uses Bevy/Rust to structure a real-time system around AppState, plugins, map loading, ECS, HUD, debug overlays, and ink-wash post-processing. Blender Agent Tool turns prompts into 3D assets through a planner, DAG, agents, DSL, and Blender runtime. These are not CUDA production ownership, but they demonstrate my ability to reason about GPU workloads, runtime resource lifecycle, profiling, asset pipelines, and AI-generated 3D workflows.
2. 项目总图
flowchart TB
GPUProjects[GPU / 3D Project Family] --> Wuxia[Wuxia Bevy Rust ARPG]
GPUProjects --> Diamond[Diamond Babylon.js Showcase]
GPUProjects --> Blender[Blender Agent Tool]
Wuxia --> Bevy[Bevy ECS / Render Pipeline / World Streaming]
Wuxia --> Ink[Ink-wash Postprocess / WGSL Shader]
Wuxia --> GameNet[Login / Scene State / Network Game Skeleton]
Diamond --> Babylon[Babylon.js Engine / Scene / Camera / Lights]
Diamond --> RTT[RenderTargetTexture Refraction]
Diamond --> Post[Chromatic Aberration / Bloom / Vignette]
Blender --> DAG[DAG Engine / Agent Workflow]
Blender --> DSL[Blender DSL / Python Runtime]
Blender --> Assets[Generated 3D Assets / Multi-view Render]
Bevy --> Transfer[Transferable GPU Skills]
RTT --> Transfer
Assets --> Transfer
Transfer --> Timeline[GPU Timeline / Resource Bottleneck]
Transfer --> Memory[Buffer / Texture / Material / Asset Lifecycle]
Transfer --> Profile[RenderDoc / Nsight / Runtime Profiling]
Transfer --> CUDA[Bridge to CUDA / Nsight Experiments]
3. Wuxia:Bevy + Rust 水墨 2.5D 武侠 ARPG
3.1 项目定位
本地路径:
/Users/fengwenxuan/Desktop/startup-project/game-projects/games/wuxia
它是一个 Bevy + Rust 的 2.5D 武侠 ARPG,核心点包括:
Bevy ECS
Rust game client
Axum + Tokio backend
Login -> CharacterSelect -> InGame state machine
mouse click movement
scene/map loading
ink-wash postprocess shader
HUD/debug overlay/minimap/skill bar
map index / RON map data / async asset loading
world streaming design
中文项目讲法:
Wuxia 是一个 Bevy + Rust 的 2.5D 武侠 ARPG prototype,数据主要来自 RON map 配置、角色状态、输入事件、资源文件和运行时 ECS state。系统启动后先进入 Login,再进入 CharacterSelect,最后进入 InGame。InGame 阶段会加载 map index 和 RON map data,构建 terrain、obstacle、portal、NPC、character、spatial grid,再通过 Bevy ECS 和插件系统驱动输入、相机、角色、世界渲染、HUD、debug overlay。
我做这个项目时重点不是“做游戏玩法”,而是练 real-time runtime system:state machine、asset lifecycle、scene/map loading、spatial indexing、debug visibility 和 rendering pipeline。性能上我会按 60 FPS 的实时系统目标理解,也就是单帧预算约 16.7ms。面试里不要编真实 FPS 数字;可以说这个项目训练的是 frame budget、resource lifetime、runtime state transition、GPU workload 和 profiling 思维。
English project story:
Wuxia is a Bevy and Rust-based 2.5D ARPG prototype. The data comes from RON map configuration, character state, input events, asset files, and runtime ECS state. The app starts from Login, moves to CharacterSelect, and then enters InGame. In the InGame state, it loads the map index and RON map data, builds terrain, obstacles, portals, NPCs, characters, and a spatial grid, and then uses Bevy ECS and plugins to drive input, camera, character logic, world rendering, HUD, and debug overlays.
The point of this project was not only gameplay. I used it to practice real-time runtime-system design: state machines, asset lifecycle, scene and map loading, spatial indexing, debug visibility, and rendering-pipeline reasoning. For performance, I reason about it as a 60 FPS real-time system, which means roughly a 16.7 ms frame budget. I would not invent actual FPS numbers in an interview; I would use the project to demonstrate frame-budget thinking, resource lifetime management, runtime state transitions, GPU workload awareness, and profiling methodology.
3.2 架构图
flowchart TB
App[Bevy App] --> State[AppState: Login / CharacterSelect / InGame]
App --> Plugins[Plugin Registration]
Plugins --> Input[Input Plugins]
Plugins --> Camera[Camera Plugins]
Plugins --> Character[Character Plugins]
Plugins --> World[World Plugins]
Plugins --> HUD[HUD Plugins]
Plugins --> Platform[Platform Plugins]
State --> Login[Login Scene]
State --> Game[InGame Scene]
Game --> MapLoader[Map Loader]
MapLoader --> RON[RON Map Data]
MapLoader --> Spatial[Spatial Grid / Obstacles]
MapLoader --> Entities[Characters / NPC / Portal / Terrain]
Input --> Move[Mouse Click Movement]
Camera --> View[2.5D Camera / Free-Lock Switch]
World --> Render[Scene / Weather / Day-Night / Foliage]
HUD --> UI[Status / Skill / Chat / Minimap / Debug]
3.3 和 NVIDIA JD 的连接
| Wuxia 能证明什么 | 对 NVIDIA 的迁移 |
|---|---|
| Bevy ECS / Rust modular architecture | 系统拆分、state machine、runtime scheduling 思维。 |
| Render pipeline / shader / postprocess | GPU workload、render pass、resource pipeline。 |
| Async asset/map loading | data path、resource lifecycle、latency spike control。 |
| Spatial grid / obstacle / map index | data-oriented design、runtime indexing。 |
| Login / scene transition / network skeleton | production workflow、state management。 |
| Debug overlay / FPS / server status | observability and diagnostics。 |
3.3.1 Wuxia 网络和同步路径 / Wuxia networking and synchronization path
Wuxia 设计文档里不是单机 demo 思路,而是从一开始预留了在线化架构:HTTP 负责弱实时 API,QUIC/WebSocket 负责强实时同步,客户端本地预测,后端权威状态。
中文讲法:
Wuxia 的网络设计可以按 game networking path 讲:Bevy client 通过 HTTPS 访问 API Gateway 做 auth/config/profile,通过 QUIC 或 WebSocket 连接 Realtime Gateway;Realtime Gateway 负责连接管理、会话路由、心跳和断线恢复;Session Service 管房间/分线/实例生命周期;Simulation Service 做权威战斗计算;World Streaming Service 做 chunk 加载和跨 chunk 迁移。客户端负责表现和本地预测,后端负责权威状态和持久化。
这个设计和 NVIDIA JD 的连接不是 GPU networking 直接经验,而是实时系统里的 network path、state sync、latency、snapshot/delta、backpressure、observability 和 failure recovery。它也能补充我 CV 里的 high-concurrency communication path 背景:连接管理、消息路径稳定性、监控指标、online issue diagnosis。
English:
The Wuxia networking design can be explained as a game-networking path. The Bevy client uses HTTPS to access the API Gateway for auth, configuration, and profile data, and uses QUIC or WebSocket to connect to the Realtime Gateway. The Realtime Gateway handles connection management, session routing, heartbeat, and disconnect recovery. The Session Service manages room or instance lifecycle. The Simulation Service performs authoritative combat simulation, and the World Streaming Service handles chunk loading and cross-chunk migration. The client owns presentation and local prediction, while the backend owns authoritative state and persistence.
The connection to the NVIDIA JD is not direct GPU networking ownership. It is real-time system thinking: network paths, state synchronization, latency, snapshot/delta updates, backpressure, observability, and failure recovery. It also supports the high-concurrency communication-path background in my CV: connection management, message-path stability, metrics, and online issue diagnosis.
flowchart TB
Client[Bevy Client] --> API[API Gateway: HTTPS]
Client --> RT[Realtime Gateway: QUIC / WebSocket]
API --> Auth[Auth / Config / Profile]
RT --> Session[Session Service]
Session --> Sim[Authoritative Simulation]
Session --> World[World Streaming Service]
World --> Chunk[Chunk State / World Store]
Sim --> Event[Gameplay Event Bus]
Event --> Replay[Replay / Observability]
Replay --> Metrics[Metrics / Logs / Traces]
3.4 面试讲法
中文:
我会按 Context、Data、Path、My work、Bottleneck、Metrics 来讲。Context 是做一个实时 2.5D 武侠 ARPG prototype;Data 是 RON map、asset、input、ECS state;Path 是 AppState -> map loading -> entity/spatial grid -> render/HUD/debug;My work 是把系统拆成插件、状态机、地图加载、runtime visibility 和渲染表现;Bottleneck 主要关注 asset loading、frame budget、state transition 和渲染资源生命周期;Metrics 不是业务数字,而是 16.7ms frame budget、FPS、加载耗时、debug overlay 和 runtime visibility。
English:
The Wuxia project is a Bevy and Rust-based 2.5D ARPG prototype. It includes a structured Bevy app, AppState transitions such as Login, CharacterSelect, and InGame, mouse-click movement, map loading from RON data, spatial grid and obstacle handling, HUD/debug overlays, and an ink-wash rendering style.
I would not present it as CUDA work. I would present it as GPU-adjacent systems experience: rendering pipeline design, asset lifecycle, scene state management, runtime data layout, profiling visibility, and performance-aware game architecture. The transferable part for NVIDIA is the way I reason about GPU workloads and runtime systems: data path, resource lifetime, frame budget, bottleneck visibility, and controlled state transitions.
4. Diamond:Babylon.js 3D 钻石展示
4.1 项目定位
本地路径:
/Users/fengwenxuan/Desktop/startup-project/labs-demos/babylon-diamond-react
线上展示:
它是 React + TypeScript + Vite + Babylon.js 的 3D 钻石展示项目,核心是高质量实时渲染:
RenderTargetTexture refraction
inner / outer layered materials
NodeMaterial custom shader JSON
PBR material
chromatic aberration
bloom
vignette
auto-rotation showcase
real-time color adjustment
WebGL runtime resource cleanup
中文项目讲法:
Diamond 是一个 React + TypeScript + Babylon.js 的实时 3D 展示项目。数据来源包括 diamond.json 模型、材质参数、用户实时调色输入、相机/灯光配置和 Babylon runtime scene state。渲染路径是 Canvas -> Babylon Engine -> Scene -> Camera/Lights -> load diamond assets -> RenderTargetTexture -> inner/outer material -> postprocess -> render loop。
我做的重点是把“漂亮的 3D 展示”拆成可解释的 GPU resource path:WebGL engine 生命周期、scene graph、render-to-texture、折射纹理、layered materials、NodeMaterial shader 配置、postprocess pass 和 engine.dispose 清理。性能上按浏览器实时展示理解,目标仍然是接近 60 FPS,也就是约 16.7ms frame budget;如果实际设备不同,不要说死绝对 FPS,而是说用 frame time、render loop stability、GPU resource cleanup 和 visual quality/performance tradeoff 来验证。
English project story:
Diamond is a React, TypeScript, and Babylon.js real-time 3D showcase. The data comes from the diamond.json model, material parameters, real-time user color controls, camera and lighting configuration, and Babylon runtime scene state. The rendering path is canvas, Babylon engine, scene, camera and lights, asset loading, RenderTargetTexture, inner and outer materials, postprocess, and render loop.
My focus was decomposing a visually rich 3D showcase into an explainable GPU resource path: WebGL engine lifecycle, scene graph, render-to-texture, refraction texture, layered materials, NodeMaterial shader configuration, postprocess passes, and engine.dispose cleanup. For performance, I reason about it as a browser real-time rendering system targeting roughly 60 FPS, which means a 16.7 ms frame budget. I would not claim a fixed FPS across all devices; I would explain that I validate it through frame time, render-loop stability, GPU resource cleanup, and visual quality versus performance tradeoffs.
4.2 渲染 data path
flowchart TB
Canvas[Canvas] --> Engine[Babylon Engine]
Engine --> Scene[Scene]
Scene --> Camera[Camera]
Scene --> Lights[Lights]
Scene --> Assets[Load diamond.json]
Assets --> Meshes[Diamond / Cloth / Environment / Shadow]
Meshes --> RTT[RenderTargetTexture Refraction]
RTT --> Inner[Diamond Inner Material]
RTT --> Outer[Diamond Outer Material]
Inner --> Post[Postprocess]
Outer --> Post
Post --> Frame[Rendered Frame]
Frame --> Loop[Render Loop]
Loop --> Frame
4.3 技术点怎么讲
| 技术点 | 是什么 | 面试意义 |
|---|---|---|
| Babylon Engine / Scene | WebGL runtime 和场景图 | GPU runtime lifecycle。 |
| RenderTargetTexture | 先渲染到纹理,再作为折射输入 | offscreen rendering / data reuse。 |
| Inner / outer material | 钻石内层折射、外层反射分离 | layered rendering / material decomposition。 |
| NodeMaterial | JSON/节点式 shader 定义 | shader pipeline 可配置化。 |
| Postprocess | 色差、泛光、暗角 | pass-based rendering pipeline。 |
| engine.dispose | 释放 WebGL/GPU 资源 | resource lifecycle 和稳定性。 |
English:
The Diamond project is a Babylon.js real-time 3D showcase. The rendering path creates a WebGL engine and scene, loads the diamond mesh, sets up camera and lights, uses RenderTargetTexture for refraction, separates inner and outer diamond materials, and applies post-processing such as chromatic aberration, bloom, and vignette.
The transferable part is not that it is CUDA. The transferable part is understanding GPU resource lifecycle, render-to-texture, layered materials, shader-driven effects, postprocess passes, render loops, and cleanup of GPU resources.
5. Blender Agent Tool:AI 生成 3D 模型资产 workflow
5.1 项目定位
本地路径:
/Users/fengwenxuan/Desktop/startup-project/labs-demos/blender-agent-tool
它是一套 AI 驱动的 3D 模型生成工具,核心模块包括:
core: DAG engine, state machine, schema, pipeline runner, agent base, memory
blender: DSL compiler + Blender runtime
llm: model routing
agents: specialized agents
cli: generate / exec
providers: external 3D AI providers
fine-tune: JSONL training data collection
中文项目讲法:
Blender Agent Tool 是一套 AI-assisted 3D asset workflow。数据来源是用户 prompt、项目配置、agent schema、Blender DSL/Python runtime、生成后的 geometry/material、multi-view render 和 export artifact。系统路径是 prompt -> planner/orchestrator -> DAG pipeline -> specialized agents -> Blender DSL/Python script -> Blender runtime -> scene/material -> multi-view review -> export glTF/GLB 或其他资产。
我做这个项目时重点是把不可控的 LLM 输出变成可执行、可验证、可修复的 3D asset pipeline。LLM 不直接“随便生成文件”,而是通过 schema、DAG、agent、DSL、runtime execution 和 review loop 约束。这个项目和 NVIDIA JD 的连接不是 GPU networking,而是 AI workflow + deterministic runtime + 3D asset pipeline + GPU-rendered runtime integration。
English project story:
Blender Agent Tool is an AI-assisted 3D asset workflow. The data comes from the user prompt, project configuration, agent schemas, Blender DSL or Python runtime, generated geometry and materials, multi-view renders, and exported artifacts. The system path is prompt, planner or orchestrator, DAG pipeline, specialized agents, Blender DSL or Python script, Blender runtime, scene and material generation, multi-view review, and export to glTF/GLB or other assets.
The point of the project was to turn unstable LLM output into an executable, verifiable, and repairable 3D asset pipeline. The LLM does not just generate arbitrary files. It is constrained by schemas, DAG orchestration, agents, DSL, runtime execution, and review loops. The connection to the NVIDIA role is not GPU networking directly; it is AI workflow design, deterministic runtime execution, 3D asset pipelines, and integration into GPU-rendered runtimes.
5.2 Workflow 架构
flowchart TB
Prompt[User Prompt] --> Planner[Planner / Orchestrator]
Planner --> DAG[DAG Pipeline]
DAG --> Agent[Specialized Agents]
Agent --> DSL[Blender DSL / Python Script]
DSL --> Blender[Blender Runtime]
Blender --> Scene[Scene / Geometry / Materials]
Scene --> Render[Multi-view Render]
Scene --> Export[Model Export]
Export --> Game[Game / Web 3D Runtime]
Render --> Review[Visual Review / Repair]
Review --> Agent
5.3 和 GPU/WebGPU 项目的关系
AI 生成模型资产 -> Blender 处理 geometry/material -> 导出 glTF/GLB -> Bevy/Babylon/WebGPU runtime 加载 -> GPU render/profiling
面试意义:
| 能力 | 说明 |
|---|---|
| AI workflow design | 不只是 prompt,而是 DAG、agent、DSL、runtime。 |
| Asset pipeline | 3D asset 从生成、修复、材质、渲染、多视角检查到 runtime 使用。 |
| Automation | CLI / script / Blender Python 自动化。 |
| Runtime integration | 生成资产可以接入 Bevy 游戏或 Babylon 展示。 |
| System architecture | LLM orchestration + deterministic runtime execution 分离。 |
English:
I also built an AI-assisted 3D asset workflow around Blender. The idea is to use an agent pipeline to turn a prompt into a Blender script or DSL, execute it in Blender, generate geometry and materials, render multi-view outputs for review, and export assets that can be used in a game or Web 3D runtime.
This is relevant because it connects AI workflow design with a real 3D asset pipeline. It is not only prompt engineering; it involves DAG orchestration, schema validation, runtime execution, asset generation, visual review, repair loops, and integration into GPU-rendered applications.
6. 和 CUDA/NVIDIA 面试怎么连接
不要说:
我做过 WebGPU/Babylon/Bevy,所以等于会 CUDA。
要说:
我的 GPU 经验主要是 Vulkan/WebGPU/WebGL/Bevy/Babylon.js 相关,不是 CUDA kernel production ownership。但这些项目训练的是可迁移的 GPU systems 能力:GPU timeline、render/compute pass、resource lifecycle、buffer/texture/material 管理、profiling/debug、memory/resource tradeoff。针对 NVIDIA 岗位,我会用 CUDA/Nsight/NCCL/UCX 实验验证 NVIDIA-specific 部分。
English:
I would not claim that WebGPU or Babylon.js equals CUDA production experience. The transferable part is GPU systems thinking: timelines, passes, resource lifecycle, buffer and texture management, shader or kernel-like workload decomposition, profiling, and memory/resource tradeoffs. For NVIDIA-specific work, I would validate the concrete behavior with CUDA, Nsight Systems, Nsight Compute, NCCL, and UCX.
7. 面试 Q&A
Q1: 你的 GPU 经验不是 CUDA,为什么仍然相关 / Your GPU experience is not CUDA. Why is it still relevant?
中文回答:
这个质疑是合理的。我不会把 Vulkan/WebGPU/WebGL/Bevy/Babylon.js 说成 CUDA production ownership。它们的相关性在于 GPU systems thinking:GPU timeline、render/compute pass、resource lifecycle、buffer/texture/material 管理、shader-like workload decomposition、frame budget 和 profiling-driven optimization。
迁移到 NVIDIA 岗位时,我会明确区分两层:第一层是通用 GPU workload 和 profiling 思维,第二层是 CUDA/Nsight/NCCL/UCX/NIXL 的 NVIDIA-specific 实现。我过去的项目证明第一层,我正在通过 CUDA/Nsight 实验补第二层。
English:
That is fair. My direct GPU experience is more GPU-adjacent: Vulkan/WebGPU/WebGL/Bevy/Babylon.js, not CUDA kernel production ownership.
The relevance is that these projects required me to reason about GPU workload behavior, render passes, command submission, resource lifecycle, buffer and texture management, shader-driven effects, frame budget, and profiling. Those concepts are not identical to CUDA, but the performance reasoning transfers.
For this role, I would use those experiences as a foundation and validate NVIDIA-specific behavior with CUDA, Nsight Systems, Nsight Compute, NCCL, and UCX benchmarks.
Q2: 讲讲 Diamond 项目 / Tell me about the Diamond project.
中文回答:
Diamond 是一个 Babylon.js 实时 3D 钻石展示项目。数据来源是 diamond.json 模型、材质参数、用户调色输入、相机/灯光配置和 runtime scene state。渲染路径是 Canvas -> Engine -> Scene -> Camera/Lights -> Assets -> RenderTargetTexture -> inner/outer materials -> postprocess -> render loop。
我重点做的是 render-to-texture、折射纹理、inner/outer layered materials、NodeMaterial shader 配置、chromatic aberration、bloom、vignette 和 WebGL resource cleanup。这个项目证明的是我能把视觉效果拆成 GPU resource lifecycle 和 render pipeline,而不是只会调 UI。
English:
Diamond is a Babylon.js real-time 3D rendering showcase. It loads a diamond scene, sets up camera and lighting, uses RenderTargetTexture for refraction, separates inner and outer materials for refraction and reflection, and applies postprocessing such as chromatic aberration, bloom, and vignette.
The engineering value is that it forced me to reason about render-to-texture, material layering, shader configuration, render loops, and GPU resource cleanup. I use it as evidence of GPU workload and rendering pipeline experience, not as CUDA production ownership.
Q3: 讲讲 Wuxia 项目 / Tell me about the Wuxia project.
中文回答:
Wuxia 是一个 Bevy + Rust 的 2.5D 武侠 ARPG prototype,数据来自 RON map、asset files、input events、character state 和 ECS runtime state。系统路径是 Login -> CharacterSelect -> InGame,然后 InGame 里加载地图、构建 terrain/obstacle/portal/NPC/character/spatial grid,再驱动 input、camera、world rendering、HUD 和 debug overlay。
我会把它讲成 real-time runtime system,而不是普通游戏 demo。核心是 Bevy ECS、状态机、插件拆分、asset lifecycle、map loading、spatial indexing、debug visibility 和 frame budget。对 NVIDIA 的迁移价值是 GPU workload、runtime data path、resource lifetime 和 profiling 思维。
English:
Wuxia is a Bevy and Rust-based 2.5D ARPG prototype with a network-game direction. It includes Login, CharacterSelect, and InGame states, mouse-click movement, map loading from RON data, spatial grid and obstacle handling, HUD and debug overlays, and an ink-wash visual style.
The relevant part is the architecture: ECS, state transitions, asset loading, scene management, render pipeline, and runtime observability. It shows my ability to design a real-time interactive system with performance and resource constraints.
Q4: 讲讲 AI Blender 资产 workflow / Tell me about your AI Blender workflow.
中文回答:
Blender Agent Tool 是一个 AI-assisted 3D asset workflow。输入是 prompt 和项目配置,经过 planner/orchestrator 生成 DAG,再由 specialized agents 生成 Blender DSL 或 Python script,交给 Blender runtime 执行,生成 geometry/material,做 multi-view render review,最后 export 到游戏或 Web 3D runtime。
重点不是 prompt engineering,而是把 LLM 输出约束成可执行、可验证、可修复的 pipeline。这里涉及 schema validation、DAG orchestration、runtime execution、visual review、repair loop 和 asset integration。
English:
The Blender Agent Tool is an AI-assisted 3D asset workflow. It uses a DAG-style pipeline and agents to turn a prompt into Blender scripts or DSL, executes those scripts in Blender, generates geometry and materials, renders multiple views for review, and exports assets for game or Web 3D runtimes.
The main point is that it connects AI workflow design to a deterministic 3D production pipeline. It is not only prompt generation; it includes orchestration, schema validation, runtime execution, visual review, repair loops, and asset integration.
Q5: 这些项目具体数值怎么讲 / How should you talk about concrete numbers for these projects?
中文回答:
对实时 3D 项目,最安全的数值口径是 frame budget,而不是编一个设备无关的 FPS。60 FPS 对应约 16.7ms 单帧预算,30 FPS 对应约 33.3ms 单帧预算。面试里可以说:我按 frame time、render loop stability、资源加载时间、GPU resource cleanup、视觉质量和性能 tradeoff 来评估。
如果没有正式 benchmark,不要说“稳定 60 FPS”。可以说:“这个项目的目标是实时展示,我用 16.7ms frame budget 的思路拆 render path;真实 FPS 会受设备、浏览器和场景复杂度影响。”
English:
For real-time 3D projects, the safest concrete metric is frame budget rather than inventing device-independent FPS numbers. A 60 FPS target means roughly 16.7 ms per frame, and a 30 FPS target means roughly 33.3 ms per frame. I can say that I evaluate these projects through frame time, render-loop stability, asset-loading time, GPU resource cleanup, and visual quality versus performance tradeoffs.
If I do not have a formal benchmark, I should not claim stable 60 FPS. I can say: the project is designed as a real-time showcase, and I reason about the render path using a 16.7 ms frame-budget model, while actual FPS depends on the device, browser, and scene complexity.
8. 90 秒英文综合讲法
My GPU-related experience is mainly GPU-adjacent rather than CUDA production ownership. I have worked on Bevy/Rust, WebGPU/WebGL, and Babylon.js-style 3D projects.
For example, the Wuxia project is a Bevy and Rust 2.5D ARPG prototype with a structured game state machine, map loading, spatial grid, HUD/debug overlays, and an ink-wash rendering direction. The Diamond project is a Babylon.js real-time 3D showcase using RenderTargetTexture for refraction, layered materials, custom shader configuration, and postprocessing such as bloom and chromatic aberration. I also built an AI-assisted Blender workflow that uses an agent/DAG pipeline to generate or repair 3D assets and export them into runtime environments.
I would not claim these are CUDA production projects. The transferable value is GPU systems thinking: render or compute passes, resource lifecycle, buffer/texture/material management, profiling timelines, memory/resource tradeoffs, and runtime performance constraints. For NVIDIA-specific work, I would validate the concrete behavior with CUDA, Nsight, NCCL, and UCX.
9. 面试边界
可以强调:
- GPU workload / rendering pipeline / resource lifecycle
- Rust/Bevy ECS real-time system architecture
- Babylon.js/WebGL render-to-texture and postprocess
- AI-assisted Blender asset workflow
- profiling and bottleneck isolation mindset
不要夸大:
- 不要说这些等价于 CUDA kernel production ownership
- 不要说 WebGPU 等价于 NCCL/UCX
- 不要说游戏项目直接等价于 AI networking