Hi I found this forum through searching, and thought that my tool maybe useful here (大家好，我是通过搜索找到这个论坛的，觉得我开发的工具可能对大家有用):
Backup link with video demos (包含视频演示的备用链接): f95zone.to
The tool can handle legacy moc format beside modern moc3 format, while it also create can3 animation file from json (该工具既支持传统的 moc 格式，也支持现代的 moc3 格式，同时还能根据 JSON 文件生成 can3 动画文件).
The project have to use codeword for reasons (出于某种原因，该项目必须使用代号).
I don’t speak Chinese, so sorry about that 
(我不会说中文，所以很抱歉)
7 个赞
So,I just write chinese/zh-cn?
那么对于论坛里的二次创作艺术者来讲,这个应用被编译成是cli还是gui形式?在使用之前安装什么环境运行时?(比如c#的.net环境运行时之类的?)
This is CLI only program since I want to iron out bugs first before considering any UI. There’s no C# runtime involved since it uses https://rust-lang.org/ which compiles to native program.
这是一个纯命令行（CLI）程序，因为我想在考虑开发用户界面（UI）之前先解决各种 Bug。该程序不依赖 C# 运行时，而是使用 https://rust-lang.org/ 编写并编译为原生程序。
？！强强！？
之前有个转换器还是拿一个样板com3往里面填数据，这个直接把整个XML序列化都写出来了（
rust也是好文明（
经过测试似乎目前版本输出的工程文件图层顺序还包含问题，根据之前我的一些经验这个顺序与moc3文件中的树的读取顺序有关，应当以深度优先的方式读取moc3中的树并基于此顺序写回cmo3工程文件
测试文件: arch-chan/Live2D/Arch Chan Model0.moc3 at main · Speykious/arch-chan
After testing, it seems that the current version still has issues with the layer order in the exported project files. Based on some of my previous experience, this order is related to the order in which the tree in the moc3 file is read. It should read the tree in the moc3 in a depth-first manner and write back to the cmo3 project file based on this order.
Test file: arch-chan/Live2D/Arch Chan Model0.moc3 at main · Speykious/arch-chan
以及在部分大型模型上似乎其输出的文件存在bug会导致live2d编辑器显存溢出
Also, it seems that on some large models, its output files have bugs that can cause the Live2D editor to run out of memory(VRAM).
Fixed for latest patch now regarding ordering issues (it was missing moc3 field).
Also for VRAM issues, I don’t think it is a bug since cmo3 probably not designed to be very efficient unless original cmo3 does not cause such issues.
针对最新补丁修复了排序相关的问题（此前缺少了 moc3 字段）。
至于 VRAM（显存）问题，我认为这并非 Bug，因为 cmo3 格式本身的设计可能并不具备极高的效率——除非原始 cmo3 文件并未引发此类问题。
I have wiped commit for reasons, sorry about that, but new update should contains various fixes.
出于某些原因，我撤销了之前的提交（对此深表歉意），不过新的更新应该包含多项修复。
Include new PSD recovery:
1 个赞
我使用了另一个公开的转换网站来测试，那个网站输出的文件不会导致显存溢出，我正在尝试调查问题
网站: moc3-toolbox.com
I used another public conversion website for testing, and the file output from that site doesn’t cause VRAM overflow. I’m trying to investigate the issue.
Website: moc3-toolbox.com
目前我使用的测试模型:
Open-LLM-VTuber-For-Kasane-Teto/live2d-models/重音テト/重音テト.moc3 at main · HuanfuLi/Open-LLM-VTuber-For-Kasane-Teto
The test model I’m currently using:
Open-LLM-VTuber-For-Kasane-Teto/live2d-models/重音テト/重音テト.moc3 at main · HuanfuLi/Open-LLM-VTuber-For-Kasane-Teto
顺带一提我使用amd rx7900xtx 24g 其直接占满了我全部24g的显存
By the way, I’m using an AMD RX 7900 XTX 24GB, and it completely fills up all 24GB of my VRAM.
似乎这个问题是由于写入纹理的方式不一样导致的经过我的测试在xml中以TextureAtlas方式写入贴图就不会导致显存溢出
It seems this issue is caused by the different way textures are written. From my tests, writing textures in XML using the TextureAtlas method doesn’t cause the VRAM overflow.
Some more bugs fixed regarding VRAM issues now that I have concrete information, thanks.
Yes it was how the tool emit duplicate texture. Didn’t noticed it since I usually start Cubism in sandbox for testing which have limited VRAM and does not cause general problem on my machine. Plus most of my models I got a hand on are in range of <7MB.
既然现在掌握了确切信息，我又修复了一些与 VRAM 相关的问题，谢谢。
确实是该工具输出了重复纹理的问题。我之前没发现，是因为我通常在沙盒（sandbox）环境中测试 Cubism，那里的 VRAM 资源有限，且在我的机器上并未引发常规问题；再加上我手头的大多数模型都在 10MB 以内。
1 个赞
我又测试了几个极端情况的live2d模型发现编辑器还有一些报错
I tested a few more extreme live2d models and found that the editor still has some errors.
下面的模型转换后会导致编辑器 抛出以下错误
After converting the following model, the editor will throw the following error:
[ERROR] Class not found: CLabelColor
[ERROR] Serializer not found: CLabelColor
[ERROR] error >> ACParameterControllableSource.labelColor [CLabelColor] /
模型文件:
链接: 百度网盘 请输入提取码 提取码: KMLT
model file:
url: 百度网盘 请输入提取码 password: KMLT
(It’s worth mentioning that this is a crackme.)
I don’t have baidu so you may try to upload to https://gofile.io/
我没有百度账号，所以你可以试着上传到 https://gofile.io/
Also that error can be temporary bypassed by set color flag to basic none.
此外，将颜色标志（color flag）设置为“none”，可以暂时绕过该错误。
其中第二个模型包含巨量的顶点，工具仍能正确处理，但是第一个模型处理后会导致CLabelColor错误
The second(第二题) model has a huge number of vertices, and the tool can still handle it correctly, but processing the first model causes CLabelColor errors.
我试一下那个网页版转cmo3的后,才发现cubism这公司在免费许可证上整点麻烦,比如限制cmo3项目参数量,纹理分辨率限制甚至不认已经导出moc3工程后的png纹理导入项目.额外一件事,许多网页播放的live2d动画是用webp代替png纹理的(不知道这些事如何影响了工具开发)
Found the bug: flag probably can’t fix the error either, since it’s missing `<?import` tag. Maybe I missed some version check. Claude is fixing it rn.
找到问题所在了：光靠 flag 恐怕也修不了这个错误，因为它缺少了 <?import 标签。也许是我漏掉了什么版本检查。Claude 正在修复这个问题。
Also where did you guys find these models lmao. CTF (capture the flag) challenge?
话说你们到底是从哪儿找来的这些模特啊，笑死。
This is an interesting challenge shared by a previous Bilibili user.
Pushed latest change just now.
刚才已经推送了最新更改
Also for non-png format, I’ll probably add alternative format later but that’s probably an optional feature since we can easily convert webp to png anyways.
至于非 PNG 格式，我可能会在后续加入对其他格式的支持，但这大概属于可选功能，毕竟我们很容易就能把 WebP 转换为 PNG。
New patch had been uploaded which add --dupe to revert back to original keyform retain mode, otherwise current behavior is now keyform reduction which should help reducing random editor crash during first model initialization and overall final cmo3 file size.
已上传新补丁，新增了 --dupe 选项，用于恢复到原始的 Keyform 保留模式；默认行为现已改为 keyform 精简模式，这有助于减少模型首次初始化期间编辑器随机崩溃的情况，并减小最终生成的 cmo3 文件大小。
