前言
2023-2025 时间过得真快啊，两年前因为一段工作经历接触到了three.js 使自己产生了写一个开源项目的想法，再到今天项目有 1K+ 的 star，除了感慨时间过得太快了，同时也有很多自己内心的感受给大家分享一下。
记得当时每一次代码提交后都会心里对自己说："已经很完美了"，"这是最后一次提交代码了"，"算了不想改了就这样吧" 这样的话。现在回顾这段历程对我来说真的很奇妙啊。
项目地址：
gitee:gitee.com/ZHANG_6666/...
github:github.com/zhangbo126/...
当时为什么会有写这样一个项目的想法？
工作原因 ：2023年这段时间我以人力外包 的身份，在中国移动成都产业研究院 工作了大概10-11个月左右的时间。以人力外包的身份开启新一段工作对于大多数人而言是非常不幸的，但对我来说却是非常幸运的，因为这里（成研院）相较于大部分传统的互联网公司无论是工作氛围还是工作强度都是非常轻松的，没有加班，没有996，没有职场PUA。在这样的氛围情况下我无论是工作效率还学习积极性都是处于最佳的状态，当然最主要的还是当时我所在的项目组接触到的一个项目->数据可视化大屏 项目需要编辑和展示three.js的3d模型，于是便开始接触起three.js了。
因为是外包只要自己按时完成工作任务，其余时间无论你干什么都没有人刻意去管你，再加上成研院 的工作量确实很少又或者说这里开发时间很充裕，于是我有了大量的摸鱼时间去构思自己的开源项目。
个人原因：
在接触到three.js后才发现原来前端不止可以实现一些传统枯燥的增删改查相关的后台管理系统，又或者是千篇一律的门户网站和小程序以及 App 这些。
相较于传统前端业务three.js能够实现的功能和视觉效果简直是太炫酷了，同时也激起了我的学习激情。
当时的 github 上并没有太多关于three.js模型编辑相关的开源项目，当时我在想如果自己能够写出一个这样的项目，然后写在自己的简历上肯定是个加分项
万事开头难，不知道怎么写那就先去"抄"吧！
在很多时候日常的工作开发中我总是会吐槽UI 的设计页面难看或者不好实现，产品 的原型需求内容不明确。但是当自己想要不通过UI 的设计图或者产品的原型去实现一个功能时，真的有点无从下手的感觉。
为了迈出这关键的第一步，当时主要是参照了 老子云 和 51建模 这两个网站3D编辑器的功能页面去实现的
老子云 3D 编辑器页面：
51 建模 3D 编辑器页面：
在有了这两个网站的界面和功能作为参考后，我也开始了项目第一版的页面搭建和设计
Three.js官方文档对于初学者来说并不是特别友好
在使用一个技术栈框架时，想要查阅文档 API 最好的方式就是去官方文档吧
但相信大多数人在刚刚开始接触到 Three.js 官方文档时或多或少都会有点不知所措吧，因为大部分的 API文档都只是简单的描述了一下这个 API 所实现的功能和一些参数内容说明，并没有提供一个完整的 demo 代码示例，这也就导致了官方文档中很多的 API 我们都不知道该如何去使用，更不知道这些 API 可以实现什么样的功能
印象最深刻的便是当时为了实现一个模型辉光的功能，把百度上能搜索到的内容都搜了一遍，才勉强找到类似的案例代码，这个过程也是非常的耗时耗力。
幸好的就是当时的 AI chatgpt 开始逐渐流行通过 AI 的辅助对于three.js一些 API 的功能使用和理解也变得更加容易简单了
第一版的界面
这个界面也是当时项目开源后的第一版界面，一共有五个模：背景，材质，动画，灯光，辅助线的编辑功能 ，以及模型的动态切换和加载外部模型等功能
这些功能也是代表着当时那个阶段我所学到的three.js相关 API 的所有内容
边学边做吧！边做边学吧！
为了实现某一个功能而去学习three.js API 的使用，这便是我在做开源项目时期的一个总体节奏吧
因为我觉得快速掌握一门语言或技术栈最好的方式就是通过写一个实际的项目去实践
同时这里也给大家简单的分享一下我个人如何快速高效率的去学习Three.js的方法吧
ps:为什么是chatgpt 了？因为 chatgpt 有一个专门的 Three.js对话窗口
就比如我想要了解 Three.js 的灯光 API 具体该如何使用，以及如何动态修改 Three.js 灯光相关的参数时
我会先通过官网文档找到灯光相关的 API 文档，然后大概了解一下这个 API 可以实现的效果，以及一些 API 的参数值内容
如果我想实现动态修改 平行光（DirectionalLight）的参数值，我会这样去描述
这里 AI 就会帮你生成一个完整的动态修改灯光参数值demo 代码，当然这里并不是让你完全去依赖 AI帮你去实现一个功能，而是借用 AI 的帮助让你快速了解到 DirectionalLight 具体是如何使用的，并且相对于官方文档提供的代码示例，AI 能够根据你的需求描述提供更加准确的代码示例
官方文档的代码示例
chatgpt根据你的需求描述提供的代码示例
通过 AI 提供的代码示例，你就可以快速知道 DirectionalLight 的 color ,position 等参数值是通过 .set() 的方式去修改,而 intensity是通过直接赋值的方式去修改
而且还能帮你扩展了解到及灯光还有一个衍生的辅助线工具 DirectionalLightHelper
又比如说你想要实现一个下雨效果但是又没有一个好的实现思路时，这时候你任然可以通过 AI 帮你提供一段代码思路
通过 AI 的帮助你就可以快速的知道原来这种雨滴效果是通过 Three.js 的点材质（PointsMaterial）去实现的
同时你也就可以反向去学习了解到 THREE.BufferAttribute ,THREE.PointsMaterial ,THREE.Points 等 API 的使用场景
通过AI提供的示例代码和代码解释之后，你在去反向查看 THREE.Points 等 API的官方文档说明，你会发现官方文档的简单描述，其实也变得并不是很难理解了
注⚠️：以上是作者个人认为比较高效率的Three.js 学习方式，如果大家有更好的学习方法，也欢迎留言交流🤝
别人有的我要有，别人没有的我更要有
第一版功能做完之后，自己对比了一下老子云 和 51建模 这两个网站，总感觉自己做的东西啥也不是。
功能太少？不够花里胡哨？ 是的，至少当时我是这种想法
于是我便开始了第二次大规模的功能开发
老子云网站有模型辉光功能，ok 那我也做一个
51 建模有模型拆解功能，ok 那我的项目也必须有
成研院 的3d模型编辑内容可以展示在可视化大屏上，ok 我也搞一个类似的模型库功能
于是在这样的节奏下我完成了项目的第二版功能开发
在改BUG和优化的路上越走越远
任何程序员任何时候都不能保证自己写的代码没有bug,当然我也不例外。
无论是我自己在写项目过程中发现的 bug 还是 git上 issues 反馈的bug, 对我来说都是受益匪浅的当我把这些bug都解决了之后，以后的three.js 开发之路就会变得更加轻松了
当然有些 Bug 和 性能相关的问题处理起来还是非常头疼的，记得当时还专门写了一篇文章去总结了一下
主打一个听劝
在项目发布到git上面之后，star 数量也开始逐渐增多了，这对我来说是当然是非常开心的，因为这是自己成果被认可的体现吧
当然随之而来的也会有很多issues需求内容
其实在提交完第二版功能的的代码之后，我内心的想法就是，这应该是最后一次提交代码了毕竟我已经把我能想到的功能和能抄的功能都弄出来了。
但是在看到一些issues上的需求内容有多个人在提问时，其实内心是有点抗拒的，毕竟每个程序员都想逃离"无良甲方"和"产品经理"的摧残。
但最终还是说服自己，一个好的项目一定要适配大部分用户的需求
于是当有人提出,这样的需求时
我：ok 满足你，把原来的单模型 编辑模式改成了可以多模型编辑的模式, 于是编辑器就支持了多模型的编辑了
又或者说这样的需求
我：好的，收到
于是我又在辉光功能里加了一个颜色选择器的功能
版本迭代+技术栈升级+代码重构
1.three.js版本的持续升级：
记得最开始搭建项目时 three.js 的最新版本是 153 版本的，在到如今的 180 版本,three.js 官方版本的迭代应该算是比较频繁的了，基本上是每个月都会升级一次版本
为了保持开源项目的three.js 版本不落后于官方的版本，也会尽量将项目的版本更新频率保持和官方同步
但是很多时候项目的three.js版本升级就会导致很多原有的功能出现问题
记得当时印象最深刻的问题就是，three.js 升级到 168 版本后，通道渲染器（OutlinePass ）不支持 Vue3 的响应数据的问题。
这个问题处理起来其实是很简单的 使用 Vue3 的 toRaw 将响应式转化为普通数据就可以了，但是排查出问题的过程确实十分煎熬的
当时的代码提交记录：
Three.js版本升级记录
2.项目代码的重构 Vuex 👉 Pinia
个人记得22年 到23年 那会儿的前端技术栈是处于 Vue2 👉 Vue3 新老交替的一个阶段，很多公司的项目新项目已经确认开始使用 Vue3 作为主要框架去使用了
项目最开始使用的是 Vue3+Vuex 去搭配的，但随着 Pinia 作为更加轻量和更加灵活更符合Vue3特性时，也开始了将 Vuex 👉 Pinia 的重构过程
同时也在这期间升级了一下 Vue 的版本 3.2.13=>3.5.13 以支持更多的Vue3 新特性
3.项目构建工具升级Webpack 👉 Vite
项目最开始使用的构建工具是 Vue3 默认的 Webpack
但随着 Vite 的逐渐流行，以及我自己也在工作项目中使用过 Vite 后，也开始认可了这个被称之为下一代的前端工具立链的构建工具
于是也开始了将项目构建工具升级为 Vite 的过程，记得当时改动最多代码的便是图片资源的引用方式吧
Webpack: require("@/assets/previewIcon/2.png")
Vite : new URL(../assets/previewIcon/2.png, import.meta.url).href
这应该是我最后一次大规模改动项目了
在工作中，我们大部分人几乎都经历过多人协作开发项目的情况
当每个人的代码格式化插件 和配置都不一样时，有时候就会出现两个人前后开发了同一个文件的代码后，导致文件内容差异过大，如果这个时候出现代码冲突后，git 的冲突解决则将会变得非常困难。
同时我也觉得任何一个前端项目统一下项目规范也是非常必要的
于是我也决定在开源项目中添加 Eslint+Stylelint+Prettier+Husky 这套规范了
ok，这样我们的项目代码格式也符合主流技术的规范了，并且不符合规范的代码也不会被提交至 git
感谢你们提的每一个 issues, 才有了现在的最终版
其实在 23 年底把当时第二版代码提交后， 我已经不打算对项目做任何功能的迭代更新了，因为我觉得目前个人的能力上限也就仅此了
但是最终也是因为这些issues，推动了我继续去迭代更新功能
无论是 bug 还是需求，每当关闭一个 issues 时，项目整体的功能或多或少都会有改动，也正是因为大家提的建议才有了后来的这些新的功能
时间会告诉你答案（2023.6-至今）
从最开始产生要写一个开源项目的想法到今天已经过去两年 左右的时间了，这个过程有项目从 0-1 开始时的煎熬，也有为了死磕一个功能熬到深夜很晚，也有因为项目star 数量从 0-100 时的兴奋和喜悦，更有实现了一个自己认为很难的功能后的成就感
现在回顾一下这段历程，很庆幸能够一直坚持，这对于我来说是受益匪浅的。
因为在这个过程中我完成了 three.js 从 入门 到深入了解 的蜕变，也让自己相对于传统的前端开发有了一个更有代表性的技术栈，也因为这个开源项目 使自己在当前竞争恶劣的大环境下还能有更多工作的选择性，同时也一定程度上影响了自己未来职业发展方向的选择
同时也很开心自己的项目被用于很多公司项目二次开发中去
4. 
7. http://111.231.134.212:8081/
为什么会坚持做开源？
其实目前这个问题，我很难给出一个唯一准确的答案
我相信这个世界上肯定真的会有人会坚持一直用爱发电，但这个人一定不是我
我想任何开源项目 的产生，都会有作者自己独有 的目的比如：
是为了打造个人IP ？
是为了获取流量？
是为了延长自己的程序员职业生涯？
是为了增加自己简历的优势？
是为了体现自己的技术水平？
又或者为了宣传自己 ？
还是说为了学习新技术栈？
这些目的 我想自己或多或少 都会有一点点吧，因为和大部分人一样作为这个社会的底层人 ，我还无法达到用爱发电的伟大境界，带有目的性的去做一件事情，才会让自己产生对未来的一点点期望，才能有更大的动力去做成功一件事吧。
结语
两年时间真的过得很快，在开发和维护这个开源项目的期间，我不仅见证的前端技术栈新老交替 的过程，也见证了 AI 的野蛮生长，以及 AI 对于互联网行业的冲击，也体验了AI（cursor）对我日常工作方式的改变。
和大部分年轻人一样我也偶尔会吐槽一下没有赶上计算机时代红利 去多挣取到更多的资本 。但是即便回到过去，以当时的眼光 和认知我们又能做出正确的选择吗？
或许我们也正处于上一个时代红利结束 下一个时代红开始 的时期，只是因为我们的眼光和认知还停留在上一个时代，也许这时候我也开始明白终身学习的意义了
不进则退，最终被淹没淘汰在时代发展的潮流中...