バーチャル3Dクリエイター神部まゆみです(*^_^*)
この記事は、VRoid Studioで作っていたオリジナルキャラを、Tripo・きゃらくる・Codex(ChatGPT Plus)を使ってリメイクしてみたので、その作業メモです。
元のキャラのデザインは残しつつ、もう少し描き込みのあるアニメ調の3Dモデルにしたいな…ということでやってみます。
制作の流れは「きゃらくる（Charakuru）」に沿って進め、調査やファイル操作、Blender・Unityでの検証などはCodexに手伝ってもらいました。
以前Tripoで3Dモデルを生成してみた記事も書きましたが、今回は元のVRoidキャラをもとに、頭と体を別々に作って組み立てるところまで試しています。
※今回はCodexくんにまとめてもらったので、ちょっと読みにくいかも？(^_^;)まぁ大部分彼にやってもらったのでイマイチ工程を把握していないというのがある…。
- 今回使ったツール。とりあえず1体を最後まで作ってみる
- 元のVRoidキャラを4方向から撮影しておく
- きゃらくるをセットアップしてCodexと進めてみる
- 【重要】元の再現だけでは物足りないので、画像の画風も調整してみる
- Tripoで頭と体を別々に生成してみる
- 分割したら頭が41パーツになった(^_^;)部位ごとに整理する
- Smart UVを試す。占有率が高ければ良いわけでもないらしい
- テクスチャ用の画像を8枚用意する。下半身は別の方法に
- 部位ごとに4Kテクスチャを生成してみる
- UV復元でエラーに。検証用コピーで組み立てを試す
- MToonで組み立てる。しかし首の位置が難しい…
- 自動リギングしてVRMに書き出してみる
- Unityに持って行ってみる。目と表情はまだ足りなかった
- VRChat PC版はVery Poorだったが、最適化したらGoodになった
- Android版も作ってみる。こちらはPoorだがビルドはできた
- 結局クレジットはいくら使ったのか？確認できた分は280
- おわりに。生成して終わりというわけではなかった(^_^;)
- 参考リンク
今回使ったツール。とりあえず1体を最後まで作ってみる
今回の流れは、VRoidで元キャラクターを用意し、きゃらくるの工程に沿って制作画像を作り、Tripoで頭部と体を別々に生成するというものです。その後、部位分割、UV、テクスチャ、組み立て、リギングを進めました。
| ツール | 今回の役割 | 記録で確認できるバージョンなど |
|---|---|---|
| VRoid Studio | 元キャラクターと4方向資料の準備 | バージョンは記録なし |
| きゃらくる | 制作工程、プロジェクト、同梱Skills・スクリプト | v1.0.4 |
| Codex | 調査、素材整理、操作、Blender／Unity検証の補助 | 使用モデルの正式な種類・版は記録なし |
| ChatGPTの画像生成 | 頭部・体の画像、テクスチャ用参照画像 | 生成モデルの正式な版は記録なし |
| Tripo | 3D生成、分割、Smart UV、4K再テクスチャ、リギング | Smart Mesh P2.0など、各工程の実表示を使用 |
| Blender | 形状確認、組み立て、位置合わせ、ウェイト・出力検証 | 5.2.2 LTS |
| VRM Add-on for Blender | MToon・VRMの出力と確認 | 4.10.2を使用 |
| Unity | Humanoidモデルの表示とVRChat用調整 | 2022.3.22f1 |
| VRChat SDK – Avatars | PC／Androidの評価とローカルビルド | 3.10.5 |
きゃらくるってのはこれね。
Tripo P2.0 × Codexで1枚絵からキャラクターモデルを制作できる「きゃらくる/Charakuru」というキットを無料公開しました！ なんと、 Tripo様より正式にスポンサードしていただくことになりました！！！ Tripoだけでキャラクターモデルを制作しようとすると、顔がガビガビだったり、動きがおかしかったり、テクスチャが汚かったりしてしまいます…！ このキットはそれを解決します！ AIに丸投げするサービスではなく、エージェントをアシスタントとして共同でキャラクターモデリングをしていくタイプのローカルキットです！ GPT-6.1 Sol,GPT-6 AstraのComputer useを最大限生かしています！ 丸投げしてしまうとクオリティがひどく、かといって人力でやると鬼ほどスキルが要求される問題の解決を目指しています。 自分がワークフローを共有したとしても再現性が無く、敷居も高かったので、いっそのことみんなが簡単に再現できるようなキットを作ってしまおうという感じで作りました！ 僕が見つけたワークフローをローカルアプリやエージェントのSkillsに詰め込み、それをユーザーが再現できる形で配布しています。 動作にblenderを活用していますが、ユーザーが触ることはありません。 人間が行う必要のある作業は、アプリ上の簡単な操作で実現できるようにしています。 無料なのでぜひお試しください～！ ※現在開発途中で足らない機能も多いですが、今後のアップデートで順次機能を追加していく予定です！
— Nano(ナノ) (@Dstudio_ai) October 6, 2026
細かいところを直し続けるといつまでも終わらなさそうなので、今回はとりあえず1体を最後まで作ってみる方針にしました。
多少気になるところがあっても、まず実際に3D化して結果を見たい。品質を詰めるのは、その後でもいいかな…という感じです。
元のVRoidキャラを4方向から撮影しておく
最初に用意したのは、同じキャラクターの正面・本人左側面・本人右側面・背面のPNGです。
vroid_front_test.pngvroid_left_reference.pngvroid_right_reference.pngvroid_back_reference.png
正面だけでは、耳の位置や後頭部、スカートの奥行き、尻尾の付け根が分かりません。特に尻尾は、腰の背面中央から生えて後方へ伸びる構造を保つよう、繰り返し確認することにしました。
元のPNGはそのまま残し、生成や比較にはコピーを使っています。途中で画像もモデルも増えてくるので、どれが元のデザインだったか分かるようにしておくと後で助かりますね。
きゃらくるをセットアップしてCodexと進めてみる
きゃらくるはGitHubのSource codeではなく、v1.0.4の正式配布パッケージを使いました。
GitHub – nanocle/Charakuru · GitHub
展開後は、ルートのAGENTS.mdを入口に、工程ごとのSkillと公式スクリプトを確認しました。ローカルアプリはhttp://127.0.0.1:8766で起動し、Edgeで制作開始画面を確認しています。
今回の実作業では、Blenderをバックグラウンド起動し、Pythonスクリプトで読み込み・検査・レンダリングする場面も多くありました。すべてをBlender MCP経由で操作した、という記録ではありません。初期セットアップ時点ではBlender MCPの導入は行っていませんでした。
また、有料処理はその都度、目的と表示クレジットを確認してから実行しました。元プロジェクトや生成モデルを残し、別ファイルやバックアップを作ってから次へ進む方針も、最初から維持しています。
導入日や開始時刻、初期セットアップにかかった正確な時間は記録なしです。
【重要】元の再現だけでは物足りないので、画像の画風も調整してみる
最初は、VRoidのデザインを忠実に再現する画像を作りました。その後、単なる再現よりも、高品質なアニメ調3Dキャラクターへのリメイクを目指す方向に変更しました。
画風参考にはChatGPTパイセンに生成してもらった↓の画像を使っています。
↑5/20に生成してもらったやつ…。
基本デザインはVRoidを優先し、画風参考のポーズや長いサイドヘアまでコピーするわけではない、という優先順位を明確にしました。
最初の頭部試作をA案として保存し、比較用に柔らかい質感のB案を制作しました。B案では髪の強い白いハイライトや金属っぽい反射を抑え、落ち着いた茶色の短髪と、柔らかい顔立ちに寄せてもらいました。
※この絵柄次第で完成モデルの顔はほぼ決まってしまうので、超重要です。これがそのまま3Dモデルになる感じなので、納得いくまで詰めたほうが良いかも。
このB案を基準に、頭部4方向、衣装込みの体4方向、全身三面図をそろえました。ここでいう「8枚＋三面図」は、後半の4Kテクスチャ用参照画像8枚とは用途が異なります。
3D生成向けには、背景をシンプルにし、方向と尺度をそろえることを重視しました。横顔と背面で尻尾の構造が矛盾しないか、短髪が勝手に長くなっていないかも確認しています。
Tripoで頭と体を別々に生成してみる
Tripoでは、最初の4候補がInvalid user inputになる失敗がありました。画像条件や向き、マルチビューとトライアルの関係を調べることになりましたが、今回参照できた記録だけでは直接原因を確定できません。失敗時に無料枠が必ず消費される、といった一般仕様も断定しないことにします。
その後、私はTripoを手動操作し、B案の頭部4方向から生成に成功しました。会話で確認できる設定は、Smart Mesh P2.0、生成数1、四角形トポロジー、約5000ポリゴンです。頭部生成の確定消費量は記録なしです。
体も手動で生成しました。こちらは4方向マルチビュー、P2.0、四角形、5000ポリゴン、生成数1、100クレジットという申告が残っています。
ただし「5000」という設定値と、実際の取得物の面数は同じではありませんでした。取得した体モデルは5391頂点・6101面で、そのうち4384面が四角形だったと記録されています。あとで三角形に変換すると数はさらに変わるので、設定のポリゴン数とVRChatのTrianglesを混同しないようにしました。
Codexは既存の生成結果からFBXやテクスチャを回収し、頭部候補と体候補として登録しました。候補は各1体を採用しています。きゃらくるの一括生成手順には各4候補を前提とする箇所がありましたが、選択・次工程の状態確認では各1候補で進められたため、数合わせの追加生成は行っていません。
この段階では、テクスチャが多少のっぺりしていても形状を優先しました。髪やメイド服の大きなシルエット、尻尾の位置を確認し、部位別4Kテクスチャは後の工程で作り直す方針です。
分割したら頭が41パーツになった(^_^;)部位ごとに整理する
頭部は無料トライアルの粗めセグメンテーションを1回実行しました。「3〜6パーツ」という目安に対し、実際には41パーツに分かれています。
分割されたからといって、髪・顔・目・耳という意味のある分類が自動で完成したわけではありません。小さな目周りの部品や、髪と皮膚の境界などをBlenderで確認しました。
分割前後ではUV配置や材質数も変わっていました。元の単一4K画像から部品別画像へ分かれ、材質が41個になったという検査記録があります。これは後の最終モデルの材質数ではなく、分割直後の状態です。
一度は、尻尾を無料のBlender処理で分離する診断もしました。衣装とのつながりが共有1頂点だったため、UVや面を保持して分けられたと記録されています。ただし、今回は標準ワークフローを体験する方針を優先し、この独自分離モデルを本番の基準へ置き換えてはいません。
体については、40クレジットを承認して粗め分割を1回実行しました。結果は22パーツ。胴と上衣・腕、独立した尻尾、脚とストッキング・靴、スカートとエプロン・裾レース、小さなリボンや金具などに分かれています。
テクスチャ工程では、63成分すべてを個別に処理するのではなく、髪・顔・上半身・下半身の4組へ整理しました。揺れ物のためにスカートを分けることと、テクスチャをどの単位で作るかは別の整理になります。
Smart UVを試す。占有率が高ければ良いわけでもないらしい
Smart UVの対象は、髪、顔、上半身、下半身の4グループです。41パーツや22パーツすべてに個別実行する工程ではありませんでした。
髪と顔には無料トライアルを各1回使いました。上半身と下半身は後で各20クレジット、合計40クレジットで実行しています。
Smart UV後に、髪のUV空間占有率は92.98%から69.54%へ下がりました。数値だけなら悪くなったように見えますが、検査では退化三角形が0、UVの範囲は0〜1内、継ぎ目の共有辺数も減っていました。一方、歪みの一部指標は悪化する箇所もあり、占有率だけで成功・失敗を判断するのは不十分でした。
元のFBX、UV、4K画像は別保存しています。テクスチャが削除される警告がある工程を実行する前に、戻れる状態を確保しておいたことは、後のトラブル調査でも役立ちました。
テクスチャ用の画像を8枚用意する。下半身は別の方法に
4K再テクスチャ用には、髪・顔・上半身・下半身の前後画像、計8枚を用意しました。3D生成時の4方向画像とは別の素材です。
最初の6枚は画像生成で制作できましたが、下半身の画像制作では安全フィルターによる拒否が発生しました。詳しい内部理由は分かりません。そこで同じ方法を繰り返すのではなく、私の指示で、既存のTripoモデルとテクスチャをBlenderでレンダリングする方法へ切り替えました。
これは公式の画像生成方法から変更した部分です。服を勝手に作り替えたり、別の画像生成サービスへ回して再試行したりしたわけではありません。
最終的には1254×1254の透過PNGにそろえ、公式ガイドの中心や尺度に合わせて登録しました。背景が透過していることと、衣装のレースに本物の穴抜きアルファがあることは別で、この時点でもレースの透過表現は完成していません。
部位ごとに4Kテクスチャを生成してみる
有料工程は、上半身・下半身のSmart UV計40クレジットと、4Kテクスチャ4組計80クレジット、合わせて120クレジットを上限として承認しました。
テクスチャは髪を先に1回生成して確認し、大きな問題がなければ顔、上半身、下半身へ進む順序です。記録では、4組とも4096×4096のBase Color JPEGを取得しています。参照画像は前後を使用し、Remove LightingはOFFでした。
髪や顔、衣装の情報は増えましたが、下半身のストッキングには色むらが残りました。また、JPEGはアルファを持たないため、細かいレースが描かれていても、模様の隙間が実際に透けているわけではありません。
ここでも完璧な再生成を繰り返すより、現状の結果で組み立てへ進んで、全体としてどこまで完成するかを確かめることを優先しました。
UV復元でエラーに。検証用コピーで組み立てを試す
ここで素直に組み立てまで行けるかと思ったのですが、テクスチャが戻ってきた後のUV復元で止まりました(-_-;)
公式スクリプトで、返却されたメッシュの座標差が許容値を超えるエラーが出ています。
調査では、髪・顔・下半身で微小な差が上限を超え、上半身は元のチェックを通過していました。
| 部位 | 元の座標差上限 | 測定最大差 | 検証用コピーの上限 |
|---|---|---|---|
| 髪 | 1.68195777e-5 | 2.55220748e-5 | 2.553e-5 |
| 顔 | 1.47364597e-5 | 3.05692083e-5 | 3.058e-5 |
| 上半身 | 1.04026725e-5 | 7.61450792e-6 | 変更なし |
| 下半身 | 1.08985194e-5 | 1.79255949e-5 | 1.793e-5 |
この数値は正規化後の基準モデル座標であり、そのままmmを表すものではありません。
頂点順序は変わり、一部の頂点数も減っていました。ただ、対応する面の欠落・追加・重複がなく、微小差を考慮した照合で面構造が一対一にそろうことを確認しています。Smart UV後と4K生成後の座標集合は一致しており、4K再テクスチャが新たな形状差を増やしたわけではないことも分かりました。
差の発生区間はTripoへ渡した後から返却までに絞れましたが、Tripo内部の丸めや変換のどこで起きたかは未確定です。
そこで、元の公式データとスクリプトを保持したうえで、検証用コピーだけに最小限の座標差上限を設定する実験を承認しました。面対応、欠落や重複、UV、4K画像などの検査は残し、検証そのものを無効化していません。
この部分は、きゃらくるv1.0.4の公式スクリプトが無変更で正常完了した事例ではありません。 以降の完成モデルも、この実験的組み立てを出発点にしています。
MToonで組み立てる。しかし首の位置が難しい…
検証用環境では、4組のUVとテクスチャを基準メッシュへ戻し、MToon材質を適用して全身を表示できました。
ここではアドオンの互換性でも一度停止しています。自動探索で古いVRM Add-on 2.20.32が先に選ばれ、Blender 5.2で廃止されたAPIの読み込みに失敗しました。既に入っていた対応版4.10.2を隔離したBlenderプロセスで明示的に読み込むことで解決しています。新しいアドオンの購入や、既存設定の保存変更はしていません。
全身にすると、今度は首の隙間や頭部の前後位置が気になりました。最初の位置合わせで改善しても、側面から見ると顎を引いたような印象が残っています。
私がBlenderで頭を少し前へ動かしたファイルも参考にし、Codexが同じカメラ条件で4候補を比較しました。最終的に採用したのは、直前の基準から前方約31.5mm、下方約3.4mm、回転変更なしの配置です。
頭と髪は一緒に移動し、顔の頂点やUVは変更していません。首も溶接した連続面ではなく、独立メッシュを重ねてつなぐ方法を維持しました。そのため、静止画で自然に見えるだけで終わらず、後の首回転テストが必要になります。
自動リギングしてVRMに書き出してみる
採用配置を確定してから、Tripoの自動リギングを20クレジットで1回実行しました。設定は人型／Mixamoです。
きゃらくるの標準経路では、髪を除いた頭と体をリギングに渡し、返却モデルのメッシュで元モデルを丸ごと置き換えるのではなく、骨配置だけを読み戻します。その後、同梱素体からローカルでウェイトを転送しました。
スカートには周囲8列、尻尾には1列の揺れ骨を用意し、腰と左右腿の3球コライダーを設定しました。このモデル用の作骨や部位ウェイトの初期値はCodexの作業スクリプトによるもので、公式が全自動で推定した値とは区別しています。登録や監査には公式スクリプトを使っています。
短髪と獣耳が一体のメッシュだったため、髪は頭へ固定しました。耳や髪のシルエットを保つ判断であり、髪まで揺れる完成モデルではありません。
VRM 1.0を書き出し、Blenderへ再インポートして、1アーマチュア、5メッシュ、19,229三角形、MToon4材質を確認しました。4K画像4枚も、VRMへ埋め込んだ後のデータが元JPEGと一致することを検査しています。
ただし、このVRMは確認用のメタ情報で出したもので、正式な作者名・利用条件を確定した配布用完成品とは別です。
Unityに持って行ってみる。目と表情はまだ足りなかった
Unityへの初回インポートは私が進め、VRChat向けのアップロード操作へ進める段階になったことを会話で報告しました。ただし、初回インポートのすべての操作や、実際のアップロード完了を示す画面は、今回の資料にはありません。
その後のCodexによる検査では、Eyeボーン自体は存在することが分かりました。一方、顔にはそのウェイトがなく、目を回しても顔の頂点は動きません。逆に首付近の体の頂点に小さなEyeウェイトが残っていて、ボーンを動かすと首側がわずかに変形する状態でした。
つまり「目のボーンがない」だけの問題ではなく、機能する目のメッシュとウェイトの対応が足りませんでした。まばたきや表情のBlendShape、顎ボーンもありません。
Eye LookをONにすれば解決する状態ではないため、今回の最適化では顔の構造を作り直さず、今後の課題として残しています。
VRChatへのアップロードと実機動作確認
↓はデスクトップモードで動かしたやつ。まぁ普通に動きましたね…。
↓はQuest版でVRで動かしたやつ。とりあえず破綻なく動きました。
ブレンドシェイプとかはまだ作ってないので表情は変わりませんがｗ
VRChat PC版はVery Poorだったが、最適化したらGoodになった
最適化の調査時、UnityはAndroid対象になっていました。PC向けのつもりでもAndroidの警告を読んでしまう状態だったため、対象を区別して評価する必要がありました。
Unityプロジェクトへのアクセスが拒否された際には、私がプロジェクトを作業フォルダーへコピーしました。Codexは変更前のAssets、Packages、ProjectSettingsなどをZIPで保全してから、コピー側を調整しています。
まず顔と髪は4Kのまま、上半身と下半身だけを2Kへ落としました。比較してみると、通常の全身表示では違いをほとんど感じませんでした。
さらに、体・スカート・尻尾を1メッシュへ、頭と髪をもう1メッシュへまとめ、重複する材質スロットを整理しました。頂点溶接や減ポリ、UV再展開はしていません。
| PCのSDK評価項目 | 元モデル | 最適化版 |
|---|---|---|
| Performance Rank | Very Poor | Good |
| テクスチャメモリ | 256 MB | 53.33 MB |
| Skinned Mesh Renderer | 5 | 2 |
| マテリアルスロット | 6 | 4 |
| 三角形 | 19,229 | 19,229 |
| ボーン | 82 | 82 |
PC用圧縮にはBC7を使い、MipMap、Streaming、Kaiserフィルターも設定しました。53.33MBは単なる理論計算ではなく、Windows対象のSDK評価で表示された値です。ただし、GPUドライバーで直接計測した実使用VRAMとは異なります。
途中、最適化VRMは衣装2Kなのに、保存したBlenderファイルを開き直すと古い4Kの埋込み画像が戻る不整合も見つかりました。検証用コピーで2K画像を読み直して保存し直し、再オープン後の状態を確認しています。画面表示だけでなく、保存後のファイルを開き直す検査も必要でした。
Unityのポーズ画像でも、ボーンを即座に動かしてCamera.RenderしただけではTポーズのまま写る問題がありました。この画像を動作テスト合格の根拠にせず、UnityのBakeMeshで実際のスキニング結果を取り出して描画し直しています。
PC専用Prefabには新しいPipelineManagerを用意し、既存アップロードIDを引き継がないようにしました。VRChatで除去されるVRM専用コンポーネントも、PC専用コピーだけで整理しています。元VRMのSpringBoneは残っていますが、VRChat PhysBoneへ自動的に変換されたわけではありません。
なお、PC切り替えについては、私から「SDK Builderで手動切り替えした」との訂正を会話で伝えています。前回の作業報告だけでは操作主体を完全に特定できない部分があるため、ここではWindows対象のSDK評価が確認できたことと、切り替え操作の履歴を分けて扱っています。
Android版も作ってみる。こちらはPoorだがビルドはできた
Android版では、SDK BuilderのPlatform(s)でAndroidだけを選び、SDKが表示したBuild Target Switcherの確認を経て切り替えました。Unity標準Build Settingsだけで完了とは判断せず、Builder側のAndroid表示も確認しています。
MToonはAndroidアバターで使えないため、同梱のVRChat/Mobile/Toon Standardへ変更しました。顔と髪は各2K、衣装は各1K。ASTC 6×6圧縮を使っています。
Android版でも三角形やウェイトは維持しています。両面描画を設定し、衣装裏の欠損を抑えました。レースは元から描かれた模様なので、Android専用に無理な透過機能は追加していません。
| 項目 | PC版 | Android版 |
|---|---|---|
| Performance Rank | Good | Poor |
| SDKテクスチャメモリ | 53.33 MB | 5.94 MB |
| メッシュ／スロット | 2／4 | 2／4 |
| 三角形 | 19,229 | 19,229 |
| 顔・髪 | 各4K | 各2K |
| 衣装 | 各2K | 各1K |
| 圧縮形式 | BC7 | ASTC 6×6 |
Android版はSDKのローカルBuildに成功し、バンドルは5,852,308 bytes、約5.58MiB。SDKで確認した非圧縮サイズは8,015,819 bytes、約7.64MiBでした。記録時のAndroid上限であるダウンロード10MB・非圧縮40MBを下回っています。
Poorの主因は三角形と4材質スロットです。AndroidのGoodを狙うには、今回のモデルでは約48%以上の三角形削減と、1スロットへのアトラス化などが必要になります。外観が大きく変わる可能性があるため、今回は実行していません。
また、AndroidでPoorのアバターは、通常の表示設定では隠れる場合があります。アップロード向けのバンドルが作れたことと、誰にでも既定で表示されることは同じではありません。
SDKの古いシーン参照による選択エラーも起きましたが、Builder表示を更新してからローカルビルドを行って解消しています。PC版は関連35ファイルのハッシュが作業前後で一致しており、Android用のシーン・Prefab・メッシュ・材質・テクスチャは別保存です。
結局クレジットはいくら使ったのか？確認できた分は280
費用については、表示料金と実際の記録を分けて確認しました。次の表は、この制作で確認できる消費の小計です。現在の一般料金表ではありません。
| 工程 | 確認できる消費 | 根拠の種類 |
|---|---|---|
| 体モデル生成 | 100 | 私の手動操作についての申告 |
| 頭部の粗め分割 | 0 | 無料トライアル使用の記録 |
| 体の粗め分割 | 40 | 残高2550→2510の記録 |
| 髪・顔のSmart UV | 0 | 無料枠2回の記録 |
| 上半身・下半身のSmart UV | 40 | 各20、台帳 |
| 4組の4Kテクスチャ | 80 | 各20、台帳 |
| 自動リギング | 20 | 2390→2370、台帳 |
| 確認できる小計 | 280 | 上記の合計 |
頭部生成や初期失敗試行などの費用は未確定なので、280を制作全体の総額とは書けません。画像生成に使ったChatGPTプランの月額や利用枠も、Tripoクレジットとは別です。制作全体の正確な作業時間も、統一した開始・終了ログがないため記録なしとします。
おわりに。生成して終わりというわけではなかった(^_^;)
画像から3Dモデルが出てくるところはかなり手軽ですが、そのまま何もせずアバターとして完成、というわけではなかったですね(^_^;)
部位分け、UV、テクスチャ、首の接続、ウェイト、表情、VRChatの性能評価…。形ができた後にも、それぞれ確認するところが結構ありました。
今回、うまくいったのは次の点です。
- 元デザインを4方向資料として残し、B案を軸に画風をそろえられたこと。
- 頭と体を別生成しても、位置合わせを経て全身モデルとして表示できたこと。
- 4K画像を残したまま、用途に応じた軽量コピーを作れたこと。
- PC版では造形を削らずにGoodへ改善できたこと。
- Android版でも、別アセットとしてローカルビルドまで到達したこと。
一方、課題も残っています。
- 目のウェイト、まばたき、表情、口パクは別の制作が必要。
- VRChat用PhysBoneは0のままで、VRMの揺れ物がそのまま動くわけではない。
- ストッキングの色むら、レースの本当の透過、肩や膝の変形品質は改善余地がある。
- 頭と首は重なり接続なので、激しい動作まで無貫通とは言えない。
- AndroidのPoorを改善するには、外観と軽さのトレードオフを検討する必要がある。
Codexには比較画像を作ってもらったり、数値を調べてもらったり、元データを残しながら別版を作ってもらったりと、かなり手伝ってもらいました。
ただ、髪の質感や頭の位置のようなところは、やはり自分で見比べて「こっちでいいかな」と決める場面もあります。全部丸投げで一発完成、という感じではないです。
まぁ今回は、VRMを書き出し、PC版でGood、Android版もローカルビルドまで進められたので、とりあえず一通り試すという目的には近づけたかなと思います。
目の動きや表情など、まだ足りないところはありますが、そのあたりは次の課題ということで…。
あとは最初の画像次第で最終的な絵柄や作風が全く変わってくるので、画像を変えて何パターンか作ってみたいですね。
また何かあれば追記します(*^_^*)
参考リンク
この記事は2026年10月25日までに参照できた制作記録に基づきます。料金やSDKの仕様を、将来も同じ条件で利用できると保証するものではありません。