Px_Bezier 016 更新

バグ修正と少々スペックを縮小しました。

• Extrude モードで Scale 値がオフセットに適用されていなかったバグを修正
• プラグイン終了時にメモリ開放が正しく実行されていなかったバグを修正
• Tube TAB の設定値をリセットするボタンを増設

スペック

• 総ノット（アンカー）数：32
• ノット間セグメント数：384
• Tube の円周セグメントの上限：36
• ポリゴンテンプレートの1ループ頂点数：制限無し
• ポリゴンテンプレートのループ数：制限無し

Px_Bezierのメモリ問題

Px_Bezier は、ツイストでロープ状の形状を作成するために、多量のメモリを必要としています。
これは、起動時に確保します。動的にメモリを確保するプラグインではありません。
これがあだになり、モデラー上に多量のジオメトリがある場合、Px_Bezier はメモリを確保できず、起動できません。

回避方になるか無理な事なのか分かりませんが、モデラーを2つ立ち上げ、1つには扱うジオメトリを置き、もう一つのモデラーでは、Px_Bezier を使用するために必要な最小のジオメトリを一時的に置き作業をし、結果を本体に戻す。なんて事できるかな？？？

動的にメモリを確保するプラグインに改造するには、ほとんどを書き換える事になるかもしれませんので、早急には無理です。
Px_Bezier で扱える節点数とそのセグメント数を少なくしたバージョンを作る事にしましたが、他に回避法があればお知らせ頂けると助かります。
（64ビットでと言うのは、なしでね）

Steve さん、情報ありがとうございます。

Px_PeDrag （Px_Saw バンドル）

Point Edge Drag ? Modeler tool [ 8.5-] win32/macUB32

Px_Saw ユーザーは、Px_Saw のダウンロードページからプラグインをダウンロードしてください。
このプラグインは、Px_Saw のキーコードが必要です。
Vmap は無視されます。

The Px_Saw user must download the plug-in on the download page of Px_Saw.
The key code of Px_Saw is necessary for this plug-in.
The Px_Saw user must download the plug-in on the download page of Px_Saw. The key code of Px_Saw is necessary for this plug-in.
Vmap is disregarded.

DSTORM

のユーザーフォーラムが再開されていたよ。

https://store.dstorm.co.jp/support/forum_b/

モッコリ盛り上がればいいな。

LW Px_Navel 002

PX_Navel 002 modeler [ 8.5- ] command free win32 / MacUB32

近頃始めたサブパッチモデリング（遅っ）。
嫌いなのである、が、ザックリと形付けるには良いんではと。。。

で、サブパッチ前提でポリゴンにおへそをこさえる（翻訳できないだろうな）コマンドプラグインを造ってみた。ツールにとも思ったが、コマンドの方が扱い易い（その他のツールを併用すると言う意味で）と判断し。

インストールすると Px_Navel と Px_Navle_UI が入ります。
UI は、パネルを表示設定するだけのプラグイン。Px_Navel で実行します。

使い方

• 扱えるポリゴンは、全て4頂点ポリゴンの、1ポリゴン、連続した2ポリゴン、固まっている4ポリゴンだけ。
• ポリゴンを選択状態にしてプラグインを実行。
• Size は、センターから最小の距離を100%とした比率（とても曖昧なのだ）
• UVは作りませんよ。
• Px_Navel_UI は、出しっ放しでもいいし閉じてもいい。見たければ Px_Navel_UI をクリック。
• くれぐれもファイル保存して遊びましょう。

8年おばかさん

LW モデラーのツールプラグイン。
8年間知らなかった事が、今日解った。

プラグインには、コマンドタイプとツールタイプがある。
コマンドタイプでは、MeshDataEdit を使用する場合 MeshEditBegin を呼び、MeshEditOp を手に入れその中のファンクションにアクセスする。編集が終われば、MeshEditOp の done を呼んで終了する。
この時、 done に渡すパラメータでジオメトリの選択状態を変更できる。

ツールタイプでは、MeshEditBegin は呼べなく、Build コールバックに MeshEditOp を持って来てくれる。ツールを終了するときは、ツールの done でメモリ開放などの後処理をして終わる。
選択されたジオメトリがあり、新たにジオメトリをツール内で作成すると、新たなジオメトリも選択状態になって終わってしまう。

純正のツールプラグインでは、例えばベベルツールなどでは、最初に選択されたジオメトリのみ選択状態を保っている。
これは、内部用SDK を使用しているための特権なのか、と、ずーっと思っていた。

今日、SDK のドキュメントを眺めていた。MeshDataEdit のページだ。
同じ MeshEditOp を受けとるのだ、ツールでも。。。。！ ！！！

Px_PoLift の更新は近い。連続して行える様になる。ちょっと試してみて OK であった。

進行中の Px_Navel（おへそツール）もコマンドタイプからツールタイプへと、できる望みが湧いて出た。

LW UV_Creeper 006

Px_UV_Creeper 006 [ 8.5- ] modeler free command

パイプ状の4点ポリゴン列に テクスチャUV を設定します。
（パイプではなくても良いんですが・・・）

これはそうとう前に知人に頼まれて途中だった物を全面書き直ししたものなので要注意！
先ほどデモムービーを作成中にLWが落ちたという恐ろしい仕上がり状態です。
そのオブジェクトは、パイプ状なのですが、途中からパイプが裂けている形状です。
通常のチューブ状態や平面では大丈夫です。
しかし、プライマリーレイヤーのジオメトリ情報を読込みますので、必要最小限のオブジェクトにしておく事をお勧めしますよ。

使い方

• 連続する2頂点を選択してプラグインを起動します。
• 第1番目のポイントに立ち第2ポイントを見ている方向が V 方向です。
• 右手方向に U が展開されます。
• 1-2ポイントの連続するポイント（突き当たるまでの前後）とそれらの左右の連続するポイントに UV が充てられます。
• V 方向は 0-100% に展開されます。
• V 方向のそれぞれのポリゴン数は同数が望ましいでしょう。
• U 方向のそれぞれのポリゴン数は同数が望ましいでしょう。
• Keep U-V ratio：V 方向と U 方向の距離の比率を保ちますので、U は必ずしも 100 % まででは有りません。
• Keep U distance：U 方向のポイント間の距離を維持します。
• くれぐれも、オブジェクト保存後に遊んでください。

LW プラグインのスッゴク大事な事

を言っていなかった様な。。。

私のほとんどのプラグインでは、起動時に全ての（FGやBGで必要な）ジオメトリ情報（ポリゴンとポイント）を読込んでいる。なのでFGやBGに大量なジオメトリが有ると、とんでもなく起動時間がかかる。下手すると落ちる。

なので、必要最小限のジオメトリを置く様に（必要ない物は隠したりレイヤーを分けるとか）しないと、イヤになっちゃうよ。自分でも忘れてイヤになっちゃう。。。

Px_PeMove （Px_Saw バンドル）

Point Edge Move ? Modeler tool [ 8.5-] win32/macUB32

Px_Saw ユーザーは、Px_Saw のダウンロードページからプラグインをダウンロードしてください。
このプラグインは、Px_Saw のキーコードが必要です。
Vmap は無視されます。

The Px_Saw user must download the plug-in on the download page of Px_Saw.
The key code of Px_Saw is necessary for this plug-in.
The Px_Saw user must download the plug-in on the download page of Px_Saw. The key code of Px_Saw is necessary for this plug-in.
Vmap is disregarded.

どこへ行く、ベジェ

この間、Px_Bezier を更新し公開した。その後も機能を追加したバージョンがあるがこれは公開していない。
現在、手抜きの仕様なためアンカー数やセグメント数に制限がある。これはメモリを確保する事を最初に固定してしまっているためだ。動的なメモリ確保が面倒なだけで今の仕様が簡単だったからだ。

少々手を入れて来ると、色々な場所で欲が出て来る。
まずはこの問題。次に1本のパスしか扱えない。別のプラグインから簡単にベジェを使えない。

公開していないバージョンは、それなりに使用できるが、ここでこれ以上手を入れてもそれ以上の拡張ができないと判断し、中断。そしてベジェの部分を取り出してライブラリー化を始めた。
汎用にする事。

これまでには、ツールプラグインで必ず必要になる「ハンドル」 ライブラリー。LWSDK のツールにはもちろん「ハンドル」が用意されている、が、役に立たないと思っている。SDK のハンドルを呼ぶと「アップ」が使えない。「アップ」は使いたい。なので「自家製ハンドル」ライブラリーを作った。
「スナップ」これもライブラリー化をしたが、Sp_Move や Sp_Roll が仕上がってからの抽出で苦労した。
当然、全てに於いてメモリ確保を一元管理できる「メモリ管理」ライブラリーも。
マウスポインターがポリゴン内にあるかどうかを判断するライブラリー、これは元気な頃の「MOMO」でアルゴリズムを問い合わせて、それを実現した物だが、、あの頃は良かったな、モモも。懐かしい。
ポリゴングループのエッジを得る物や、メッシュの流れをだけを読む物など、、、。
こういう物は、最初に作ると効率が良いが、途中から抜き出すのは、最初から作るより時間がかかる。
何故なら、欲、欲がどんどん湧いて出て来る。
それは一つの役割をさせる事に、あらゆる方向からのアプローチに応えられる様にとか、もしかしたらこんな事を後々要求するかも、とか。自由度を高めてしまう。その事で似た様なファンクションが増え肥大化する。
時間はいくらあっても、って状態になる。本当に使われるのか？、その時に書き足せばとも思うが、その時には内容を忘れかけていて、解読しながらだろうと想像が付くので今書いておこうと。。。

結局、動的にメモリーを確保しながら、アンカー数・セグメント数を制限しない。また、複数のパスを描ける事。ここでベジェをカスタムポリゴンとして扱えれば、「最高」なのだけれど。。。。
今の私にはそれはできそうもなく、残念だ。

で、ベジェのライブラリーをこさえて、何に使うのか。んんん。:-)