ClipStudioのボーンについてはまったく把握していないのですが、ちょっと調べるとMaya以外で出力したFBXだと「標準ボーンマッピングモード」というもので調整するような記載が見つかります。
現状はこちらを利用しているのでしょうか？

ご返答遅くなり申し訳ございません。
標準ボーンマッピングモードで動かせることを確認できていたのですが、公式からダウンロードできるサンプルのFBXモデル（body.fbx）をメタセコにインポートしたところ、ボーンの座標軸が公式のドキュメントに記載の向きと一部違う（親骨の直下にある骨のみ？）ので、なんでだろう…と悩ませてました。

サンプルがFBXデータなのもあり、その骨をテンプレートにして作成できたらカンタンかと思った次第です。

公式のサンプル
https://www.clip-studio.com/clip_site/download/clipstudiomodeler/clipstudiomodeler_top

最初のクリスタ専用で使用するサブPCから投稿した際、普段メタセコを使用するPCの投稿名で合わせるのを忘れてましたので、ご了承ください…

URL内を探してみたものの見当たらないのですが、サンプルのbody.fbxはどこにあるのでしょうか？

>URL内を探してみたものの見当たらないのですが、サンプルのbody.fbxはどこにあるのでしょうか？
お世話になっております。
お送りしたページが違ってたようで、確認不足で申し訳ございません。
以下のページ、中ほどにある「はじめに」の項目にあるリンクからFBXが落とせます。
ご検証のほど、よろしくお願いいたします。
https://tips.clip-studio.com/ja-jp/articles/1166

Ver4.8.1で子ボーンへの方向をどの軸にするかを「前方の軸の向き」で簡便に設定できるようになりました。
これで大丈夫なのではないかと思うのですが、実際にデータを用意してClipStudioへ持っていく検証まではできていないので、何か不都合な点などありましたらご連絡いただければ幸いです。

最新版での対応ありがとうございます！

知人を巻き込んで検証してましたので、遅くなってしまい大変申し訳ございません。

ひとまずVer4.8.1にて、サンプルデータをインポートして骨の軸の向きが正しく表示されていること、前方の軸の向きも調整できるのを確認できました！　現状ですと座標軸の表示サイズを大きくできないため大変見辛いですが非常にうれしいです！

ただし、ClipStudioに出力したところ以前と変わらず標準ボーンと仕様が違うみたいで、現状そのまま使用することができませんでした。

改めて、公式のサンプル（body.fbx）も確認しましたが、そちらはインポートするだけで問題なく使用できます

そこでMaya（バージョンは2019）を持ってる知人がおりましたので、公式のFBX（body.fbx)とメタセコから出したFBX（公式のbodyをインポートしてそのままFBX出力※公式推奨のバージョン201400)を検証してもらいました。

軸の向きは同じようでしたが、メタセコのFBXは空ノードがGroupというノード（FBXの仕様？）で出てないことが原因のようでした。

以下、検証結果
＜ClipStudio公式のサンプル（body.fbx）＞
骨の親ノード　→　reference_bb_という名前のGroupノード
メッシュの親ノード　→　girlA_groupという名前のGroupノードで、その下の階層にあるノードも、body_meshという名前のGroupノード
　
＜メタセコのFBX＞
骨の親ノード　→　reference_bb_という名前の空のMeshノード
メッシュの親ノード　→　girlA_groupという名前のMeshノードで、その下の階層にあるノードも、body_meshという名前のMeshノード

お手すきの際、改めてご確認、ご検証よろしくお願いいたします。

上記で＜メタセコのFBX＞の記載内容を間違えてましたので、以下内容で訂正いたします。

------------------------------
＜メタセコのFBX＞

■公式のサンプルモデルをメタセコにインポート時の設定

　内部テクスチャをファイルに出力：しない
　光線読み込み：する
　未使用ノードを除外：しない
　バインドポーズを適用：しない（メタセコで骨が壊れたため）

メタセコにインポートした時点でMaya上の表示と違ってた部分：

＜オブジェクトウィンドウ内の階層※Mayaの階層と比較＞
reference_bb_
└　以下、Mayaと名称で相違なし（Mayaでは骨データのようです）

girlA_group
└body_mesh

だいぶ時間が経ってしまいましたが、検証結果を含めてVer4.8.2で多少対応を入れました。
9239の投稿にありましたように、空のノードについてはMeshとして出力されていたのをNullに変更しています。

body.fbxのインポート時に階層構造が異なる箇所については手動での修正が必要になります。
普通にインポートすると「reference_bb_」以下のツリーがオブジェクトとボーンの両方に重複してしまうので、インポート時のオプションで「未使用ノードを除去」するか、後でオブジェクトパネルでreference_bb_以下のオブジェクトを一括削除してください。
また、ボーンのツリーの先頭が「hips_bb_」になっていますが、元データでは「reference_bb_」の下に「hips_bb_」がぶら下がっているので、「reference_bb_」ボーンを追加して「hips_bb_」をその子にします。
これで元のデータ構造と完全に同じになるはずです。

ClipStudioModelerでの検証が少し触ってあまり問題なさそうという程度しか確認できていない（細かい部分の操作までわからないため）ので、改めてご確認いただければと思います。

Ver4.8.2で法線方向への移動、中点の削除の両方に対応しました。
後者はちょっと気づきにくいですが、「エッジ」コマンドの挿入時にAtl+クリックで逆の操作ができる形になっています。

影ムラとは具体的にどういったものを指しているのでしょうか。
いくつか考えられるものがあってどれか分からないので、実際の画像があれば良いのですが、当掲示板には画像の貼り付けができませんので、弊社サポートまでメール添付で画像ファイルをお送りいただければ幸いです。
外部のファイルアップロードサービスなどで画像を確認できるようにしていただいても構いません。

早く対応していただき、ありがとうございました
メール添付で画像ファイルを送らさせていただきました

水平面ではなく正しくは、平面（水平・鉛直問わず）です
すみません
以下、抜粋です

光の角度にもよりますが、添付画像建物の壁やガラス（平面）に、
モデリングしたメッシュ形状にはない、内部処理されたような斜め線や、斜めハッチングのような影ができます
テクスチャの境界でもなさそうなんです

材質は
窓ガラス→透明体，薄膜
葉っぱ系→glTF(Blend)，png
それ以外→glTF(Default)，png，jpg
です

レンダリング時の縞模様の件ですが、
そもそもインポートしたFBXファイルなので、
よく分からないノイズが乗っていて当然だと、
まず認識しました。
以下、試して分かったことです。

メタセコV481a(64bit)Windowsを起動し、
新規作成、基本図形から200mmの立方体（分割1）を
ワールド座標中央に作り、標準機能、パストレーシングレンダリングを実行。
縞模様はありません。
次に立方体をX方向に+2000mm移動してみると、
わずかに側面に対角線状の影模様が発生。
さらにZ方向に+2000mm移動すると、
別の面に縞模様が発生。

今度は10倍の大きさ2000mmの立方体（分割1）を
中央に作りレンダリング。
わずかに縞模様。
この立方体を、XYXそれぞれ20000mm移動すると、
同様の縞模様が発生。

現在詳細を調査中ですが、オブジェクトのサイズが大きいときに変な縞模様が発生しているようですので、レンダリング前にオブジェクト全体を数百以下くらいのスケールになるよう縮小してみてください。

今後のリリースで根本的な対策を施したいと思います。

「レンダリング前にオブジェクト全体を数百以下くらいのスケールになるよう縮小」了解です。

>今後のリリースで根本的な対策を施したいと思います。
設定がシンプルで動作が軽く、仕上がりがきれいなレンダリングソフトはほかにはないので楽しみにしています。

ありがとうございました

Ver4.8.2でオブジェクトのスケールに関わらず、おかしなノイズが出なくなりました。
シーン全体のサイズに対して極端に小さいものを写すような条件下では不正確な表示になることは依然としてあるようですが、よほど極端にしない限りは実用上は問題になることもないと思います。

再現方法
Metasequoiaで、メッシュ情報を持たない空のオブジェクトレイヤーをFBXとしてエクスポートする
Unityで、そのFBXを読み込む。
該当の、メッシュを含まないオブジェクトレイヤーにMesh Filter及び、Mesh Rendererのコンポーネントが追加されている。

恐らくですが、Unityは、ゲームオブジェクトというトランスフォーム情報のみの空のレイヤー、Mayaはグループという同様にトランスフォーム情報のみの空のレイヤーというデータ構造を持てるようになっており、メタセコには「オブジェクトレイヤー」というメッシュ情報を持っているのが前提の構造のため、メッシュ情報が無いが構造的にはメッシュ情報を持っているレイヤーデータとしてFBXに出力されているのではないかと思います。

そのため、メタセコの出力したFBXは仕様上絶対おかしいかというとそうでは無いと思うのですが、他の出力環境と揃える意味でもメッシュの中身が空の場合はメッシュ情報を持っているレイヤーとしてエクスポートされないと理想です。

Ver4.8.2で頂点・面がない場合はNullノードとして出力されるよう変更しました。

使用状況がよくわかりませんので、
・OSのバージョン
・各モニタの解像度、拡大縮小（％）
・モニタの配置レイアウト
など、どういったPC環境で利用しているか具体的に記載いただけますか。

>使用状況がよくわかりませんので、
>・OSのバージョン
>・各モニタの解像度、拡大縮小（％）
>・モニタの配置レイアウト
>など、どういったPC環境で利用しているか具体的に記載いただけますか。


使用OSのバージョンはWindows 10(21H2)で、モニタは3枚「(1920×1080),(1024×768),(1920×1200)」で解像度はすべて100%、モニタの配置レイアウトは左から上記の順番に並列です。

>使用OSのバージョンはWindows 10(21H2)で、モニタは3枚「(1920×1080),(1024×768),(1920×1200)」で解像度はすべて100%、モニタの配置レイアウトは左から上記の順番に並列です。

年末年始を挟んだため時間がかかりましたが、こちらで調査したところ、限定的な条件で同様の現象が起こることは確認できました。

こちらで確認できたのは、拡大縮小率が異なるモニタ間をまたいでパネルを配置したときにずれることがありました。ただ、これも必ずではないようで起きたり起こらなかったり、また拡大縮小率が同じなら起こることはありませんでした。
モニタ３つとも100%とのことですが、確かに間違いないのでしょうか？

拡大縮小率が違っているケースでは、
・デスクトップ上のアイコンを右クリックして「プロパティ」
・「互換性」欄内の「高DPI設定の変更」
・「高DPIスケール設定の上書き」をONにして「アプリケーション」を選ぶ
とすると回避はできるようです。ただ、同じなのに起こっているようでしたらこの方法も有効ではないかとしれません。また、あくまで回避策なので常用はしないほうがいいかもしれません。

現状では以上となりますが、この問題については引き続き調査を進めます。

了解しました。
解決策を試してみたところ、直りました。
ありがとうございました。

また、モニターについてはもう一度確かめたところメインのモニターのみ150%になっており、100%に戻してましたがやはり左上に上昇してしまいました(ただし上記の回避策でいずれの解像度でも上がらないようになりました)。

32bit版ではプログラム・データ合わせて理論上で2GB、実際にはそれよりもずっと少ない量しか扱えません。
そのため、アンドゥの使用量を大きくしてしまうと、肝心のデータを格納できなくなってメモリ不足によるエラーが発生しやすくなります。

アンドゥは32bit版では多くても256MB、できればそれ以下（100MB程度）にしてください。
64bit版ではより多く設定しても大丈夫です。

分かりました。ご返信いただきありがとうございます。

ちなみにですがNAL.3さん作成のNormalMoveCmd（http://mattaku.jp/html/download_p.html）というプラグインが作業にかかせないため32bit版で作業するしかない状況となっています。
もし可能でしたら同じ機能（選択部分をドラッグでまとめて法線方向に移動する機能）を追加していただけますと幸いです。

よろしくお願いします。

OS・プラットフォームにより異なります。
ヘルプのインストールの頁に記載されていますので、そちらをご覧ください。

Latheは既に標準機能として搭載されています。
オブジェクトの設定で「回転体」を指定してください。

Create springはあくまでサンプルで、それほど細かい設定ができないので、便利かというと微妙な気がしますが…
ちなみにVisual Studioには無償版もあるので、そちらをインストールすればどなたでもプラグインを自分でビルドして作成することはできます。

ご教示いただいたやり方で、線から回転体の作成できました。非常に便利です。

Create springはあくまでサンプルである旨、承知しました。Visual Studioでのビルドは自分には敷居が高いのでこれは諦めます。

ご返信ありがとうございました。