PoserへのOBJファイル読込み

例のSuperSevenのPoser化の一連で、OBJ形式のデータを最新のmodo301で生成した場合、Poser側の読込みでうまくいかない件、ローテクではあるが、いろいろと検証している。今回はOBJ形式を扱える各アプリでの検証結果である。


段取りはこうである。
『Poserでうまく読込めなかったOBJファイルを、そのままの状態で各種3DCGアプリで読込んでみる。』
それから、
『各3DCGアプリで読込んだ状態で、そのアプリでOBJ形式に変換して、Poserで読込んでみる。』

まず最初は、このSuperSevenの生みの親でもあるShadeからである。(でもバージョンは最新のver9)
結果は、


読込みは全くOKである。
が、Shadeのブラウザの内容をよくよく見ると、modoでパート分けした名称が幾つも現れている部位もある。たとえばフェンダー部位は、


          この部分と、


この部分とに分かれている。もちろんオーバーラップしているポリゴンは無いから、全体としては正常なモデリングとして扱われる。この状態そのままでShadeにて新たにOBJ形式で保存したものを、Poserに持ち込むと、


OKなような感じである。が簡易的にレンダしてみると、


フェンダー部分やエンジン・カバー部などに稜線が目立つ。これは先のポリゴンのグループ分けが複数に分かれてしまった部位に現れるようだ。
従って、Shadeを介したOBJ形式も正常ではないってこと。
しかし、このShadeによるOBJ形式は、Poserでは質感分けが反映されないが、グループ分けは元々のmodoでのパート設定の通りに分けられている。




次はLightWaveでの場合だ。LightWaveの場合はOBJ形式での読込みが出来ないので、Poserで表示できなかったデータを、modoでLW形式に変換したモノを使う。従って、仮にmodoのOBJ変換がイレギュラーである、という仮説には適合しない検証となるが、参考にはなるかもしれない。
で、LightWaveでの読込みは問題無いとして、LightWaveでOBJ変換したデータをPoserで読込むと、


OKであり、軽くレンダリングしてみると、


もともとmodoでマテリアル設定した部位毎に質感も(ある程度)継承している。

さて次はVueでの場合だ。その結果は、


このデータ、Vueでは少なくとも形状データは正常に読込まれている。ここまで検証を進めてきて、フト感じた。『modoのOBJ変換データがダメなのではなく、PoserのOBJ読込みがダメなんではないか?』と。。実際、他の3DCGアプリではほほ問題無く開けているんだから。。
そういえば、、PoserのOBJ形式対応はプアだと昔どこかで見た(読んだ)記憶がある。

ということで、Poserで正常に読込めるデータと、読込めないデータの違いを比較すべく、それらのデータをテキストエディットで開いてみた。Macの場合、このテキストエディットでデータ全文が表示できるようである。


左がPoserで正常に読込まれるデータ、右は今回のダメなデータの記述内容である。
特にこの行からの、数値列に『/』の有無が目立つ違いである。そして赤い線引いた部分は、この同じ記述が出てくるまでの行数の違いを現している。行数が違うということは、右側のダメなデータの方は、何かのデータが欠落しているってこと。(う〜ん、この点については、全く同じデータだったのか自信がなくなっている。Poserで読込めるデータと、読込めないデータが、全く同じデータってことはあり得ないから、右のダメ・データは何かポリゴンを削除した可能性もある。。)

といった中途半端な比較ではあるが、この『/』の有無って何を現すのだろう。でもこの『/』付きでも、ほとんどの3DCGアプリは読込めるんだから、大きな違いではなさそうだ。しかし、PoserのOBJ解釈ではダメなのか〜??

まぁ〜こんな感じで、全くアカデミックではない検証しかできないのだが、どうやら問題はPoserのOBJ読込みの問題も考慮しないといけないようだ。そう思ってWebで調べ出したら、こんな記事が見つかった。
『WavefrontOBJ読込みがエラーなしで終了しているがオブジェクトがない。→最終行をダミー(コメント行or 改行)にする。』
ここのサイトである。ここで言われた通り、最終行を改行したみたのだけど、結果は変わらなかった。。(コメント行ってどう記述するのか判らず、で単純に改行するんじゃダメなのかも)

さてさて、検証は続く、だ。ワケ判んないが、手当たり次第で『当たる(判る)』かもしれないし、勉強にもなるしネ〜。

BlogTopへ戻る