[過去ﾛｸﾞ] 統一３Ｄスレ (558ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
413(4): 2009/02/02(月)04:30 ID:??? AAS
I'm having some questions about mipmap maybe which doesn't
matter where the plat-form is.
I would like to dynamically load mipmap levels only if they
must be needed and also would like to delete them just when they
aren't needed anymore.
The question is that I must compromise to delete some textures
when many maximam size of texture are requested at the same time,you know,
省2
417(1): 2009/02/02(月)11:15 ID:??? AAS
>>415 I quite agree with you.
Although I have no idea what platform >>413 is targetting,
I guess that loading and offloading individual mipmap levels would
generally be very inefficient and easily cause CPU or GPU to stall.
422: 327 2009/02/02(月)13:25 ID:??? AAS
>>413
私はミップマップについていくつかの疑問を恐らく持っています。
たぶん、どのプラットフォームかは重要では在りません。
ミップマップが必要とれるか、今はもう必要ない場合にそのミップマップを消去したいときもまた、
私は動的に各ミップマップレベルをロードしたい。
質問は、ご存知のように多くの大きなサイズのテクスチャが同時に要求されたとき。
もしその合計サイズがVRAMがカバーできるよりも大きくなったなら、
省2
425: 2009/02/02(月)13:45 ID:??? AAS
>>413
I had faced to the similar case as you.
There is a good solution for running short of VRAM when using like as mipmap
but still it is not a ideal method.(as 415 said it can be remarkely
said dynamic texture management)
If you don't have to sort polygons such as no-semitrans polygons,
sort these polygons not by Z-value but by texture,yes as you guess it is
省3
426: 327 2009/02/02(月)13:47 ID:??? AAS
>>417
>>415
激しく同意。
>>413がどのプラットフォームを対象にしているのか俺はしらんけど、
個々のミップマップレベルを読みこんだり消去したりするのは普通はむちゃ非効率的で
造作もなくCPUとかGPUを止まらせると思う。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.020s