添加物理模拟/阴影支持

[MetsukiMio]

我是从b站的视频找到这个仓库的
之前我也做过minecraft mmd渲染器，但是我最初的实现方法是使用jni调用saba，然后向minecraft在实体渲染时提供的缓冲区直接写入，完成了对光影阴影效果和物理模拟（saba库自身提供）的支持（详细实现参考https://github.com/Jack253-png/Advanced-Framework, https://github.com/Jack253-png/saba-native）

仔细理解了您的实现，看起来是使用了compute shader计算了顶点数据，最后通过独立管线渲染，我不知道这里是否可以通过写入minecraft自己的实体渲染管线实现对光影阴影效果的兼容？
（具体实现效果可以看我的b站账号的第1，4，5个视频，希望能对您进一步优化mmd渲染器提供思路和实现）

[MetsukiMio]

第二个链接应该是
https://github.com/Jack253-png/saba-native

[fifth-light]

你好！我之前对你的 Advanced Framework 早有耳闻，也翻过你的代码。但是我的思路和你的框架采用的 saba 思路不太一样，我这次的思路是打算用纯 Kotlin/Java 手搓一个渲染框架。可以看到我主要还是以 glTF 为核心进行数据建模和表示的（最早支持的其实是 glTF 模型，MMD 模型支持是后面加进去的）。

我现在有三个渲染模式，其实最早我是在顶点着色器做蒙皮、形态键变换的，虽然效率高（不像 saba 一样在 CPU 做顶点运算，这次在 GPU 做），但是这样不兼容光影（因为用的是自己的 RenderPipeline），于是后来又引入了 CPU 顶点变换（但是效率比 saba 低多了）还有计算着色器变换模式，这两个模式正和你说的方式差不多，计算顶点数据并提交给 Minecraft 自己的实体渲染管线。虽然后面这两个渲染模式下我确实是单独开了个 RenderPass，但是我使用的是原版的 RenderPipelines.ENTITY_TRANSLUCENT，因此有着完全的光影兼容。在视频里你也可以看到，计算着色器变换模式就完全兼容光影了。

由于全部都是从头开始写的代码，除了目前还没提交的 IK 部分移植了 saba 的实现，模型加载、场景图都是我自己写出来的。因此物理支持我也得从头手搓，这次我打算用 ODE4J 试试，它是我唯一找到的目前还在持续维护的纯 Java 物理引擎了。

你说的光影阴影效果我应该是有的，不过在视频中由于世界时间和光影而不明显。我给一张我现在在 MakeUp 光影下的截图：

[MetsukiMio]

不过最主要的是模型自投影（模型本身对模型光线的影响）要怎么处理，我之前也没能很好的处理这个问题

[fifth-light]

我暂时理解你说的自投影是模型自身产生的阴影打在模型自己上面的现象。

MakeUp 阴影质量中

MakeUp 阴影质量高

如果你说的自投影是这样的话，其实光影用的 shadow map 技术不需要额外处理就能实现自投影效果。Saba 或者 MikuMikuDance 的阴影是采取把模型压扁的的变通方法来渲染的。

[fifth-light]

如果你想说的是模型法线，那么我也实现过正确的模型法线（而不是固定0, 1, 0），效果十分难看，就没这么做了：

[MetsukiMio]

如果你想说的是模型法线，那么我也实现过正确的模型法线（而不是固定0, 1, 0），效果十分难看，就没这么做了：

草，我之前尝试模型法线的时候也是这么难看（
想额外问一句，这窗口边框看起来像gnome（

[fifth-light]

想额外问一句，这窗口边框看起来像gnome（

你没猜错，就是 GNOME。我用的 Fedora SliverBlue

[MetsukiMio]

想额外问一句，这窗口边框看起来像gnome（

你没猜错，就是 GNOME。我用的 Fedora SliverBlue

不过用了compute shader就强制要求opengl 4.3了，macos支持会出问题（

[fifth-light]

不过用了compute shader就强制要求opengl 4.3了，macos支持会出问题（

如果冒险的话，可以尝试 Zink + MoltenVK 一类的（

我会自动检测是否支持 SSBO 和计算着色器，不支持的话就不会允许使用计算着色器模式。考虑到 CPU 变换模式太慢，mac 和一些手机（主要还是 MobileGlues，支持了计算着色器却不支持 SSBO？）上还是别开光影了，用顶点着色器做变换吧。

[MetsukiMio]

不过用了compute shader就强制要求opengl 4.3了，macos支持会出问题（

如果冒险的话，可以尝试 Zink + MoltenVK 一类的（

我会自动检测是否支持 SSBO 和计算着色器，不支持的话就不会允许使用计算着色器模式。考虑到 CPU 变换模式太慢，mac 和一些手机（主要还是 MobileGlues，支持了计算着色器却不支持 SSBO？）上还是别开光影了，用顶点着色器做变换吧。

还有一种奇技淫巧就是通过传统渲染管线变相实现compute shader，将数据伪装成顶点数据，通过独立的管线将变换好的顶点数据写进贴图里，然后再读取出来或者是直接扔给主管线处理（

[fifth-light]

其实我计划中还有一个渲染模式，就是对光影的顶点着色器打补丁，以添加蒙皮和形态键支持。如果这个模式实现，那么它就是最快的模式，并且兼容没有计算着色器的设备。但是考虑到这样做的兼容性成本（还得为不同光影做单独适配），保留其它的渲染模式也是必要的。

[MetsukiMio]

其实我计划中还有一个渲染模式，就是对光影的顶点着色器打补丁，以添加蒙皮和形态键支持。如果这个模式实现，那么它就是最快的模式，并且兼容没有计算着色器的设备。但是考虑到这样做的兼容性成本（还得为不同光影做单独适配），保留其它的渲染模式也是必要的。

不知道minecraft实体渲染是否允许两张贴图，如果可以的话就能把顶点数据用额外的管线写进第二张贴图里，主管线顶点只放index，渲染时从第二张贴图里拿数据当作顶点坐标，不支持的话也可以合并两张贴图，上面一半是纹理，下面一半是顶点数据（可能会比直接管线慢一点，但是不需要compute shader也能直接兼容光影）（

[fifth-light]

不知道minecraft实体渲染是否允许两张贴图，如果可以的话就能把顶点数据用额外的管线写进第二张贴图里，主管线顶点只放index，渲染时从第二张贴图里拿数据当作顶点坐标，不支持的话也可以合并两张贴图，上面一半是纹理，下面一半是顶点数据（可能会比直接管线慢一点，但是不需要compute shader也能直接兼容光影）（

你这要改顶点着色器。既然都要改顶点着色器了，不如一步到位直接在顶点着色器完成变换。

[fifth-light]

核心就在这个表里了

[MetsukiMio]

不知道minecraft实体渲染是否允许两张贴图，如果可以的话就能把顶点数据用额外的管线写进第二张贴图里，主管线顶点只放index，渲染时从第二张贴图里拿数据当作顶点坐标，不支持的话也可以合并两张贴图，上面一半是纹理，下面一半是顶点数据（可能会比直接管线慢一点，但是不需要compute shader也能直接兼容光影）（

你这要改顶点着色器。既然都要改顶点着色器了，不如一步到位直接在顶点着色器完成变换。

似乎这样改也没办法避免光影不兼容问题（（