ラベル Lightwave3D の投稿を表示しています。 すべての投稿を表示
ラベル Lightwave3D の投稿を表示しています。 すべての投稿を表示

2021/04/17

リハビリ Lightwave 3D

 昨夜自らに鞭打って、ほぼ3年ぶりに3DCGモデリング・レンダリングアプリであるLightwave 3DをPCで立ち上げた。バージョンは2020.0.2で最新だが、メジャーバージョンアップは体調を崩してから1回すっ飛ばしている。

 まぁ、「会社の病気休暇中に何遊んでんの?」って言われると「ぐぬぬ」なのだが、この種のアプリでの作業は集中力を要求するし、時間は有限だから作業の手際の良し悪しがアウトプットに直接影響する。だから実際に作業してみての結果は、病状の回復具合の指標となり得ると考えているのだ。結論から言うと、昨夜は2時間ほど、今日は午後の3時間ほど触り、そこそこのアウトプットを得られた。現段階では「新しく始める、一から作る」はキツい、が「次に何をするか自分の中で明確な作業の再開」はできるといったところだろう。

 作業対象のデータは、自分のYoutubeチャンネルなどのヴィジュアルで使うつもりのVocalod GUMI(Megpoid)のモデルだ。まだ頭部だけ、髪も面倒臭くて手すら付けていないが、その代わりにソ連の初期宇宙服のヘルメットを被せてある。現在のYoutubeチャンネルのヘッダーの画像は、今回の作業再開前の最後のレンダリング結果を加工したものだ。そもそもは"High school GUMI"でのヴィジュアルを意識したモデリングだが、着手時はともかく、手癖やらなんやらでもはや見た目は別物だ。宇宙服のヘルメットを被った頭部だけ・・・スカイ三平さんの宇宙開発ゆっくり解説動画中の霊夢みたいやね、とか今突然思っちゃった。

 作業自体は主にリギングで、モデリングはしていない。だが、Nullオブジェクトとチャンネルフォロワーを使って、レイアウト上での黒目(緑目?)位置のコントロール(≒視線のコントロール)を実現できたのは個人的に満足度は高い。前半は厳密さが要求されて気を使う必要があるが、後半は単調な繰り返し作業と、トータルで見ると本当に面倒臭いからだ。やり終えるには多少の気力が要る。次は口と眉のモーフ編集か、身体のモデリングか・・・まぁ、前者だろうなぁ。



 

 具体的にやったことは左右の黒目のテクスチャの貼り付け角度や大きさをNullオブジェクトの回転で制御できるようにしただけだが、貼り付け角度の変更だけでそれっぽい結果を得るためには、貼り付け角度変更時の回転中心(眼球中心位置相当)になる貼り付けの基準位置をまず見つけなければならない。結局作業の大部分は、作図解法さながらのモデリング解法による左右の目のテクスチャ貼り付け位置の特定と、すっかり忘れていたアプリの操作法を思い出すことや新たなキーマッピングの発見などに費やされた。なお、仮想的な眼球の直径は約38cmもあった。

 なお、より真面目な視線コントロール、別の言い方をすると「どこを見ているかをNull位置で指定してやると、そこに視線が向くように黒目の位置が変わるようにする」には、ボーンを2本とNull1個を加え、やはりチャンネルフォロワーを使ってやれば実装できる。この時のボーンの根本(回転中心)は、当然、仮想的な眼球の中心だ。こちらの方法だと視点と顔との距離も黒目位置に反映されるため、寄り目もできるようになる。静止画ではなくアニメーション前提の場合は絶対こちらの方法にすべきだ。

 過去エントリで既に書いたことがあるかもしれないけれど、1日に16時間覚醒状態が保て、一つの作業に2時間集中して取り組むことができれば、少なくとも「会社のオフィスに行って、ちゃんと仕事をしている『振り』」以上のことはできる。だからこそ「今の自分がどのくらいの時間、どのくらいの深さで集中することができるか?」を常に把握したいし、「もしかしたらできるかも」と思ったことには取り合えずチャレンジするようにしている。

 先行して「とにかくブログを書く(誰も読んでないっぽいが)」、「DAWアプリであるCubase Proに触る」にもチャレンジを始めている。今も頭は時に割れるように痛むし、歯もグラグラしているしでツラいと言えばツラいのだが、持論である「取り組んだことを終わらせることができる限りは、自分自身は終わってない」は捨てられない。終えるためにはまず取り組む必要がある。時に中止や廃棄も決断する。上記の持論の実践は体調不良を理由に一時的に停止状態だが、ほんのちょっとだけだけど停止解除への希望が見え始めた。この点は単純に喜んでおこうと思う。

2018/05/12

LightWave 2018.0.4アップデート

 アップデートが出るのが早いのは良いのだが、もちっと落ち着いた方が良い様に思う。

 具体的には、「もっとちゃんとした、不具合と不具合個々への対応予定のリスト」を出した上で、アップロードのロードマップの提示、アップデートのリリース、リスト更新を繰り返した方が良い。現在の対応はまだ場当たり的に見える。リリースノートを読む(つまりアップデートのリリース後になる)までアップデート内容が部分的にしか分からないという状況は、時間に追われている身には手の打ちようが無くて途轍もなく辛い時がある。

 と言うのも、Blenderの躍進などもあり、低価格寄り製品とは言えLightwave3Dユーザーの人口もさすがに以前よりプロ側にシフトしたと思うからだ。つまり、「業界(の人間)相手」を前提とした対応方法に明確に舵を切った方が良い。「暇な業界人」・・・希少種だと思いますよ。

 リリースノートを見る限り既に不具合はナンバリングされており、不具合のデータベース化の仕組みは既に存在している筈である。ならば、後は外部への見せ方だけの問題だと思うのだが。まぁ、それにいったん手を付けたものの、余りに不具合リストの拡大が早くて「対応時期未定」の項目だけみたいなリストしか出せなくなってしまったゲーム会社がありましてね・・・

 さて、個人的に既にメリットのあったアップデート0.4での改善点は以下の2点。2点目はアップデートで発生した不具合(激怒した人も、脱力した人もあろう)のアップデートによる解決という間抜けたものだが、みんな!今は単純に喜んでおこうよ。
  • 異常に遅くなっていたモデラーの起動時間が、2015以前と同等まで早くなった(2015と何度も比べたので確実)。
    だからどうしたレベルの話と思う人もいるだろうが、機能は変わらず、メモリ使用方法変更のアナウンスも無いままの体感30倍以上の低速化は「他の不具合が有る兆候の可能性大」と見るべきだろう。
  • アップデート0.2で動作だ不安定化した「モデラーのメニューへのcfgファイルの読み込みによるブランチ追加」がちゃんと動作するようになった。
    この機能が動作しないと、私の環境でも20個以上の追加プラグインを一つ一つ手動でメニューに登録しなけらばならず、面倒臭いし複数のライセンス認証も含めると20分ぐらいの作業になる。機能が動作すればメニュー登録もライセンス認証もそれぞれ10秒以内、全作業でも1分ぐらいしかかからない。

2018/04/29

GW前処理事案 - Lightwave3D 2018の過去バージョンとの互換性

 0.3パッチのリリースでやっとまともになったか、と言ったところ。非平面ポリゴンに対するレンダラーのトレランスは更に低下。「レンダラーも別の意味でまともになった」と言ってしまえばそれまでだが、一部のモデラーツールの低精度さ、処理の適当さなど旧レンダラーの非平面ポリゴンに対するトレランスの非常識なまでの高さ故に許されてきた部分ももう限界だろう。

 ただ、従来よりも低コストでノイズが下げられるという意味では良いレンダラーとも言えそうだ。サードパーティであるOctaneレンダラーの出方次第ってのもあるが、GPUへの対応を期待したいところではある。

 透明(ガラスなど)や半透明(プラスチックなど)の物質のサーフェイス設定の互換性維持はレンダラーの仕様変更により原理的に不可能になった訳だから、要は残りの部分はどうかってことだよね、結局。

 0.2パッチでイメージテクスチャーのコンバージョンが(非常識にもこのタイミングでやっと…それまでは完全に除去されるだけだった)実装され、0.3パッチでは反射回りのコンバージョン不具合がかなり是正された。後はリグ、特にGenoma導入前のIK、FK混在リグの納得できるレベル(つまり、人体が人体の形を維持している状態)での再現ですなぁ・・・

 なお、以下に示した画像(VF-1Aバルキリー、コスモゼロ)の作成で使用したデータは、パッチ0.3で旧データを読み込んだ上で、キャノピー等の透明部分のサーフェイス設定のみ手動で修正したものだ。また、主翼後退角の変更などレイアウト上での編集はかなり実施しているので、自分でも初めて観る画像ばかりなんですよ。
  0.3パッチ導入以降の金属表面の反射具合の再現(サーフェイス設定の互換性維持)はかなり良い。

2018/03/06

Lightwave3D 2018.0.2アップデート来る!

 最初っからこうでなくっちゃね。「Lightwave3D 2015以前のバージョンで作成したオブジェクトを読み込んだ場合に、サーフェイス設定が削除されてオブジェクトがつやつやの灰色一色になってしまう」問題がある程度解決されました!良かった良かった。

 テクスチャ設定の再現が良好なので、旧データのコンバージョンの手間が大幅に低減されそうです。

 ただし、レンダラーが変わったせいなのか反射光周りの設定は高確率で化けます(と言うより、特定の値に固定される感じ)。下の図はLightwave3D11で作成したシーン及びモデルファイルをレイアウトに読み込んだ結果です。反射の設定が化けたせいでキャノピーが真っ白になってしまってます。銀色の部分の反射も若干変化してますね。

2018/01/29

Lightwave3D、終わっちゃう?(3)

 多少触った結果、まぁ踏みとどまったかなって印象になりました。

 ただこれは趣味で使っているから言える話であって、仕事で使っている人にとっては結構問題アリで移行は従来よりも面倒臭そうです。導入時期やコストに頓着せず、それでもLightwave2018が避けられない場合は、多くのバグフィックスが期待されるアップデート待ちが正解っぽいですね。サーフェイス設定周り、レンダラー周りのバグやクラッシュの多さは結構イライラさせられますし、UI変更ももう一段階の整理が必要だと思います。

 あと、Lightwave2018にちゃんと対応したリファレンスマニュアルの早期リリースを!

2018/01/22

Lightwave3D、終わっちゃう?(2)

 本日はLightwave2015を使い、VF-1Aのモデルのサーフェイス設定のLightwave2018フォーマット互換形式へのコンバート(ノード編集への完全移行)に取り組みました。Cosmozeroでの経験も反映して作業の効率化を図りつつも、2時間以上かかりました。この手のつまらない単調な作業に取り組めるぐらいには、体調、気分は戻ってきたかな?

 やはり、スタンダード/Standardノードの「光沢」とクラシックの「光沢」の数値を一緒としてもレンダリング結果が異なる場合があります。この「光沢」、新しいレンダラー用のプリンシプルBSDFノードには直接1対1に対応するパラメータがありません。つまり、従来の「光沢」の再現には本質的に複数のパラメータの調整が必要ということなのでしょう。ですのでレンダリング結果(やLightwave2015上でのプレビュー画像)の「光沢」を(少なくとも見かけで)コンバート前後で同じにするためには、スタンダード/Standardノードの「光沢」の数字を「反射光」の数値に合わせてクラシックの数値から変更しなければならないということのようです。

 あとセルシェーダーを使うとレンダリング中に必ずクラッシュするとか・・・Lightwave3D 10~2015ではクラッシュなんてほとんど経験してこなかったんですけどね。
  ラインレンダーの特性には変化はなさそう、悪くないです。

2017/07/16

Lightwave3Dモデリング、リハビリ着手!

 うつ症状向けに調剤されている薬は現在は1種、しかも昼間用1カプセル、サインバルタ(30mmg)だ。医者との相談しつつ使用0もにらんで減薬を進めてきた結果なのだが、この三連休で使用0を試し、現在2日目だ。案の定、所謂離脱症状にのたうっている。もう薬無くてもやれそう、という感覚は半年ほど前からあるのだが、この離脱症状ってのが曲者で色々と躊躇してしまう。まぁ、今回は様子見で、やめられそうと判断したら夏休が本番ということになるだろう。

 で、離脱症状について少々。

 まず所謂「ションビリ」、耳元で「シャンシャン鳴り続く」、指先が「ビリビリし続ける」という症状だ。実際には、聞こえる音は「微かなシャー」、ビリは指先よりも額から顎にかけて感じている。あと、車酔いしたような、ずっしりした頭痛とフラフラした感じがある。いやぁ、これじゃ車は運転できないねぇ。あと、面白い症状としてたまに感じる激しい歯痛、ポイントは痛む歯が抜かれていたり金属に変わっていたりと既に存在しないところだ。ファントムペインっぽいんだよね。それでもいざ起ればのたうち回るのは必至で、やっかいではある。

 ん、で、趣味の分野でも連休を生かしてリハビリ中。今回の主眼は3DCGモデリングだ。対象となるアプリはLightwave3D。

 Lightwave3Dの特徴は、モデリングに使うモデラーとレンダリングやアニメーション作成に使うレイアウトが別プログラムという点だ。両プログラムを立ち上げた状態でのモデラー上におけるモデル編集結果のレイアウト上のモデルへの反映は 、ハブと呼ばれるプログラムがバックグラウンドで行う。ハブは一種の通信プログラムで、ネットワーク通信プロトコルを使ってモデラーとレイアウトの2つのプログラム間のデータ授受を制御している。

 なぜこんなことを書くかと言うと、先のWindowsの大型アップデート以降にハブが上手く機能しなくなっていたのだ。昨日はその対策に追われたと言って良い。結論から言うと、OneDriveが悪さをしていたようだ。OneDriveはマイクロソフトの一種のクラウドデータ共有サービスで、当然ネットワーク通信を行う。極々まれなのだが、ハブの機能を使おうとすると(セットアップもしていない)OneDriveがログイン情報を要求してくることがあった。そこでOneDriveをアンインストールしたところ、現在は部は快調に動作している。

 と言う訳で、いよいよLightwave3Dでのモデリングに再挑戦の準備は整ったようだ。となると、次はモデリング対象をどうするかであるが・・・

 ここは何の迷いもなく、Angel Interceptor(古い方)に決定。理由はそんなサジェスチョンを電波で、いやパケットで以前に受けた・・・気がするからだ。コスモゼロに挑んだあとにがっくり調子を崩したことも踏まえ、調子を崩した前後に考えていたことから始めてみようということです。

 え、何?Angel Interceptorを知らない?白くて突き刺さりそうな機体、イギリスですよ、形からして十分変態。


 "White as Snow"をヘビロテしながら準備中。案の定と言うか、当然と言うか、撮影モデルも大きさによって微妙に形状が違うと言うか、三次元曲面処理が部分的に違うんだよなぁ・・・


三面図はWikipediaから入手できたしね。あ・・・(これは違う)。


 

2015/03/22

新規PC、届かず。

 「太平洋にハリケーン、船舶運航スケジュール乱れる」の報があって案の定、先週の今頃は太平洋上に出ていた筈のPCは届かず、当初20日だった配達予定日も未定になってしまった。PC更新は環境(ほぼインストールアプリケーションと同意)の掃除の良い機会で、準備万端整えてこの土日を迎えた訳だが完全に肩透かしを食らってしまった。ちなみに現行のDELL製PCもアセンブルは米国だったが、国際輸送が航空便だったのでびっくりしたことを今でも覚えている。

 しょうが無いので?、OctaneレンダーのLightwave3D用デモプラグインを入手してLightwave3D 11.6で今日は半日遊んでみた。OctaneレンダーはnVIDIA製グラフィックチップを使ったレンダラーで、購入検討段階にある。現行PCのグラフィックカードはnVIDIA Geforce GT630というロートルではあるのだが、96個の並列利用可能なCUDAコアを持つ。

 結論から言うと、「バージョンアップを待って再検討」。現在のOctaneはバージョン2.5+αで、Lightwave3Dに関しては統合自体には問題は無い。ただし、Lightwave3Dでこれまで作って来たモデルやシーンがそのまま使えるかと言うと、そうは問屋が下ろさない。実際に使ってみて、
  • モデルの質感(マテリアル)設定は、Octane用に書き換えなければならない
  • 4点以上の頂点を持つポリゴンが望むようにレンダリングされることは保証されない
  • レンダリング時に必要なPC本体メモリの使用量はネイティブレンダラーより小さい
といった点が良く分かった。 速度はCUDAコア×96如きでは知れているが、それでも「インタラクティブビューにはやや非力かな」といったところだ。ちなみに、新規PCのグラフィックカードのCUDAコア数は1024だ。

 で、Octaneレンダーの次バージョン(octane 3)はこの夏にリリースが予定されている。ニュースリリースによれば、次バージョンには以下の機能が盛り込まれる。
  • OpenCLサポート
    これは、GPUがnVIDIA製で無くても良いと言う事だ。AMD、IntelのGPUも使える可能性がある
  • FBXフォーマットサポート
    Lightwave3D上でモデルの質感(マテリアル)設定は、Octane用に書き換える必要がなくなるかもしれない
という事で 「バージョンアップを待って再検討」となった訳だ。

2015/03/14

PCをアップデートするよ!

 これでも8年前まではPCは自作していた。コンバット・フライトシミュレータとかやっていたから、今で言うところのゲーミングPCでも上のレベルの性能を追求した。CPUのオーバークロックは当たり前、CPUを買うにも製造番号(同じCPUでも製造工場によってオーバークロック耐性が違っていたりしたから)までチェックしていた。

 が、歳をとってゲームをしなくなり、また自作することによるコストメリットも薄れて来たあたりで「DELLで良いや」って感じになってしまった。今使っているPCはDELLのデスクトップで、7年間以上トラブルらしいトラブルもないまま現在に至っている。欠点と言えばハードディスクのデータ転送速度が元々低かったことで、メモリ増設である程度はカバーできたもののボトルネックであることには変わりない。ちなみになぜDELLかと言うと、「DELLは10年後もPCビジネスをやっている」という根拠無き直観に基づくもので、少なくとも8年は直観通りだったということだ。

 さて、車もそうだったのだが、それなりに高価な買い物は私の場合はほぼ間違いなく「半ば衝動買い」である。「半ば」という意味は、「欲しいっ!」という衝動には一切応じないが、「買うなら今だ!」と言う自分の直観(ゴーストの囁き?)には素直と言う事だ。まず「欲しいっ!」があって、それをいったん忘れて、然るべき時期が来れば虫の知らせのように「買うなら今だ!」という精神状態が突如やって来る。大抵は3~4年忘れている。

 今回のPC購入の決断も、と言うか決断すらしたのかも怪しい。会社で仕事中にふと「さぁ、PCを更新しよう」と思い、退勤後に自宅でDELLのサイトにアクセス、15分ほどで購入手続きを終えてしまった。今頃は太平洋上を日本に向かっている筈である。購入モデルの選定では、SSDドライブを使うかどうかと搭載メモリサイズの2点だけはちょっと悩んだが、それも本当にちょっとだけ。何故ちょっとかと言うと、事前に何も調べていないんだからそもそも判断基準が無い訳で、悩むこと自体が無理なのである。

 こんな調子なのだが、後で色々調べてみたらなかなか自分のニーズにマッチした構成になっているのがある意味恐ろしい。と言うか、私の人生は万事そういう感じなのである。ちなみに購入モデルは何かのキャンペーン対象品で(在庫処分扱いとは別。おそらくホビーユースには値段が高く、プロユースには性能が不足、かつDELL内のゲーミングPCブランドAlienwareとも構成が被るので売りにくい商品なのではないかと邪推)、CPU価格以上の値引きというオマケ付きだ。

 新規PCへの要求は、まず(ホビーユースの範疇で)長整数及び倍精度浮動小数点演算速度が高いCPUを搭載し、周辺機器がその足を引っ張らないことである。この要求は主に2つのニーズに対応している。

 一つめのニーズは、DAWであるCubase使用時の私へのストレスを下げること。

 使った事の無い人には分からないと思うけど、DAW起動中は常にCPUに一定以上の負荷がかかっている。音楽製作ツールであるDAWはリアルタイム音響生成・合成処理が基本で、アプリ操作者の操作に即座に反応する必要がある。リアルタイム処理という点ではソフトウェアシンセサイザーも同じで、それなりにつくり込んだデータをCubaseにロードしただけでCPU使用率60%は当たり前となる。CPU負荷を下げるため、これ以上は編集しない演奏データはフリーズ(演奏結果を音声データとしてディスクに書き出し、以降はリアルタイムの音声合成処理はせずに書き出した音声データを再生する)するのだが、ここでハードディスクのデータ転送速度が低いことが現行PCではボトルネックになっている。CPU使用率或いはディスクアクセス負荷の何れかが再生中に一瞬でも100%となると、ほぼ半々の確率でCubaseはクラッシュするし、場合によってはハードディスク上のデータまで破壊する。

 Cubase設計者も馬鹿ではないので、ハードディスクからの音声データ読み出しは巧みにスケジューリングされている。しかし、例えばPiapro Studio(ボーカロイド・エディターの一種)といったプラグインがどのタイミングでディスクからデータを読み出すかまではCubaseは知ることができない。故に、Piapro Studio上でボーカロイドデータにブレス音(息継ぎ音。ボイスバンクと呼ばれるボーカロイドの音声ライブラリには含まれず、独立した音声データファイルとして提供される)を追加した途端、クラッシュが頻発するといった状態になり得る。また、フリーズデータが大きくなれば、いずれリアルタイム処理に必要なデータ転送速度がハードディスクの最大データ転送速度を越えてしまうのも必然だ。

 上記のブレス音の件は原因究明まで時間がかかったが、色々と得るものもあった。代表的な知見は、「Piapro Studioではトラックにブレスが含まれている場合、トラックがミュート状態でもハードディスク上のブレス音データ読み出し処理をする」だ。Piapro Studioを使っていて、急にホストDAWのクラッシュが増えたり、再生時のノイズが増えたりした場合、Piapro Studio上でのブレスの使用を疑う価値がある。少なくともCubaseの場合は、ブレス音は音声ファイル自体をオーディオトラック上に置くか、Groove Agentなどのサンプラーのパッドに割り当てて使うか(大抵の場合、音声データはメモリ上にロードされる)の何れかにした方がクラッシュの防止という観点からは良い様だ。

 もう一つは、3DCGアプリであるLightwave3Dのレンダリング時間の短縮だ。レンダリングというのは、モデルを配置、照明やカメラを設定した後の「画を計算して得るプロセス」である。これはCPUの演算速度がダイレクトにモノを言う。

 現行PCのCPUはIntel Core2 Quad 2.66GHz(4スレッド=4並行処理)、現在太平洋上の新規PCのCPUはIntel Core i7 3.6GHz(4コア、8スレッド)だ。ネット上を調べると、同じデータを様々なPCやMacでレンダリングした際のレンダリング時間を互いに報告しあっている海外スレッドがあった。報告者の何人かはメールやメッセージをやり取りしたことのある人間で、カナダのVFX業界のフリーランサー達だ。さすがに飯のタネだけあって、彼らの使っているPC、と言うかWS(ワークステーション)の仕様は凄くて、8コアCPU×2=16コアはもはやお約束だ。しかも十中八九DELLだ。

 さて、フリーランサー達のWSでレンダリング時間40分のデータ、現行PCと購入PCで予測されるレンダリング時間はどうだったろうか?公平を期すためにOSはWindows 7 64-bit、メモリは16GB(新規PCのメモリ搭載量は32GB)のPCに絞って報告されているデータを集計してみた。結果は、現行PC相当の仕様のマシンで9時間~11時間30分、新規PC相当の仕様のマシンで2時間~2時間40分となった。ざっくり、1/3以下のレンダリング時間短縮が見込めるということだ。この差は実は大きい。

 もしあなたがサラリーマンなら、1日8時間程度は会社に居るだろう。現行PCで24時間かかるレンダリングを実施する場合、現行PCでは翌日にならないと結果が分からないが、新規PCなら出社時にレンダリングを開始すれば退社時に結果が確認できる。結果も見てミスを発見しても、細かなミスならば退社までにデータを手直しして再レンダリングしてしまえば、翌日の出社時には望む結果が得られているだろう。レンダリング時間の短縮はユーザーのワークフローの自由度向上に効くが、やはり1/2以下ぐらいまでは短縮されないと「劇的な効果」は得られない。

 Lightwave3Dではレンダリングに割り当てるスレッド数を制限できる。だからスレッド数は全スレッド数の半分しか割り当てないと言う様な使い方ができる。これまではレンダリングには全スレッドを割り当てていたのでレンダリング中はメールチェックぐらいしかできなかったが、新規PCではレンダリング時間を従来以下としつつ、レンダリングしながらも現行PCのフルパワー状態以上のCPUパワーが享受できると見る事ができよう。やっぱり両者の差は大きい。

 加えて、新規PCのCPUは十分な能力のグラフィックチップを内蔵している。

 3DCGのレンダリング処理は並列化処理に向いているので、やはり並列化処理に特化したグラフィックチップ(GPU)によるレンダリング演算はプロユースでは既に一般化しつつある。Lightwave3Dデータに対応したGPUレンダラーも既に存在し、レンダリング時間がCPUのみの場合の1/30以下という結果も得られている。つまり、Lightwave3Dが本格的にGPUレンダリングをサポートするようになれば、画面表示はCPUのグラフィックチップに任せ、「レンダリング演算専用のグラフィックカード(或いは一昔前のTeslaのような並列演算専用カード)」を挿す、なんて贅沢も可能となるんじゃないかなぁ…と思う。

 ちなみに新規PCのデリバリー予定は1週間後だ。来週の土日は新規PCの環境整備で潰れそうっすなぁ。

2015/03/06

Lightwave3D 2015リリース!

 愛用の3DCGアプリLightwave3Dの最新バージョンの"2015"日本語版が3/3にリリースされたので、早速アップグレードした。Lightwave3Dに関しては、バージョンアップ直後のバージョンで致命的な不具合に接した事が無い。これは同様のシチュエーションで必ず驚くような不具合を抱えているCubaseなどとは全く異なる。

 今日のところは、取り敢えず以前のデータを幾つか読み込んでみて動作をチェックした。物理演算機能を使った既存データもチェックしたが、やはり一切問題はなかった。さて、ぼちぼち3DCGモデリングも再開しましょうか!