用Unity3D打造可交互三维中国历史朝代表：透视穿透与Shader实践-北京尧图网络

去年做了一件事用Unity3D把中国历史朝代表做成一个可交互的三维时间轴项目代号叫Nano Banana Pro。这个名字听起来像是某个水果主题工具链的普通版本实际是我们内部对这个知识可视化项目的完整迭代代号。做之前同事都觉得“这不就是一张加长版图片”做完之后效果完全不一样——它可以点、可以拖、可以半透明穿透看下层时间线甚至还能玩朝代排序小游戏。这个项目适合两类人参考一类是想做历史、科普、教学类可视化应用的Unity3D开发者另一类是手里攒了大量二维图表数据、想升级成三维交互展示的从业者。接下来我把整个项目从设计思路、技术选型、核心Shader写法到生产环境里踩过的各种坑都摊开讲希望对你有帮助。1. 项目解析与整体设计思路1.1 为什么把朝代表做成Unity3D交互应用传统的中国历史朝代表长期就是一张横向长图或者一个表格信息量很大但阅读体验很挑人。倒不是表格本身有问题而是它没法表现“同一时间段内多个政权并存”这种关系。比如北宋和辽、西夏在时间上是重叠的南宋又和金、蒙古重叠。普通表格要么把并列政权放在一行格子里要么加密集备注一开始看还行看多了就开始晕。我当初做Nano Banana Pro的初衷就是把这些“同时存在但不在同一条主干线上的政权”用三维空间的深度关系拉开。一个朝代就对应一块独立的面板主轴上是传统大朝代辅轴上是同时期的并列政权。你看到的就不再是格子而是一排排像书脊一样按时间排序的“朝代板块”。这个表现方式用PPT做不了用Web做很费劲Unity3D反而是最顺手的一个。另外还有一层考虑孩子和年轻人对平面表格普遍无感但对“能亲手操作、能穿透观看”的3D空间很有兴趣。把历史知识放进这种空间里不是把内容娱乐化而是换一种更符合直觉的信息传递方式。1.2 技术选型对比Unity3D vs Web vs 静态图表我把最早评估过的几个方案放在一张表里直接对比方案交互能力3D/透视表现数据接入学习成本我的结论静态长图/PPT极弱无无低只适合快速出原型不适合作为成品Web前端图表库中等弱需要WebGL叠加方便中适合做2D交互做穿透式3D要绕很多路Unity3D强强方便中高最终选型选Unity3D还有一个原因当时目标平台是Windows触控平板和安卓平板Unity的跨平台输出比Web在国内移动设备上要稳得多视频流、点击反馈、渲染性能都比浏览器方案省心。尤其是指尖点击的响应速度Unity原生应用能做到近乎零延迟Web在部分设备上总会觉得慢半拍。1.3 模块化架构数据、渲染、交互、扩展四层分离这个项目虽然定位是“小工具”但我在架构上按产品级做的。核心分四层数据层朝代信息、事件、人物、视频片段地址全部外置用JSON管理。渲染层时间轴面板生成、材质变化、镜头控制。交互层点击、拖拽、缩放、透视切换、小游戏流程。扩展层视频流讲解、后续可接入的3D文物展示模块。这样做的主要原因是知识型应用的数据一定会反复调整。历史顾问可能今天把某个朝代起始年份改一下明天又加一个重点事件。如果数据写在代码里每次都要发版把数据抽到JSON或ScriptableObject策划自己就能改我这边只需要提供好读取接口就够了。实测下来这个决策后来给项目省了至少一周的返工时间。2. 核心视觉方案材质透视与“上层穿透看见下层”2.1 交互目标用透明度解决朝代重叠遮挡问题Nano Banana Pro里最重要的一条交互就是“上层穿透看见下层”。这句话说直白点主轴上的大朝代面板如果挡住了后面的并列政权面板我只要点一下前面这块前面这块就会变成半透明后面被挡住的内容就能透出来。这个交互不是炫技是刚需。历史朝代表里唐宋元明清这种大朝代确实很好排辽宋夏金这种时期就麻烦。如果所有朝代面板都按同一个Z坐标排后面的面板必然被前面的盖住用户只能通过列表翻看那3D布局就失去了全部意义。做透视切换之后点谁谁变透明用户能直观看到“在这一片时间段里还有其他政权同时存在”。我还想过要不要把并列政权默认就做成半透明但后来发现那样做信息很乱所有东西都半透明等于都看不清。所以最终改成“默认全部不透明点击后再切换透明度”这样既保留了正常浏览状态又保留了深度穿透能力。2.2 自定义Shader实现关键代码与渲染设置我用的不是半透明材质的默认改法而是写了一个自定义Shader用一个float参数控制整块面板的透明度Shader Custom/TimelineTransparent { Properties { _MainTex (Texture, 2D) white {} _Color (Tint, Color) (1,1,1,1) _Transparency (Transparency, Range(0,1)) 1 } SubShader { Tags { RenderTypeTransparent QueueTransparent } Blend SrcAlpha OneMinusSrcAlpha ZWrite Off Cull Off Pass { CGPROGRAM #pragma vertex vert #pragma fragment frag sampler2D _MainTex; fixed4 _Color; float _Transparency; struct appdata { float4 vertex : POSITION; float2 uv : TEXCOORD0; }; struct v2f { float2 uv : TEXCOORD0; float4 vertex : SV_POSITION; }; v2f vert (appdata v) { v2f o; o.vertex UnityObjectToClipPos(v.vertex); o.uv v.uv; return o; } fixed4 frag (v2f i) : SV_Target { fixed4 col tex2D(_MainTex, i.uv) * _Color; col.a * _Transparency; return col; } ENDCG } } }这段Shader有几个点值得说明。Queue设置为Transparent是告诉Unity让它在所有不透明物体之后再渲染否则半透明叠半透明会乱序ZWrite Off是必须的不然透明的面板会把深度写进去后面的面板还是透不出来Blend SrcAlpha OneMinusSrcAlpha是标准的alpha混合模式不管是PC还是移动平台这套基础写法都不会出大问题。2.3 点击检测与透明度联动逻辑点击面板后要让“这一块面板”变成半透明同时“被它挡住的并列面板”恢复成不透明。实现原理不复杂先用Physics.Raycast射出射线拿到命中的朝代面板再根据该面板的时间区间遍历场景中所有朝代面板当前点击的面板以及时间栈更晚的面板全部把_Transparency设置为0.15不在此区间内或位于其视觉下层的面板恢复为1再次点击空白区域所有面板恢复为不透明。C#核心代码大概长这样public void OnDynastyClicked(DynastyPanel target) { foreach (var panel in allPanels) { if (panel target || panel.WindowIsLaterThan(target)) { panel.SetTransparency(0.15f); } else { panel.SetTransparency(1f); } } }WindowIsLaterThan这个判断我最初用的是“面板起始年份是否大于被点击面板的起始年份”这个简单规则。实际做的时候发现辽和北宋这种起止几乎一致的政权用单纯大小判断会误伤。后来加了容错当两个面板时间线重合度超过80%视为同一个视窗层的并列面板一起置为半透明。2.4 移动端性能与美术资源优化半透明材质在移动端的最大问题是Overdraw。我一开始PC上跑得很流畅打包到安卓平板上就有点卡排查后发现是叠了太多半透明面板GPU要一遍一遍做颜色混合带宽消耗很大。优化方案很朴素场景里的朝代面板数量严格控制在30个以内事件文字和图标不单独开Mesh全部合到面板贴图里。单个面板用512x512的贴图动态文字用TextMeshPro叠加在面板上方。实测下来在普通安卓平板上也能稳定跑满60帧。如果面板数量必须要多建议把静态面板合并进同一个Mesh减少DrawCall否则透明的Panel会被当成多个动态物体渲染开销成倍上涨。3. 完整实操流程从数据到界面到小游戏3.1 朝代数据组织JSON/ScriptableObject怎么选历史数据这部分一开始我和很多Unity开发者一样习惯用ScriptableObject编辑器里拖拽配置确实方便但它不利于数据版本管理。后来把数据交给历史顾问统一管理时对方不可能打开Unity编辑器所以我把数据抽成了独立JSON整个时间轴组件启动时读取一次。JSON结构大概长这样[ { id: tang, name: 唐朝, start: 618, end: 907, capital: 长安, color: #C0392B, type: main, events: [贞观之治, 安史之乱] }, { id: northern_song, name: 北宋, start: 960, end: 1127, capital: 开封, color: #2980B9, type: main, events: [澶渊之盟, 王安石变法] }, { id: liao, name: 辽, start: 916, end: 1125, capital: 上京, color: #27AE60, type: parallel, events: [澶渊之盟] } ]type字段非常关键它决定这块面板在场景中是放主轴还是并列轴。有了这个字段布局算法就知道北宋和辽应该出现在同一时间窗口的不同深度层而不是硬塞在同一行。颜色字段也要在JSON里定义不同朝代用不同色系视觉上会清晰很多。3.2 3D时间轴布局解决年代表重叠问题的坐标系设计这是Nano Banana Pro里最花时间的地方。时间轴我用X轴表示年份Z轴表示朝代面板的深度Y轴用来做高低错落展示。主轴朝代放在Z0层并列政权放在Z-2或者Z2层并在X轴上错开一点偏移避免完全重合看不出前后关系。刚开始我想把所有朝代放在一条直线上结果五代十国数据一进去直接乱成一锅粥。后来改成“主线朝代居中并列政权前后错落”的布局所有主线朝代面板的X坐标由年份区间换算Z固定为0并列政权面板在各自时间区间里相对主线面板向内收缩一定比例Z轴往正方向移两米。这样从俯视角看能直观看出谁和谁重叠从主视角看上层就是主要朝代下层就是同时期并立的政权。换算公式很直白把数据年份映射到世界坐标面板起始X (朝代起始年份 - 最早年份) * 单位年份宽度面板长度 (朝代结束年份 - 朝代起始年份) * 单位年份宽度单位年份宽度我取了0.02相当于一年对应2厘米。中国历史朝代表从夏代到清代大约四千年最长画出去80米启动时相机放在全局视角配合ScrollRect或者鼠标滚轮缩放就能很顺滑地从全景拉近到任意朝代。3.3 视频流接入用VideoPlayer做历史背景叙事知识展示类应用最怕生硬所以我给每个主要朝代配了一段几十秒的短视频放在详情页里当叙事入口。Unity处理视频流的方案很多我建议用VideoPlayer组件加RawImage而不是直接把视频绑到Mesh材质上。后者虽然也能用但后期要控制暂停、进度条、多语言字幕时会很麻烦。接入时有一个关键参数VideoSource。本地视频用URL模式指向StreamingAssets目录下的文件远程视频直接指向HTTP地址。实际项目里所有朝代视频我统一放在服务器上客户端按需加载安装包不用做到几个G。用代码控制播放的框架大概是videoPlayer.url dynasty.videoUrl; videoPlayer.Prepare(); videoPlayer.prepareCompleted _ { rawImage.texture videoPlayer.texture; videoPlayer.Play(); };需要注意如果视频比较大Prepare阶段会有几秒等待界面上必须加loading动画不然用户会以为程序卡死了。还有一点RawImage所在的Canvas渲染模式用Screen Space - Overlay最稳这样视频流刷新和UI点击事件不会打架。3.4 游戏化模块朝代排序小游戏的实现要点为了不让应用变成“只读的展览”我还加了一个很轻的小游戏朝代排序。玩法很简单每次从所有朝代里随机抽5个打乱顺序显示在界面底部玩家需要按时间先后把它们拖拽到上方时间轴的正确位置。这个模块的实现重点有三个拖拽用Unity的EventTrigger或IBeginDragHandler/IEndDragHandler做把朝代卡片拖到时间轴上的目标槽位。判定比较卡片朝代起始年份和目标槽位序号对应的正确年份区间误差在5年之内算正确。反馈正确时卡片变绿并吸附错误时卡片弹回原位置并加抖动动画。这个小游戏代码量其实不大但对用户留存和知识记忆帮助很明显。做并列政权知识点时我还复用了透视材质——答错后把并列政权的时间板块显示出来让玩家直观看到正确的时间关系而不是只给一个“答案错误”的冷冰冰提示。4. 常见报错、翻车现场与排查技巧4.1 中文乱码、粗体失效与TextMeshPro字体配置历史项目跑不掉中文。中文字体和西文字体不一样字体文件动辄几MB而且很容易踩坑。我第一次直接用Unity默认的Dynamic Font编辑器里看着一切正常打包到安卓平板上标题全变成方块。后来查了日志发现是设备系统字库覆盖不全Unity的动态字体在部分设备上会回退成系统字体。解决办法是全部改用TextMeshPro并把中文字体烘焙到TMP Font Asset里。烘焙的时候文字集不要偷懒只导常用字朝代名、人名、地名、事件名里生僻字很多最好把全文数据先跑一遍收集所有用到的字符再丢进字符集编辑器。按这个流程做之后中文显示问题就再没出现过。4.2 SolidWorks等外部3D模型导入Unity3D的坑当时有一个扩展计划把某些朝代的代表性文物做成3D模型放进详情页。设计那边从SolidWorks导出了模型给我结果我导入Unity以后模型要么巨大无比要么方向是歪的。这类问题其实不是Unity的错是源软件的坐标单位和轴向跟Unity不一样。SolidWorks默认单位是毫米Unity是米所以导入FBX时Scale Factor要设置成0.001否则一个几十厘米的模型会变成几十米。另外SolidWorks的坐标轴方向和Unity不完全一致导入后通常需要绕着X轴旋转90度。如果设计端能统一导出成FBX而不是OBJ材质信息保留得更多省去很多调整时间。想省事的开发者可以直接在Project窗口里把模型的Scale Factor、Rotation都预设好做成模板后面再导入类似文件就不用反复改了。4.3 半透明Shader在真机上的排序问题这个坑我印象最深。在编辑器里半透明面板的穿透效果运作得完全正常打包到安卓平板上某些面板突然“闪掉”了或者前后遮挡关系直接乱套。原因是移动端半透明物体渲染顺序和编辑器不完全一致尤其是我在场景里既用了多个相机透明排序又叠加了Canvas UI情况会变得更复杂。排查方式很直接把所有用到透明Shader的物体挂到同一个自定义排序层通过Renderer.SortingOrder手动指定层级。同时把相机的Transparency Sort Mode设为Custom Axis让半透明物体的排序更可控。设置完之后真机上的渲染顺序就和编辑器一致了。4.4 包体膨胀与加载耗时数据、视频、贴图的优化策略Nano Banana Pro做到后期包体一度膨胀到接近1GB主要就是视频素材和文物模型。后来我做了三层优化视频全部走远程加载不打包进安装包。朝代配图尽量用512x512以下统一压成ASTC格式安卓端内存占用下降约30%。程序化生成朝代面板面板本身是一个白色Prefab颜色和文字全部运行时赋值不额外存图片资源。这套优化做完最终安装包控制在120MB左右冷启动时间从6秒降到2秒以内。对一个以信息和交互为主的应用来说这个体量是能接受的。后续如果再接入更多文物模型建议也全部走AssetBundle远程分包不用急着塞进首包。我在这个项目里体会最深的一件事是技术方案永远要跟着内容结构走。当初如果坚持把所有朝代排成一列后续就不会出现穿透透视这个核心交互如果数据不抽成JSON历史顾问改一个年份就要动一次代码。很多功能看似是临时加的其实是被数据形态逼出来的。最后再留一个小建议如果你想复刻这个项目不要一上来就拆Shader和写排序算法先把朝代数据按“主线/并列”分好类再搭一个最简单的长条面板看看效果。数据模型对了后面所有酷炫功能都会顺理成章地长出来。

用Unity3D打造可交互三维中国历史朝代表：透视穿透与Shader实践

相关推荐

企业级AI Agent落地实战：从单体到多Agent协作与生产加固

基于YOLOv5的非机动车违规停放检测全流程

CBCT投影重建实战：从FDK到深度学习，破解放疗图像质量难题

更多资讯

从Apache SeaTunnel到ASF Member：开源长期主义的实践之路