●LightWave 2015のUpdate3（2015.3）が米国でリリースされました。
・ＰｙｔｈｏｎのシステムアップデートやNVIDIA Optimus technology※のサポート。
（※ＣＰＵ内臓グラフィクスとGPUによる自動負荷切り替え機能によるパフォーマンスの最適化と
消費電力の効率化。win7以上）
・パイプラインのアップデートとして、AfterEffectsとGozの改善や、VPRとビューポート及び
リストアオプションの強化。
・インターチェンジの機能強化として、CC2015(AE)への対応、FBXリグ(Maya)のインポートの改善、
Unityと他ゲームエンジンのUV対応、アレンビックのサブディビジョンメッシュ対応の改善、
ZBrush(4R7)のGoZ対応の追加。
・LScriptのSceneObjectAgentに対しての改善。22の新しいデータメンバと環境定数のサポート
並びに、LWのカスタムオブジェクトアクセス上のPython制御のアップデート。
・各種バグフィックス
●新たにチュートリアル（クイックスタート）ビデオ（英語）4本が公開されています。
https://www.lightwave3d.com/learn/category/quick-start/
・Mac版のライセンシングの手順
・PC(Win)版のライセンシングの手順
・モデラーインターフェイスの解説
・レイアウトインターフェイスの解説
順次追加されるようです。
●シーグラフ期間中のキャンペーンとして、
LW2015と3ｒｄpowersツールのバンドル販売が行われます。
https://www.lightwave3d.com/buy-lightwave-3rd-powers/
（キャンペーン期間が1週間と短いので日本代理店は除外かも。）
●v2015.3（英語版）の体験版が公開されました。
https://www.lightwave3d.com/try_lightwave/
トライアルライセンスを取得すれば、90日間機能制限無しです。
●RobPowersさんがSiggraph2015に合わせLiveStream(WakulTV)に出演されたみたいです。
久々の公の場なので何を語ってくれたのかと思いきや上記プロモーションに終始したみたい
です。収録内容は後でアーカイブ公開するかなぁと思います。
シーグラフ期間中に追加アナウンスがあれば、都度、追記したいと思います。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
LightWaveのPivotの仕様
LWのPivotはモデラーとレイアウトでそれぞれ異なる仕様です。それぞれの特徴を以下に書き出してみました。モデラーのPivot：
・モデラーのPivotは位置情報のみで、回転・スケールの情報はありません。
・モデラーのPivotはレイヤーに固定されています。
・モデラー側のPivot位置をレイアウト側へと渡す場合は、レイアウトで、Modify > Move Pivot >Reset
コマンドを実行。Hubが起動していない場合は該当のオブジェクトファイル(.lwo)のPivot位置を
参照します。尚、モデラーではレイアウト側へPivot情報を渡すコマンドはありません。
・モデラーのPivotはオブジェクトファイル(.lwo)に保存されます。
レイアウトのPivot：
・レイアウトのPivotは位置・回転・スケールの情報があります。
・Pivotのアニメーションは出来ません。
・レイアウトでアイテムの置き換え（交換）を行ってもPivotは交換されません。
・Hubリンクしてても、レイアウト側のPivot位置をモデラー側へ渡すコマンドはありません。
（手作業でレイアウトのPivot座標値を拾い、その値をモデラー側のPivot値へ入力することは可能です）
・レイアウトのPivotはシーンファイル（lws)に保存されます。
・レイアウトでオブジェクト保存を行っても、Pivot位置はオブジェクトファイル(.lwo)には保存されません。
・レイアウトのPivotの中心点移動(MovePivot)・中心点回転(RotatePivot)編集はアンドゥ出来ません。
Pivotの仕様が統一出来ない理由は、モデラーにオブジェクト座標が存在しないからでしょう。仮に、モデラーにオブジェクト座標があったとすれば。。きっとボーンもモデラーに実装出来そうですし、他にもレイアウトと同じことが色々出来そうなので、モデラーとレイアウトを分ける意味（大義）が無くなるのかもしれません。。（笑。
レイアウトに読み込まれたアイテム名称の命名規則
以前から漠然としてたのでスッキリさせるために書き出して纏めてみました。（以下v9.6で検証です。最新verでは未検証）
1）
Case_01.lwoのオブジェクトファイルには図のようなアイテムが1番レイヤー（レイヤー名称：body）に存在してます。このアイテムをレイアウトに読み込みます。
2）
レイアウトに読み込まれたカレントアイテム名称はオブジェクトファイル名のCase_01となり、1項のレイヤー名称（body)はカレントアイテムの名称に付加されません。
3)
次に、1項のアイテムを2番レイヤー(body)に移して、一番レイヤーは空にしてレイアウトに読み込みます。（図の状態はオブジェクト再保存＞閉じる＞再読み込みの工程を経てます）
4）
レイアウトに読み込まれたカレントアイテム名称はCase_01:bodyとなります。つまり、アイテム名称はオブジェクトファイル名+レイヤー名となります。
5）
ちなみに、複数レイヤーにアイテムが存在する場合（1番/body、2番/lib）だと、
6）
レイアウトに読み込まれたカレントアイテム名称は4項同様にオブジェクトファイル名+レイヤー名となります。（レイヤーに名称を付けていない場合は、そのレイヤー番号が付加されます）
纏めると、
1番レイヤー（イニシャルレイヤー）にしかアイテムが存在しない場合は、そのオブジェクトは単体アイテムとみなされ、レイアウトではオブジェクトファイル名称のアイテムとなります。又、そのアイテムが1番レイヤー以外のレイヤーに存在（配置）してる場合や複数レイヤーにアイテムが存在する場合では、レイアウトでのアイテム名称はオブジェクトファイル名+レイヤー名（或いはレイヤー番号）と表記されます。って、ルールかなぁと思います。
余談ですが、
1、2番レイヤーにアイテムを置いて、2番レイヤーに対してレイヤーパネルの目アイコンのチェックをOFFにしてオブジェクトファイルを一旦保存した後、レイアウトにそのオブジェクトファイルを読み込むと、1番レイヤーのアイテム名称はどうなるでしょうか？
結果は、1番レイヤーのアイテム名称はオブジェクト名+レイヤー名（Case_01:body）となります。
この結果から推察すれば、1番レイヤー以外の目のアイコンを全てOFFにしても1番レイヤー以外のレイヤーにジオメトリが存在すれば、そのオブジェクトファイルは単体アイテムとはみなされない。ってことなのでしょうね。（2番レイヤーのアイテムは目アイコンをOFFにしてるのでレイアウトには読み込まれません。）
ここらの命名規則は知らなくても作業側の体制に影響はしませんが、仕様としてなんだかスマートじゃない気はします（笑。仮にどんなケースであっても、オブジェクト名+レイヤー名の表記にしてしまえばスッキリしそうですが。。（他の処理的？に何か依存する関係があるのかもしれません。）
以上の解説はマニュアルには書かれていませんので、一部解釈に語弊があるかもしれません。
SIGGRAPH 2015が来週に迫って来ましたが、NewTek(LW3DG)は去年に続き今年も出展はスルーでしょうか。SIGGRAPHの開催期間に合わせた自社Web上でのShowReel(2015)等のビデオ公開や、2015年度版LWマガジン発行等のイベントもどきは実施されるかもしれません。しかし、今年は定型的イベントで終わって欲しくありません。何故なら今年でCORE中止から4年目を迎えるからです。CORE中止直後にロブ氏が語っていた当時のロードマップの発言内容を鑑みれば、4年目を迎えた今年は当時の発言に対する何かしらの経過を発表して欲しいところです。http://www.cgchannel.com/2011/06/rob-powers-on-lightwaves-three-year-roadmap/
当時COREアプリはその完成度に不評を買い頓挫してしまいましたが、COREアーキテクチャのコンセプト自体は大方好意的に受け止められていたはずです。もう時効だと思うので、ここらで蒸し返して当時のCOREアプリの一部機能を以下に抜粋してみます。抜粋内容は現時点でLW側にもたらされていない機能です。ユーザーに一度でもCOREという夢を魅せてしまった以上、そのCORE事件を完全払拭する為にはCOREを超える何か（コンセプト）が不可欠ではないかと思うのです（笑。
・COREコンセプト：
COREはオブジェクト指向であり、パラメータノードベースのアーキテクチャです。
シーングラフに基づいて構築されているため、シーン内部の全データはルートノードから広がる
グラフ内のノードとして表示されます。データやオペレーション、保存方法に関してモディファイヤ
スタックなどのような他の手段が採用されることもあります。モディファイヤスタックにはシーン
内部の各メッシュアイテムに対するモデリングオペレーションが保存されます。
この結果、COREデータフローはノードとモディファイヤスタックの二重構造となっています。
・パラメトリックモデリング
作成過程のどの段階においてもモデルのアトリビュートを検索し、修正を行うことが可能になる
ためアトリビュートを自由に変更できるようになります。アクションは全て保持され、モディファ
イヤスタックに更新されます。
・複数シーンドキュメント/参照シーン
複数のシーンを異なるショットもしくは同一ショットの異なるバリエーションとして作業できるよう
になります。複数シーンはアウトラインパネルの中で表示および管理されます。
同一セッション内における複数のシーンの編集に加え、シーンは他のシーン内部からも参照
が可能になっています。こうすることでタスクをさらに管理しやすいドキュメントへと分解して
いくことが可能であり、特定エレメントの目的に焦点を当てやすくなります。
必要になれば、より大きなマスターシーンの中で参照できるようにもなります。
・簡易合成環境
レイヤーのブレンディング、連番画像の調整などに適した環境を提供します。
Foundryにより提唱されているOFX(OpenFX)規格準拠のプラグイン製品をサポートします。
・Layer(レイヤー) パネル
LayerパネルはLightWaveモデラーのレイヤーパネルとは異なります。Layerパネルはモデリン
グやアニメーション、全般的なレイアウトのタスクのために使用されます。このパネルはシーン
アイテムを配置するためのレイヤーを作成する場所です。
このレイヤーで可能なことは
ビューからのオブジェクトの非表示。
オブジェクトにロックをかけることによる不用意な選択の回避。
レイヤーコンテンツに対する独自の描画スタイル。
より組織化されたワークスペースの維持。
・Connection Editor (コネクションエディタ)
Connection Editorを使うと、COREシーンのすべての局面における内部接続と関係性をつくる
ことができます。アイテムはOutline(アウトライン)パネルからConnection Editorへと編集用に
ドラッグされます。ノードやさまざまなオペレータを追加し、Expression(エクスプレッション)を
作成し、アトリビュートを修正したりといったことが可能になります。
ブックマークはConnection Editor内部で利用可能であり、物事を組織化できるようになります。
このブックマークにより、ほかのブックマークされたページ上にあるノードの一部を必要になった
場合にノード参照をコピーペーストできます。さらにノードをグループ化させることでノードの
流れが結合した際における混乱を軽減させることが可能です。
・Attribute (アトリビュート) パネル
COREオブジェクトの数値やアトリビュートデータを管理し、ツールオプションを設定する際など
に使用されます。これによりUIの混乱は最小限に抑えられます。COREのAttributeパネルの
コンテンツは、オブジェクトや選択されているツールに依存して変わります。
・Snapping (スナップ)
Point Snap (ポイントスナップ)/Edge Snap (エッジスナップ)/Face Snap (面スナップ)/
Grid Snap (グリッドスナップ)/Angle Snap (角度スナップ)
・SDK へのフルアクセス
SDKは完全にオープンにされており、COREへのフルアクセスが可能です。
基本的にCOREテクノロジ開発に使用されるのと同じSDKとなります。
COREは製品出荷時と同じSDKで開発されているため、サードパーティ製品の開発者はCORE
開発チームがCOREテクノロジで行っていることと全く同じことが行えます。独自のレンダリング
エンジンやツールセットを追加する場合も、他のベンダーは何も制限されることはありません。
COREは標準機能であろうとサードパーティ製開発製品であろうと、全てを同等に扱います。
・ワ－クスペース
Model (モデル)/Surface (サーフェイス)/ Setup (セットアップ)/ Animate (アニメート)/
Render (レンダー)/Composite (コンポジット)
・各種ウィンドウのドッキング(Qt)
0 件のコメント:
コメントを投稿