6/08/2018

An Implicit Frictional Contact Solver for Adaptive Cloth Simulation
https://www.youtube.com/watch?v=brzmcVNB12w

Eulerian-on-Lagrangian Cloth Simulation
https://www.youtube.com/watch?v=eF-0wscx5k8

突き抜けない(笑。
_______________________________________

v2018では実質ノードベースのマテリアルになっているので、現在のサーフェイスエディタの有り方が凄く怪しくなっているように思えます(笑。極論言えば、サーフェイスリストを管理してるだけの存在になってしまっているような?。例えばノードエディタ側にサーフェイスリストを組み込み、サーフェイスエディタを無くしてしまえばどうなるか?(笑。遊びがてらに描いてみたのが下図です。左側がv2018オリジナルのサーフェイスエディタで、右側が考案組み込み版です。この状態だと一見、v2018オリジナルと変わり映えしませんが、まずMaterial項目欄の▼ボタンを右クリックすると、図のようにポップアップが開き、Shading Modelへの切り替えが出来る仕様を想定しています。そして、右上の">>"ボタンをクリックすると。。

下図のようにノードエディタが展開します。
左側のサーフェイスリストから該当のノードネットワーク表示へと同パネル上で切り替えが可能になります。左上のNodeタブは既存のノードエディタと同じノードリストを表示することが出来ます。この図の状態であれば、右上の"<<"や"<"ボタン、そして左上の">"ボタンがクリック可能なので、左側の">"ボタンをクリックすれば、そのボタンより左側の領域(リスト欄)全てを隠すことが出来ます。よって、左上の">"と、右上の"<"の両方をクリックすれば。。

下図のようにノードエディタをリスト欄無しのフル画面表示に出来ます。
このフル画面表示では左上のサーフェイスリストが入ってるポップアップボタンが表示されるので、このボタンから任意のサーフェイスのノードネットワークに切り替えることが可能です。

これは悪まで遊びでなのでなんでも有りなのですが、現実にUIを改定するとなると、このようにサーフェイスの専用ノードUIを作ってしまうのは問題あります。その他モーションや変位、ライト等々の他要素のノードエディタと共通する仕様を大前提として考慮しなければ、個々のUIの開発と改定が必要になりますし、ユーザー側もノードエディタへのアクセスフローが統一できなく無くなってしまうので、実際にはこのように一部だけを捉えた短絡的なUIではなく、もっと総合的に深く考察する必要があります。


以下追記。
最初の図では下部コメント欄横にある"S"ボタンがサーフェイス設定に対するコメント入力/表示を表していて、この図の状態だとSボタンは強制表示となりグレーアウトします。で、各矢印の展開/格納ボタンを使って、ノードエディタを展開している時は各ノードを選択すればコメント欄横のボタンが"N"表記へ自動的に切り替わり、ノードに対するコメント入力/表示になります。これは既存のノードエディタのコメント仕様と同じですが、ルートノードであるSurfaceノードを選択している時はサーフェイス設定に対するコメント入力/表示モードへと切り替わる仕様を想定しています。よって、ノードエディタ展開時には"S"と"N"のトグルボタン仕様になっています。
他、検索欄横にある"hide"ボタンはシーンエディタにあるhideボタンと同じ機能で、サーフェイスリストで選択したサーフェイス名をリストから隠すことが出来ます。個人的にサーフェイスエディタに欲しいと思っていた機能なので付けてみました(笑。このhideボタンはリストから任意の複数サーフェイスを直接選択して非表示/表示させることが出来るので、直感的且つ自由度の高い操作性だと思います。
余談になりますが、v2018のサーフェイスリストには検索オプションが付いています。このオプションは、/ , @ , # 等の記号の組み合わせで検索の拡張性を図っていますが、UI上からこれら記号を選択することは出来ず、その記号の説明もUI上では皆目わかりません。こういうコマンドライク操作は好きではありませんが、右クリック又はポップアップボタンから記号の選択や、その記号の解説が目視出来れば良かったのですが。。

マテリアノード以外にもv2018では変位系やライト等でも更にノードベースへの依存度が高くなっています。よって、自由度や機能力は向上していますが、反面、アーティスト向けのユーザビリティ性が置き去りにされているように思えます。個人的にノードベースを突き詰めることは賛成なのですが、個々のノードに対しての扱いや操作性の丁寧なケアは必要だと思います。単にノードを積み上げれば良いという方向性だと、ちょと乱暴で、その繰り返しだけを行えば、LWらしさ(直感的操作や応用性)はどんどん失われて行くように思えます。
例えば、v2018では従来からあるベンド等の変位プラグインを新たに変位ノードとして実装していますが、そのノードをダブルクリックしてアトリビュートパネルを開くと、そこに存在するパラメータはAxisType一つのみです。つまり、この変位ノードで実際オブジェクトを変位させる為にはこの変位ノードの入力アトリビュートへと他の要素のノードの幾つかを接続する必要があります。これは果たしてアーティストライクな仕様(フロー)と言えるでしょうか。例えば、基本パラメータに限ってはアトリビュートパネルからボタン操作だけで完了するような仕様でなければいけないと思うのです。暗にコマンドライク、プログラマブル(安易なノード仕様)に突き進めば、LWである理由はどんどん失われ兼ねないと思うのは自分だけでしょうか。。

_______________________________________

上図はv2018.0.4(体験版)です。
"単一作業画面"に於いて、IKBoosterトラックの0フレーム位置とタイムラインの0フレーム位置にズレがあります。このズレが生まれたのは今から約8年前となるv10の時です。上図黄色枠内にあるミニスライダーとEボタンが新規に追加されて、その新規ボタンの追加スペース分だけタイムライン(0位置)が右に押しやられた結果、IKBTrackとタイムラインのキー位置でギャップが発生したのです。
IKBTrackは複数ビューでの表示も可能である為、タイムラインのキーとIKBTrackのキーは同じ位置である必要はない。というのが、おそらくIKBTrackの仕様だと思います。ですので、8年間もこの状態から変更されないのだと想像します。
しかし実際の作業として、IKBTrackはキーフレーム表示が無いので、どうしてもタイムラインのキー位置を参照して操作することになります。よって、このズレがあると直感的な操作が非常に困難になる訳です。自分は更新止めてる身なので今更報告するのも気が引けてるんですよねぇ。。

0 件のコメント:

コメントを投稿