Metasequoia BBS

[7169] ウェイトについて / 七司

Done [Question] Response

メタセコイアVer4.5.9(64bit)を使っています。
ウェイトについてなのですが、ウェイトの数値を10など低い数値にしても、数値を100にした時のようにボーンに付いて動きます。
どのようにすればあまり動かない様になりますか？

2017-08-15 08:40

Show the middle 1 messages.

[7172] Re: ウェイトについて / 七司

Response

わかりました。ありがとうございます。

2017-08-16 18:11

[7167] ver4に関して / とり

[Question] Response

メタセコイヤver4に関して。
ｏｂｊｅｃｔ名やｍａｔｅｒｉａｌ名設定時[_]の表示がされないのが気になりますが、これはプログラム上の仕様で今後修正の予定は無いのでしょうか。
現状でも見えていないだけで　テキストなどにコピー・ペーストした際に存在はしているので大した問題ではないですが。可能であれば。

2017-08-13 13:38

[7170] Re: ver4に関して / Administrator

Response

アンダーバーも普通に表示されるはずですが、環境設定でフォントをデフォルト（メイリオまたはMS Pゴシック）以外を指定していたりということはありませんか？

2017-08-16 10:20

[7008] MQDrawPolygon / tamachan

[Announce] Response

https://github.com/devil-tamachan/MQDrawPolygon
SAI/AzPainter2などで描いた形をポリゴン化するメタセコイア４用プラグイン

2017-05-06 23:31

Show the middle 1 messages.

[7168] Re: MQDrawPolygon / tamachan

Response

・面に貼ったテクスチャを変換するモード追加
・立体テクスチャ機能追加（メタセコイア標準機能と紛らわしいですが別機能）
　立体テクスチャ機能のサンプル: https://sketchfab.com/models/4fba4b3fafb443479340ae8cfa9b1942

2017-08-14 23:34

[7162] ウエイト情報の消失 / かたつむり

Done [Bug report,ウエイト　スキニング] Response

お世話になります。

メタセコイアv4.5.9 32bitでMMDモデルの作成中ですが、作業中になんらかの理由で設定済みのウェイト情報が消失する現象に悩んでおります。

もっとも最近ではPMD出力を終え、そちらでスキニングに問題の無かったモデルでこの現象を確認しており、mqo側は最後に調整した一部のオブジェクトのものを除いてウエイト情報が完全に消失していますが、同モデルから出力されたpmdモデルではモデル全体に問題なくウエイトが反映されています。

また、作成中モデルのバージョンを遡って確認したところ、直前のモデルでは、ウエイトのペイントモードでは画面上ではスキンにボーンカラーが乗った状態で表示されるものの、実際に各頂点をチェックしてもウエイト値が確認できず、スキニングモードでのボーンタブでポージングを行っても、ポーズが反映されないデータも存在していることが分かりました。

数日前も同様の現象があり、この時は私の操作ミスなどを疑い、また作業量的にも問題の無いレベルだったため、バージョンを遡ったモデルから作業をやり直しましたが、今回同様の現象が発生し、かつ作業量的にもやり直しは難しいと感じたため報告させていただきました。

現時点では私の作業手順や操作に関する問題などの可能性も否定できませんが、上述のボーンカラーが塗られながらも変形しないスキンメッシュのモデルの存在を確認するに至り、ソフトウェア側の不具合の可能性もチェックして頂きたく存じます。

この問題の回避方法、また私の理解不足や誤操作の可能性、さらには破損したと思われるモデルデータの復旧方法などがありましたら、ご教授いただけますと幸いです。

2017-08-09 11:45

Show the middle 1 messages.

[7166] Re: ウエイト情報の消失 / かたつむり

Response

>こちらはウェイトがない（少なくともそう見える）状態でpmdに出力するとウェイトが付いているというころでしょうか？

どのタイミングでウェイト情報が完全に消失したのかは分からないのですが、作業の流れとしてはpmd出力直後にmqoで保存したように記憶しています。出力されたpmdは問題なし、保存されたmqoはウェイト消失状態となっていました。

>文章だけでは原因・可能性を挙げることしかできないので、実際にデータを確認してみたいのですが、mqo/mqxファイルのセットをいただくことは可能でしょうか？もしできるのでしたら弊社サポートまでメールでお送りいただければ幸いです。
はい、では後ほどサポートにメールさせていただきますのでよろしくお願いいたします。

2017-08-10 14:42

[7164] Autodesk / たけし

[Talk] Response

AutodeskがCG関連会社をいくつか買収してますよね。
Metasequoiaは3ds maxと結びつきが強いので、tetrafaceを100億円で買収なんて話は持ちかけられてませんか？

2017-08-10 06:50

[7160] コマンドパネルのスクロール / TK

Done [Question] Response

お世話になります。ご質問なのですが、
左メニュー(コマンドパネル)をスクロールさせるとパネルがカクカク状態でスクロールされます。
アクティビティモニタで確認したところ、CPU使用率が90%くらいまで上がっていました。
やはりマシンのパワー不足でしょうか？

動作環境
Metasequoia Ver 4.5.9
Mac mini(Late 2012)
CPU:Core i-7/メモリ 16GB
Intel HD Graphics 4000 HD (1536MB)
macOS Sierra 10.12.6

2017-08-08 23:21

Show the middle 1 messages.

[7163] Re: コマンドパネルのスクロール / TK

Response

>若干古いMacということもあるとは思いますが、新しくて性能のいいMacを使ってもそれなりにカクカクはします。

ご回答ありがとうございました。

2017-08-09 13:00

[7114] 4.6β不具合、要望 / まじかる☆しげぽん

[Bug report,Ver4.6.0beta] Response

・MQOファイルをダブルクリックで開けない。
32、64bitともMQOファイルをダブルクリックで開こうとしてもメタセコが立ち上がりますがMQOファイルが読み込まれません。

・法線の平均化がオブジェクトが分かれてると動作しない。
同一オブジェクト内で切断されている部分は平均化できますが、オブジェクトが別オブジェクトになっていると平均化できません。
顔のパーツなどオブジェクトを分けた状態で平均化するのは普通に行うことなので、別オブジェクトでも平均化できるようにしてほしいです。
別オブジェクト間でのその他の処理はまだ未検証です。

とりあえず、2点ほどになります。

Metasequoia 4 Ver4.6 Beta1 (32bit) is running.
Windows version : 10.0  Build:15063  (x86)

Number of CPU : 8
Physical memory : 16351 MB
Direct3D11 Driver: NVIDIA GeForce GTX 970
    DeviceID: 5058
    SubsysID: 913904728
    Revision: 161
    FeatureLevel: 11.0

2017-07-24 22:07

[7115] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

MQOがダブルクリックで開けないのは、環境設定で関連付けを再設定しても読み込めません。
メタセコのショートカットにD&Dしても読み込んでいないので、引数のファイルパスを読み込んでないように感じます。
一度、メタセコを立ち上げた後にウィンドウにD&Dした場合は開けます。

2017-07-24 22:13

[7116] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

別のPCでも試してみましたが、同じくMQOファイルを関連付けしてる状態でダブルクリックしてもメタセコが起動するだけでファイルが読み込まれませんでした。

Metasequoia 4 Ver4.6 Beta1 (32bit) is running.
Windows version : 10.0  Build:15063  (x86)
Number of CPU : 8
Physical memory : 16333 MB
Direct3D11 Driver: NVIDIA GeForce GTX 670
    DeviceID: 4489
    SubsysID: 2216300611
    Revision: 161
    FeatureLevel: 11.0

2017-07-24 22:19

[7117] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

・メッシュの再構成が対称に対応していない、対称化機能がほしい

メッシュの再構成を実行すると、「対称」編集をオンにしていても左右非対称のオブジェクトが生成されます。
「対称」編集ボタンがオンだったら左右対称のオブジェクトを生成、もしくはメッシュの再構成に対称機能が欲しいです。
また、対称がオンになっていなくても基本的に左右のトポロジーが同一な部分は対称になるようなアルゴリズムにしてほしいです。
対称をオンにしないケースは、右腕から先は非対称だけど体の中心部分は対称というような状態のモデルです。

2017-07-24 22:28

[7118] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

・メッシュの再構成で元メッシュの流れを考慮、ディティールが細かい部分に対してポリゴンを配分するオプションを追加してほしい

現在の状態だと、左右対称のモデルでも左右非対称にリトポロジーされてしまうためなんとなく流れに沿ってる感じもするのですが、下記のリトポロジーモデルのように元メッシュのトポロジーの流れを再構成に反映してほしいです。
http://imgur.com/yq21vbT

また、現状全体同じ解像度感で再構成されますがディティールの細かい部分にポリゴンを割いて、平たんな部分の分割を抑えるというようなオプションが欲しいです。
現状ポリゴン数を下げると全体的に低解像度になってしまうので、必要な部分のディティールが消えすぎてしまいます。
このオプションを実装する場合、どのぐらい細かい部分のディティールを維持するか～％みたいに指定できる形が望ましいです。
http://imgur.com/1D4Hph2

メッシュの再構成は、結構いい感じにリトポロジーできてるので上記のように調整できるようになればだいぶ良さそうです。

対応ご検討よろしくお願いします。

2017-07-24 22:53

[7119] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

■メッシュの再構成関連
http://imgur.com/a/wkTV1
・末端の形状を維持してほしい
スカートのような板ポリ上のオブジェクトで末端の形状が維持されず添付画像のようにガタガタになってしまいます。
基本的に末端の形状は維持するアルゴリズムにしてほしいです。

・菱形状に交わるようなリトポロジーにならないように
左右対称、流れに沿うというに対応されたら改善される点かもしれませんが、スカートの腰部分に集約する場所で全体の解像度を維持して形状を作ろうとするためこのような部分が菱形で交わるように集約しています。
基本的にこういう処理にならないような再構築アルゴリズムにしてほしいです。

・多角形を生成しない
基本的に再構築したメッシュはNゴンを使用しないで三角もしくは4角形で構築されるようにしてほしいです。
リトポ後のメッシュを活用するケースを考えてもNゴンはZBrushやゲーム上で基本的に使用できないので4角形以下で構築するようにしてほしいです。

・途中から列を増やさないオプション
現状途中から三角形を挟み列を増やすような再構成になってますが、これにより多角形や上の部分まで同じ解像感の四角形で構築されて行き場がなくなったメッシュが菱形上に交わるというようになっているように感じます。
形状的に狭まってる部分は細長い四角になって下から上まで流れがちゃんと作られている形状の方が扱いやすいです。
そのため、すべて4角形で構成して途中で列を増やさにアルゴリズムが欲しいです。

2017-07-24 23:30

[7120] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

http://imgur.com/a/6RvW0
例えば、スカート状のような集約していくような形状はこのように上にいくにしたがって細長い4角形で形成される感じです。

ZBrushなどでは、adaptiveという設定値を低くすればなるべく正方形に近く値を上げれば長方形の形状を許容しディティールを再現するようになっています。

※補足
一つ上のレスでNゴン、多角形と言っているのは5角形以上の多角形のことです。

2017-07-24 23:46

[7121] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

・グループ間のサイズ調整を行ってもうまく反映されていない箇所がある
UV操作にあらに追加されたグループ間のサイズ調整というのは、UVグループをメッシュの面積を元にサイズ調整する機能だと思われるのですが、一部は確かに比率があってるのですがメッシュに対して逆に面積が小さくなってしまう場所もあるようです。
http://imgur.com/a/Glldy

こちらは、内製プラグインによるUVサイズの平均化と比べた画像ですがVer4.6の「グループ間のサイズ調整」を実行すると服、胴体、靴の比率は合いましたが腕、足はメッシュに対してUVが小さくなってしまっています。
3段目は内製プラグインによってUVサイズを平均化した状態です。
メッシュの面積を元にUVのサイズを平均化する処理を行ってもらっています。
こちらの方だと、全体が綺麗に平均化された状態です。

Ver4.6betaで実装されている方も一部は均一化されているためアルゴリズムに何かしらの問題があると思われます。
全体が綺麗にサイズ調整されるように修正していただければと思います。

2017-07-25 00:29

[7122] Re: 4.6β不具合、要望 / mqouser

Response

> [モーフ]にベースの形状の変更をターゲットに自動反映させる設定[形状変更の自動反映]が追加されました。
この機能ですが、頂点の座標のみを変更した場合には反映されないのでかなり機能が限定されていて使いづらく感じました。
現状の仕様はモーフによる移動と形状の変更をどう判定するのかという問題があるためであると思います。
そこで例えば変更を加える元となるオブジェクトとしてターゲットオブジェクト、これを複製して変更を加えたアフターオブジェクトを作成して、
この二つのオブジェクトの差分をモーフオブジェクトに反映させるような仕様で実現できるのではと考えます。

2017-07-25 00:44

[7123] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

・プレビューの対象面のチェックが記憶されない
プレビューに追加された対称面のチェックの状態が記憶されません。
チェックをオフにしてメタセコを終了しても次回起動時にオンになったままになります。

2017-07-25 00:49

[7124] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

・32bit版でブーリアンでボクセルベースアルゴリズムを使うと現状100％落ちる
単純な球体とキューブのオブジェクトをボクセルベースアルゴリズムで解像度128で実行してみましたがおそらくメモリ不足で現状ほぼ100％落ちます。
64bit版ではなんとか完了するようです。
開発環境では、32bit版でも正常に動作してるのでしょうか？
もし、ほとんどの環境でメモリ不足などで落ちるなら32bit版からはオミットしたい方がよいように思います。
何回か実行しましたが同様にクラッシュして同じようなエラーログが残っています。

Metasequoia 4 Ver4.6 Beta1 (32bit) is running.
Build time: Jul 24 2017 09:56:29
Windows version : 10.0  Build:15063  (x86)
Number of CPU : 8
Physical memory : 16351 MB
Direct3D11 Driver: NVIDIA GeForce GTX 970
    DeviceID: 5058
    SubsysID: 913904728
    Revision: 161
    FeatureLevel: 11.0

Exception code: c0000005 (EXCEPTION_ACCESS_VIOLATION)
Access violation at address 0562A300. Read of address FFFFFFFF.

2017-07-25 01:44

[7125] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

・マッピングの再配置でUVの切れ目に白いピクセルが描画される
http://imgur.com/a/UUaDh
マッピングの再配置を行うと、UVピッタリに切り取って配置され淵に白い縁取りが発生しています。
UVはピッタリ切り取りするとこのようになるため基本的に数ピクセル余白を取ってテクスチャを作成します。
再マッピング後の状態は一応余白を取ってるように見えますがこの白いピクセルは意図した状態でしょうか？
正しい処理としては、UVの際のピクセルを余白のスペース分拡張したテクスチャを生成すべきです。
https://www.youtube.com/watch?v=fa9ki3MBzsY
こちらのxNomalのDilationの処理を見ると分かりやすいです。

また、透明にアルファテクスチャが当たっているとこの白い縁取りが透明に抜かれた状態になります。

・同一座標に重なってるUVをバラさないでほしい
上記画像を見てもらえると分かると思いますが、手や足など左右で対称のパーツ、またボタンなど同一なものなどはUVを重ねて展開してテクスチャを描いています。
今回、マッピングの再配置を対応していただいたのは素晴らしいのですが現状のUV再配置ですと中央の頂点が共有されている折りたたまれたUVでないと同一座標に重ねているUVはバラバラになってしまうため、不必要に同じテクスチャがバラバラに配置されテクスチャ解像度が落ちてしまいます。

これを、同一座標のUVはバラさないでそのまま元の状態のように重なったまま再配置するようにしてほしいです。
これは以前からも要望として挙げているのですが、これが対応されないためにその部分を削除しておいたりパーツを分けて置いたり結構面倒なことをやっているためオプションとして実装してほしいです。

なにとぞ対応ご検討よろしくお願いします。

2017-07-25 02:48

[7137] Re: 4.6β不具合、要望 / Administrator

Response

Beta2で
>・MQOファイルをダブルクリックで開けない。
>・プレビューの対象面のチェックが記憶されない
>・32bit版でブーリアンでボクセルベースアルゴリズムを使うと現状100％落ちる
>・マッピングの再配置でUVの切れ目に白いピクセルが描画される
の不具合を修正しています。

他は仕様であり、変更予定はありませんが、
> ・グループ間のサイズ調整を行ってもうまく反映されていない箇所がある
については調整の基準となるのが境界の辺の長さです。歪みの少ないオブジェクトでは面積を基準したものとほぼ違いがありませんが、長さ基準のほうが歪みが大きい場合でも境界付近でのテクセルサイズがほぼ変わらないといったメリットがあるのでこちらを採用しています。
（最終的にどっちがいいかはケースバイケースだとは思います）

2017-08-01 16:08

[7138] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

迅速な不具合対応ありがとうございます！

>他は仕様であり、変更予定はありませんが

こちらですが、ここに挙げている不具合以外の要望は実際アーティストが使ってみて対応されてないと実用するには難しいと感じた点の要望になります。
現状、ベータ版とのことでとりあえず実装してみた感が強いので引き続き対応検討頂きたいです。
せっかくいい感じの機能を実装されていってるので、仕様で片づけてしまうと現状ちょっとどれも中途半端すぎます。

＞グループの再調整は境界線を基準にしてる
こちらも同様に、アーティストが実際使ってみて実用上オブジェクトの面積の基準にまず全体が均一になるというのが重要です。
境界線のテクセルが合っていても、解像度が違いすぎた場合結局その部分を拡大しないといけません。

また、境界の辺の長さを基準にしてしまうと展開時のUVの変形状態に依存してしまうので、辺の長さが平均化されてなかったりするとよりこれらの問題が顕著になってくると思います。

なので、アーティスト視点から見たらまずは全体の解像度を均一化してほしいのでオブジェクトの面積ベースで平均化してほしいです。

2017-08-01 16:54

[7140] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

>グループの再調整について
こちら、テクセルサイズが一致している場合を重視している場合と全体を平均化させたいケース（実際にモデルを制作していたら分かりますがほとんどの場合はこちらの機能を望まれていると思います）があると思うので、アルゴリズムを選択できる形が望ましいかなと思います。

・グループの再調整のオプションでアルゴリズムを指定できるように
境界辺の長さを基準
オブジェクトの面積を基準

2017-08-01 17:52

[7141] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

各不具合修正点を確認致しました。

>・MQOファイルをダブルクリックで開けない。
ダブルクリックで開けるようになっているのを確認しました。

>・プレビューの対象面のチェックが記憶されない
対称面のチェックが記憶されているのを確認しました。

>・マッピングの再配置でUVの切れ目に白いピクセルが描画される
白いピクセルが描画されてないのを確認できましたが、下記の画像のようにUVギリギリで画像が生成されているので今度は、黒い背景色がUVの切れ目に表示しされてしまいます。
http://imgur.com/a/sKfPl

その為、下記の画像のようにマップの再配置を行った場合UVの端のピクセルを拡張していき、他のUVの拡張されたピクセルと交わるまで拡張してほしいです。
http://imgur.com/a/DLFb4

上記テクスチャは、Flaming PearというサイトのSolidifyというPhotoshopのプラグインで縁のピクセルを拡張しています。
https://www.youtube.com/watch?v=r9l8RfTvqyI

このプラグインがいつ配布停止されるか分かりませんし、マップ再配置の処理として上記の処理を行って問題を解決してほしいです。

2017-08-02 03:44

[7142] Re: 4.6β不具合、要望 / Administrator

Response

>>・32bit版でブーリアンでボクセルベースアルゴリズムを使うと現状100％落ちる
>いきなり落ちることは無くなりましたが、やはり32bit版ではメモリ不足になるのか98％あたりまで進んでクラッシュしました。

制限をつけ忘れていましたが、ボクセロイドと同様に32bit版では256が解像度の上限となります。
メモリ不足によるクラッシュについては対策を検討中ですが、実用面から言うと実質64bit専用機能といって差し支えないと思っております。

2017-08-02 12:39

Show the middle 16 messages.

[7159] Re: 4.6β不具合、要望 / まじかる☆しげぽん

Response

・Matcap表示時のテクスチャを重ねて表示する処理は残してほしい

>Matcap表示時にはテクスチャを重ねずに表示されるようになりました。

とありますが、Matcapを表示した際にテクスチャを重ねて確認する場合もあります。
そのため、Matcapをオンにした場合にビューポートの表示のテクスチャの表示状態を記憶しておいてほしいです。

例
１．通常表示でビューポートの表示＞テクスチャをオンにした状態にしておく
２．Matcapモードをオンにして、表示＞テクスチャをオフにする
３．Matcapモードをオフにする。表示＞テクスチャがオンに戻る。
４．もう一度Matcapモードをオンにする。Matcapモード時の表示設定が記憶されていて表示＞テクスチャがオフになる。

こういう感じです。
これなら、Matcapモードでテクスチャ表示を重ねて確認したい時もあるけどMatcapモードをオンにした時に、テクスチャをオフの状態ですぐ確認できると思います。

2017-08-08 16:49

[7149] 開くフォルダを現在開いているファイルのフォルダにしてほしい / まじかる☆しげぽん

[Request] Response

ファイル＞開くで参照するフォルダを現在開いているファイルのフォルダを参照してほしいです。

現状、前回に保存を行ったフォルダを参照するようになっておりメタセコを立ち上げてファイルを読み込んでも、そのファイルを保存しない限り以前に保存したファイルの場所が参照されるのでとても使いづらいです。

【例】
１．「D:\Data\ProjectA\model.mqo」というファイルを保存する
２．開くでファイルを開くときに、「D:\Data\ProjectA\」が参照される
３．「D:\Data\ProjectB\model.mqo」というファイルを開く
４．同じフォルダに入ってる別のmqoを開こうと「開く」を実行すると
　　前回別のファイルの保存フォルダの「D:\Data\ProjectA\」が参照される

というように、すでに作業が終えた場所を参照されるので毎回パスをコピーしたりして今開いてるファイルの場所を指定しなおさないといけなかったりしてかなり面倒です。
これを現状開いてるファイルのフォルダを参照するようにすればそのような煩わしいことは不要のはずです。

対応宜しくお願いいたします。

2017-08-03 19:05

Show the middle 1 messages.

[7151] Re: 開くフォルダを現在開いているファイルのフォルダにしてほしい / まじかる☆しげぽん

Response

さらに検証したところ、「上書き保存」では開くで参照先が変わらず「名前を付けて保存」された場合のみしか開くの参照先が更新されないようです。
なんかいつまでも古いファイル作業したときの場所参照しているなと思ったら上記のようでした。

2017-08-03 22:07

[7146] サンプルのpyファイルの解説記事 / たけし

Done [Question] Response

Metasequoiaに最初から入っているサンプルのpyファイルを、僕が書く記事で解説してもOKでしょうか？

2017-08-03 11:30

Show the middle 1 messages.

[7148] Re: サンプルのpyファイルの解説記事 / たけし

Response

わかりました。
ありがとうございます。

>記事を書くこと自体は構わないですが、内容が間違ったものを掲載されるのはさすがに困りますので、原稿ができた時点で一度弊社サポートへ問い合わせいただけると幸いです。

2017-08-03 15:39

[7143] オブジェクトのトランスフォーム / たけし

Done [Question] Response

例えば以下の様なmqoファイルがあるとします。

Object "obj1" {
    depth 0
    folding 0
    scale 1 1 1
    rotation 0 0 0
    translation 0 0 0
    visible 15
    locking 0
    shading 1
    facet 59.5
    color 0.898 0.498 0.698
    color_type 0
    vertex 3 {
        -28.188351 72.524345 -32.074852
        -100.08739 26.023481 40.436657
        66.125122 0.000060648 -38.177235
    }
    face 1 {

2017-08-03 09:38

Show the middle 1 messages.

[7145] Re: オブジェクトのトランスフォーム / たけし

Response

わかりました。

>一般的な3DCGソフトと異なり、頂点座標はすべてグローバル空間で管理され、その操作もすべてグローバル座標上で行われます（そもそもローカル座標の概念自体が後付け）。
>そのため、ローカル座標のSRTを変更しても基点の位置しか変わらないので、SRTの変更と同時に頂点座標も更新する必要があります。

2017-08-03 11:15