/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
摘要：
本文探讨在 Web 端实现珠宝 3D 定制功能时遇到的技术挑战与解决方案。重点分析如何利用 Three.js 处理 PBR 材质实时切换的性能瓶颈，以及如何设计一套支持“尺寸-工艺-材质”多维组合的 JSON 数据结构，以实现前端渲染状态与后端生产数据的准确映射。
一、 技术背景与挑战
在需要展示珠宝类产品的 Web 应用中，用户常需调整戒臂宽度、项链长度或预览刻字效果。传统方案多采用预渲染视频或序列帧，存在以下技术痛点：
交互延迟： 参数变更需重新请求资源，无法做到毫秒级响应。
存储爆炸： 若支持 10 种材质 × 5 种宽度 × 20 种刻字，组合数达 1000+，预渲染的存储与维护成本极高。
数据断层： 前端展示的“视觉参数”与后端生产系统所需的“物料清单（BOM）”往往无法自动映射，需要人工二次处理，容易出错。
因此，采用参数化实时渲染与结构化数据驱动是目前更可行的工程方案。
二、 前端渲染：PBR 材质与几何形变
材质实时切换方案
珠宝的核心质感在于金属光泽与宝石折射。我们采用 PBR (Physically Based Rendering) 工作流：
贴图复用： 将 Roughness（粗糙度）、Metallic（金属度）、Normal（法线）贴图分离。切换材质时，仅替换 Albedo（颜色）与 IOR（折射率）参数，无需重载 4K 贴图，显存占用可降低 60% 左右。
环境光遮蔽 (AO)： 珠宝细节多，需烘焙高精度 AO 贴图，确保在暗光环境下刻字凹槽等细节仍有清晰的阴影表现。
几何形变实现
针对“戒臂宽度”、“链长”等形变需求，不使用 Morph Target（形态目标），而是采用 Shader 顶点偏移：
在 Vertex Shader 中，根据 Uniform 传入的 widthFactor，沿法线方向偏移顶点。
注意： 形变后需重新计算法线，否则光照会出现断层。我们在 Fragment Shader 中通过 dFdx/dFdy 实时推导屏幕空间法线，以保证高光连续。
三、 数据结构：从视觉参数到生产参数的映射
这是实现前后端协同的关键环节。前端传递的数据结构必须兼顾视觉效果与生产可行性。
设计原则： 采用 Feature-Flag + 参数对象 模式。
{
"base_sku": "RING-AU750-001",
"custom_params": {
"geometry": {
"band_width": 3.5, // 单位: mm，精度0.1
"band_thickness": 1.8, // 单位: mm
"ring_size": 12 // 港码
},
"craft": {
"type": "laser_engrave", // 工艺类型：激光刻字/微镶/喷砂
"content": "FOREVER",
"font_id": "F-003",
"depth": 0.15 // 刻字深度，直接影响CNC刀头路径
},
"material": {
"main_metal": "AU750-W", // 18K白金
"stone_setting": "pave" // 密镶工艺
}
},
"render_hash": "a1b2c3d4" // 前端渲染快照哈希，用于状态追溯与核对
}
关键点：
枚举约束： 所有参数必须在后端定义的合法值域（Valid_Range）内，前端应做预校验，拦截非法参数，避免无效请求。
版本控制： 每次参数变更，render_hash 必须更新。生产系统可依据此 Hash 追溯当时的渲染状态，有助于问题排查与状态复现。
四、 性能优化策略
在移动端等 WebGL 性能受限的环境中，需做以下针对性优化：
LOD (Level of Detail)： 当模型距离相机 > 50cm 时，自动切换为低多边形（Low-poly）模型，隐藏微镶等细节，仅保留主轮廓。
纹理压缩： 使用 KTX2 / Basis Universal 等 GPU 友好格式，相比 PNG/JPG，解码速度通常有数倍提升，显存占用可减少 50% 以上。
Web Worker 离屏计算： 将 JSON 序列化、Hash 计算、参数校验等 CPU 密集型任务移至 Worker 线程，保证主线程渲染帧率稳定。
五、 总结
实现一个可用的珠宝定制系统，其技术难点不仅在于“渲染出图”，更在于确保“前端渲染参数与后端生产参数的一致性”。
前端开发者需要超越 Shader 效果本身，深入理解后端生产的数据结构需求。只有当 width: 3.5mm 这个参数在前端准确表现为视觉宽度，同时也能被后端系统无误地解析为生产指令（如 CNC 刀头路径）时，整个技术方案才算构建完成。
关于作者：
笔者是一名专注于 WebGL 图形学与前端架构的开发者，对 Three.js 性能优化与复杂场景下的数据结构设计有浓厚兴趣，欢迎在评论区交流相关技术问题。
