【JMF】Java Media APIs【JOGL】

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/ 35 名前：デフォルトの名無しさん mailto:sage [2008/02/19(火) 18:04:41 ] C#なんてwinでしかうごかんくせに糞重いもん使ってられるか やっぱ立てれば馬鹿が釣れるんだなと立てた人参上 ネイティブでやりたいならC++で十分。 36 名前：デフォルトの名無しさん mailto:sage [2008/02/20(水) 00:36:20 ] >>32 かわいそうに。発狂してしまったのか。 MacOSXとかちょっと使ってみ。WindowsのUIが腐っていることに気づくと思うぞ？ 37 名前：デフォルトの名無しさん [2008/02/20(水) 08:25:57 ] マルチプラットホームとかバカか？ いつまでもJavaの思想にすがってんじゃね―よｗ コーデックの一つも実装できないくせに、Javaにおんぶで抱っこで、おまえはバカだろｗ 38 名前：デフォルトの名無しさん [2008/02/20(水) 08:31:51 ] MacとWindowsを使ってる人の比率を知ってるだろ。 重要なのは、腐ってるUIかどうかじゃないと思うぞ。 確かにMacは見た目だけはセンスありそうだが、Mac使う奴はお子ちゃましか集まってないだろ。 それと、おまえはUnixとかも入れて評価してそれでもWindows UIは腐ってるといってるのか？ 39 名前：デフォルトの名無しさん mailto:sage [2008/02/20(水) 08:42:21 ] >>34 マルチプラットホームのことを意識してる奴は少ないと思うが？いつの時代の話をしてるんだ？ 未だにJavaのキラーアプリもなければ、アプレットもしょぼいのだけだな。 やっぱりこれがJavaだ！！ って感じが、マルチプラットホーム対応のJavaであってもないのはどうしてだろう。 コーデックとか内部の処理はnativeになるからjavaはnativeは弱いし、 native使うんじゃ、マルチプラットホームとは言わないんじゃないか？ マルチといいつつも、所詮win, redhat linux, solarisの3つしかないしｗ 40 名前：デフォルトの名無しさん mailto:sage [2008/02/20(水) 10:47:33 ] 携帯で動けばいいんだよ 41 名前：デフォルトの名無しさん mailto:sage [2008/02/20(水) 18:45:49 ] 別にコーデックの内部がnativeとは限らないんじゃね? MP3はJDK1.2時代にすでにpure javaなデコーダで鳴らせてたし、 いまはMPEG4 videoのpure javaなデコーダもあるしね。 マルチかどうかは知らんが、Sunが直に出して無くても良いんじゃないか? 42 名前：デフォルトの名無しさん mailto:sage [2008/02/20(水) 19:08:55 ] 積和演算の塊みたいな処理をJavaでやるのはなんかCPUを無駄遣いしてるような気もする。 そろそろ行列演算ライブラリをJava標準に入れてもいいんじゃないか？ IA、Sparc、PPCとかのメジャーな環境ではSIMDを叩くようにして。 43 名前：デフォルトの名無しさん mailto:sage [2008/02/20(水) 19:17:21 ] AtomicIntegerみたいにJavaにSIMDプリミティブを導入してJITかけようってことか？ そうでなくて行列専用？ 44 名前：デフォルトの名無しさん mailto:sage [2008/02/20(水) 22:35:13 ] マルチプラットフォームには今でも夢見てるだろ 実際Flashが実現できてる事をJavaが実現しようとしないことが問題なわけで。 Javaはビルダーレベルで無償だから、旨みがなくて一生このままだろうが。 45 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 11:24:52 ] vecmathとかってSIMDつかってるのかな? SIMDを使えるようにするよりは、GPGPUの法が現実的? 46 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 18:34:38 ] おまえら大丈夫か？ Javaのマルチ環境サポートの話をする奴もいれば、SIMDとかGPUとかネイティブよりの奴もいるし。 こいつらは、JMFに何を期待して、一体やりたいんだろう。 47 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 18:45:15 ] やっぱりすごいことしようとすると、SIMDとかハード頼みになるんだよね。 別にJava（JVM)は、すごいことをするような専用の環境ではないだけど。 48 名前：デフォルトの名無しさん mailto:sage [2008/02/21(木) 18:48:02 ] >>46 このスレはおおむね期待通りに機能してるよ？ 隔離スレだもの 49 名前：デフォルトの名無しさん mailto:sage [2008/02/22(金) 01:03:07 ] GCのある言語でカジュアルに書けてなおかつOS毎のある程度の最適化が行われるようなモノを求めてるんだろう。 俺もそうだが、大規模のソフトウェアを書こうとすると C++ ってのは今ではもう絶望なんだわ。 IDEがサポートしきれない複雑怪奇な仕様の言語でプログラム書くのはもうかんべん。 50 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 00:57:31 ] >>45 SIMD使ってるかどうかは分からないが、Vecmathは標準構成に入れて欲しい気も… 51 名前：デフォルトの名無しさん mailto:sage [2008/02/23(土) 23:15:28 ] LLVMで動くJavaVMができれば面白くなると思うのは気のせいですか？ 52 名前：デフォルトの名無しさん [2008/02/24(日) 15:30:47 ] それってJava Media APIsとなんか関係あるの？ 53 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 20:32:33 ] www.pushing-pixels.org/?p=260 半透明・非矩形ウィンドウの作成のためのAPIが追加される模様。 素晴らしい。 54 名前：デフォルトの名無しさん mailto:sage [2008/03/02(日) 23:33:42 ] やっとできるようになるのか。Macじゃ前からできるからのう。 55 名前：デフォルトの名無しさん [2008/03/02(日) 23:37:39 ] よっしゃーー！！！ わくわくだ〜 56 名前：デフォルトの名無しさん mailto:sage [2008/03/03(月) 13:59:17 ] あんなのがそんなにうれしいのか… 57 名前：デフォルトの名無しさん mailto:sage [2008/03/03(月) 18:47:31 ] 実際に作ってみると非短形ウィンドウって使わないな。 58 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 00:48:12 ] MSオフィスのイルカみたいなキャラクター系とか、 メディアプレイヤー系ソフトのスキンとか、 タスクトレイの噴き出しみたいなとか・・・くらいか？ 59 名前：デフォルトの名無しさん mailto:sage [2008/03/04(火) 02:15:17 ] なぜか解らないけどオーディオプレーヤーは非矩形ウィンドウが好きだよね… 半透明の方は非矩形よりはまだいろいろと使い道がありそう 60 名前：デフォルトの名無しさん mailto:sage [2008/05/08(木) 21:46:10 ] joglのdemosを試しているのですが、demos.hdr.HDRで失敗しています。 起動はするのですが以下のダイアログが表示され、メインウィンドウ内もなにやらバグっています。 「Texture rectangle extension not available (need one of GL_NV_texture_rectangl,GL_EXT_texture_rectangle or GL_ARB_texture_rectangle」 もしかしてハードウェアの問題でしょうか？ 実行環境はCPU CeleronM360, RAM 768MB, グラボ Mobile Intel 915 Express, OSWinXP sp2です。 61 名前：デフォルトの名無しさん mailto:sage [2008/05/08(木) 22:54:30 ] そのGPUでは無理。 62 名前：デフォルトの名無しさん mailto:sage [2008/05/09(金) 01:55:56 ] つーかオンボでOpenGL試すとかw Texture rectangle extension not available (need one of GL_NV_texture_rectangl,GL_EXT_texture_rectangle or GL_ARB_texture_rectangle って書いてあるじゃん。 63 名前：デフォルトの名無しさん mailto:sage [2008/05/09(金) 20:17:33 ] オンボだろうが何だろうが拡張を必要としない範囲では使って当然だろ 64 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 12:14:46 ] www.Javafx.comの「Movie Cloud」の説明には、 > In the Video Cloud demo watch up to 200 video and audio clips > playing simultaneously at Blu-ray HD quality. > A new advanced JavaFX Media Framework enables > high fidelity audio and high definition video in your JavaFX applications. と書いてある。 対応コーデックがどれなのかまでは調べていないけど、 JavaFX Media Frameworkを使えば、Blu-ray HD品質の動画を 再生できるようになるのでは。 65 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 12:40:00 ] >>64は、>>14、>>15、>>22へのレスです。 >>49 全くもって同意です。 しかしそういう用途をターゲットにしているのは、 JavaでもC#でもなく、Dではないかな。 少なくとも現時点では。 66 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 03:08:32 ] DってDigitalMarsの？MSの？ 67 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 15:30:13 ] >>64 これじゃない？ itpro.nikkeibp.co.jp/article/NEWS/20080509/301068/ 68 名前：デフォルトの名無しさん [2008/05/25(日) 18:01:33 ] >>65 Dは有り得ない 69 名前：デフォルトの名無しさん mailto:sage [2008/05/25(日) 18:54:45 ] コンパイラのバグと仕様変更が凄まじいからな。 でもjavaよりマルチメディアましだと思う。 JMFもただの純粋なラッパーだし規格がもう古いし。 70 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 12:17:30 ] >>1にあるAPIは新たにJOGLという名前で呼ばれるようになったのか。 初めて知った。 ここ暫らくJavaに触れていなかったのでものすごく懐かしさを感じるAPIに 再開した気分だ。 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 ] 彼の理想郷を現実のものとして実現させるには、あと８年はかかるだろうな・・・

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef