现在很多 OCR 模型实际上已经支持了一定程度内的旋转文本的识别，即图片中的非水平方向的文本可以正确识别其方向并按照正常的水平顺序返回该文本；但这仅限于每一个 Bounding Box 内的文本，因为 OCR 模型一般原始输出都是从图片中获取一个个单独的文本区域——即 Bounding Box，然后识别该区域的文本，并不会对这些 Bounding Box 进行拼接得到按正确顺序返回的完整文本，如：
从图中右侧不难发现哪怕图片中的文本有一些旋转，OCR 模型也可以识别出这些文本块的方向，并返回正确的文本顺序；但是如果要以正确的顺序（从左至右，从上至下）返回所有的文本行，就需要自己去处理了。
一般来说，我们可以假设图片中的文本旋转方向都是一样的（适用于常见的单页文本拍照或者扫描件），因此只需要得到一个整体的旋转方向，然后基于这个方向进行一个逆运算即可得到正常水平方向的 Bounding Box 位置，也就能拼接得到视觉层面上正常顺序的完整文本了。
bge-m3 是由 BAAI 在 2024 年推出的一个比较经典的 Embedding 模型，是一个支持多语言的 Embedding 模型，除此之外，它还支持输出稀疏向量和 ColBERT 向量，因此用途比较广泛。按照目前 AI 模型的发展速度（竞争很激烈），这个推出了一年多的模型理应算是个老古董了，实际上到目前为止（2025-9-20），该模型还能在 MTEB Leaderboard 榜单上保持在第 23 位的位置，且在 hugging face 上的月下载量保持在五六百万之多：
不过话又说回来，这大概率是因为 Embedding 模型还没有隔壁 LLM 那么卷，2025 截至目前也就阿里推出的 Qwen3-Embedding 模型很有竞争力；
其实本来只打算写一下我是如何通过自定义材质来实现特定场景下突破 UBO 数量限制的，但是写着写着发现很有必要捋清楚 Babylonjs 内部着色器预编译的机制，不然连我自己都不清楚我为啥要这么做🙈。
虽然我之前确实对 Babylonjs 的源码做过一些分析记录，但总体比较零散，完全无法在脑海中形成一个系统性的、清晰的流程。所以这次我就把 Babylonjs 的仓库 clone 到本地，使用 Cursor 将其作为本地知识库进行详细的源码分析，得到了多份分析报告文档，基于这些文档我才对 Babylonjs 内部一些机制有了更详细和全面的了解。
而这些报告文档我都放到了 Github 上，感兴趣的可以去看一看，我觉得从里面确实可以学到不少关于 Babylonjs 源码的思路。
我前不久独自开发了一个 在线3D展览 的项目，该项目的主要需求就是渲染展厅模型及展厅中的大量展品，也包含大量用来给展品打光的聚光灯。
MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 在 2024 年底推出的一种开放协议，旨在通过标准化接口实现大语言模型（LLM）与外部数据源及工具的无缝集成。其核心采用客户端 - 服务器架构，客户端（如 AI 驱动的 IDE、聊天机器人）可通过协议发现并调用本地或远程的 MCP 服务器（如文件系统工具、GitHub 接口等），LLM 在推理过程中自主判断是否需要调用工具，再由服务器执行具体操作并将结果返回给模型，形成动态交互的工作流。该协议通过统一标准化的工具调用方式，解决了传统 AI 应用开发中碎片化 Agent 集成的问题，类似 USB-C 接口统一设备连接。[1]
简单地来说，MCP 赋予了 LLMs 进行标准化调用工具及获取数据的能力，由于是标准化协议，所有基于 MCP 实现的工具（Server）都可以被 MCP 客户端（如 Cursor、windsurf 这类 IDE）进行调用，其作用很类似当年微软提出的 LSP（该协议使得同一个编程语言 Server 能够在实现了 LSP 协议的客户端进行调用，大大地提高了 IDE 之间的编程语言插件复用效率）。同样地，由于 MCP 的存在，目前扩展 LLMs 能力的开发流程变得统一起来，因此尽管该协议目前（2025-03）才刚提出几个月，社区就已经实现了大量的基于 MCP 的工具，且该协议目前由 Anthropic 主推（这家公司的模型大家应该都不陌生吧，旗下的 Claude 就是目前编程模型界的 Top1），并得到了 Cursor、windsurf 和 Cline 等主流 AI IDE 和插件的支持，因此我很看好 MCP 的前景和发展潜力。
