遅くなりましたが、去年(11/12/2018)書いた記事の続きです。
今回、焦点とするのはv11.5の時に実装されたモデラー側の新ツールアーキテクチャと、そのアーキテクチャ上で作られた幾つかの新モデリングツールです（マニュアルではこの新ツールアーキテクチャをSyncmeshと呼んでいます）。このSyncmeshは新モデリングツールを支える重要な改革だったはずですが、実装された設計思想は個人的に多くの点で疑問のあるものでした。今回はこのSyncmeshとSyncmesh上で作られた幾つかのツール仕様を考察してみたいと思います。多分長くなりそうなので何回かに別けて追記することになります。
Syncmeshとは何か？Syncmeshそのものはモデリングツールではなくて、モデリングツールを設計するする為の土台のようなもので、この土台(Syncmesh)で作られた新ツールには以下のようなものがあります。
Line Pen, Align, Axis Translate,Tweak, Axis Rotate, Heat Shrink, Axis Scale, Transform, Chamfer, Thicken, Place Mesh, Slice, Straighten, Edit Edges, Pick Surface
ｖ6.0以降、LWのモデラーツールは良くも悪くも長年その仕様の根幹は変更されませんでした。ですが、ついにv11.5の時にモデリングツールに新しい仕様として実装されたのがこのSyncmeshです。Syncmeshはツールへの対話性の向上とより迅速なツール開発を目的として実装されていて、Syncmeshを用いて作られたツールは従来のツールとは機能的にも内部構造的にも区別されているので、従来のツールでSyncmeshの機能を活用することは出来ません。つまりSyncmeshは従来のツールシステムとは互換性の無い独立したシステムと言えます。Syncmeshでは幾つかの新しい機能をサポートしていますが、個人的にこの中で疑問のある仕様（機能）を取り上げてみます。

1）Syncmeshのスナップ機能

・ポリゴン背面側にあるコンポーネントに対してはスナップが出来ない仕様です。個人的には背面側へのスナップの有効/無効を切り替えるスイッチが必要だと思います。特にそう感じる場面はワイヤーフレーム表示の平面ビュー内でポリゴン背面側にあるコンポーネントへスナップさせたい時です。

ポリゴン背面側のジオメトリにはスナップ出来ない

・異なるオブジェクトファイル同士（マルチドキュメント）ではスナップ出来ません。

・Center（中央）スナップ機能の仕様（性能）が良くない。

左図はセンターを見つける為にポリゴン中央付近をマウスで探してます（笑。図のような拡大表示の時や複雑なN-Gon形状の時では中央の目ぼしが付き難くくなります。例えば右図のようにマウスカーソル位置が中央から大きく外れていたとしても、ポリゴン内にマウスカーソルがあれば強制的にスナップマークが中央へ移動（スナップ）する仕様でなければいけないと思います。

・スナップボタン(HUD)の仕様も余り良く無いと思っています。

左図が既存のスナップボタンです。右図が考案したスナップボタンです。右図一番上の[Snap]ボタンは以下のボタン種の選択/非選択の状態を保持したままスナップ全体のON/OFFを切り変える為にあります。その下のCenterボタンは頂点、エッジ、ポリゴン、スプラインボタンの中央スナップの有効/無効を制御します。又、このCenterスナップが有効の時は、左図にあるオブジェクトスナップとセレクションスナップボタンの機能が自動的に有効になることを想定している（ビューにそれらのスナップマークが表示される）ので、左図にあるそれらボタンは右図では全て削除しています。又右図ではスプラインとグリッドスナップボタンを追加してます。左図と右図のボタン数は同じですが、機能は増えていてアイコンもより解り易いと思います。（Gridボタンに関してはビューのスケールでグリッドサイズを自動更新する既存モデラーのグリッド仕様を見直すことを前提としてます）

追記(6/1)
SyncmeshにはLWのモデリングツールの将来を背負ってます（笑。故に、Syncmeshで作られたツールは全ての点に於いて過去ツールよりも数段上の性能（ツールフロー）を提供しなければその存在意義は無いとさえ思っています。以下ではSyncmeshで作られた幾つかのツールに対して個人的に思う疑問点を取り上げ、合わせて提案もしてみます。

・Axis Translate / Axis Rotate / Axis Scale
これらAxis系ツールは同時期に実装されたので、ツール同士のフロー（操作性）は論理的な整合性を伴なっているはずだ。と個人的には思う訳です（ツール名称からも類似仕様がイメージ出来ますし）。しかし実際にはそれぞれのフローに共通性は無く、目先の手数を減らす事を重視したフローのように見えます（あくまで個人的見解ですが）。なので本来あるべき機能性の部分が損なわれてしまっているように思えるのです。。では、この疑問点を下図で解説して行きます。

図はAxis Translateツールの実行手順を表しています。
図左列はワールド軸拘束の移動。図中央列は任意軸の移動手順を示します。
Axis Translateツールはその名の通り、軸を基準とした移動編集ツールです。ですので図左列のように、軸を指定→軸拘束で移動量を決定。という手順はこのツールの目的（趣旨）に適合しています。一方、任意軸に対する移動編集（図中央列）の手順に関しては、軸の始点を設定→軸の終点を設定（移動）と言った、先程の手順とは異なります。これは軸を決める操作と言うよりも、移動元の始点と移動先の終点を決める操作。と言う方がしっくりくるかもしれません。つまり、軸の設定を活用していない編集性です。このような操作性は昔からあるスナップドラッグツールのようにダイレクト移動ツールとして実装すべきで、Axis Translateのように軸要素を編集基準としたツールに実装すべき操作性では無いように思います。結論を言うと、任意軸拘束の移動（図中央列）はワールド軸拘束の移動（図左列）と同じ手順のフローにしなければいけないと思うのです。つまり図右列（考案）のような行程（手数）が必要です。そうすれば下図のような任意軸での編集が可能になります。又、Step2で操作が一区切りする（軸指定が完了する）事で、ビューからマウスを外して数値入力パネルの操作が容易になります（ちなみに現在の仕様だと、Altキーを押しながらマウスカーソルをビューから数値入力パネルへと移動させるへなちょこ仕様です。又、数値入力するとビュー上のガイドは消えてしまいますし、入力制御は軸の始点終点のワールド座標値のみなので、まず殆ど役に立たない数値制御になっていると思います）。
下図の任意軸に対する移動は、既存のAxis Translateツールの通常フロー（仕様）では実行不可能な編集内容です。編集の目的がツール名称（Axis Translate: 軸指定の移動）に合致しているにも拘わらず、そのツールでは編集することが出来ない。ってなると、モデリングフロー（ツール選択）に於いても混乱を生じることになるので、整合性のある仕様にして欲しいものです。

上図考案仕様であれば、下図のような移動スナップ(Axis Translate)が可能になります。

Axis Translateで他に見直すべき機能。
・移動量（数値）のOGL上の表示と同値の数値入力パネル表示
　（他のAxis RotateやAxis Scaleツールではこれら数値表示/入力がある為）
・移動軸の数値入力パネルでの表示/制御と、軸変更を可能とする各軸のボタン。
・編集中のキャンセル機能。

次はAxis Rotate (Axis Scale)ツールです。上図Axis Translateツールでは軸指定にスナップが利用出来、更に移動量の指定にもスナップが利用出来ました。つまり、Axis Translateではツール編集全般に於いてスナップの利用が可能になっています。一方、Axis Rotate（やAxis Scale)ツールでは軸指定にスナップは利用出来ますが、回転量（やスケール量）に対してはスナップが利用出来ません。これらツールはAxis系の類似ツールで且つ同時期の実装でありながらスナップ運用（機能）の整合性が取れていません。。
下図右列（考案）のように回転量に対してもスナップが利用出来る仕様にしなければ、Axis Translateツールとのツールフローや機能性に差異が生じます。

Axis Rotateツールの法線拘束(Shift+クリック）では法線がコンポーネント(ポリゴンやエッジ）中心に固定されています。つまり法線拘束(Shift+クリック）では回転軸を任意の位置に指定することが出来ません。と言いますか、このような軸（法線含む）拘束の機能はTransformツール側の編集性と被る機能なので、本来あるべき実装とすれば、これらAxis系ツールはTransformツール側の軸拘束機能としてTransformツールへ統合すべき機能のような気がします。そうすれば、Transfromツールのマニュピレータ＝軸拘束なので、機能性も合致しますし、余計なツールを増やさずにも済みますし、Transformツールの利用価値も上がります。

他にSyncmeshで作られたツールで、個人的に特に酷い仕様（性能）だと思っている、幾つかのツールをピックアップしてみます。

・Slice
ポリゴンを任意位置でカットするツールです。
実はSliceが実装される以前からAdd EdgesというSliceの機能に類似するツールが実装されています（元はDSさんのプラグインです）。で、このAdd Edgesはモデラーにエッジの概念（選択）が存在しない時代(v8.X以前）に作られたツールなので、ツール起動中のエッジ指定には独自マーカーをクリックするという操作性になっており、使い勝手が優れているとは言えませんでした。そこで、Add Edgesを置き換えるべく新しく実装されたのがこのSliceツールだと思うのですが、いかんせんその機能性は呆れるぐらいショボくて、Add Edgesを置き換えるだけの機能性が無いツールでした。で結局、今でもAdd Edgeは残したままになっているので類似ツールを増やしたただけ。という、なんともヤルセナイ実装をしてしまっています。で、こんなしょぼい性能であれば当然次のアップデートで見直され、機能拡張されるはずだと思っていたのですが、ご存じの通り"放置"されています。。
では、Sliceの何がショボいかを下図参照下さい。

図左側から説明すると、
a.対称編集モードに対応していないので、対称カットが出来ません。
実はモデラーに昔からある幾つかの対称非対応ツールについてはバージョンアップ都度に修正が行われ、対称編集モードに対応されて来ています。にも拘わらず、このSliceは新規に実装したツールでありながら対称編集モードに対応していません。まさに間抜けな設計です。
b.Syncmeshで作っていながらスナップHUDを実装していません。しかもエッジとポイントスナップを解除出来ないスナップ強制仕様になっている為、本来出来なければいけないカット処理が出来ない欠陥仕様です（別途下図で説明）。
c.ポリゴンフェイス上でカットを刻む（頂点作成）が出来ません。
このSliceの機能目的と類似する他社のほぼ全てのポリゴンカットツールではSliceがモデラーに実装された時期の数年以上前からフェイス上で刻める機能が実装されていました。つまり、他社のそれよりも新規の実装でありながら時代遅れの機能性になっていると言えます。
d.エッジを跨いだ一括カット処理。
これも、他社類似ツールで普通に出来る機能ですが、Sliceは出来ません。

最後に、b項の欠陥仕様を説明します。
b項にも書いた通り、Sliceはエッジと頂点のスナップ機能を外す事は出来ない仕様なので、頂点に限りなく近い位置でカットしようとすると、頂点側にスナップされてしまい、下図左側のような頂点付近の位置でカットする事が出来なくなります。これはカットツールの機能性とすれば欠陥です。根本的にはSliceにスナップHUDを実装すればスッキリ解決することですが、仮にビューの拡大率に対してスナップ範囲が調整される仕様であったなら、欠陥仕様なんて言わずに済んだのですが。。

ま、とにもかくにも何を考えてツール設計したのか意味不明な仕様で、こんな体たらくな新規実装をしているからモデラーは何時までたっても時代遅れを払拭できないのでしょう。数点のツールを取り上げただけで言い過ぎと思われるかもしれませんが、これだけではありませんから。。未だ他にもおかしな仕様のツールがSyncmesで作られています。
モデラーに昔からある古い機能やツールは今後の見直しで検討されれば良いことだと思って緩い目で見れますが、Syncmeshは比較的新しいシステムで謂わばツールシステムの起死回生とも言える進化？です。それがこんな体たらくなツールで量産されると、お先真っ暗って思ってしまう訳です。。なのであえて突っ込んでみました（苦笑。

もう一つだけ取り上げてみます。
・Place Mesh

Place Meshは背景にあるオブジェクト（メッシュ）を前景のジオメトリに配置するツールです。配置時にポリゴンや頂点に強制スナップする仕様ですが、何故かエッジだけスナップ出来ません（苦笑。又、マウスのリアルタイムなガイド操作に対してコンポーネント中心へのスナップ機能もありません。なので根本的に図上段左のようにスナップボタン（HUD)が必要だと思います。
又、ビュー内のマウスドラッグ上下/左右操作でスケールやスピン値の調整が出来る仕様ですが、この仕様だと上下/左右方向にある程度キッチリ分けてドラッグしなければ、意図しないスケールやスピンが適用されてしまいます。クリックで連続配置する場合でもクリック時にマウスが若干動けば、意図せずにスケールやスピンが適用されていたりします。つまりクイックな操作性を求める為にケアレスミスを含む操作性になっていると言えます。これを防ぐには図のようにCtrlキーを押しながら最初にドラッグした方向にパラメータ調整を拘束する仕様であれば、スケールだけ或いはスピンだけと言った個別パラメータの調整が的確に行えるようになります。この操作性を他で例えれば、標準の移動ツールで行うCtrlキーを使った軸拘束と同じような挙動です。ドラッグ途中でマウスがヨタッても目的のパラメータ調整の拘束が外れることはありません。但し、現在の仕様のようにドラッグ操作だけでスケールとスピンを同時に調整することが出来なくなるので、どちらが良い操作性かは一概には言えませんが、只個人的には、わずかな手数削減やわずかな速さを得る為に、ケアレスミスが有りうる操作性にするよりも、確実性を担保出来る操作性の方を重視したいです。
図上段右は、XZ平面に平行で-Y方向に法線があるポリゴンに対しては、法線方向と逆方向つまり図のように+Y方向に配置されてしまいます。仮にこれが仕様であれば、機能としての整合性（法線方向に配置仕様）が取れていないので、おそらくバグではないでしょうか。。
下段図では、[Ignor…]ボタンをONで配置→[Ignor…]ボタンをOFF→アンドゥでやり直そうとするとガイドが動かなくなります（笑。この手順を踏まなくても、ツール起動中にアンドゥを行うとマウスの動きにガイドが適切に追随しないのでバグだと思います。ツール側が保持するデータがアンドゥによるデータ更新に対応出来ていない為ではないかと邪推します。(v2019.0.3)

・Edit Edges
選択エッジに対応していませんし、エッジ追加時の曲率補完オプションもありません。ってか、そもそもEdit Edgesはそのツール名称からどんな編集が出来るツールか皆目分かりませんから、ツールに実装した編集機能をツール名称に出来ていない時点で、ツールの設計思想が既にアウトだと思います。

・Lattice Tool
ローカル軸指定が出来ないとか軸拘束編集が出来ないとかとか。。



＿＿＿＿＿＿＿　以下戯言＿＿＿＿＿＿＿＿＿
Syncmeshのスナップは個々のツールに紐付けされた機能として実装されるので、個々のツールの設計思想によってスナップの運用がバラバラになります（上記でも示したように）。これは言い変えると、ツール設計者の思想やセンス次第で個々のスナップの機能性や運用方法が左右されると言う事です。ですが、これはこれでツール特化型スナップシステムとして有りです。その個々のスナップ仕様を良く精査して実装すれば良いだけのことです。Syncmeshのようにツール機能に紐付けされたスナップシステムを仮にローカルスナップシステムと呼ぶとすれば、個人的にはロカルスナップとは別にグローバルなスナップシステムもLWのモデリングプロセスに必要だと思っています。グローバルなスナップシステムとは、例えば作業中にジオメトリやガイド等の単純な編集（ドラッグ）操作が発生すれば、その時どんなツールを使用していても任意で呼び出せるスナップシステムのことです。他社で言えばメインUI上に常に表示されているスナップボタンのようなものです。又、グローバルなスナップシステムはレイアウト側（アニメーション）のスナップシステムと共有（共通）する仕様でもあるべきです。
既存のSyncmeshシステムは今後の新モデリング環境へ対応した設計になっているとの事ですが、果たしてその進化がどのような姿で形成されて行くのか、少なくとも現状の新ツール群の完成度を引きずっているようであれば、先の見通しが明るくなるとは思えないです。良い方向に舵取りされることを願っています。。