LOG82R2R2R2026/3/7

3Dpressoで動画から3Dモデルを生成する

3Dモデルを生成する

R2R2R（Real-to-Render-to-Real）開発の続きとして、3Dスキャンツールの調査と新しいワークフローの開拓を行った。Luma AIのWeb版3Dスキャン機能が終了していたことを受け、代替サービス「3Dpresso」を発見・登録し、コーヒーカップの動画をアップロードして3Dモデル生成を開始するところまで進めた。

※注釈：デジタルツイン学習（R2R2R）の検証プロセス本プロジェクトは、AIの判断を物理的動作へ変換する設計を検証するものです。現実空間をデジタルツイン化し、仮想空間での大量試行（Real-to-Render）から得た最適解を、実世界のモーター駆動（to-Real）へ還元する「R2R2Rパイプライン」の実装過程を記録・考察します。

ポリゴン削減の完了

前回の小鉢スキャンデータに対してMesh Simplifier（Unity）を実行し、ポリゴン数を大幅に削減することに成功した。

削減結果：999,647ポリゴン → 150,136ポリゴン（約85%削減・6分の1）

これにより、Unity上での200万ポリゴン超え警告も解消され、物理シミュレーションの動作が安定した。MeshSimplifierToolはEditorスクリプトとして作成し、Tools → Simplify Kobachi Meshから実行できる。

Luma AIのWeb版3Dスキャン機能が終了

次のターゲットとして「コーヒーカップ」をスキャンするために、Luma AIのWeb版（app.lumalabs.ai）で動画アップロードによる3D生成を試みた。しかし調査の結果、Luma AIはWeb版の3DスキャンサービスであるGenie機能を2026年1月1日に終了していることが判明した。

現在Luma AIで3Dスキャンを行うには、iPhoneアプリ「Luma 3D Capture」を使う必要がある。WebサービスはDream Machine（動画・画像生成AI）に特化した方向に移行している。

代替サービス「3Dpresso」の発見と登録

Luma AIの代替として、韓国のRecon Labsが開発した「3Dpresso」を発見した。3DpressoはWebブラウザから動画をアップロードするだけで3Dモデルを生成できるサービスで、R2R2Rのワークフローに適している。

主な特徴：

スマートフォンで撮影した約1分の動画をアップロードするだけで3D生成
NeRF＋フォトグラメトリのハイブリッド技術（MetaRECONエンジン）を採用
OBJ・GLB形式でエクスポート可能（Unity・Unreal・Blender対応）
新規登録で30クレジット無料付与
AIテクスチャ生成機能あり（プロンプトでテクスチャを変更可能）

コーヒーカップの動画撮影とアップロード

Googleアカウントで3Dpressoに登録後、コーヒーカップを約1分間撮影した動画（311MB・MOV形式）をアップロードした。アップロード完了後、サーバー側で「Modeling in progress」として3D生成処理が開始されたことを確認した。

処理完了後はメールで通知が届く仕組みになっており、完成後にOBJエクスポート→Unityインポートの工程に進む予定だ。

今後の期待と考察

3DpressoはNeRFベースのAI補完技術を使用しているため、Luma 3D（純粋なフォトグラメトリ）と比べて未撮影部分の補完精度が高い可能性がある。コーヒーカップの取っ手裏側や底面など、今まで精度が落ちやすかった部分の改善が期待できる。

R2R2Rの観点からは「現実の物体を忠実にデジタル化する」精度が重要であり、複数サービスを比較しながら最適なワークフローを確立していく。

kobachi_2をUnityに配置・スケール調整

3DpressoでスキャンしたコーヒーカップのOBJファイルではなく、先行して生成済みの小鉢（kobachi_2）をUnity 2022 LTSのシーンに配置した。ここで予想外のスケール問題に直面し、解決までに複数の仮説検証が必要だった。

最初、小鉢のScaleを実寸（直径10.5cm）に合わせてX/Y/Z: 0.105に設定したところ、ロボットアームより明らかに小鉢が大きく見えた。ロボット（mechArm 270-M5）側のスケールを疑い、Robot_0_0、RobotArmy、baseと各階層のScaleを確認したが、すべてX/Y/Z: 1だった。

次にbaseメッシュのImport Settingsを確認したところ、Scale Factor: 0.001、Convert Units: 1mm (File) to 0.1m (Unity) という設定が判明した。つまりURDFのモデルデータがmm単位で記述されており、インポート時に0.001倍されていた。計算上はmechArmの高さ約350mmがUnity上で0.35unitになるはずで、理論的には正しい。

しかし実際にグリッド（1マス=1m）と比較すると、Scale:1のロボットは米粒ほどのサイズしかなかった。Scale Factorの変換が期待通りに機能しておらず、実際にはモデルが1/1000スケールで取り込まれていた。

検証の結果、RobotArmyのScaleを10に設定することで、グリッド1マス(1m)に対してロボット高さ約35cm相当という正しいサイズ感が得られた。小鉢のScaleは0.3が視覚的にちょうどよいサイズ比となった（グリッドの小マス=10cmに対して小鉢の直径が約10cm相当）。

最終的なスケール設定

RobotArmy Scale: X/Y/Z = 10
小鉢（result）Scale: X/Y/Z = 0.3

MeshCollider＋Rigidbodyの設定

スケール調整が完了したところで、小鉢（result）に物理コンポーネントを追加した。

InspectorのAdd Componentから以下を追加：

MeshCollider（Convex: ✅）
Rigidbody（Use Gravity: ✅）

追加直後に2つのエラーが発生した。

1つ目は「Couldn't create a Convex Mesh from source mesh within the maximum polygons limit (256)」。3Dpressoのスキャンメッシュはポリゴン数が多く、Convex Hull生成の上限に引っかかるケースがある。今回は部分的なhullで動作したため続行できた。

2つ目は「Non-convex MeshCollider with non-kinematic Rigidbody is no longer supported since Unity 5」。MeshColliderのConvexチェックを一度外して入れ直すことでエラーが解消した。

設定完了後、小鉢がガタガタと揺れ続ける挙動が発生した。Convex Meshの近似精度の問題で、スキャンデータの底面の微細な凹凸が物理演算に影響していた。RigidbodyのIs Kinematic: ✅ を有効にすることで静止させた。Is Kinematicの状態でもスクリプトからtransform.positionやMovePosition()で制御できるため、ロボットアームのピック＆プレイスシミュレーションには支障がない。