3D技術交流を主目的としてイロイロ書き込む場所

*HOME*TOP*投稿*検索*管理*

基本方針　重要なのは気遣いよりも明確さ。ただし初心者には優しくしないとダメ。
書き込む人の心掛け　打たれ強さが「強」の人には、間違いの指摘、疑問や意見の提示とか、ちょっと辛口でもオッケー。無防備の人には優しく。
読む人の心掛け　あやふやな説明は軽く流し読みしてください。初心者のことは暖かく見守ってください。
投稿用パスワードはmeshiです。スパム対策ですので、時々変更します。左下の「PASS」は任意のモノをどうぞ。右下の方の「投稿用PASS」に指定のモノを入れてください。
CelsViewのMikuMikuDanceデータ入出力機能
まつい  
区分: 説明   打たれ強さ: 強   論拠・確実性: 経験則  
CelsViewでMMDファイルとモーションを読み込み
sio29氏作成のCelsView最新バージョンは、MikuMikuDance用の
キャラクター・モーションデータを取り込んで、別形式で出力できるので
これを試しているところです。
2ヶ月半も遅れてしまいましたが、ようやく手をつけ始めました

■キャラデータ読込
PMDファイル（＝MikuMikuDance形式キャラクター）は、1キャラ目を読み込む分には、特に問題なし。
2ファイル目以降は、高確率でエラー強制終了となります。

■モーション読込
ドラッグでもファイルメニューからでも大丈夫な感じ。ちゃんと動いています。すばらしい。
IKで動かしている下半身については再現されないですが、これは仕様。

■モーション出力
CelsViewで読み込んだモーションを、別形式で出力できるので、試してみました。

　BVH形式：ToyStudioで読み込んだら完全再現されたので、問題なさそう
　VMD形式：保存時にエラー強制終了、確認できず
　MKM形式：最初のキーフレームのポーズが、最後までずっとコピーされているっぽい


まだ検証が不十分なので、再現性とかもう少し追ってみます。
Date: 2011/05/06/00:47:01   No.329


CelsViewについて
sio29  
区分: 説明   打たれ強さ: 強   論拠・確実性: 仕様  
http://sio29.sakura.ne.jp/celsview/celsview_091210.lzh
http://sio29.sakura.ne.jp/celsview/scriptsample.lzh
コマンドラインオプションの代わりにスクリプトに対応しました。
http://muffin.cias.osakafu-u.ac.jp/~matumoto/cgi-bin/xt.cgi?prog/squirrel_lang
スクリプトは組み込みスクリプト「Squirrel」(スクワール)というのを使用しています。
CelsViewに組み込まれた関数については「./help/celsview_script.html」を見てください。
ただし全ての関数についてのドキュメントはまだ出来ていません。
とりあえずキャプチャに関係する部分だけをドキュメント化しました。
スクリプトの実行は「メニュー→ファイル→スクリプトの実行」でmctという拡張子のファイルを指定してください。
mctはテキストファイルで普通のテキストエディタで編集できます。

キャプチャをするにはcaptest.mctの10行目のsrc_filename="〜"の〜の部分を自分モデルファイル名に
11行目のimage_filename="〜"の〜の部分というころを出力したいイメージファイル名を指定してください。
フォルダの指定は「\」ではなく「\\」を指定してください。
連続してキャプチャしたい場合は、14行目の「/*」と25行目の「*/」を削って
同じようにsrc_filenameとimage_filenameを指定していってください。

レンダリングについてですが全てGPU(ハードウェア)で行っています。
遅いのはGPUからCPUに転送が遅いのとキャプチャオプションのアンチエイリアス処理です。
キャプチャオプションのアンチエイリアスと表示オプションのアンチエイリアスは別モノで
前者がCPU(ソフト)、後者がGPU(ハード)で行われます。
GPUのアンチエイリアスだけでいい場合はキャプチャオプションのアンチエイリアスを切ってください。

Mikoto処理についてですが、mkm(モーション)自体の処理はできてますが、
アンカーによる頂点ウェイトの計算が分からないままです。いろいろ試行錯誤をしましたが結局うまく行きませんでした。
Date: 2009/12/10/22:51:25   No.315

Re:CelsViewについて
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
おおおー。すばらしい。
さっそく試してみました。

CelsViewバッチ処理が実装されたとき、WSHのベタベタな処理より3倍速くなりましたが
それと同じ種類の感動があります。
簡単で確実で高速。日本語ファイル名でも大丈夫でした。
いやもう、期待以上の出来映えですよ。

実はここのところずっと、レジストリ直接書替でバッチ処理対象MQOパスや出力画像パスを変更したりとか
野暮ったいことを実験していたんです。
不慣れながらkernel32やuser32を使って、プロセスのハンドルを取得するところまでは行きましたので、
あとはバッチ処理完了がうまくつかめればWSHやVBAから制御できるかな、とか思ったのですが
うまくつかめませんでした。
やむなく「バッチ処理完了後にCelsView終了」ってのだけ、要望を出そうとしていたところです。

本当にありがとうございました。
Date: 2009/12/11/03:55:37   No.316

Re:CelsViewについて
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
アンチエイリアスについて。

ご指摘通り、キャプチャオプションのアンチエイリアスをOFFにしてみました。
GPUアンチエイリアスだけでも十分綺麗だと思います。

GPUのアンチエイリアスだけで実行してみたところ、うちのAthlonX2 2.5GHzでは
256×256サイズのPNG出力が6秒、2000×2000サイズのPNG出力が11秒でした。
概ね画像処理部分が2〜3倍高速になっている感じです。

大きめの画像（2000×2000程度）で出力しておいて動画編集で縮小する方が、
アンチエイリアス強めの中くらいの画像（1000×1000）よりも融通が利くので、
CPUアンチエイリアスはOFFでいこうと思います。
Date: 2009/12/11/04:00:37   No.317

Re:CelsViewについて
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
Mikotoアンカーの頂点ウェイト計算について、自分なりの考えなど。

アンカーBOX範囲内の頂点にウェイトが乗って、アンカーBOX範囲外の頂点にウェイトが乗らなければ
ぶっちゃけた話、細かいウェイト値の誤差があっても構わないと思います。
「仕様です」と説明されれば、使う側は納得してデータを修正するものですし。

たとえば、アンカーBOX重なりの中点から、アンカーBOX最大距離を含む楕円球を作って
「中点からの距離に応じてウェイトを均等割り付けする」とかでも良いと思います。

アンカーBOXの凹んだ部分の処理がうまくいかない仕様ならば、
ユーザーはそれに合わせてデータを修正します。
複数のツールをまたいで作業をする場合、何かと違いは出るものですし、
そのへんはユーザーが努力すべき部分であろうかと。

現状の仕様だと、ごく一部の頂点がとげとげビームになることと、
目玉があさっての方向に向いてしまうことが問題ですが、
それ以外は十分だと思っています。


ちなみにMikotoは、ボーンやアンカーBOXの相対サイズによって
ウェイトの乗り方が変わってしまうのですが、
アレは不便なので踏襲しなくて良いと思います。
Date: 2009/12/11/05:17:06   No.318


[Q]2009年版
tkz  
区分: 質問   打たれ強さ: 普通   論拠・確実性: あやふや  
Mikotoスクリーンショット
まつい様：

初めまして、tkzと申します。いきなりの用件で失礼します。
「2009年版の素体」をMikotoで読み込み、ベースアンカーを移動したら、
"hair1"が悲惨なことになりました。（添付画像を参照）

これは、データの方に原因があるのでしょうか？それとも、Mikotoの
仕様なのでしょうか？ご教示頂ければ、助かります。
お忙しいところ、済みません。宜しくお願い致します。

追伸：
いつも素晴らしいモデル・データを有難うございます。
嘆息しながら眺めています。
Date: 2009/10/16/17:59:23   No.311

Re:[Q]2009年版
まつい  
区分: 回答   打たれ強さ: 強   論拠・確実性: 仕様  
髪の先端が箱からはみ出しています
tkzさま

はじめまして。まついです。

ご指摘、感謝いたします。
また、データを使っていただけて、嬉しく思います。

コレは「ダメなデータを作ったので、Mikotoが仕様通りダメな動きをしてくれた」ものです。
添付画像のように、髪の一部がアンカーBOXからはみ出していたため、
その部分だけ置いてきぼりになっております。

この素体は、何体かのパーツを組み合わせたモノなのですが、
じっくり動作確認をせずにアップしたため、
不具合が残ったままとなってしまいました。


急ぎ、データを修正しましたので、再度ご確認いただけますでしょうか。
　※ファイル名は同じです。
Date: 2009/10/17/00:57:27   No.312

Re:[Q]2009年版
tkz  
区分: 質問   打たれ強さ: 普通   論拠・確実性: あやふや  
まつい様：
tkzです。お世話になっております。

＞再度ご確認いただけますでしょうか
Mikotoでも、ToyStudioでも、完璧に動かせることを確認しました！
お忙しいところ迅速なご対応を頂き、本当に有難うございました。
それでは失礼いたします。
Date: 2009/10/17/01:28:38   No.313


ToyStudioに関する質問と要望　その１０
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
ToyStudio 1.5.0.4が出ていたので、さっそくいじり始めました。
いい感じにバージョンアップしています。

■スムーズスキニング機能の改善
アンカーBOX判定精度が向上したので、スムーズスキニング時、
かなり思い通りにウェイトを設定できるようになりました。

前回、アンカーBOX範囲外にウェイトが乗ったモデルを用いて実験してみましたが、
意図通りの範囲に、綺麗にウェイトが乗りました。


■FBX入出力の改善
ユーザー登録していると使える「FBX形式」の入出力機能について、
「体と服と髪」とかの複数レイヤーに分割したファイルも
正常に読み書きできるようになっていました。

コレはFBX SDK側不具合が原因だったそうですが、
そのSDKを新しくすることで解決したみたい。

いつも使っているMikoto形式MQOデエタで試してみたところ、
ToyStudioから出力したFBXをToyStudio自身で読み込むのも問題なし、
KeyNoteからFBX出力したモノをToyStudioで読み込むのも問題なしでした。

完璧です。
Date: 2009/07/05/03:21:31   No.304

1.5.0.4で気になった点
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
さわっていて、ちょっとだけ気になった点があります。

■ポイント選択精度
3Dウィンドウでのポイント選択が、「厳密な精度」に戻っているような気がします。
タブレットだとうまく選択できない感じが、1.5.0.1以前っぽい。

■既存キーショートカット
矢印キーでジョイント選択を上下できる既存機能について、
下矢印がうまく動作していないように思います。
上矢印は問題なし。

まだそんなにさわっていないので、
もーちょっとイロイロいじりたおしてみます。
Date: 2009/07/05/03:23:29   No.305

Re:ToyStudioに関する質問と要望　その１０
ピエール   HOME
区分: 説明   打たれ強さ: 強   論拠・確実性: 仕様  
使っていただいてありがとうございます。

影響範囲の内外判定では、ずっと使ってきたアルゴリズムよりも単純で
高精度の方法があることが調査の過程で分かり、個人的に勉強になりました。

ポイント選択がやりにくくなっているバグについて、確認できました
ので、1.5.0.6で修正しました。Direct3Dのウィンドウにおける選択矩形(点線)
の描画がVistaでは通常無理で、試行錯誤しているうちに関係箇所がおかしく
なっていました。(^〜^)
Date: 2009/07/15/22:49:29   No.307

Re:ToyStudioに関する質問と要望　その１０
ピエール   HOME
区分: 説明   打たれ強さ: 強   論拠・確実性: 仕様  
矢印キーでの選択がおかしい件についても確認しましたので、
次のバージョンで修正いたします。

ご報告ありがとうございます。
Date: 2009/07/16/20:08:24   No.308

Re:ToyStudioに関する質問と要望　その１０
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
おお、1.5.0.6の使用感を書こうと思ったら、もう1.5.0.7になっている。
てなわけで急ぎ1.5.0.7を試してみました。

タブレットでジョイントを楽々選択できるのと、
矢印キーでの選択動作できるのを確認しました。

どちらも、その機能があるのが前提で操作するクセがついていて、
ものすごーく手に馴染んでいたことを、あらためて痛感しましたデス。
（矢印キー選択は、Mikoto操作中にも間違えてよくやっちゃう）

しかし、VISTAはウィンドウ内描画がそんなに異なるモノなのですか。
複数OSへの対応は、手間がかかりますね。
Date: 2009/07/18/17:58:09   No.309

Re:ToyStudioに関する質問と要望　その１０
ピエール   HOME
区分: 説明   打たれ強さ: 強   論拠・確実性: 仕様  
> しかし、VISTAはウィンドウ内描画がそんなに異なるモノなのですか。
> 複数OSへの対応は、手間がかかりますね。

VistaのUAC(ユーザーアカウント制御)も対応を難しくしているようです。
XPまでのように設定ファイルなどをアプリのフォルダに置いたりすると、
OSによってユーザーフォルダ内に勝手に複製ファイルが作られていて、
アプリは実際にはそっちにアクセスしていたりします。(^〜^)
Date: 2009/07/20/11:44:10   No.310


ToyStudioに関する質問と要望　その９
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
腕に影響範囲BOX外のウェイトが乗る
腕に首ウェイトが乗った例
メッシュ細分割で多少解決
現在、Ver.1.5.0.3をさわっていますが、いくつか気になった点があるので記述。

■スキニング時のウェイトについて
Mikoto形式データを読み込んで自動スキニングする際、意図しないウェイトが乗っているようです。

ウェイトを薄く広く乗せたいので、減衰率を1〜3程度にしているのですが、
保存した生データを眺めてみると、前腕頂点と思われる範囲に首ボーンのウェイトが、微少量ですが乗っています。
アンカーBOXによるウェイト遮蔽効果が不十分な感じ。

■暫定的な解決方法
アンカーBOXのポリゴン割りを細かくしたところ、意図しないウェイトの乗り方が減りました。
以前も「ポリゴンの内外判定の誤差を調整する」とかいう話があったと思いますが（2008/05/07頃）、
たぶん同じ理由っぽい。

■自分なりの提案
アンカーBOXの内外判定に誤差が存在する以上、完全にコレを解決するのは難しいのではないかと思います。
そこで。

スキニング時のパラメータに「最近隣ボーンから○階層以上離れたボーンは参照しない」みたいなオプションを追加すると
今の仕様を崩すことなく、余計なウェイトが乗らないようにできるのでは。
Date: 2009/05/21/03:28:22   No.292

アニメーションのインポートについて
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
既に他の方が要望を出されていますが、.toyファイルからアニメーションをインポートする際
ボーン名で紐付けする機能が欲しいです。
ただし、せっかく階層構造化して同名ボーンを使えるようにしているので、コレも活かした形で。

■概要
アニメーションインポート時「ボーン名で紐付け」オプションを追加する。
同名ボーン対応として「階層をさかのぼってボーン名検索」オプションもつける。
さかのぼり階層の数も指定できるようにする。

例：
　root￥スカート右前￥中￥先端
　root￥スカート右後￥中￥先端

さかのぼり階層：3　→　ボーン名「スカート右前￥中￥先端」と「スカート右後￥中￥先端」でそれぞれ紐付け可能
さかのぼり階層：2　→　「中￥先端」というボーン名が重複することになるのでエラー
　ボーン名重複チェックリストが表示できると、なお良さそう。

■使うシーン
胴体の動きを簡易ボーンセットで作っておいて、スカートの動きだけを個別に作り、
アニメーションをそれぞれインポートして、キーのコピペで胴体の動き＋スカートの揺れを実現する。

また、グーチョキパーを「手だけの立体」で作っておいて、アニメーションをインポートして
キーのコピペで胴体の動き＋グーチョキパーを実現する、等。

■備考
キャラクターモーションを作る場合、体全体の動きと、指先や手の表情といった細かい動作は
別々に作って合成する方が、手間が小さくなると思います。

髪・スカート等の揺れモノは、キャラによってあったりなかったりするので
髪ボーンやスカートボーンの有無を無視して、アニメーションをインポートできると便利。
Date: 2009/05/21/03:42:16   No.293

ウェイト設定について
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
Maxの影響範囲ソーセージ
ToyStudioでスキニングをする場合、ボーンウェイト減衰率を指定します。
お尻のあたりは薄く広くウェイトを乗せたいですが、膝や足首はもっと狭く乗せたいので、
特定のボーンウェイトについて「何回かに分けて再設定する」必要があります。

最初の1体を設定するときに手間をかけるのは構わないのですが、同じボーン構造のキャラを何体も作る場合
全く同じ作業をキャラの数だけ行うことになります。
こういうのはスクリプトで半自動化するか、ソフトウェア側にその設定を保持するか、等、
同じコトを手作業で繰り返さなくてすむ仕組みが欲しいです。

例によって、実現の難易度を考慮せず要望だけ記述しました。

■ボーン毎の設定を保持する機能
ボーン別にウェイト減衰率と影響ボーン数を設定し、保存できるようにして欲しいです。
あと、その設定を外部ファイルに記録し、「ウェイト設定インポート」みたいな形で使い回せるように。

■既存の仕様を気にしない案
ボーン毎のウェイト影響範囲を可視化してほしいです。
Maxの標準ボーンは、ソーセージ状の影響範囲（ボーン付け根と先端に二重球体を表示し、
球の直径をいじることでウェイトセット範囲を設定します。

これとアンカーBOXによる遮蔽機能を併用できると、かなり楽にセッティングできます。
　MaxはアンカーBOXによる遮蔽機能がないので、イロイロ難儀。
Date: 2009/05/21/04:49:35   No.294

Ver.1.5.0.3感想あれこれ（１）
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
■ボーン選択とウェイトペイント（いい）
少し前のバージョンに比べ、ボーン選択とウェイトペイントが格段にやりやすくなっています。

3Dウィンドウでのポイント選択精度をユルめに設定することが出来るようになったので、
タブレットでも楽にボーンを選べます。
以前はタブレットだと微妙なズレがあってうまく選択できず（手はちょっと震えているから）、
トラックボールを使うか、オブジェクトウィンドウでボーンツリーを選ぶかしていました。

ウェイトペイントで＋−ボタンがついたのは嬉しいです。
ウェイトをペイントするときは「ちょっと塗ってまた薄めて、また塗って」の繰り返しです。

薄めるときには「置き換え」＋「ウェイト値0入力」に切り替える必要があったのですが、
＋−ボタンがあると「加算」を選びっぱなしで、かつウェイト値の再入力をすることなく
塗り具合を薄められるように。

■回転ツール使用時のマニピュレータ操作
回転ツールでポーズを付ける際、マニピュレータの3軸それぞれを個別に動かす場合と、中央の黄色い部分を操作する場合がありますが、
黄色い部分（もしくはボーン）を操作する場合の回転方向について。

マウスを画面に向かって左右に動かすと、ジョイントは左右にねじれ、上下に動かすと上下にねじれます。
これは至極真っ当な動作だと思います。実際、使いやすい。

これに「画面に向かって時計方向／反時計方向に回転する」機能が欲しい。Shiftキー併用とかそんな感じで。
ローカル座標系のきっちりした操作はハンドルのXYZ軸を個別に操作し、スクリーン座標系の直感的な操作は
ボーンをそのまま適当に動かせると、右脳も左脳も生きる、隙のない操作系っぽい感じがします。

■Mikoto形式データ読込
昨年の段階では「Mikoto形式データ読込」→「保存時に強制終了」とか発生していたのですが、
現在は発生しません。全く問題なく保存できます。
当時、何がダメだったのかははっきりしないですが、ともかくこの問題は終了。
Date: 2009/05/22/03:45:20   No.295

Ver.1.5.0.3感想あれこれ（２）
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
■やっぱり欲しいキー操作機能
以前にも書いた要望ですが、ジョイント操作（X・Y・Z軸の回転・拡大縮小・移動）を、キー入力でやりたいです。
全部のジョイント角度をFKできっちり作っていく、とゆー方針を固めたので、あらためて要望。

果たして自分以外の何人が必要とする機能かは分かりませんが、FK操作においては、
キー入力で回転出来るのと出来ないのとでは、作業の速度が全然違ってきます。

Mikotoだと（何故か）バンク回転だけキー操作できるようになっていて、ともかくコレは使っています。
コレに加えてヘッド回転とピッチ回転もキー操作できたら、キー操作なしに比べ、モーション作成効率が
たぶん2倍くらいに向上すると思います。
10時間かかる動きなら5時間。100時間かかるショートダンスモーションが、50時間。

オブジェクトウィンドウ上や3Dウィンドウ上で、カーソルキーでジョイント選択するのは
MayaやMaxでもできますが、キー操作でヘッド・ピッチ・バンク回転させる機能はなかったはず。


問題は「どのキーをアサインするか」ということなのでしょうけれど、
「Altキーと数字キー1〜6」に割り振るのなんかどうでしょう、と提案。

とりあへづ「Alt＋数字」はまだ空いているみたいですし、数字の1〜6あたりなら
左側にしかAltキーのついていない小型ノートPCでも問題ないと思います。

1・2でX軸の＋と−、3・4でY軸、5・6でZ軸。
回転・拡大縮小・移動の選択は、これまで通りツールをR・C・Tキーで切り替え。
キー入力で何度回転するか（何％拡大するか）は、環境設定とかで変更可能。

気にせず本音を述べるなら、上記と同じ機能を「Ctrl＋テンキー」あたりに持たせたり、
「Ctrl＋Shift＋テンキー15度ずつ回転」とかできる方が好みですが、
ノートPCのことを考えると、テンキーにはあんまりアサインしない方が良いのかも。

■ドリブンキーがあったら活用したい
これも以前に書いたことですが、ドリブンキー機能がほしいです。あらためて。

指を5本全部いっぺんに開いたり閉じたりする場合とか、しゃがむ動作（腰・腿・膝・足首を同時に曲げつつ体を下げる）とか、
大まかにざっとポーズを組みたい場合、ドリブンキーが使えると便利っぽいです。
ボーンセットアップ関連の本や関連サイトを見ると、指を一括で動かす組み方はけっこう使われているみたい。

■デュアルクオータニオンによる変形補正機能が欲しい
最近だとXSIやBlenderに実装されている「デュアルクオータニオン変形」がToyStudioにもあれば、と思います。

肘・膝関節を曲げたときの「内側のひしゃげ」は、ポリゴン列を1列にすることでとりあえず回避できますし、
補助ボーンを組み込んで補正すればハイポリでもいけます。

が、大きくねじったとき（通称：雑巾絞り）の痩せ方は、補助ボーンでの回避も困難です。
手首や肘で無理なねじり方をした部分がすごーく細くなります

実装についてご一考いただければ幸いです。

※ウェイトを2つまでしか乗せられないなら、デメリットの方が大きいかも知れませんが。
　実際、Mikotoはイロイロ不便ですし。
Date: 2009/05/22/03:47:00   No.296

Re:ToyStudioに関する質問と要望　その９
ピエール   HOME
区分: 回答   打たれ強さ: 強   論拠・確実性: 経験則  
ピエール@ToyStudioです。
ご質問やご要望などありがとうございます。

上の項目から順次お答えさせていただきます。

＞ ■スキニング時のウェイトについて
＞ Mikoto形式データを読み込んで自動スキニングする際、意図しないウェイトが乗っているようです。
＞ 〜

データを調べてみないとわからないのですが、ポリゴンの内外判定にはポリゴン面の
方向を用いていますので、両面ポリゴンが混ざっていると、内外判定がおかしくなります。

影響範囲用のポリゴンに両面ポリゴンが混ざっていないかチェックしてみてくださいませ。

そうでない場合、関連部位のみのデータでかまいませんので、送っていただければ
こちらで調査してみたいと思います。(^〜^)
Date: 2009/05/25/00:08:23   No.297

これでご確認いただければ
まつい  
区分: 回答   打たれ強さ: 強   論拠・確実性: 経験則  
腕アンカーBOX形状によってはうまくいく
Diffツールで両方を比較
FILE 298_3.lzh
デエタ（成功例＋失敗例）
いつも通りてんこ盛りな質問・要望で、恐縮です。

腕アンカーBOXを差し替えつつ、スキニングを試したところ、
余計なウェイトが乗るモノと乗らないモノがありました。

たまたま再現しただけで、原因までははっきり分からないのですが、
ほとんど同じ形状（頂点番号は異なる）なのに、片方だけ余計なウェイトが乗ります。

両方のToyStudio形式、および元のMikotoデエタをアップしました。
味も素っ気もないモデルで申し訳ないですが、これでご確認をお願いします。
読込時設定は、減衰率：3、影響ボーン数：4、影響範囲チェックは両方ONです。

※見た感じ、両面ポリゴンはなさそうでした。
Date: 2009/05/25/03:36:56   No.298

Re:ToyStudioに関する質問と要望　その９
ピエール   HOME
区分: 回答   打たれ強さ: 強   論拠・確実性: 経験則  
問題点の割り出しとテストに時間がかかり、返答が遅くなってしまいました。
失礼しました。

やはり影響範囲BOXの内外判定周りに問題がありました。こちらの開発バージョン
では修正できましたので、次のアップで更新する予定です。

いろいろ試してみたのですが、最終的には内外判定用の低レベル処理を誤差の少ない
新方式にしたところ、問題を解消できました。

＞ スキニング時のパラメータに「最近隣ボーンから○階層以上離れたボーンは参照しない」みたいなオプションを追加すると
＞ 今の仕様を崩すことなく、余計なウェイトが乗らないようにできるのでは。

影響範囲BOXの頂点座標範囲で最終判定をするようにしましたので、万が一ポリゴン
の内外判定を突破されても、とんでもない位置のポリゴンにウェイトがのることも
ないようにしました。また両面ポリゴンでも判定可能にしました。

わかりやすい比較データまで用意していただいて、ありがとうございました。
Date: 2009/06/02/21:53:58   No.300

Re:ToyStudioに関する質問と要望　その９
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: その他  
おお、解決しましたか。ご対応いただき、ありがとうございます。
では「最近隣ボーンから○階層以上離れた〜」は不要そうですね。

次の更新を楽しみにしています。
Date: 2009/06/04/03:44:05   No.301

追加で細かい要望
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
マニピュレータの黄色を常に手前表示させたい
操作系の細かい要望です。

■マニピュレータキューブ部分「常に手前表示」
マニピュレータの中央の黄色キューブ部分を「常に手前表示する」オプションがほしいです。
慣れると3軸ハンドルより使用頻度が高くなるのですが、左右対称のジョイントだと
片側は軸方向が反転するので、黄色キューブ部分が3軸ハンドルに隠れてしまいます。

現状でも3軸ハンドルを小さくするという選択肢はありますが、リング状のものは
大きい方がいじりやすいので、画像のようなサイズにして使っています。

■軸の長さ変更
3軸ハンドルを大きくすると、リング部分がジョイントから離れてしまうので、
軸部分の長さを初期設定で変更できるようにしていただけないでしょうか。

■シーン設定のデフォルト値
シーン毎に設定できる値について、ユーザーデフォルト値を保存できるようにしていただけないでしょうか。

現在、わたくしはバックカラーを藤色にして、表示を正射影にして、ジョイントサイズを0.5にして、
座標軸とグリッドとジョイント影響範囲を非表示にする、という操作を、ファイルを読み込む都度
必ず手動設定しています。

5月だけでも200回以上はファイル読込をしているので、上記操作を200セット行ったことになります。
1セットあたり10秒前後を要するので、合計で2000秒ってとこ。

わずかな手間ではありますが、ユーザー初期設定として保持できればと思います。


以上、ご一考いただければ幸いです。
Date: 2009/06/04/04:02:18   No.302

Re:ToyStudioに関する質問と要望　その９
ピエール   HOME
区分: 回答   打たれ強さ: 強   論拠・確実性: 経験則  
上の項目からお答えさせていただきます。

＞　アニメーションインポート時「ボーン名で紐付け」オプションを追加する。
＞　同名ボーン対応として「階層をさかのぼってボーン名検索」オプションもつける。
＞　さかのぼり階層の数も指定できるようにする。
＞　〜

ボーン名でアニメーションの割り当てができると、サブのボーンセット単位での
インポートでも使えそうですね。ToyStudioはオブジェクトの親子関係でボーンを
保持しているので、結構すんなりとインポートできる場合が多いと思われます。


＞　■ボーン毎の設定を保持する機能
＞　ボーン別にウェイト減衰率と影響ボーン数を設定し、保存できるようにして欲しいです。
＞　あと、その設定を外部ファイルに記録し、「ウェイト設定インポート」みたいな形で使い回せるように。

減衰率はボーンごとに持たせることができると思います。影響ボーン数は、頂点に
ついての値になりますので、持たせるとしたらポリゴンオブジェクト単位になりますね。

＞　■既存の仕様を気にしない案
＞　ボーン毎のウェイト影響範囲を可視化してほしいです。
＞　Maxの標準ボーンは、ソーセージ状の影響範囲（ボーン付け根と先端に二重球体を表示し、
＞　球の直径をいじることでウェイトセット範囲を設定します。
＞　〜

二重の間のエリアが減衰範囲になっている感じですね。スキニングのアルゴリズム的には
対応しやすいですが、ソーセージ物体の操作用GUIの方が重要になりそうです。


＞　3Dウィンドウでのポイント選択精度をユルめに設定することが出来るようになったので、
＞　タブレットでも楽にボーンを選べます。
＞　〜

ちょっとぶれの大きいマウスを使っていたら、ポイント選択ができにくいことに気づいて
許容範囲で判断するようにしました。プログラム的には数行の変更なのですが、使い勝手は
かなり違いますね。(^〜^)

＞　〜
＞　これに「画面に向かって時計方向／反時計方向に回転する」機能が欲しい。Shiftキー併用とかそんな感じで。
＞　ローカル座標系のきっちりした操作はハンドルのXYZ軸を個別に操作し、スクリーン座標系の直感的な操作は
＞　ボーンをそのまま適当に動かせると、右脳も左脳も生きる、隙のない操作系っぽい感じがします。

その通りですね。


＞　■やっぱり欲しいキー操作機能
＞　以前にも書いた要望ですが、ジョイント操作（X・Y・Z軸の回転・拡大縮小・移動）を、キー入力でやりたいです。
＞　全部のジョイント角度をFKできっちり作っていく、とゆー方針を固めたので、あらためて要望。
＞　〜

りょうかいです。クリックしすぎで右手が痛くなったため、私も左手でマウスを操作していますが、
その場合テンキーが一番使いやすそうです。右手マウスの場合は、テンキーを使うとマウス
から手を離すことになるので、やはりテンキー以外の方がよさそうです。実際に試してみて判断
する必要がありそうです。

＞　■ドリブンキーがあったら活用したい
＞　これも以前に書いたことですが、ドリブンキー機能がほしいです。あらためて。
＞　〜

りょうかいです。

＞　■デュアルクオータニオンによる変形補正機能が欲しい
＞　最近だとXSIやBlenderに実装されている「デュアルクオータニオン変形」がToyStudioにもあれば、と思います。
＞　〜

多少制限のあるアルゴリズムのようですが、ひしゃげ回避の点で優れているようですね。


＞　■マニピュレータキューブ部分「常に手前表示」
＞　〜

各軸のハンドルに隠れないようにするのに、この方法がありましたね。気づきませんでした。

＞　■軸の長さ変更
＞　3軸ハンドルを大きくすると、リング部分がジョイントから離れてしまうので、
＞　軸部分の長さを初期設定で変更できるようにしていただけないでしょうか。

現状はマニピュレータ全体のサイズですが、各ハンドルサイズと軸の長さ指定になりますね。
　
＞　■シーン設定のデフォルト値
＞　シーン毎に設定できる値について、ユーザーデフォルト値を保存できるようにしていただけないでしょうか。
＞　〜

りょうかいです。現状では背景カラーはオプション設定／シーン設定で保持されていて、
ジョイント半径はシーン設定で保持されています。

多くのご要望ありがとうございます。ToyStudioのユーザーの方では、構造のシンプルさや
操作のわかりやすさをまず評価されることが多いです。そういった点を踏まえながら、さらに
使い勝手を向上できるように、ご要望の機能を検討させていただきたいと思います。

モデラーやアニメーターソフトもある意味コンテンツの一種であり、使っていて楽しいという
ことが、今後最も重要な要素なっていくように思います。
Date: 2009/06/06/17:43:53   No.303


ToyStudioに関する質問と要望　その８
まつい  
区分: 説明   打たれ強さ: 強   論拠・確実性: 経験則  
補助ボーンなしでも綺麗に曲げる
動かしてみた
FILE 280_3.lzh
改良版デエタ（モーション付き）
待望のアニメーション操作に入ることができました。

Mikotoモーションを読み込んでそのまま使おうとすると、補正ボーンはかなり邪魔になると実感したので、
ウェイト調整＋ポリゴン割りの工夫で乗り切るよう、デエタを修正しました。
膝裏・肘裏・脚の付け根のポリ列を一列にするとゆー、ハイポリモデルでは通用しない後ろ向きな手法ですが、
ローレグ気味のパンツラインでもひずみが目立たないようになっています。
脇の下と腰のルートだけ、手動ウェイト調整してあります。

Mikotoで作ったモーションを読み込んで動かしてみましたが、極端な動きをしない限り、特に違和感はないデス。
Date: 2008/05/07/03:54:22   No.280

スキニング処理の影響範囲指定について
まつい  
区分: 説明   打たれ強さ: 強   論拠・確実性: 経験則  
影響範囲BOXを越えてウェイトが設定される
影響範囲BOXの遮蔽処理に、多少不具合があるようです。
既に把握されているかも知れませんが、こちらで確認した現象を挙げておきます。

■現象
影響範囲BOXにより遮蔽されるべきボーンウェイトが、時々BOX範囲をはみ出して設定される

上の「280_3.lzh」には、Mikoto対応MQOとToyStudio形式の両方が入っています。
うちの環境では、ファイル読込時の自動スキニングでも、その後の手動スキニングでも
「腹」「鎖骨[L]」「髪_Ex2」において、影響範囲BOXの領域を越えて、ウェイトが設定されております。

---以下、不要となった補足事項-----------------------------------------------------------------------
元のMikotoデエタは諸事情により、ルートの位置を腰の後ろ30センチほどのところに持ってきているので
ToyStudio読込後、メニュー「オブジェクト」→「ボーンの追加／ウェイトの再セット」にて
参照するボーンのところで「Anc_ベース」のチェックを外す必要があります。
その際「チェックされていないボーンのウェイトを0にする」をONにしてください。

※すみません画像の囲み位置がチョット間違っています。バストじゃなくて鎖骨でした。後で画像を差し替えます。

　05/08　画像とデエタを差し替えました。
　怪しいルートを影響範囲BOXで囲んだので、ウェイトの再セットは不要となりました。
Date: 2008/05/07/04:33:24   No.281

アニメーション操作関連の細かい要望とか
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
■アニメーションパネルの選択

アニメーションパネルでモーションを選択する際、現状ではマウスでダブルクリックしないと選べないようです。
Enterキーによる選択を有効にしていただけないでしょうか。

■グラフウィンドウでの編集

グラフウィンドウ上で、キーフレームをコピー・貼り付けできるようにして欲しいです。
任意のキーを選択してコピーして、別のフレームに適用する、とゆー使い方です。

■AVI出力の不具合（？）

うちのデュアルモニター環境では、AVI出力が失敗します。
同じファイルをシングルモニター環境のPCで読み込んでAVI出力すると、ちゃんと読める動画になります。

　→コレ、再現性チェックには何をアップすると良いでしょうか？出力失敗したAVIファイルとか、必要ですか？
Date: 2008/05/07/05:07:15   No.282

Re:ToyStudioに関する質問と要望　その８
ピエール   HOME
区分: 説明   打たれ強さ: 強   論拠・確実性: 仕様  
こちらのサイト、ホントにながめているだけでワクワクしてしまいます。
早速ながら、添付データを再生して狂喜しております。(^〜^)

> Mikotoで作ったモーションを読み込んで動かしてみましたが、極端な動きをしない限り、
> 特に違和感はないデス。

動かしてしまうと、以外にスキニングのアラなどが目立たないことには私も実感します。
音が入るともっと気づかないものかも知れません。

> 影響範囲BOXにより遮蔽されるべきボーンウェイトが、時々BOX範囲をはみ出して設定される

開発の段階で何度かありました。ポリゴンの内外判定の誤差をもっと小さくとる
必要があるようです。

> アニメーションパネルでモーションを選択する際、現状ではマウスでダブルクリックしないと
> 選べないようです。Enterキーによる選択を有効にしていただけないでしょうか。

りょうかいです。キーボード対応は忘れがちです。

> グラフウィンドウ上で、キーフレームをコピー・貼り付けできるようにして欲しいです。

これは繰り返し要望されておりますね。作業量との兼ね合いで、対応のタイミングを図っております。

> うちのデュアルモニター環境では、AVI出力が失敗します。

マルチモニター環境が手元にないので、すいませんが今は修正が出来ないと思います。
数フレーム分の非圧縮ファイルをlzhなどにしたものをいただければ参考にしたいと思います。


次のバージョンアップでは、データのプレイヤーを用意する予定です。TOYSTUDIOは編集ソフト
なので、GUIへのメッセージ処理が多く、それほどアニメーションの再生パフォーマンスを
上げられません。プレイヤーの方では再生パフォーマンスを最適化していく予定です。

ファイル形式は図形/アニメーションデータと、テクスチャーや音声データ等も含めてワン
パッケージ化された暗号化形式のものなので、動画のような配布形態が出来ると思います。

間に合えば、トゥーンシェーディングにも対応する予定で、短編の3DリアルタイムCG
アニメーション プラットフォームになるかもと思います。
Date: 2008/05/07/20:56:19   No.283

Re:ToyStudioに関する質問と要望　その８
まつい  
区分: 説明   打たれ強さ: 強   論拠・確実性: 経験則  
>音が入るともっと気づかないものかも知れません。

リアルタイムモーションに音を入れるとゆーのは、かねてより望んでいたモノでした。
とりあへづチュートリアル通りに操作して音を鳴らすところまではできましたので、
「音あり前提のモーション」を考えているところデス。


>開発の段階で何度かありました。ポリゴンの内外判定の誤差をもっと小さくとる
>必要があるようです。

個人的には「多少時間がかかっても誤差が小さい」方が良いですが、
判定誤差と処理速度はトレードオフだと、落としどころが難しそうですね。


>TOYSTUDIOは編集ソフトなので、GUIへのメッセージ処理が多く、
>それほどアニメーションの再生パフォーマンスを上げられません。

あ、なんか納得。
データプレイヤーでは再生に特化できる分高速になるとゆーことですか。
うちの環境でも動きが時々カクカクになっていますが、プレイヤーができたら
激重キャラに差し替えて、勝手にベンチマークとかやってみると思います。


あと、失敗したAVIファイルは後でアップしておきますが、
基本的にマルチモニター対応とかは後回しでいいです。
多分ものすごく少数派でしょうし、シングルモニター機で出力すれば問題ないですし。
Date: 2008/05/10/02:52:05   No.284

Re:ToyStudioに関する質問と要望　その８
ピエール   HOME
区分: 説明   打たれ強さ: 強   論拠・確実性: 仕様  
> あ、なんか納得。
> データプレイヤーでは再生に特化できる分高速になるとゆーことですか。
> 〜

そうですね。マウスクリック用とか、ボーン表示用とか、マニピュレータとか
の編集用オブジェクトなんかもいらないので、全体的にコンパクトに出来ます。
実行ファイルの形式もMFC利用からAPIのみになるので、配布DLLも少なくなります。

> あと、失敗したAVIファイルは後でアップしておきますが、
> 基本的にマルチモニター対応とかは後回しでいいです。
> 〜

りょうかいいたしました。
Date: 2008/05/13/23:11:04   No.285

Re:ToyStudioに関する質問と要望　その８
まつい  
区分: 意見   打たれ強さ: 強   論拠・確実性: 経験則  
ToyStudioのカラー設定は2色
CelsViewだとこんな感じ
ToyStudioがバージョン1.4.0.2になっていたので、使ってみました。

油断している間に2つほどバージョンが上がっていたのですが、1.4.0.0からの修正点は
アニメーションキーのコピーとか、ボーン数制限の撤廃とか、アニメ調表示とか、あとバグフィックス。

とりあへづアニメ調表示をいじってみましたデス。

で、気付いたこととゆーか、CelsViewとToyStudioの仕様の違いがけっこーあります。

他のツールと比較していいの悪いのと論じるんではなく、作りが違うモノですね、
とゆー観点で記述していますので、ご了承ください。

-------------------------------------------------------------------------------------------
今のところToyStudioのアニメ調表示は、CelsViewよりもハードウェア的な敷居が高い感じです。

具体的には、うちの可愛い旧型機（2003年型ビヂネス機、i865）を用いた検証で
前者は限定的セルアニメ調表示が可能であり、後者はセルアニメ調表示自体が不可能でした。

マテリアル毎にちまちまと表示設定をしていくのはどちらも同じですが、CelsViewは陰影4色、ToyStudioは2色です。
前者がDefuseやAmbient等を無効にしているのに対し、後者は有効なままです。
CelsView的観点で云うと「エッジが有効でセルシェーダが無効」で、陰影色は指定できる感じ。
あと前者は陰影を表示できますが、後者は陰のみです。

ちなみに六角大王Superではキオさんとかが「エッジが有効セルシェーダ無効」で
魅力的なモノを作っています。この辺は使い方次第。
わたくしわこの4年間、CelsView（＋旧CelShade）と共に歩んできたので、4色陰影が体に染みこんでいますが。

セルアニメ調表示＋リアルタイムボーン操作ができるとゆーメリットは大きいです。
いちいち保存して他のツウルで読み直す、とゆー手順がいらなくなるから。
-------------------------------------------------------------------------------------------

なお、2色目を設定しようとすると、1色目が変更されてしまうようです。コレはおそらく要修正項目。
あと「デバイス」の「ハードウェア頂点処理」を無効にしていると、セルアニメ調表示が崩れます。これは多分、仕様。

他の機能はこれからいじります。まづは速報まで。
Date: 2008/06/29/22:51:09   No.286

Re:ToyStudioに関する質問と要望　その８
ピエール   HOME
区分: 説明   打たれ強さ: 強   論拠・確実性: 仕様  
とりあえず、2色目をいじると1色目が変更されるバグを修正しておきました。(^〜^)

今回は、アニメーション キーのコピペ機能のボリュームが相当に大きかったので、アニメ調シェーダは
基本的な機能のみに絞りました。これはビデオカードの「頂点シェーダ」機能を使っているのですが、
自由度がとても高いものなので、機能的にはどうにでもできる感じです。

それと、アニメ調表示ができなかった旧型機のビデオカードの頂点シェーダ バージョンを教えてくださいませ。
Date: 2008/07/04/21:37:23   No.287

Re:ToyStudioに関する質問と要望　その８
まつい  
区分: 説明   打たれ強さ: 強   論拠・確実性: 経験則  
旧型機でもセルアニメ調表示自体はできていました
すみません、レスが遅くなりました。

旧型機のi865ビデオチップについてデバイス情報を確認したところ、
頂点シェーダ バージョンは「3.0」とありました。
--------------------------------------------------------------
ラスタライザ: ハードウェア
頂点処理: ソフトウェア
スキニング処理: 固定機能+頂点シェーダ
Zバッファー: 24bit
最大描画プリミティブ数: 65535
固定機能 最大ブレンド行列数: 4
固定機能 最大ブレンド行列インデックス: 255
固定機能 最大ライト数: 4294967295
頂点シェーダ バージョン: 3.0
頂点シェーダ 最大定数レジスタ数: 8192
頂点シェーダ 最大命令数: 4294967295
ピクセルシェーダ バージョン: 0.0
最大テクスチャーステージ数: 4
最大同時テクスチャー数: 4
最大テクスチャーサイズ: 2048,2048
バンプマッピング: 無効
輝度付きバンプマッピング: 無効
フルシーンアンチエイリアス: 利用不可
--------------------------------------------------------------

なお、あらためて確認したところ、上記PCでは「アニメ調表示ができない」のではなく、
「一部正常表示されていない部分がある」という状態のようです。
陰影の色は、綺麗に表示されています。不正確な報告をしてしまい、すみませんデス。

--------------------------------------------------------------
■正常に表示出来ていないっぽい部分
・輪郭線が、設定の如何に依らず「白色」になっている
　　→頭部リボンとかその他全部、白色の輪郭線です。
・テクスチャー境界が微妙におかしい
　　→脚の付け根付近、色のつながりが変です
・なんか陰影が逆転して表示される
　　→顔の陰は、光源が後ろにあるような表示になっています。
　　　体は光源が正面にある感じ。
--------------------------------------------------------------

※DirectXは、2008年6月版を使用しています。
Date: 2008/07/12/21:48:18   No.288

Re:ToyStudioに関する質問と要望　その８
sio29  
区分: 説明   打たれ強さ: 強   論拠・確実性: 仕様  
横から失礼します。
i865は固定パイプラインなのでShaderには対応していません。
頂点シェーダバージョン「3.0」というはソフトウェアエミュレーションのバージョン数でi865自体の機能ではないです。
ただし頂点Shaderに限りソフトウェアエミュレーションを使えばどんなハードにも使用できるので問題点はピクセルパイプラインにあると思います。
たぶん対応していない機能(CAPS)が呼ばれているのではないでしょうか?

http://www.netsphere.jp/dxinfo/
>dxinfo
どのGPUがどの機能(CAPS)を持っているかはこちらのページが参考になると思います。
http://sio29.sakura.ne.jp/dxview/dxcapsview.html
あと私のページにも過去持っていたVGAのDXCapViewerのログを取っておいてあるので参考にどうぞ

古いGPUに対応させるときはCAPSを見てプログラムを分けていくしかないと思います。
Date: 2008/07/13/14:40:52   No.289

Re:ToyStudioに関する質問と要望　その８
ピエール   HOME
区分: 説明   打たれ強さ: 強   論拠・確実性: 仕様  
まついさん、sio29さん、ありがとうございます。

私の手元にある数種のビデオカードでは、ハードウェアでは問題ないのですが、シェーダのコードは同一で、
ソフトウェア エミュレーションの場合に影用のテクスチャー座標が照明方向に対して反映されない状態に
なっています。上に添付されている画像も同じ症状ですね。

今のところ、現状のマルチパス レンダリングでのステートの設定位置が、エミュレーションではNOなタイミング
になっているのではないかと思っています。やはりエミュレーションでもトゥーン シェーダができたほうがいいので、
何とかしたいですね。
Date: 2008/07/14/22:19:18   No.290


現行ログ/ [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
No. PASS
No. USER PASS
0006639
[TOP]
shiromuku(u)GUESTBOOK version 1.55