Re: celsviewの最大ポリゴン数 -
sio29 2008/09/21(Sun) 22:49
No.5426
特に制限は設けてませんがあえていえばメモリのある限りとなります。
ただしCelsViewは32bitアプリなので8GB積んでいても使用されるのは32bitアプリの上限4GBまでなります。
また内部的な話になりますがCelsViewはCelshadeというシーンエディタのエンジンをそのまま使用しています。
Celshadeはシーンエディタであるためエディタブルにデータが管理できるように通常のビュワーに比べれると数倍メモリを消費するようになってます。
なので正確に測ったことはありまんがpironさんのおっしゃるとおり100万ポリゴンあたりが上限になるのではないでしょうか?
ただしバッチ処理中のみ落ちるというのであれば何かメモリ開放し忘れているのかもしれません。
Re: celsviewの最大ポリゴン数 -
piron 2008/09/22(Mon) 06:58
No.5427
ご返答ありがとうございます。
メモリはよく消費するのは気がつきまして他のソフトとの
兼ね合いもあってx64化しまた。おっしゃるとおり32bitOS
だと2GBまでしか扱えません。他のアプリ同時起動していると
メモリが使えないときもありますが
x64だと4GBまでにUPするので緩和されました。
局面制御使う上に編集過程のオフジェクトを一時的にコピー
しておくクセがあるので時折整理ないとマズイですね。
落ちるのはパッチ処理中等の
Fileを開いているときにさらに開くタイミングで落ちます。
マルチドキュメントはOFFです。
Re: celsviewの最大ポリゴン数 -
sio29 2008/09/23(Tue) 01:39
No.5428
>落ちるのはパッチ処理中等の
>Fileを開いているときにさらに開くタイミングで落ちます。
バッチ中にタスクマネージャーのページファイル使用量が増えたまんまだったりしますか?
バッチ処理は基本的に1ファイルごとにメモリ確保、開放しているのでうまく動作していれば
ページファイルサイズは減ったり増えたりするはずですがうまくいっていない場合は増え続けます。
自分の持っているファイルでは問題ないようですが、どうでしょうか?
またページファイルサイズがあまり使ってないのに落ちる場合は単純にプログラムのバグかもしれません。
Re: celsviewの最大ポリゴン数 -
piron 2008/09/23(Tue) 07:38
No.5429
調べてみました。
タスクマネージャのプロセスでCelsViewが使用するメモリ量の変化の仕方ですが
ファイルを開いたときに一瞬
CelsView本体+開いていたファイル+開くファイル [Aの状態とします]
分のメモリが消費されているようです。
開くことができれば古いファイルのメモリは開放されます。
なので増え続けるということはないです。
バッチ処理のときもファイルを開くことを内部で行っていると
思いますのでAの状態が繰り返されています。
Aの状態のときにCelsViewが使用するメモリ量1.8GB辺りを越えると
終了してしまいます。
逆にAの状態時に1.8GBを超えないようにファイルを収めれば
落ちないようです。
そのラインがおおよそ100万ポリゴン辺りのようですね。
再現用にファイルを作ってみました。
お手数おかけしてスミマセンがよろしくお願いいたします。[添付]: 215537 bytes
Re: celsviewの最大ポリゴン数 -
sio29 2008/09/23(Tue) 15:21
No.5430
Re: celsviewの最大ポリゴン数 -
piron 2008/09/24(Wed) 22:15
No.5432
調べていただきありがとうございます。
メモリの制限と、開放タイミングがわかりましので
そこに気をつけながら使わせていただきます。
また、私の場合ですとそこまでハイポリで表現したいものは
なくて単に整理してないとかundo用にとっておくだけです。
メタッコはデータが肥大化するといろいろ不都合がでてくるので
ファイルを分けたり整理する癖をつけるようにしたいと思います。
ご丁寧に対応いただきありがとうございました。
Re: celsviewの最大ポリゴン数 -
sio29 2008/09/24(Wed) 23:50
No.5433
http://sio29.sakura.ne.jp/celsview/celsview_080924.lzh
その1)
モデル用ワークから無駄なメモリを少し減らしました。
またデータ読み込み前に以前のデータを開放するようにしましたのでメモリ圧迫は減ったと思います。
その2)
またカメラの「傾き」に対応しました。
「Comm→カメラ→数値」の中の「傾き」がそれにあたります。
ただしY軸がカメラと水平になると「傾き」はリセットされてしまうので注意してください。
その3)
かなり暫定的ですがmikotoモデルに対応しました。
ただしモーフィング、オブジェクトセレクタなどには未対応です。
sdefはスフィリカルデフォームではなくDualQuaternionで変形しています。
(※DualQuaternionの変形にはまだバグがありボーン角度によりポリゴンがひっくり返ってしまうことがあります)
使い方は、まず「オプション→ミコトモデル有効」を有効にしてください。
「ミコトモデル有効」を有効にした場合にのみミコトモデルとして読み込まれます。
モーションの読み込みは「ファイル→モーションを開く」で行います。現在対応してるのはmkm形式のみになります。
モーションは現在のモデルに関連付けされて読み込まれます。モデルがない状態でモーションを読み込んでも無視されます。
アニメーション再生、停止などは「Comm→アニメーション」の項目で行います。
ミコトモデル対応についてはかなり試験段階なので全てのデータが問題なく再生できるとは思わないでください。
またおかしいところがあったら教えてください。
http://sio29.sakura.ne.jp/tmp/celsview_080904.avi
ちょっと古いバージョンだけどこんな感じです。
※ミコトモデルを読んだ状態でMCSを保存するとおかしくなるので注意してください
Re: celsviewの最大ポリゴン数 -
piron 2008/09/26(Fri) 07:31
No.5436
ありがとうございます〜
それで早速使わせていただきました。
その1
テストのため意地悪なことしてます。
画像は
200万ポリ(ログの値です)で
8人分(25x8)のデータが入ってます。
メモリの使用量も大幅に減ってます。
いろいろ無茶できそうですw
その2
広角で回転できると楽しいですねぇ
早速やっています。
その3
KeyNoteに移行中なのですぐに確認が...
でもすごく便利そうです。
ぜひ使ってみたいところです。
Re: celsviewの最大ポリゴン数 -
sio29 2008/09/26(Fri) 15:34
No.5437
>KeyNoteに移行中なのですぐに確認が...
すいません。言葉が足りなかったですね。
その1のみpironさんに対しての文章で、
その2は「カメラの傾き」の要望を頂いたhinataさんに対しての文章です。
その3はミコトモデルに興味のある人に対しての文章です。
確認云々は興味がある人のみお願いします。
Re: celsviewの最大ポリゴン数 -
piron 2008/09/26(Fri) 19:41
No.5438
こちらこそ気を使わせてしまってすみません
わかってましたがうれしくてうかれてました。
Re: celsviewの最大ポリゴン数 -
まつい 2008/09/27(Sat) 23:37
No.5441
Mikotoモデルに興味アリアリな一人として、
動作検証をしてみました。
スフィリカルデフォームとDualQuaternionとの違いで
深く曲げた箇所の変形具合は微妙に異なりますが、
それほど気にならないです。
DualQuaternion用にモデル側を修正すれば無問題かと。
なおモデルによっては、所々にトゲトゲが発生しますが、
これはポリゴンひっくり返り現象でしょうか。
あと、mkmを読み込んで連番PNG出力をしてみましたが、
Mikotoの連番MQO出力→CelsViewバッチ処理を行うより
ずっと早く、快適です。
Re: celsviewの最大ポリゴン数 -
sio29 2008/09/28(Sun) 15:50
No.5442
そこまで酷いのはどうでしょう。
sdefをbdefにしても同じ症状がでるのならばDualQuaternionのせいではなく、
アンカーの計算が間違っている可能性のほうが高いです。
Re: celsviewの最大ポリゴン数 -
まつい 2008/09/28(Sun) 18:00
No.5443
動作検証の続きです。2点ほど、判明した事象があります。
■MCSファイルに起因する問題
旧バージョンのCelsViewで保存した、Mikotoモデル用MCSファイルを使用したのですが、
McsObject項目に「sdef:hair」等が記録されており、これが影響しているようです。
DIFFツールで両MCSファイルを比較したところ、ここが異なっていました。
MCSファイル内のMcsObject項目をすべて削除したところ、
スカート部分以外は正常に表示されるようになりました。
■sdef、bdefに起因する問題
スカート部分はbdefで組んでいるのですが、これをsdefに変更すると、
破綻は「せいぜい面がひっくり返る程度」に落ち着きましたです。
逆に、全オブジェクトをbdefにすると、最初の画像と同じ
とげとげビームが出るようになります。
(未検証ですが、面がアンカーの重なりをまたいでいる箇所で異常が出やすいようです)
→現状でもbdef部分をsdefにリネームすれば、ほぼ問題なく使えるようです。
以上、ご報告でした。
Re: celsviewの最大ポリゴン数 -
piron 2008/09/28(Sun) 20:32
No.5444
こちらでも試してみましたが
とげとげビームが出方はまついさんの画像の通り
二通りに分かれました。
出ないほうのモデルは同じように腰部分のみに出ます。
おそらくルートの子ボーンだからでしょうか?
このモデルはbdefも使われていますが腰部分以外は
問題ないです。
もう一方、トゲトゲビームが出るモデルのほうは
sdefだけですが発生しています。
アンカー関連のオブジェクト構成が複雑だと
発生するように感じました。
この機能のおかげで
局面制御を入れているモデルでオブジェクト表示を切り替える
モデルだとオリジナルのMqoの設定がそのまま利用できるので
便利ですね。
連番Mqoで出力した場合その辺りの設定が無効になるので、
なにかしら処理しないといけなかったのでラクチンです。
Re: celsviewの最大ポリゴン数 -
sio29 2008/09/29(Mon) 00:37
No.5445
>スカート部分はbdefで組んでいるのですが、これをsdefに変更すると、
sdefのほうが正常にうごくというのがなぞですね。
>もう一方、トゲトゲビームが出るモデルのほうはsdefだけですが発生しています。
sdefもでますか…
自分の手持ちのデータだと面がひっくり返るデータはあるのですがトゲトゲになるデータはもってないで、うーむ
たぶんアンカー計算がおかしいと思うのですが…
Re: celsviewの最大ポリゴン数 -
まつい 2008/09/29(Mon) 20:27
No.5449
とげとげビームが出るデータです。
うちの環境では、複数台のPCで100%再現しています。
ご確認ください。
http://mattaku.sa-ra-sa.com/datas/haruhi_cheer_test.lzh
>もう一方、トゲトゲビームが出るモデルのほうは
>sdefだけですが発生しています。
以前のバージョンのCelsViewで、Mikotoから出力したMQOデータを読み込んで、
MCSファイルを上書きした後でも、その現象がsdef部分で発生しますか?
>出ないほうのモデルは同じように腰部分のみに出ます。
>おそらくルートの子ボーンだからでしょうか?
はっきりとは分かりませんが、おそらくそうだろうと想像します。
うちのデータでも、多分先端寄りのボーンで発生しているように見受けられます。
Re: celsviewの最大ポリゴン数 -
piron 2008/09/29(Mon) 22:33
No.5450
原因が特定できるように
再現用にシンプルにしてみたところ
発生箇所が少し変わりました。
ツインテ部分とフトモモ部分です。
・1つのボーンにいくつかのアンカーがあるとトゲトゲ具合が
変わるようです。
(腰ボーンに対してボディとスカート等です。)
・アンカーのオブジェクト1つあたりに
複数のボーンのアンカーが入っていると
問題が発生しやすいようです。
・複雑なところ?が出やすいようです。
再現用のモデルの場合ツインテールですね
MCSは
最新Verで生成し直しています。
こちらではMCSファイル関連で変形に差は生じていません
いろいろ触っているとKeynoteや04f
アンカーとボーンのしくみは一緒ですが
かなりクセが違いますね。それぞれ使いこなそうと
踏み込んで組み上げると両対応できなくなりますね。
[添付]: 257434 bytes
Re: celsviewの最大ポリゴン数 -
sio29 2008/09/30(Tue) 02:05
No.5451
まついさん、pironさんデータありがとうございます。
現在のcelsviewはmcsがあるとミコトモデルに対してmcsの設定がいろいろ悪さをして設定を変えてしまっているようです。
またアンカーの計算がおかしいのは確かなようです。
アンカーの内包するボーンの検出や頂点の検出がうまくいってないようです。まだ原因は分かりませんが…
>かなりクセが違いますね。それぞれ使いこなそうと
>踏み込んで組み上げると両対応できなくなりますね。
現在のcelsviewのミコトモデル対応はまだまだ実験段階なのでこれでfixということではありません。
一応、bdefに関してはmikotoと同じ変形をするところまでもっていきたいです。
sdefに関してはDualQuaternionのまま近い動きができればなと考えてます。
mikotoのウェイト計算は謎が多いので試行錯誤です。
まぁ、とりあえずはバグを取るのが先決ですね。
やはり自分のデータだけだとデバッグするのは難しいですね。