- 1 名前：デフォルトの名無しさん [2008/01/26(土) 20:26:43 ]
-
ここで扱う内容は以下、
Java Media APIs
・Java Media Framework (JMF)
・Java Sound API
・Java 3D
・Java Binding for OpenGL（JOGL）
・Java Advanced Imaging（JAI）
・Java Image I/O
・Java 2D
・Java Speech API
・Java Telephony API（JTAPI）
本家
java.sun.com/javase/technologies/desktop/media/
- 71 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 12:32:42 ]
- よく嫁
>Java Binding for OpenGL（JOGL）
- 72 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 12:43:12 ]
- >>42
それなんていうMATLAB?
- 73 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 12:44:47 ]
- >>46
SIMDとGPUは携帯電話、サーバ、PC、PDA、家電に標準搭載されれば
プラットフォーム非依存ということになる。
- 74 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 13:48:05 ]
- >>71
あ、ほんとだ
勘違いしてた
- 75 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 22:59:06 ]
- KhronosがGPGPU技術標準化の作業部会を設立 - あの「OpenCL」も検討
ttp://journal.mycom.co.jp/news/2008/06/18/013/index.html
JOCLでファイナルアンサー
- 76 名前：デフォルトの名無しさん [2008/07/22(火) 21:58:52 ]
- TextSS
- 77 名前：デフォルトの名無しさん mailto:sage [2008/09/05(金) 00:10:24 ]
- JTAPIとCisco JTAPIの違いは差分だけ？
全くの別物？（んなわけないとおもうけど）
- 78 名前：デフォルトの名無しさん mailto:sage [2008/09/06(土) 00:32:11 ]
- 解決
思っていたとおり拡張でした。
- 79 名前：デフォルトの名無しさん [2008/09/21(日) 03:38:18 ]
- >>45
まったく使ってない
- 80 名前：デフォルトの名無しさん [2008/09/28(日) 07:07:46 ]
- JMFでmp3再生しようとしてJMF MP3 Pluginをブチこんでみたけど，一部のmp3ファイルが再生できない．
もしかしてVBRエンコードされちゃってるmp3ファイルとかは再生できないのかな？
- 81 名前：デフォルトの名無しさん mailto:sage [2008/09/28(日) 21:44:09 ]
- JMF向けMP3プラグインは複数あるからどれのことか分からん
- 82 名前：デフォルトの名無しさん [2008/10/04(土) 16:47:57 ]
- うお、お前らちょっと俺も混ぜろｗ
- 83 名前：デフォルトの名無しさん mailto:sage [2008/11/24(月) 11:55:25 ]
- >>73
ただ、JMFというよりはJVMの拡張という話題という気もする。
JMFからいちいちJNIでSIMD命令をコールするなんて構造にはならないだろうし。
- 84 名前：デフォルトの名無しさん mailto:sage [2009/01/27(火) 01:01:01 ]
- そういう目的でJNI使ってもあんまり意味無いよ。使えると使い物に成るは別。
結局はハード依存のほうが速度出せるのが現実だからな。クロスプラットホーム捨てればいいだけだけど。選択枝増やすのは大変だが減らすのは簡単。
マクってJMF使えないのな。どうせマク使わないからどうでもいいけど。
MP3プレイヤ作ろうと思ったけど、マクでは動かない事にするｗｗｗ
- 85 名前：デフォルトの名無しさん [2009/02/04(水) 02:50:39 ]
- >> 84
これ使えないの？
www.javazoom.net/mp3spi/mp3spi.html
- 86 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 10:56:34 ]
- Java Sound API と mp3 spi でできるよな･･･
- 87 名前：デフォルトの名無しさん [2009/02/27(金) 00:12:09 ]
- MonoじゃSIMDがサポートされたらしいけど、Javaは？
- 88 名前：デフォルトの名無しさん mailto:sage [2009/02/27(金) 12:02:10 ]
- SSEは使うけど、ベクトル化はないんじゃないかな。
- 89 名前：デフォルトの名無しさん mailto:sage [2009/02/27(金) 12:16:47 ]
- 基本的な配列操作とかにSSE使うようにして欲しいって言うのは、Acceptされてるね。
Javaの場合SIMDサポートするなら、SSEだけじゃなくてVISは外せないだろうし、
やるならHotSpotでがんばるんじゃないかな。
Monoもベクトル操作のIL追加して、JITでやってるみたいだし。
- 90 名前：デフォルトの名無しさん mailto:sage [2009/02/28(土) 15:06:10 ]
- 確か、1.4くらいのときからJVMはSSE使ってるんだよね。
どういう風に利用しているのかはよくわからないが。
- 91 名前：デフォルトの名無しさん mailto:sage [2009/03/03(火) 16:32:48 ]
- UseSSEで設定できるよ。
UseSSE=0 SSE使わない
UseSSE=1 SSE
UseSSE=2 SSE2
UseSSE=3 SSE3/SSSE3/SSE4A
UseSSE=4 SSE4_1/SSE4_2
基本はFPの演算をFPU使わないでSSEでやるのがメインじゃないのかな。
gccの-mfpmath=sseみたいなやつ。
JDK7の開発ラインだと、SSE4.2の命令使ってString.indexOfとかやってるみたい。
- 92 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 10:00:11 ]
- Java3Dについての質問です。
これって、一発書いてくるくる回したりするだけなら楽だと思いますが、
例えば、プレゼンテーションモデルが変更して再描画をする時とか、
いちいちJava3Dのオブジェクトを全生成する必要がある気がします。
つまり、再描画に対して恐ろしくパフォーマンスが悪い気がするということです。
この考えは正しいでしょうか？
Java3Dのオブジェクトを生成するのは、swingのRectangleなどを生成するのとは桁違いに重いので、
3Dプログラミングで再描画をするということを考えた場合、Java3Dはパフォーマンス的に致命的であるような感じがします。
みなさんの意見を聞かせてもらえませんか？
例えば、Java3Dでネットゲームを作ると言った場合、
連発する再描画が間違いなくボトルネックになる気がします。
- 93 名前：デフォルトの名無しさん [2009/04/11(土) 10:14:02 ]
- すいません、あげときます。
- 94 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 11:16:48 ]
- >>92
>いちいちJava3Dのオブジェクトを全生成する必要がある気がします。
なんでそう思うの？
- 95 名前：デフォルトの名無しさん [2009/04/11(土) 12:22:02 ]
- >>94
そうしない方法があるんですか？
例えば、天体シミュレーションのケースを考えましょう。
地球のまわりを月が回るだけの簡単なプログラムですが、
プレゼンテーションとしては
earth = [x, y, z]
moon = [x, y, z]
という座標が考えられます。
これを元に差分演算を行い、位置をどんどん変化させていきます。
これを描画する場合、
JPanelを継承した天体ビューアでは、
このモデルを引数として初期化する時にシーングラフを生成します。
この時、それぞれの天体を描画するためにSpheare < Primitiveを使うこととします。
微小時間後にプレゼンテーションモデルの位置が変わります。
この時ビューアの方に変更の通知が入り再描画になります。
再描画の方法としては、またオブジェクトを生成してシーングラフをリコンパイルするしかありません。
Java3Dはシーングラフの変更については描画結果とバインドしてくれているので、
シーングラフを動的に書き換えればそれが描画結果に反映されますが、
シーングラフを書く元となったデータとは分離されています。
これと同じケースはSwingでも言えると思います。
データを描画する際には常に全部再描画、通常、全Shapeオブジェクトの再生成です。
全生成というのは、シーングラフのUniverseなどを再生成するという意味ではなく、
上記の例でいえば、天体を表すオブジェクトを生成して、BranchGroupに動的につなげ直す必要があるということです。
再生成は避けられないと思います。
- 96 名前：デフォルトの名無しさん [2009/04/11(土) 12:28:47 ]
- 追記です。
もし、Java3Dがプログラム上で上記のような再生成を行ったとしても、
最適化技術によって、メモリ領域のreallocateが起こらない、
描画としても再描画については高速になるなどの技術があるのだとしたら、
それを記した記事を教えてもらえると助かります。
- 97 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 12:41:44 ]
- そもそもゲーム用じゃないと思うよ。
パフォーマンス気にするならCで組んだら。
pc12.2ch.net/test/read.cgi/tech/1235736212/ 【C++】 DirectX初心者質問ｽﾚ Part22 【C】
pc12.2ch.net/test/read.cgi/tech/1214127501/ DirectShowと戦うスレ Part 4
pc12.2ch.net/test/read.cgi/tech/1178285897/ 【PureVideo】DirectX Video Acceleration【AVIVO】
pc12.2ch.net/test/read.cgi/tech/1222593978/ 画像処理 その11
pc12.2ch.net/test/read.cgi/tech/1221215309/ OpenGLスレ Part12
pc12.2ch.net/test/read.cgi/tech/1061285378/ Managed DirectX vol.2
pc12.2ch.net/test/read.cgi/tech/1238898918/ Web系・組込み・ゲーム開発プログラマ交流
pc12.2ch.net/test/read.cgi/tech/1189892773/ C言語でトランプゲームを作りたい
pc12.2ch.net/test/read.cgi/tech/1230890476/ ゲームプログラムなら俺に聞け
pc12.2ch.net/test/read.cgi/tech/1212972014/ C# C＃ C♯でゲームを作ろう Part1
pc12.2ch.net/test/read.cgi/tech/1164171086/ 3Dアルゴリズム全般
pc12.2ch.net/test/read.cgi/tech/1206152032/ 【GPGPU】くだすれCUDAスレ【NVIDIA】
pc12.2ch.net/test/read.cgi/tech/1103655588/ SDL=Simple DirectMedia Layerでゲームだ
pc12.2ch.net/test/read.cgi/tech/1155153009/ 3Dグラフィックスプログラミング
pc12.2ch.net/test/read.cgi/tech/1071176841/ ゲーム製作に最適な言語
pc12.2ch.net/test/read.cgi/tech/1191484421/ ゲームの作り方教ぇて＞＜
- 98 名前：デフォルトの名無しさん [2009/04/11(土) 12:47:01 ]
- >>97
そもそも再描画は意識せず、
一回書いたらあとはJava3D上でのインタラクションしか追加しない
という前提で作られたライブラリだということでしょうか？
また、再描画時に全オブジェクトの再生成が必要だ、
という私の考えはそもそも正しいのでしょうか？
- 99 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 12:55:55 ]
- 間違ってると思うよ。
- 100 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 12:56:34 ]
- >>97
ダメスレ・オンパレード
- 101 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 12:57:51 ]
- よくわからんが、このあたりのソースでも読んでみれば？
www.asahi-net.or.jp/~cs8k-cyu/java3d/river.html
- 102 名前：デフォルトの名無しさん [2009/04/11(土) 13:01:45 ]
- >>99
どう間違ってるのか教えてもらえませんか？
- 103 名前：デフォルトの名無しさん [2009/04/11(土) 22:03:30 ]
- >>101
読みましたが、
"ひどい"という印象を受けました。
コードの質も悪いですが、何より悪いのは、
モデルであるはずのBoatなどがjava3dのオブジェクトにべったり依存していて、
とても再利用出来ないということです。
私はプレゼンテーションモデルを意識した実装をJava3Dで行おうとしています。
質問しているのは、モデル変更に伴う再描画においてオブジェクト生成のオーバーヘッドがあるのかという話です。
Java3Dの中で完結するインタラクションの類であれば、コストは低いでしょうが、
プレゼンテーションモデルが変更された時の再描画は、どうなるのかというのは、とても気になるところだと思います。
- 104 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 01:28:48 ]
- 基本的に再利用自体にオーバヘッドが有ると思うけどね。
java自体で描画してない以上、非効率なのはしょうがない。
- 105 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 01:56:18 ]
- 自分、以前Java3Dでゲーム作ってたけど、JOGLに移行した。
オブジェクトに直接座標を指定するだけでけっこう面倒だったような記憶がある。
一通りの機能を実現するための手続きは用意されているんだけど、
それからちょっとでも外れたことをしようとすると途端に難易度が上がるという印象だった。
で、描画エンジンをJOGLで作り直した。
モデル描画と座標管理を自前で作ることになったけど、それでもまだJava3Dでゲーム作るよりは
楽という気がするなあ。
- 106 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 03:59:50 ]
- java3dはゲーム向きじゃないよなぁ
- 107 名前：デフォルトの名無しさん [2009/04/12(日) 08:37:05 ]
- >>104
再利用にオーバーヘッドがあるのは当たり前です。
例えばUnixのコマンドはとても再利用性が高いパーツだと思いますが、
パイプを使ってやりとりするため、非常にオーバーヘッドが高いです。
初回でオーバーヘッドがかかるのは我慢出来ます。
Java3Dはシーングラフについて最適化かけていますし、なので非常に軽くくるくる回ったりします。
今問題なのは、再描画のコストです。
プレゼンテーションモデルが変更された時、再描画は初期描画と同等のコストがかかるというのが理論的に適切なのでしょうか？
プレゼンテーションモデルと完全に分離した実装をした場合、Java3Dは非常にやりやすいです。
しかし、インタクション（ゲームとかもその類です）を前提にした場合、再描画のコストがひどいのではないかという予想です。
めんどくさいので自分ではやっていません。
やった人がいたら教えてください。
>>105
外れたことというのは何ですか？
確かにAPIが複雑すぎるゆえに、何をするのか分からないライブラリがありすぎます。
openGLはシンプルなAPIで非常に分かりやすいですね。
超高級のRubyと中級言語のC言語みたいな感じだと思います。
RubyはAPIが複雑すぎて意味不明です。私はPythonを好みます。
>>106
ゲーム向きかどうかでない理由はなんですか？
ゲームのみに向いていないのか、もっと一般的にゲームの含まれるクラスについて向いていないのかということをはっきりさせた文章を書いてください。
私は、オブジェクトで管理出来るという利点からして、シーングラフ自体はゲームに向いていると考えます。
- 108 名前：デフォルトの名無しさん [2009/04/12(日) 08:42:37 ]
- 私がもう１つ、Java3Dの存在意義について悩むところは、
Java3DはJava実装なので、例えばCPythonではサポートされません。
Jythonを使えば、Jython3Dなどというラッパーライブラリが存在するのでそれを使えばいいですが、
私は、JavaだろうがPythonだろうが、可読性の高い低いはプログラマの実力次第だと思っているので、
Eclipseのサポートを捨ててまでJythonからJava3Dを使う理由がよく分かりません。
プログラムという大きな単位のうち、表面部分のプログラミングがどれだけ負担かと考えると、
それほどでもないと言った感じがします。
Java3Dは、プロトタイピング用の言語なのでしょうか？
こういう絵になるかもなーというのを描くための言語と見ると存在意義がある気がしますが、
描画する限りはインタラクションが存在しないアプリケーションなどありえないはずなので、
そう考えた時、もし再描画に高いオーバーヘッドが存在するならば、Java3Dはそもそも使い物になりませんという話になる気がします。
・・・というか、再描画にコストかかるかも分からんとか言ってるなら、実験すればいいのかな・・・
- 109 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 08:44:59 ]
- java + 3d + game + library + power これをストレスなくいっぺんにできる環境は「果たしてPCなのだろうか？」考えたことあるか
- 110 名前：デフォルトの名無しさん [2009/04/12(日) 08:49:00 ]
- CPUやGPUの性能を問題にしているのではありません。
大体、ゲームを作るだなんて一度も言っていません。
- 111 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 09:03:47 ]
- ＞もし再描画に高いオーバーヘッドが存在するならば、
ハード知識がこの程度しかないなら、その長文は君がパイソンを使えば解決するのであって、ライブラリが肌に合うかどうか程度の問題でしかない。
それよりも、高速な再描画についてはGPUがもうすこしで汎用プログラム可能となるから、その問題もあと数年（３−５年程度）で解決できるだろう。
それまで待てないなら従来どおりGPUの方（のライブラリDirectXやGLやGPGPUなど）を勉強するしかないな。
ただ、DirectXなどのライブラリをJNI経由で呼べばよいだけなんだけど、オーバーヘッド君じゃそういう発想はないんだろうな・・
- 112 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 09:13:58 ]
- Javaでmedia(a/v)とかgameに活気がなくいつまでもjavaがデスクトップに進出できないのは、こういう熱意ある若いクリエータが少ないからだろうと思った。
rubyよりpythonとかいってるところを見ると、いまだとよりお気楽なflashの方に活路を見出すだろうし、数年するとflashは廃れてmssilverとかjavafxとかの時代になるんだろうな。
これじゃjava mediaに戻ってくる奴はいないよな。
- 113 名前：デフォルトの名無しさん [2009/04/12(日) 09:47:54 ]
- >>111
確かに、私にはハードの知識がありません。
研究室としてはハードよりのこともしていますが、私のグループは違います。
私は高レベルなAPIを使う方が楽でいい、という主義なので、グラフィックはまずjava3dから入りました。
よって、その中で何が起こっているの分かりませんし、
オブジェクト生成時、シーングラフ解析時に何が起こっているのかもよく分かっていません。
しかし、なぜハードの話が出てくるのでしょうか？
私は再描画の際にオブジェクトの再生成が起こることは不可避なのかという質問をしています。
ずばり、インタクティブな操作においてプレゼンテーションモデルが書き換わり再描画をする場合、
joglとjava3dではどのような性能差があるのかお答え願いたいです。
joglはfloatなどのprimitiveに対して単純データ結合であり、単純な描画をしてくれるという印象です。
しかしjava3dはシーングラフというオブジェクトを経由するのでその生成コストが免れないのでないかといっています。
joglの場合でも、ポリゴンを生成したり色々と生成コストがかかるものでしょうか？
例えば、球を10000個ほど再描画する際にjoglとjava3dではどのくらいの性能差がありますか？
java3dは初期描画時にシーングラフ（Universeなど）の生成が入るのでその分遅いですが、
それ以降は、描画対象のオブジェクトだけを再生成すればいいので、別段遅くないということであれば嬉しいです。
- 114 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 11:24:43 ]
- そういうのを研究室で聞いたらどうですか？
蓄積されたノウハウってやつですが、３流大学じゃそういうノウハウもないんでしょうけど。
＞私は再描画の際にオブジェクトの再生成が起こることは不可避なのかという質問をしています。
不可避かどうかはソフトではなくて、ハードの方に依存していて、再生成をハード側が要求するのもあれば、
しないのもあります。
たとえばハードいっても、抽象化したハードjvmならnew（ソフト上）をするし、ネイティブリソースを直接いじる（ハード上）ならcでスタックにおくだけですし。
高APIでもいいですが、より複雑なことをやりたい、なにか物申したいなら、そういうあたりを勉強してからじゃないですか？
cpuにfpuユニットが搭載され、今ではsseもあたりまえにハード搭載されてきた歴史があります。
しかし、３Dは多少マザボにオンチップとなりはじめましたがまだ搭載ハードではないし、
ソフトで実装してるなどあたりまえで、ハード・ソフト混在の状態です。
たとえばDX9のアプリをDX6当時のGPUでは高速描画出来ないのでソフト処理になるため、どんなに進化してもこのようにソフトの仕様（再生成必要など）に依存する。
以上のように抽象化する下地が出来てないので、３Dはあなたが思っているようなライブラリ作れません。
くだらない長文を書いて荒らすよりも、まずは自分で測定し実際に問題があったところを質問したらどうですかね？
あなたの哲学妄想はチラシの裏に書いたらどうですか？
- 115 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 11:57:34 ]
- 何か別のアプリがあって、その表示エンジンとして使いたいならOpenGLの方が楽だと思う。
最近のバージョンには触ってないけど、Java3Dの1.2とか1.3だと、
モデルを動かすのに速度ベクトルを設定して、Java3D側で動かしてもらうってやりかただった記憶がある。
全体的に、直接的にパラメータをいじらせるのを避ける思想という感じがする。
Java3Dに脇役に徹してもらうのは難しくて、アプリケーションをJava3Dの流儀に合わせる必要がある。
- 116 名前：デフォルトの名無しさん [2009/04/12(日) 12:13:05 ]
- >>115
直接的にモデルに相当するパラメータをいじられるのを嫌うというのは当たり前だと思います。
Viewの変化に関するストレテジ的なパラメータ設定しか出来ないようになっています。
例えば、見た目を変えるとかその程度です。
Java3dでオブジェクトの位置を動かすのはTransform3Dをいじって動かすという方法が考えられます。
しかし、描画したあとにTransform3DをいじるということはMVCフレームワークの観点からいって、かなり邪道であるように思えます。
Transform3Dは描画する時の座標設定でのみ使って、のちの移動はすべてモデルの変化を反映する形で再描画するというのが正しいと考えます。
>Java3Dに脇役に徹してもらうのは難しくて、アプリケーションをJava3Dの流儀に合わせる必要がある。
この部分ですが、"脇役"というのは何を意味していますか？
プログラムに主役脇役がいるということは初耳です。
独自にプレゼンテーションモデルを設定し、それをJava3Dで見るだけという方法ではいけないということですか？
そのプレゼンテーションモデルはjoglであろうがJava3dであろうが、あるいは他のライブラリであろうが表示することが出来るものです。
あなたが意味しているのは、
もしJava3Dは何かプレゼンテーションモデルを作ってそれを表示させる為のものではなく、
Java3Dのオブジェクトを繋ぎ合わせて絵を描くためのお絵描き言語だということでしょうか？
"難しい"というのであれば、どう難しいということを説明してください。
>>114
三流ですいません。
- 117 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 12:57:30 ]
- CADの世界じゃ「オブジェクトを繋ぎ合わせて絵を描く」のが主流だな。
あちらの用語ではフィーチャー・ベースとかいったかな。
アニメーションも2Dプログラミングの世界ならスプライトを使うが普通だし、
最初から高級APIだとうたうJava3Dのアプローチとしては自然じゃないかな。
- 118 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 14:11:16 ]
- 何もやったことなくて愚痴ってるだけでしょ
新手の荒らしっところだな
- 119 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 14:24:23 ]
- オーバヘッド君がやりたいことは、多分3Dのvisualizationとかだろうな。
www3.math.tu-berlin.de/jreality/21-0-screenshots.html
能書きは多いけどどうせ愚痴ばっかりで自分でライブラリ作れないだろうから、先人の作ったのをありがたく使わせてもらうのがいいんじゃないの？
どの道３D（ゲームも含む）やるならjava,rubyよりも、英語が完璧に出来ないと苦労するんじゃないかな・・
- 120 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 14:40:37 ]
- >>119
でも、こんな曖昧な質問レスに対してそれでもみんな構ってくれてるのが偉いというか大人というか…
「とりあえずサンプルコード組んで晒せ。その後でなら話聞いてやる」
というスレもあるからなあ。
- 121 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 15:00:22 ]
- このスレは閑古鳥だからヒマなんだろ
ていうか、ある程度出来る奴ならこんなところこないで英語のフォーラム行くし
日本語しか出来ないならクリエイティビティなことはあきらめて日雇い三流プログラマ（月収１５万）がお似合いだろうな
- 122 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 15:53:37 ]
- >116 はなんじゃ？ここは学会じゃねぇぞ
- 123 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 16:00:53 ]
- おまえら元気にしてるんだな・・・。
- 124 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 16:12:50 ]
- 三流大の研究なら、めんどくさいので自分ではやっていません。やった人がいたら教えてください。じゃなくて、自分で検証してみろよ。
Cで組んだほうが早いと思うよ。面倒なので自分では遣らないけどなｗｗｗ
cudaででも直接描画したら？
pc12.2ch.net/test/read.cgi/tech/1206152032/
【GPGPU】くだすれCUDAスレ【NVIDIA】
- 125 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 16:17:36 ]
- まあ、よりプリミティブなものを求める気持ちは分かるけどね。
俺もJava5のfor拡張は、登場から1年近く使ってなかったし。
- 126 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 16:35:28 ]
- >>125
それはgenericsあってのforだから、使かわなかっただけじゃね？
- 127 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 16:48:11 ]
- >>126
いや、ArrayListがRandomAccessをインプリメントしてるのに、
イテレータを使ってくれることが何か納得できなかったｗ
そういや値のバリデータに正規表現を使うこととかも抵抗があったな。
実用性の範囲が明確になってくるとそういうのは次第に消えてったけど。
- 128 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 16:53:11 ]
- implements RandomAccessに納得するかどうかは意味上の話だからgenericsとはまた別の問題と思うが。
それと、バリデータじゃなくてバリデートだと思うんが・・・
- 129 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 16:58:49 ]
- >>92の再来？相変わらず文脈が読めてないな。
- 130 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 17:11:07 ]
- java3dはあと何年かかるんだろう。もうすぐメモリも８Gとかあたりまえの時代がくるのに・・・
- 131 名前：デフォルトの名無しさん [2009/04/12(日) 18:40:18 ]
- >>117
まず、何が"自然"なのか、補語が抜けています。
it is natural to 何なのですか？
たぶん言いたいことは、シーングラフのTransform3Dをboatがいじって移動させることは妥当であると言いたいのでしょうが、
私が目黒川のコードで悪いといっているのは、boatがTransform3Dに依存しているというところです。
プレゼンテーションモデルの変更をすべてシーングラフに通知する必要はなく、
例えばボートが動いたということであれば、
まずボートのモデルを移動させて、次にプレゼンテーションモデルから、ボートの位置が変わったことをシーングラフを含むビューに通知すべきだということです。
簡単にいえば、「依存関係が逆」ではないかと言っているのです。というか双方向参照になっています。論外です。
"Java3Dのシーングラフはモデル中のあるオブジェクトの移動については全描画をしなくとも部分的なシーングラフの変更のみで対応出来ます"
という仕様にすぎません。
仮にTransform3Dが不変オブジェクトならば、これが不可能になり、モデルが何か変更したらそれを通知するためにはオブジェクトの全生成をしますという仕様になります。
これは耐えられないのでシーングラフがオブジェクトの移動に関しては部分的に変更を許すというインターフェイスを設けたにすぎません。
CADの件についてもフィーチャーベースだろうが何だろうが、基本的にはこういう原理かと思います。
Java3Dが高級APIだからとかいう理由ではなく、単にモデルの変更を全部受けずに、移動に関しては部分的に受けた方がパフォーマンスがいいのでそうしたということでしょう。
ただ一方で、Primitiveなオブジェクトについては座標系のデータが不変になっており、融通が効かなくなっています。
それについて部分的な変更を許容することに、理由は知りませんが、意味を感じなかったのでしょう。
スプライトの話はどうしてここで出てくるのか理解出来ません。
スプライトというのは知らなかったので、今wikiで調べたのですが、
モデルがビューに依存していい理由がどこにあるのか分かりませんでした。
CADの例も同様です。
- 132 名前：デフォルトの名無しさん [2009/04/12(日) 18:42:12 ]
- 続きです。
おそらく、ある分野においては、
モデルをビューに対して依存させることでプログラミングをしやすく出来る的なことが言いたいのでしょうが、
私には一体どういう分野でそういう理屈が通るのかが分からないので教えてください。
CADにおいて、あるいはゲームのアニメーションにおいてモデルがビューに依存すると"よい"といえる具体例をお願いします。
>>124
三流なのでそれすらも出来ないということです。
>>130
何が？
あと何年、"何を達成するのに"かかると言っているのですか？
- 133 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 18:53:17 ]
- 他のクラスに強く依存しているとは言うけど、別に彼はライブラリ作ってるわけでもなければ
モジュール化するためのサンプルを書いてるわけでもないからね・・・・
どうでもいいけど大御所の３Dのプログラミング本（当然英語だけど）読んだら？
- 134 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 19:01:57 ]
- それはそうと、今度は長文の爆撃投下か・・・
新手の荒らしはいろんなところから現れるよな
- 135 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 19:07:20 ]
- 彼の理想郷を現実のものとして実現させるには、あと８年はかかるだろうな・・・
- 136 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 19:10:54 ]
- >>130
しばらく放置気味だったから、シェーダ対応の1.5が出たときはびっくりした。
ただ、LookingGlass作ってた人もSunをやめちゃったし、JOGLも正式リリースされたし、
有り難みはだいぶ薄くなっちゃった感じはあるな。
- 137 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 19:21:01 ]
- いまSUNはIMBの買収とか経営の方で立てこんでるみたいだから、人がいなくなるってのもしょうがない感じはする。
ソフトの世界だと、別に会社がなくなってもそのプロジェクト自体は存続する（特にオープンにしてあると）から、外の世界での騒動とはあまり関係ないんだけど。
IMBCが作ろうがSUNが作ろうがプロジェクト自体の出来はあまり差はないかな。APIはその会社の癖がだいぶ出るだろうけど。
どうでもいいけど、java mediaのコーデックどうするつもりだろう・・
- 138 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 19:31:40 ]
- ……IMB?
- 139 名前：デフォルトの名無しさん [2009/04/12(日) 19:41:26 ]
- >>135
ようするに
"どんな言語で書いてもオーバーヘッドがない"
という状態ですか。
メモリの問題ではなく、CPUの性能が上がったり、
GPUを利用したプログラムが標準になってくれば、
基本的には"開発者に優しい"ことが最優先になってきます。
現状でもかなりそうですね。
つまり、現在不快に思える処理時間の遅さが不快でなくなればいいということです。
私の理想は、"美しい設計"です。
設計的に曲がったことは絶対にしたくありません。
理由のない設計は、何より可読性を落とします。
プログラムを読む時、それがある正しい方針の元に設計されている時、明らかに読む速度は上がります。
可読性という点において、プログラミング言語による差はもちろんあります。
例えば、Pythonで書かれたプログラムは一般的にJavaで書かれたプログラムより読みやすいでしょう。
しかし、わけの分からない設計、あるいはもっと局所的にいえば、フィールドの使いまわしなど、
可読性を落とすもっと大きなファクターはたくさんあるわけで、
結局のところ、可読性は、そのコードを書いたプログラマの腕依存ということになるわけです。
目黒川のコードは非常に読みにくいです。大きな理由としては、
1. 設計思想が意味不明
2. 変数の名前が理解不能
3. どこで定義された変数なのか理解不能なことが多い
と言ったところですね。これを書いた人はコードコンプリートを読んでないのでしょう。
>>136
joglがリリースされたことと
Java3dのありがたみの間にある相関性は何ですか？
それ以前はjavaで3dといえば、java3dしかなかったという意味ですか？
- 140 名前：デフォルトの名無しさん [2009/04/12(日) 21:01:25 ]
- そろそろ「その理想的な設計に基づいたソースコード」をアップしてくれませんか？
長文能書きは聞き飽きたので
- 141 名前：デフォルトの名無しさん [2009/04/12(日) 21:04:10 ]
- こういう人っていつの時代でもいるけど、いっつも上の方７６度ぐらいのところを向いてるよねｗｗ
- 142 名前：デフォルトの名無しさん [2009/04/12(日) 21:11:02 ]
- まあ、こういうおとぼけチャンは「かっちょいい３Dライブラリ」をいつか作ってくれるだろうから気長に待ってばいいんじゃね？
だけど８年以内に作ってくれよ。
そうじゃないとハードの方が先に進化して必要とされず、せっかく作っても「かっちょ悪いライブラリ」になっちゃうから。
- 143 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 21:11:41 ]
- 過疎スレなんだからまったりしようぜ
- 144 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 23:48:53 ]
- ここで、Java3Dについて書くと、添削してもらえるらしいです。
査読してもらってから投稿しましょうね。
- 145 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 23:52:04 ]
- 実際問題、このスレでjava3D使ってる人いる？
漏れはJOGLに逃げたが。
- 146 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 00:26:52 ]
- 高レベルで使いにくいから俺もJOGL
- 147 名前：デフォルトの名無しさん [2009/04/13(月) 20:34:55 ]
- おれもjogl勉強し始めた。
めんどくさいけど、3Dプログラミングなんて単なる技術的な問題で、
設計も何もなく、ただAPIのとおり組み立てればいいだけだから、気が楽だね。
Java3Dの方が表面的には楽だけど、
joglの方が
1. APIがコンパクト
2. openGLのことならぐぐればすぐに出てくる。Java3Dは辛い。
3. てゆうか研究室の人に聞けばたぶん何でも分かる。
という点でむしろ良いのではないか。
そもそもopenGLはグラフィック学習用の言語であって、
実用性うんぬんを差し置いても勉強しなければいけないものなのではないか？
それは、メモリアーキテクチャを勉強するのにC言語を勉強するのと同じ意味なのではないか。
実用性の問題ではない。コンピュータリテラシの問題だ。
そう判断して、joglを勉強し始めた。
いっとくが、それでもやっぱりおれは高級言語が好きだ。
特にPythonが好きだ。
C++まではただ動くことが条件だった。
Javaで、安全にプログラムを書く仕組みが組み込まれた。
Javaの普及によって色々なフレームワークなどが開発された。
オブジェクト指向への貢献としてはJavaは良い仕事をした。
そして、Pythonは、そこに美しさを組み込んだ。
だからおれはPythonが好きだ。
たぶん出来る人間はPythonが好きになる。
この言語にはそういう魅力がある。
オブジェクト指向が分かれば間違いなくPythonに魅力を感じる。
Rubyにはそういう魅力はない。
- 148 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 21:53:04 ]
- よそで熱弁しろｗ
- 149 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 22:05:19 ]
- リアルでは誰もかまってくれないんだろうなぁ・・・・
- 150 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 22:19:59 ]
- >>147
> おれは2chで自分語りするのが好きだ。
まで読んだ。
- 151 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 22:21:20 ]
- それくらいにしといてくれ。
自棄おこしてコピペ荒らしとかになられても困る。
…まあ、もしそうなったら単にまた過疎化するだけか。
- 152 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 22:42:10 ]
- Cでdirectx弄ると、3DCGソフトの出力が使えて便利とかあるけどね。
全部javaも良いけど、簡単な方法はいくらでもある。
人のコードの批判はするけど、自分では３流故にコード書けないみたいだしね。
美しさよりもまずは動作させないと論文に成らないと思うｗｗｗ
- 153 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 23:43:57 ]
- 論文というより、まだ始めたばっかりの初心者だと思うんだが
- 154 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 23:55:13 ]
- 始めたばかりならどんな糞コード書いてでも動いて完成させることを最優先した方がいい。
- 155 名前：デフォルトの名無しさん mailto:sage [2009/04/14(火) 01:07:46 ]
- >>152
動作しなくても論文にはなるだろうし、動作しないと論文にならないものならdirectxとか使ってる場合じゃないだろ
- 156 名前：デフォルトの名無しさん [2009/04/14(火) 07:23:35 ]
- Java3Dはjavaプラットフォーム上でしか動かない。
joglはopenGLを元にしているので、javaプラットフォーム上は当然として、C実装の言語上でも動く。
openGLが分かればjava3Dはわりと理解しやすい。
よってjoglを勉強するのが最善。
ここには、CからJavaに向かう時のパラダイムシフトがないし、
ただのライブラリ、言ってしまえば、バカでも勉強すれば分かるところ。
抽象的な概念もないし、勉強しておくべきだろうな。
と思った。
あと少しでおれは神プログラマになれる。
- 157 名前：デフォルトの名無しさん mailto:sage [2009/04/14(火) 21:30:18 ]
- 納得しようとしたけど j って付いてる時点で諦めた
- 158 名前：デフォルトの名無しさん mailto:sage [2009/04/14(火) 23:25:55 ]
- 動作しない物を論文に書いても検証出来ないと思うが。
結局はGPUで描画されるから、理解のためにGPU直接動かせば良いじゃん。
その仕組みが分かった上で、高級言語のjavaでどう有るべきか論文書くならまだ分かるけどさ。
- 159 名前：ちんこ ◆GbXlaaQNk. [2009/04/18(土) 18:56:04 ]
- 当方ちんこだが、
今、openGLの勉強をしている。
でも、
"これはアプリケーションを構築するという意味では使い物にならんかもね"
というのが正直なところだ。
アプリケーションを構築する上では、
オブジェクト指向だからとかそういうことではなく、Java3Dを使う方が得策な気がする。
グラフィックを使うプログラミングのうち、95%の欲求はJava3Dによって簡単に解決される気がする。
残りの5%の人はまぁ頑張ってください、と。
こういうライブラリのとる態度というのがそういうものだからね。
多くの欲求を満たすために設計されて、それ以外の人は頑張ってという態度をとる方が効率がいい。
例えば、Javaにしても、アプリケーションを構築する上でたぶん95%の欲求はJavaで満たせる。
だけど残りの5%はC/C++でしか満たせないでしょうと。
Pythonとかにしても、パフォーマンス上の理由で使いたくないという場合はほとんどないと思う。
CPUの性能が上がっていくから、ボトルネックはどんどん局所化していく。
人はどんどん高水準な言語を求めていく。
それでも、その元となっている言語を疎かにしていいというわけではないんですね。
特に、そういう原始的な言語は基本的な理論を含んでることが多いから。
openGLは3Dグラフィックの基本が含まれている。
JavaFXはJava3Dをサポートすることを願う。
そうすれば、Java3Dは生き残れるw
- 160 名前：デフォルトの名無しさん [2009/04/18(土) 18:59:04 ]
- openGLってなんですか？
- 161 名前：ちんこ ◆GbXlaaQNk. [2009/04/18(土) 19:08:45 ]
- 知らんけど、
3Dグラフィック処理をそれなりに簡単にやってくれる
業界標準気味のライブラリ。
それなりに面白い。
openGLは、どの言語でもライブラリが作られるから、必須な気がする。
- 162 名前：デフォルトの名無しさん mailto:sage [2009/04/18(土) 19:21:01 ]
- ………ここまで来ると、本当の天然なのか、
本物は既にこのスレから立ち去ってて、あのキャラを面白がって演じてる人間がいるのか、
判断が難しいところだな…
- 163 名前：デフォルトの名無しさん mailto:sage [2009/04/18(土) 20:30:26 ]
- これがうわさの、春になるとニョキニョキしてくる「ちんこ」ってことでしょｗ
- 164 名前：sage [2009/04/18(土) 23:59:57 ]
- JMFで、悩んでいます。
巷の画像処理技術に興味を覚え、今更ながら時代遅れのJMFを勉強
をはじめました。JMF関連の書籍やサンプルコードの入手して簡易
の動画ツールを構築しています。
その折、サンプル動画ファイルを引き込みMediaPlayer クラスの
getVisualComponent()でVisualコンポーネントを得ようと試みて
ますが、nullの返却しか得られません。
(JMStudioでは映像を見る事ができる動画ファイルを扱ってます)
getVisualComponent()の利用で注意する点を御存知でしょうか。
諸兄方々の御力添えを頂けますよう宜しくお願いします。ﾉｼ。
- 165 名前：デフォルトの名無しさん mailto:sage [2009/04/19(日) 00:21:47 ]
- コード晒さんとなんとも
- 166 名前：ちんこ ◆GbXlaaQNk. [2009/04/19(日) 08:54:28 ]
- よし、今日はopenGLの教科書を読み切るぜ！
天才だから余裕w
- 167 名前：デフォルトの名無しさん [2009/04/19(日) 10:41:48 ]
- WindowsならJMFよりFMJだれかやってないか？
アパーアアアアアアアアアアアアアアアアアアム！！！！！！
- 168 名前：sage [2009/04/19(日) 10:41:52 ]
- >>165
レスありがとうございます。
公開向けにコードをカスタマイズしてましたが、avi形式に変換
する事でmpgファイルを扱えるかも知れないと気付きました。
もう少し、がんばります。ﾉｼ。
- 169 名前：デフォルトの名無しさん mailto:sage [2009/04/19(日) 10:48:25 ]
- codecねーんじゃね？JMF的に
- 170 名前：デフォルトの名無しさん mailto:sage [2009/04/19(日) 11:08:32 ]
- openglのグラボが高い現実。
directxのほうが安いぞｗｗｗ
- 171 名前：デフォルトの名無しさん mailto:sage [2009/04/19(日) 15:43:18 ]
- JMFはcodecは自前で実装するもんだから無いだろうな。
winの実装はDirectXのベタラッパーだからバグもばっちり再現だし。
- 172 名前：ちんこ ◆GbXlaaQNk. [2009/04/23(木) 18:58:16 ]
- java3Dやばい。
何この神ライブラリ。
気に入ったw
- 173 名前：デフォルトの名無しさん mailto:sage [2009/04/25(土) 03:38:11 ]
- 他所では動かない現実ｗｗｗ
- 174 名前：デフォルトの名無しさん [2009/05/19(火) 01:37:26 ]
- >>1
且且~
且且~
∧__∧ 且且~
（´･ω･) 且且~
`/ヽＯ=Ｏ且且~
/ ‖_‖且且~
し￣◎￣◎￣◎
皆さん､お茶が入りましたよ…
- 175 名前：デフォルトの名無しさん mailto:sage [2009/05/19(火) 22:55:34 ]
- ageるなksg
- 176 名前：デフォルトの名無しさん [2009/06/05(金) 14:54:13 ]
- >>174
∧,,∧ ∧,,∧
∧,,(´-ω-)(-ω-｀)∧,,∧
( ´-ω)旦o) (o旦o(ω-｀ )
(_ o[( ´-) (-｀ )]o _)
└'ー-（_ )][( _)ー'┘
'ｰ'^ｰ' 'ｰ'^ｰ'
- 177 名前：デフォルトの名無しさん [2009/06/23(火) 21:40:17 ]
- JMC (Java Media Components) を使ってる人はいないのかな?
floris.ouwendijk.nl/blog/index.php?blog=2&title=java_media_components&more=1&c=1&tb=1&pb=1
JavaFXと一緒にダウンロードできるライブラリで、
Java 7からは標準になる模様。
OSがネイティブで扱えるコーデックは全部対応するとか。
これが本命じゃね?
- 178 名前：デフォルトの名無しさん [2009/06/24(水) 08:41:17 ]
- デスクトップ（２D）関係はjavafxにするみたいだよ。
数年前からアナウンスあったけどコーデックとかもjavafxは組み込み済みだし。
それとJMFはjdk1.7で少し結合されるんじゃなかったか。
- 179 名前：デフォルトの名無しさん mailto:sage [2009/06/24(水) 11:24:28 ]
- すでにJava Soundが統合されたのにこれ以上何を・・・
- 180 名前：デフォルトの名無しさん mailto:sage [2009/06/24(水) 11:51:27 ]
- java seに結合して組み込むならSPI方式とかプラグイン方式とかのフレームワーク化がお似合いでしょ。
mp3とか264とかのコーデェックを言語（ライブラリ）に入れようと考える発想がマルティクスな感じ。
- 181 名前：デフォルトの名無しさん mailto:sage [2009/06/25(木) 06:22:54 ]
- でもオブジェクト指向言語としては、みんなが使う様な機能は再利用したい感じ。
標準に無いからそれぞれが組み込んで再利用が無いのってOOP的には逝けてない。
- 182 名前：デフォルトの名無しさん mailto:sage [2009/06/25(木) 09:23:48 ]
- そのなんとか言語は、コードの再利用を促進はするが強制はしない。
よく分かってないみたいだしこの際だから勉強しなおしたほうがいいんじゃないの？
そもそもコーディックの類はオブジェクト何とかはまったく相性悪いよ。
- 183 名前：デフォルトの名無しさん mailto:sage [2009/06/27(土) 09:14:03 ]
- みんなでH264やMP3のコーデックを作りまくるのがjavaのメリットなんだよ。
- 184 名前：デフォルトの名無しさん mailto:sage [2009/07/11(土) 13:43:23 ]
- JOGLも2.0から大幅に仕様変更
- 185 名前：デフォルトの名無しさん mailto:sage [2009/07/13(月) 17:36:15 ]
- 開発者ではなくただ見たいだけのユーザです。
Cycore Cult3D Viewer についてはこちらでうかがえるでしょうか？
Vista SP2 IE8 で TCV: TOYOTA CAR VIEWER が動作せず、推奨措置、Google検索でも当を得ません。
- 186 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 23:21:13 ]
- >>184
OpenGL2.x以下が切り捨てられたら泣く。
glBegin-glEndとディスプレイリストの組み合わせって小規模のプログラムだと結構便利なんだよ。
全部をVBOにしろって言われたらしんどすぎる。
- 187 名前：デフォルトの名無しさん mailto:sage [2009/09/03(木) 00:14:42 ]
- JMC良さそうだね。
自作アプリに組み込んでみるよ。
- 188 名前：デフォルトの名無しさん mailto:sage [2009/09/04(金) 03:54:24 ]
- JavaFX1.2になって、JMediaPlayerってコンポーネントがなくなり
SwingにJMCを仕込むのは難しくなってた。
SwingにJavaFXを貼り付けるハックを見つけたんで、そっちから
攻めるのがよさそう。
Java7でJMCが標準になれば無駄な苦労なんだろうけど。
|
 |
