Unity做可视化无可厚非，特别是3D渲染这块的，解决方案算是比较成熟的了。但如果你是那种各种表格数据的业务系统呢？

是不是觉得头大，表格数据这块根本不是Unity的强项，而且考虑到Unity可以用的UI库，各种局限。

网络上搜了一通，得出一个似乎可行的办法：

Winform开发（至少数据表格这块可以很轻松解决了），那么3D展示这块呢？使用DirectX，或者嵌入Unity3D的模块（当年的UnityWeb）。

用DirectX还能理解，但是用UnityWeb？一个已经停止维护的功能？还是旧版本。

于是取巧的方式，就是当需要渲染3D模块的时候又调用命令打开一个Unity开发好的EXE，然后获得窗口句柄控制窗口的显示和层级。

祭出当时用的解决方案：

https://github.com/U3DC/Unity-Winform-Solution

是不是很别扭？

肯定啊~

那还有更好的解决方案么？

必须有~

回过来说，我们必须根据当前人员的技能配备来考虑技术选型，不然项目很大可能陷入持久战，周期越长，越可能走偏。

比如，团队里前端主力是Unity，搭配C#/C++服务端，和几个美术(模型、UI)。

这完全就是游戏向配置啊~

那怎么走？

1.前端主要框架由Unity实现，这种偏业务的系统，比较重UI，选择一个UI框架会让这个事情更加流畅。

2.后端工作比较重头了，所有的数据都在后端这边跑，由前端（unity）发起请求，后端响应并反馈。

3.这是重点---> 前端实现时，把所有数据方面的图显示模块预留出来，这里，我们使用网页嵌入，选择一个合适webview插件，或者自己基于开源内核封装也可以。

4.注意：业务层的东西比如图标数据，在3D场景里本质就叫2D的UI页面。这样就很好理解了吧，有了webview，我们就可以让图表那些更加的灵活。前端也不需要为实现那些图表效果而掉光了头发。

5.前端数据依赖于后端，前端主要负责两方面：一是3D方面的显示与操作。二是业务数据的请求和响应显示。而服务端则要处理数据的计算，还有图表页面的处理。

总结：

我们当时在做这个3D可视化业务系统的时候，绕了大弯子。当然主要问题是局限于如何用Unity做出需要的各种表格数据还有图表（雷达图、柱状图、趋势图）等等。其实完全可以换一种思路，就是让这一块独立出来变成内嵌的模块。就像一开始说的那个方案：用winform内嵌unity3d的web模块。

当然，那个项目远不止涉及到这个图表的问题，还有接入海康、大华那些监控的实时流数据，并显示在Unity的项目里。这又涉及到RTMP协议的一些东西了。这些后续有时间再做分享吧。

有更好想法的朋友，也欢迎给我留言~

打赏

扫一扫，请博主喝杯咖啡～