 Re: 次期Shadeに望むもの ( No.77 ) |
- 日時： 2003/08/06 20:24
- 名前： 宮田
- >>75重力で空間が曲がるなんてほとんどアインシュタインの世界ですね
あ、これは概念的な話なんですけど‥‥
球表面に描かれた直線を２次元に投影すると直線から半円までの色々な曲線が描けます。
同様に４次元空間（SFではなくて数学的に曲がった空間）での直線を３次元に投影すると
ねじれた曲線になるのではないかということです。(^^;;
逆に、ねじれを簡単に考えるために虚数軸を考えることで３次元での扱いが可能となった
‥‥ということだと妄想してました（笑）
>>76この動きがShadeの回転ジョイントでは再現できないことに気づいて愕然としました。
>>これもブラウザ中の階層に縛られる今のインターフェースによる限界なのでしょうか。
数学の「群」ですね。。
かなり高度な数学なので私にはまったく謎（魔法？）の世界なんですが（T^T)
ちなみに、旧エクスさんのマーク最初ルービックキューブだと思ってました。
ではなくって、多分ボクセルですよねあれ(^^;
PS
>>76くやしいのでスクリプトで動かしてみました。
すごいですねこのスクリプト。
できないことだと思っていたんですができちゃうんですね。
久しぶりに感動しました  。
|
| Re: 次期Shadeに望むもの ( No.78 ) |
- 日時： 2003/08/07 03:34
- 名前： 平山
- 参照： http://www2u.biglobe.ne.jp/~k_hiray/ps_db/search/
- ＞数学の「群」ですね。。
＞かなり高度な数学なので私にはまったく謎（魔法？）の世界なんですが（T^T)
え、そんな難しいものなんですか？
確かに６面そろえるのは相当難しそうですが・・・
＞ちなみに、旧エクスさんのマーク最初ルービックキューブだと思ってました。
＞ではなくって、多分ボクセルですよねあれ(^^;
なんか似てますね
ボクセルというと、ピクセルの立体版でしたっけ？
３DCGで空間を分割することによって効率的にレンダリングする
手法もボクセルっていいますね。
以前、この方法をTackSさんに教えてもらって、
スクリプトの処理スピードが大幅にアップしたことがあります。
＞すごいですねこのスクリプト。
＞できないことだと思っていたんですができちゃうんですね。
＞久しぶりに感動しました 。
ありがとうございます。
Ｒ５ならマニュアルで動かせるので、是非６面クリアに挑戦してみてください
といいながら、私も１面がやっとでしたが・・・(^^;;
http://www2u.biglobe.ne.jp/~k_hiray/tmp/rubic.gif
|
| Re: 次期Shadeに望むもの ( No.79 ) |
- 日時： 2003/08/07 22:41
- 名前： 宮田
- >え、そんな難しいものなんですか？
中高あたりでやる「集合」が基礎なんですが、集合を加減算レベルとすると群理論は微積レベルぐらいでしょうか。
最初見たとき友人達と「恐ろしいこと考える人がいるなあ」と話していました。
大学で数学を専攻した方なら解けるかと思います（実際解いた人がいました。合ってたかどうかは謎ですが‥）。
すでに忘れてしまっていますが、実は１・２層は動かし方が色々あるんですが３層は動かし方が数種類しかありません。
これさえ覚えれば誰でもそろえられると思います（私は自力で解けませんでしたのでカンニングしました 笑）
‥‥全然話が脱線してしまいました。
>ボクセルというと、ピクセルの立体版でしたっけ？
>３DCGで空間を分割することによって効率的にレンダリングする
>手法もボクセルっていいますね。
ソリッドモデルの場合、重心や張力を計算するのに無限分割は難しいので立方体の空間分割を単位にして計算して
いますね。医療分野の画像処理でも密度の問題があるので良く使われます。
サーフェスモデラとは少し考え方が違いますね＞ソリッドモデル。
>以前、この方法をTackSさんに教えてもらって、
>スクリプトの処理スピードが大幅にアップしたことがあります。
この方法を拡張すると衝突判定ができるかと思うのですが。
大まかな方法ですがバウンデンボリュームという方法で、形状をキューブなりボールなりで包んで形状の干渉を判定する
方法がありますよね。ラジオシティの場合、形状の交差が面倒を起こすので、これがあると形状配置が楽かなと思って
いたのですが‥ソリッドの考え方でShadeでは難しいのでしょうか。
（パストレはあまり気にしなくて良いようなので、すでに必要ないのかもしれませんけど）。
平面線画ではワーノックの手法というのを使えば早くできるそうですね。
|
| Re: 次期Shadeに望むもの ( No.80 ) |
- 日時： 2003/08/08 03:29
- 名前： 平山
- 参照： http://www2u.biglobe.ne.jp/~k_hiray/ps_db/search/
- ＞ルービックキューブ
大学の数学で解き方を研究するほどのものだったとは・・・
＞この方法を拡張すると衝突判定ができるかと思うのですが。
＞大まかな方法ですがバウンデンボリュームという方法で、形状をキューブなりボールなりで包んで形状の干渉を判定する
＞方法がありますよね。
じゃあ、私の場合大まかな方だと思うんですが、
形状を空間にランダムに配置する時、すでに配置した形状と重ならないよう
チェックする必要があるんですが、すべての形状をチェックしていたのでは
効率悪いので、空間を複数のボクセルに分割して、配置予定ポジションが含まれる
ボクセル内の形状だけを調べるという方法でした。
|
| Re: 次期Shadeに望むもの ( No.81 ) |
- 日時： 2003/09/14 20:05
- 名前： Tak
- 思い出したように書き込みますが、最近ビデオカードを試す機会があったので、報告です。
まず最近のATI RADEON廉価版9200ですが、なんの設定変更もせず気持ちよく動いてくれました。
ただ私のSCSIカードと相性が悪くいまははずしてます。安いカードのせいかゴーストもでてました。
今まで使っていたのがMatrox Millenium-IIなので、なにに変えても早くなるんではないかと期待してました。
ATIのカードのかわりにMatroxのG400を中古で買ってきてさしたところ、なんと遅いこと。
ハンドルを動かすと数秒ほどして画面のハンドル描画がされる有様で、Milleniumより遅くて使えません。一番早いのはOpenGLのアクセラレーションをきったときでした。
もうちっと安定度の高いGraphic APIになりませんか。(誰に言うべきか、あまりに筋違い、、）
OpenGLはMacと共通なので便利でしょうけれどこうビデオカードの影響をうけるのでは、信頼を失いかねないですね。
自分の環境でOpenGLの性能試験と診断ができるツールがあると問題の切り分けぐらいできるのではないかと思います。
|
| Re: 次期Shadeに望むもの ( No.82 ) |
- 日時： 2003/09/16 01:43
- 名前： 平山（管理人）
- 参照： http://www2u.biglobe.ne.jp/~k_hiray/ps_db/search/
- ビデオカードの問題、まだ尾を引いてるんですね。
よくわからないんですが、OpenGL導入してから、クイックレンダリングオフの
画面描画もOpenGLでやるようになったんでしょうか。
クイックレンダリングオフの場合も、R5から画面更新がすごく遅くなったような気がします。
＞一番早いのはOpenGLのアクセラレーションをきったときでした。
これも情けないけど、私の場合、切ってもR4より遅かったですね。
ほんとに切れてたんでしょうか。
ビデオカードすべてに合わせるっていうのも難しいのなら、
従来の描画方式も選べるようにしておいて欲しかったですね。
今はPC買い換えたので、そこそこ快適に表示されるようになりましたが、
重いシーンを編集する時に思うように動かないっていうのは
変わらないです。
|
| Re: 次期Shadeに望むもの ( No.83 ) |
- 日時： 2003/09/17 03:02
- 名前： 吉阪
- Shadeのクイックレンダリング（というより図形ウィンドウの描画）自身は
OpenGLを切っても、どちみちOpenGLのAPIをたたく形になってるかと思います。
＃常套手段なんですが、バックバッファにOpenGL描画を行い、それを表にフリップすると
＃アクセラレータが効かない状態でOpenGL Offってできます。
＃（この場合、OS標準のOpenGLソフトウェアレンダラが走ることになります）
ですので、OpenGL Offの場合は、純粋な（Shade独自の）ソフトウェアレンダリングじゃないんですよね
（これがShadeR4以前とR5以降との大きな違い）。
描画がR4以前は速かったのは、クイックレンダリング部分以外は8ビットモードで
描画していたからかなぁ、と想像しています（1ピクセル1バイトで処理するので速い？）。
あくまで想像の域はでないのですが。
なにせ、このへんの「本当の意味でのソフトウェアレンダリング」を
実装すると、非力なグラフィックカードでもそこそこ動くようになるはずなんですが・・・
わざわざOpenGLを通すこと自体（ソフトウェアレンダラに限っては）無駄が多いんですけどねぇ。
安定性もしかりです。
特に、ワイヤーフレームを表示するくらいなら
一昔前のグラフィックボードの場合は、ソフトウェアレンダリングでガシガシ書いたほうが速いですし。
ただ、Shade7以降はOpenGLによる速度の問題・安定性改善が大きなキーワードになってるようですので
改善はされるのではないかなぁ、と思ってます。
＃このへんのOpenGLがらみでの信頼性も含めた問題は、
＃私もかなりプッシュしてます（笑）。むしろ新機能とかよりも
＃優先度は高くしたほうがいいのでは、とも思いますね。
＃Shade7でのスリム化は、とにかく基盤（Shadeコア自身）を安定させる、
＃という 開発体制の表れだと信じてます。
後、OpenGLやDirectXを使ってレンダリングする場合、
描画するオブジェクト数が多くなると、ある量を越えるとガタッと速度低下したりも
します（グラフィックボードによるかもしれません）。
OpenGLなどを経由しない 純なソフトウェアレンダリングの場合、
そのあたりは描画情報に比例して重くなる、となりますで
アクセラが効いた状態よりもダメージも少なそうです。
そのへんの調査も重要かもしれませんね（いわゆる耐久テストですね）。
|
| Re: 次期Shadeに望むもの ( No.84 ) |
- 日時： 2003/09/17 20:19
- 名前： 平山（管理人）
- 参照： http://www2u.biglobe.ne.jp/~k_hiray/ps_db/search/
- 吉阪さん、こんばんは。
アクセラレータ切っても、
ワイヤフレーム含めてOpenGLでレンダリングすることに変わりはないんですね。
OpenGLソフトウェアレンダリングだと、グラフィックカードによる問題は出ないとしても、
Shade独自のソフトウェアレンダリングの方が速いなら
そちらも選択できるようになっていた方がいいですねえ。
そういえばR5から線の太さやポイントの大きさが変わりましたが
描画スピードの違いはそのあたりの影響もありそうですね。
R5以降の画面描画でもう一つ気になることがあります。
形状を移動させる場合、
R4までは移動後の形状の描画が終了する前に
移動の軌跡が表示されていたので、重い形状を移動させる場合でも
移動方向と距離の目安がついていたのですが、
R5以降は移動後の描画が終了しないとこの軌跡も表示されなくなりました。
このため、Shift+Xキーとマウスボタンを押したまま描画が終わるのを待たないと
形状がどこに移動されるかわからないということになってしまいます。
ドラッグ途中の状態も描画されるようになったのですが、
ドラッグ先に完全に追従はできないので、
ここでいいかと思ってマウスボタンをはなすと、
違うところに移動してしまうことがしばしばです。
(これくらい重くなってくると、しばらく編集しない形状は他のファイルに
エクスポートしておくなどの待避策をとらないと作業にならないです)
これは透視図のカメラアングル変更の場合も同じで、
アングル変更の目安にしていた立方体表示が
画面描画と同じタイミングでしか表示されなくなりました。
最終的な画面描画に時間がかかるのはしょうがないとしても、
移動の軌跡や立方体は即座に表示して欲しいし、
移動途中の形状描画はバウンディングボックスを選べるなどの
オプションも欲しいところですね。
エクスのころにも要望出したことがあるんですが、
作業効率に大きく影響する部分なので、何とかして欲しいです。
＞＃このへんのOpenGLがらみでの信頼性も含めた問題は、
＞＃私もかなりプッシュしてます（笑）。むしろ新機能とかよりも
＞＃優先度は高くしたほうがいいのでは、とも思いますね。
私もそちらを優先的にやって欲しいです。
＞＃Shade7でのスリム化は、とにかく基盤（Shadeコア自身）を安定させる、
＞＃という 開発体制の表れだと信じてます。
え、スリム化という方針が決まっているんですか。
しかし、基盤を安定させるという方針には大賛成です。
新機能を追加するにしても、基盤をきちんとしておいた方がスムーズに進むと思います。
急がば回れという言葉もあるし
|
| Re: 次期Shadeに望むもの ( No.85 ) |
- 日時： 2003/09/18 00:10
- 名前： 吉阪
- バウンディングボックス描画などの「はしょる描画」は、ぜひともほしいところですね。
OpenGL描画する場合は、基本はすべてを描画（変化しない部分も）ですので
そのへんの改善で高速化（快適化）できる部分はまだまだ残されているのでは、
と思ってます（編集中の形状の差分だけ描画するとか、アクティブな４面図中の
１面だけに再描画をかけるとか）。
あと、Shadeの図形ウィンドウの上に別のウィンドウを重ねると、
重いシーンの場合は、全部の再描画がかかって激重になるのもなんとか(^_^;;
やはり、ゲームでなくて編集ツールに対してOpenGL（ハードウェア）の恩恵を求めるのは
得手不得手があるような気もします。
平山さんのご指摘のは、OpenGLの効率化のために切り捨てたんじゃぁ、と
想像できる部分もありますね。
>え、スリム化という方針が決まっているんですか。
誤解を与える書き方してしまいました、すみません m(_ _)m
BCNとかのニュースサイトで、（かなり前ですが）時枝さんのメッセージがあって
もう一回原点を振り返る、みたいな表現をしてたんです。
なんで、あまり追加機能というよりも基盤をどうにか、って感じで
「スリム」って表現しちゃいました。
なにせ、ニュースサイトや雑誌を見る限りは、さすがに大きなばくちはしないんでないかな、
と思ってたりします（普通に考えると、Shade6の上に新たな機能を追加すると
（システム屋の視点から見ると）明らかに先がないですし(^_^;;。
そのあたりは、開発の方も十分認識されているようでした）。
> 急がば回れという言葉もあるし
これは同意です。
Shade自身は他の3DCGツールよりもいい部分もありますので（特に教育分野。簡単に扱えるという点で）、
そのあたりをのばして差別化していくってのも手かなと。
拡張は後から（後バージョンから）でもできるわけですし。
3DCGをこれから始める方々にとっては、他のツールだと複雑すぎなんですよね(^_^;;
|
| Re: 次期Shadeに望むもの ( No.86 ) |
- 日時： 2003/09/18 03:06
- 名前： 平山（管理人）
- 参照： http://www2u.biglobe.ne.jp/~k_hiray/ps_db/search/
- ＞編集中の形状の差分だけ描画するとか、アクティブな４面図中の
１面だけに再描画をかけるとか
なるほど、アイデア次第でまだまだ改善の余地はありそうですね。
必要でない計算はなるべく省略するっていうのは、
いろんなところで使えそうですね。
以前、動いている形状だけ(というか選択した形状だけ)にモーションブラーを
かけられないだろうかと思って、スクリプトでやろうとしたことがあります。
バックドロップとの合成がうまくいかなくて失敗してしまいました(^^;;
＞スリム化
一瞬機能も切りつめるのかと思ってしまいましたが、
無駄な贅肉を落とすって意味では、非効率的な処理やインターフェースの改善
といったものがメインで、必要な部分まで落とすってことはあり得ないですよね
＞（普通に考えると、Shade6の上に新たな機能を追加すると
＞（システム屋の視点から見ると）明らかに先がないですし(^_^;;。
やっぱりそう思われますか。
私も今の状態のまま機能追加を続けていくと、
さらに使いづらくなるばかりのような気がします。
＞Shade自身は他の3DCGツールよりもいい部分もありますので（特に教育分野。簡単に扱えるという点で）、
＞そのあたりをのばして差別化していくってのも手かなと。
これも同感ですね。チュートリアルを1日やれば、とりあえず使えるようになる
3DCGツールっていうのはそうないですよね。
高度なことをやろうとすると、使いにくさや物足りなさを感じてしまうブラウザや
ジョイントも、わかりやすさという点ではいちばんだと思います。
でも、このあたりでスリム化をはからないと、このわかりやすさという長所も
捨ててしまうことになりかねませんね。
|
Shadeプラグイン・スクリプト検索
次期Shadeに望むもの