The 'Script' folder contains several sample Python scripts, so please refer to them first to learn the basics of scripting.
And, the 'Help' menu in the script editor contains descriptions of classes, functions, and properties.

>The 'Script' folder contains several sample Python scripts, so please refer to them first to learn the basics of scripting.
>And, the 'Help' menu in the script editor contains descriptions of classes, functions, and properties.


But how i do it ? am not coder and its for me imbossibile to change 200-300 materials everytime i import from blender to meta and since i do aterials and i need to change all materials all at once selected object only! :S

>The 'Script' folder contains several sample Python scripts, so please refer to them first to learn the basics of scripting.
>And, the 'Help' menu in the script editor contains descriptions of classes, functions, and properties.

kinda hard tryed many methods but not working idk : S

>The 'Script' folder contains several sample Python scripts, so please refer to them first to learn the basics of scripting.
>And, the 'Help' menu in the script editor contains descriptions of classes, functions, and properties.


import random

doc = MQSystem.getDocument()
objnum = doc.numObject

for oi in range(0,objnum):
    obj = doc.object[oi]
    if obj is None: continue

    if obj.selected:
        mat = obj.material
        mat.ambient = 0.50


Error code

Through perseverance, I found how to do it. You have to use the 'Hole' tool

内製ライブラリの外部提供はしておりません。
pngやjpgファイルの読み書きがしたいのであれば、stb_imageなどを利用されてはいかがでしょうか？

目的の機能か分かりませんが、グラデーションにウェイトを設定するプラグインを作られてる方がいるのでこれでどうでしょうか

PacketbirD【Metasequoiaプラグイン】あーくちゃんボーンツール
https://booth.pm/ja/items/2768486

The .x file format is very old legacy, and Microsoft no longer supports it. Why do you need it now?

>>The .x file format is very old legacy, and Microsoft no longer supports it. Why do you need it now?


well considering you have a exporter for it, why not the importer so that anyone can reimport these files to do modifications on older models or new models created with it!

If you output to a non-mqo/mqoz file and then load it again, it will not be in the same state as the original. A reload workflow is not appropriate, and the original mqo/mqoz files should remain.

In any case, the x file format is too old and should no longer be handled in the modern era. However, if you must read x files, please use an external file converter. I don't know the details, but there are several free conversion online services.

>If you output to a non-mqo/mqoz file and then load it again, it will not be in the same state as the original. A reload workflow is not appropriate, and the original mqo/mqoz files should remain.
>
>In any case, the x file format is too old and should no longer be handled in the modern era. However, if you must read x files, please use an external file converter. I don't know the details, but there are several free conversion online services.



If that is true then what was the point of creating any other importer for metsaquioa?

>If that is true then what was the point of creating any other importer for metsaquioa?

I don't understand your question. What kind of answer do you expect?

>>If that is true then what was the point of creating any other importer for metsaquioa?
>
>I don't understand your question. What kind of answer do you expect?

the .x format maybe old but its still supported by some people in the industry.

>the .x format maybe old but its still supported by some people in the industry.

I don't know what industry you're in, but I believe it is risky in every respect to continue to use an industrial system that relies on old technology and does not support modern formats.
However, if you must do so, as already mentioned, an external converter can solve the problem right now. Have you considered that option?

こちらが、UniGLTFというVRMを扱うプラグインからGLBを出力する機能で出力したsparse accessorを有効にしたGLBと、未使用のGLBのサンプルデータです。
sparse accessorを有効にしたデータを読み込むとメタセコがクラッシュする場合があります。

（glTF-Validatorではどちらのデータも問題なしですが、khronos公式のglTFサンプルビューアーでエラーとWindows標準の3Dビューアーではクラッシュ）

UniGLTFという機能から、エクスポートを行ったところVRMとしてエクスポートされてるデータとはまた異なる壊れ方をしてるので、一旦これらのサンプルデータを元に検証を行ってもらえればと思います。

https://github.com/vrm-c/UniVRM/files/9934212/GLB_sparse.accessor_testzip.zip

VRM1_Constraint_Twist_Sample.glb
VRM1_Constraint_Twist_Sample_sparse accessor.glb（sparse accessor）

一応、出力元の環境の方でもissueを立てて検証を行ってます。
https://github.com/vrm-c/UniVRM/issues/1906#issuecomment-1302807143

参考画像：
sparse accessor無し
https://user-images.githubusercontent.com/26161297/199865017-515152d3-df3d-412f-aeda-f40ca733d121.png
sparse accessor有り（ブレンドシェイプが壊れる）
https://user-images.githubusercontent.com/26161297/199865315-0ce15992-4ee0-44e6-87ff-a6fd3a9c8c00.png
VRM1として出力されたGLBデータ（ブレンドシェイプに変化がない）
https://user-images.githubusercontent.com/26161297/199834633-775ed22d-833a-4253-ac1d-121f8051254e.png

以下の参照画像が間違っていました。
＞VRM1として出力されたGLBデータ（ブレンドシェイプに変化がない）
正しくはこちらとなります（変化がない状態）
https://user-images.githubusercontent.com/26161297/199830946-703ddb7c-2e68-46f8-b48a-51a8c0724efd.png

sparse accessorについては公式のサンプルもほぼ用意されていなく、実データを見たことがなかったので、対応はしていません。
用意いただいたデータを試しに読み込んでみたのですが、データが破損しながらもその他の部分は読めることもあるようですが、異常終了してしまう可能性もあるので、sparse accessorを含むデータだと予め分かっている場合は読み込まないようにしてください。

今後のリリースで対応を検討します。

なるほど、そういう経緯だったのですね。
対応検討ありがとうございます。
宜しくお願いいたします。

sparse accessorの公式サンプルがあったので、他のデータと一緒に参考になればと思います。

https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/SimpleSparseAccessor

とりあえずVer4.8.4aで対応したつもりですが、テストしたデータ数
が少ないため対応が十分かどうか正直なところまったくわかりません。
何かおかしな点などありましたらまたよろしくお願いいたします。

対応ありがとうございます。
早速、Ver4.8.4aで確認してみました。


https://github.com/vrm-c/vrm-specification/tree/master/samples/VRM1_Constraint_Twist_Sample/vrm

上記のVRM1としてsparse accessorが有効になっているデータを、拡張子をGLBにしてインポートしてみたところ正常に読み込めているのを確認しました。
ただ、インポートしたデータをそのままGLBとしてエクスポートして再度Metasequoiaで読み込もうとすると「ファイルの読み込みに失敗しました」というエラーが出て正常に読み込めないので確認していただけるでしょうか。
一旦、MQOファイルとして出力してからそのMQOを開きなおしてGLB保存しても同様のエラーが出て読み込めないGLBファイルとなってしまうようです。
https://github.khronos.org/glTF-Validator/
こちらのの、glTFValidatorを通すと以下のエラーが出ます。Blenderでも同様のエラーが出て読み込めないファイルが出来上がってしまうようでした。
>Invalid JSON data. Parser output: FormatException: SyntaxError: Expected double-quoted property name in JSON at position 75983


https://github.com/vrm-c/UniVRM/files/9934212/GLB_sparse.accessor_testzip.zip

一方で、こちらのUniGLTFから出力されたsparse accessorのデータを同様に、インポートしGLBで保存して再読み込みしたところ問題なく読み込めているようです。
こちらでは、glTFValidatorではエラーは出ませんでした。



両者の、インポートによる状態の違いエクスポートされたデータの違いを確認していただけるでしょうか。

調べたところ、どうもConstantシェーダがあるとエラーデータが出力されてしまうようです。
glb内にunlit拡張が指定されているとインポート時にConstantシェーダとなるのですが、その状態で出力するとダメという状況です。

調査の方ありがとうございます。
この問題はつまり、unlit拡張情報を持つglTFを読み込むとConstantシェーダーになるということはその拡張情報があるかぎりConstantシェーダーで出すと必ずエラーになるということですよね。
ということは、シェーダーを変えれば問題がなくなる。
Constantシェーダーとの相性問題？なのでしょうか
そのような状態のデータをインポートしたとして、エクスポート時にエラーデータにならないように対処するというのは可能でしょうか？
手動でシェーダーを変えることは勿論できますが、glTFの持つ情報を維持していた場合必ずエラーのデータが出るというのは自動で回避できないものかなと思うのですが如何でしょうか

この問題は、Constansシェーダーとの何がエラーデータの引き金になっているのでしょうか？自分の認識ではConstantシェーダーというのはメタセコイア独自のシェーダーで外部へエクスポートする際にシェーダーそのものがエクスポートされるわけではないので問題が無いと認識していました。

どのバージョンからか不具合でおかしくなってしまったようで、Constantシェーダだとエラーになるので、現状では回避のために他のシェーダに切り替える必要があります。

修正版を出す予定ですが、リリースに若干手間がかかるので、どのタイミングで出すか決めかねています。glTF周りは割と注力しているので、早めに出したいところではあるのですが…

返答ありがとうございます。
対応いただけるとのことでありがたいです。
私的にはタイミングは、開発者様の都合がいいタイミングで大丈夫です。

Ver4.8.4bでConstantでも問題なく出力できるよう修正しました。
ついでに、unlit拡張が含まれるファイルを入力した場合、そのままglTFシェーダの非照明がオンになるよう仕様変更もしています。

調べたところ、ご指摘の通りどうも出力時にスムージング角が適用されていないようです。
今後のリリースで修正しますが、現状での対策として
・法線コマンドで全頂点の法線を「固定」してから出力する
・他のファイルフォーマットを使用する
のどちらかを行ってください。