介绍
奇葩的 spline&装饰器模式
# spline
spline 其实就是一个制作卡通风格（主要）的 3d 软件，优点就是操作体验和平面设计类近似（极为简单） 且根植于 three（所以转换到 web 不会出现渲染问题），个人认为它会在卡通风格干掉所有其他的方案，包括代码编写和 3d 软件
# 问题
在低代码方案中，做出来一个拖拽渲染效果是不难的，难的是行为的注册，比如我希望操作一个按钮从而更改另一个组件中的数据,spline 本身只支持动画的交互，通过交互使应用状态变化（即在生产环境里真的能用）是做不到的。
# 解决方案
# 基于 spline 的二次开发
这也是官方推荐的模式，也给了一个基于 react 的例子，本质上就是一个 three 的 scene，去获得对应的模型 or 监听事件即可（不用担心 react 的问题，写一个 vue 的 wrapper 可能 5 分钟都多了） emmm，如果是从零开始的话，这个方案会靠谱的多，因为本质上 spline 不是 three.js（1），它有一个独立的运行时，这同样意味着其不能在已有的 three 项目中存在
# 基于 three 的渐进式开发
确实可以将其转为 three.js 的一个 scene，官方是允许这种行为的，但由于没有运行时，会丢掉很多东西，比如一些着色器（如 outline 就会失效），所有的事件动效。这种情况姑且可以理解为，提供纯粹的模型和特定的着色器（价值比较低）。
我目前已经成功在之前的 folio 项目中实践了，卡通风格的 3d 渲染中会有一些小技巧（比如用深度来代替光线），我应用的前提就是 folio 本身是依赖 matcap 来实现光照，spline 的一些着色器和这个项目很契合，核心思路都是通过着色器去模拟高水平的光照，
只是一个特例
顺带一提，folio项目通过各种方法去减少渲染贴图的需求，从而减少对建模师的需求（2），节省成本（所以可以牺牲一点用第二种模式，第一种模式则是节省前端的成本），如果是往（2）这个思路上靠，建议在模型名上做点手脚
# three.nest
简而言之，把之前的思路实践了一下，把three写成nestjs风格，完全实现了ioc（aop。。这和服务端实现不大一样，感觉没啥用啊，顶多相当于一个hook），现在核心已经弄完了，添加模块就行了，感觉除了对treeshake不太友好以外其他应该还行，争取一两个月内迁移掉吧