シェーダープログラマが集うスレ

1 ：01/11/08 〜 最終レス ：2012/09/29

　　　　　　　∧ ∧ 　　　　　／￣￣￣￣￣￣￣
　 　　　　　(,,・∀・) 　　　＜　　ゲームにもシェーダーの時代到来でち♪
　　　　　　 ＠＿） 　　　　　＼＿＿＿＿＿＿＿

バーテックスシェーダーとかピクセルシェーダーとかを語りまくるスレ。

2 ：

リンクとかはこの過去ログにあるよ。
切れてるのも多いかも。
DirectX&OpenGL【シェーダ】プログラミング
http://piza.2ch.net/tech/kako/993/993758383.html

3 ：

チュートリアルはIF氏のＨＰが詳しいよ。
ttp://www5.tok2.com/home/IF/

4 ：

ＭＳＫＫのコラム新作。
頂点単位のスペキュラ ライティング
http://www.microsoft.com/japan/developer/directx/japan/dx8/SpecularLight.asp

5 ：

ラデオン８５００買ったがハングしまくる。
鬱だ。

6 ：

シェーダーは今から覚えなくても
DX9以上になって条件分差とかが実装してから
取り組んだ方が良さそう。
コロコロ仕様変わってるし。

7 ：

X-BOXのシェーダーは今後数年は変わらない。
X-BOXと同じシェーダーをサポートする安いgeforce3 ti 200は買い。
radeon8500の方がgeforce3より機能は上だけど
今のところビデオカードとして評判最悪なので待った方がいい。
http://pc.2ch.net/test/read.cgi/jisaku/1004787773/l50

8 ：

OpenGL使ってる向きにはEXT_vertex_shaderがおいしそうに見えるんでない？
http://www.ati.com/na/pages/resource_centre/dev_rel/sdk/RadeonSDK/Html/Samples/OpenGL/SimpleVertexShader.html
こっちの方で統一してくれないかな？＞NVIDIA
＃OpenGLでの統一されたシェーダープログラムはOpenGL2.0までおあずけか…

9 ：

>>8
完全に同じものはNVIDIAのGF3ではハード的にサポートできない。
NV_vertex_program環境で、EXT_vertex_shader風に書きたいならば
自分でEXT_vertex_program風のライブラリを書くしかない。

10 ：

自分でEXT_vertex_program風のライブラリを書くしかない。
↓
自分でEXT_vertex_shader風のライブラリを書くしかない。

11 ：

>>9
やっぱりEXT_とはいっても事実上ATI_vertex_shaderなのね…。
ピクセルシェーダはともかく、頂点シェーダーくらいなんとかならんのかな〜？
ちなみにGF3とRADEON8500の間でサポートできない頂点シェーダの
命令ってなんです？DirectXでも互換性ないのかな？

12 ：

DirectXの頂点シェーダーは互換性ありますよ。
CPUのエミュもあるし。
DirectXの頂点シェーダーは楽です。

13 ：

>>12
DirectXが互換性あるなら、OpenGLもドライバレベルでなんとか
ならんかなぁ…、といってみるテスト。いやそんな重要なことじゃないけどさ。
http://www.3dlabs.com/opengl/ogl2.pdf
が現実になる日を待ちつつ、NV_vertex_programを使いましょう＞OpenGLの人
>CPUのエミュもあるし。
Radeonは知らないけど、NVIDIAのデトネタならOpenGLもソフトエミュしてくれる
よね？
>DirectXの頂点シェーダーは楽です。
NV_vertex_programならDirectXと大して変わらないし、EXT_vertex_shaderなら
さらに楽ゲな気がする。ちょっとしたシェーダーの違いなら頂点シェーダーを
定義している部分で分岐
if(ほにゃらら)
{
glShaderOpNEXT( ... );
}
できそうだし。（RADEONもってないから試してないけど）
＃実際にバリバリ使ってくと種類増えるでしょ？＞シェーダー
スレ汚しゴメソ。

14 ：

デトネタはNvidiaのビデオボードの人しか入れられないし・・・・
DirectXではNvlinkをうまく使えば種類は減らせるよ。
面倒だけどね。

15 ：

>>13
DirectXのvertex shaderの互換性はATIが妥協しての互換性だと思う。

16 ：

ピクセルシェーダーも1.1までならgeforce3とradeon8500で互換性ありかも。

17 ：

radeon8500いいかも。
安定性が問題だけど。

18 ：

ps.1.4
texcrd r0.rgb,t0
texld r1,t1
mov_d4 r1,r1
add r0.rgb, r0, r1
phase
texld r0,r0
add r0,r0,v1
MFCPixelShaderにｺﾋﾟﾍﾟ

19 ：

意外とphase関連の制限に引っかかるかも

20 ：

あげ〜ん

21 ：

シェーダーも内包した新しいXFileの仕様作ってくんないかなー＞ＭＳ
プログラマが趣味でやる分には今でも十分遊べるけど、ちょっとでも
実用的にゲームでも作ろうとするとソフトからの吐き出しとかでえらい
苦労するのよね。
　どーもＭＳは古いXFile互換にこだわるけど、そろそろ下位互換に
こだわらなくてもいいのにね。

22 ：

シェーダー内包したモデルフォーマットって
いいかもね。最近はMayaとかMaxとかXSIで
シェーダー組めるらしいから是非！
OpenGL2.0も含めた汎用フォーマット希望！

23 ：

てか、XMLの時代にXファイルは時代遅れ。

24 ：

>>22
>最近はMayaとかMaxとかXSIでシェーダー組めるらしいから
Mayaはシェーダーというよりは、描画部分をそっくり取替えできちゃうみたいね。
http://www.aliaswavefront.com/en/Tmpl/Maya/html/index.jhtml?page=/en/Community/Games/index_m.html&style=normal
サンプルはNV20系依存なプログラムだけど、これならFireGL8800とかの独自機能
でも勝手に組み込めちゃえそう。もっともRADEON系でMayaがうまく動くかどうか
わかんないけど。
>OpenGL2.0も含めた汎用フォーマット希望！
じゃ、いっそribファイル形式で（ｗ

25 ：

VertexShaderで、スプライト表示してるけど、あまりパフォーマンス良くない。
表示サイズ変えると、CPU負荷が激増するんだけど、（XPで調査）GPUで描画してるんじゃないのかな？
誰か、やってる人いたら、教えて下さい。
自分は、XP,GF3、P3１Gで、３２＊３２SPRTが１F６００前後です。
シェーダーでは、取り敢えず、
V0にロードされた頂点座標に、Trans値を足して、0-1間にCLAMPしてるだけです。
（後、TextureUV設定）

26 ：

>>25
「自分は」のところが何言ってるのか意味不明なんだけど。
あと、CPU負荷はどうやって計測したの？
CPU負荷が増えるんじゃなくて、たんに関数がブロックしてるだけだと思うけど。

27 ：

なかなか集わないね。

28 ：

>>26
＞「自分は」のところが何言ってるのか意味不明なんだけど。
すんません。（大体）１Fで表示出来るスプライト数が６００個。て事です。
（プレステ以下、、）
上司に聞いたら、１０万以上出る筈。と。
＞あと、CPU負荷はどうやって計測したの？
XPの、Ctrl+Alt+Deleteで出る、タスクマネージャーで確認してます。
（プログラム実行した状態で）
＞CPU負荷が増えるんじゃなくて、たんに関数がブロックしてるだけだと思うけど。
すんません。その通りです。ｗ
DrawPrimをSprite数分、Callしてました。
まだ、DX弄って、１週間ぐらいで、全然理解出来てないみたいです。
取り敢えず、PointSprite(Particle)のデモが、パフォーマンス高そうなので、
調べてみます。
どうやら、頂点バッファを数回に分けて、Lock>DrawPrimしてるみたいです。
そうすると、CPU,GPU待ちが起き難くなるみたい。

29 ：

vertexbuffer関係、修正したら、1Fに12000ぐらいは出るようになった。
目標50000。寝よ、、。

30 ：

2chだとこの程度か･･･

31 ：

　　　　　　　　　　　　　　　 ,,.ｒ'' ゛~~` ''ッ,,　　おめーら、毛シェーダで俺様でも　　　　　　　　　　　　) 　 ）
　　　　　　　　　　　　　　､ ゛　 ,,,,,,,,,,,,,,,,,,,,, ヾ.　　 表現できっか？あん？ 　 　 ,.、　　　/ ／
　　　　　　　　　　 　 　 ﾐ　　 ﾐ゛,へ.__, ,_ﾉヽ i.　　　　　 　 　 　 　 　 .| |l　　　l ,´
　　　　　　　　　　　　 ﾐ　　　 ﾐ,　( ・) {・ﾌ 〉 ﾐ.　　　　　　　 　 ＿-､i::| |ニニii '
　　　　　　　　　、,,,,ツi:　　　　 ﾐ,｀~´ ヽ~〈　 .ﾐ　　　　　　　　/,‐ヽヽ`､||
　　　　　　　､ｼ`｀　　 i:　　　 　 ,ゞ 　'ｎ.inヽ. .ﾐ　　　　　　　　　　（ .〉〉/
　　　　　　ｼ　 ／／　　　　　　ﾐ｀　　　 l.l　ヽ"、　　　　　 　 　／　 ノ
　　　　 ﾐ/ ｼ　　　　　　　　 　 彡　,＝こ二=.{　ﾐ,,　　　　　 ,ｒ'´　,,､'゛
　　 　 ﾐi. / 　/　　　　　　　' ! w､｀~^' vwｖ '､ 　 ﾐ 　 　 　〃　.ﾐ

32 ：

ハナ毛 程度なら表現できますです。はい。
#きゃー引っこ抜かないで〜！

33 ：

ちなみに、リアルタイム系のシェーダーの場合どういう風に絵描きさんはオーサリング
してるんですか？
１・プログラマが決め撃ちのシェーダーをマテリアルとしてアサインする。
２・ShadeTreeみたいに視覚化されたシェーダー言語、もしくはもとからオーサリング
ツールにあるシェーディング構造をコンバートするインハウスツールを制作している。
３・その他
リアルタイムで実行されるシェーダーなので、制約が色々と厳しいんでしょうけど、
少なくとも２のような形でないと、絵描きさんがシェーダーのメリットを享受できない
気がするのです。なんかこのスレ見てるとまだ
（リアルタイムシェーダー＝プログラマさんのオモチャ）って気が…。

34 ：

>>33
１で十分な気がしますが？
リアルタイムシェーダーなんていくらインターフェイスをビジュアル化してもデザイナーが扱いきれるものではないし。
プログラマがシェーディングモデルを組んで、
デザイナーはパラメータやテクスチャを調整するので十分なのではないかと。

35 ：

>>34
う〜ん、デザイナーが扱えないと断言するのはどうかと。
実際オフラインのレンダリングでは多くの絵描きさんがもっと複雑な
シェーディング言語を扱ってるわけですし。
たとえば、MayaのHyperShadeみたいなGUIでシェーディングモデルを
組み立てて、それをそのままターゲットのシェーディング言語に出力
出来るのであれば、そちらのほうが表現の自由度が高まるわけで。
（たとえば、眼球に独自のシェーダーを割り当てたいなーという時に
いちいちプログラマさんにシェーダー書いてもらうのと、自分だけで
表現を完結させられるのでは生産性が全然違うし。）
もっともオンラインでは命令数の制限やその対処法（計算の結果を
テクスチャに収めておくことで複雑な計算を単純化するとか）で独自
のノウハウが必要になりそうですが。

36 ：

>>35
だから、現状のシェーダーは
法線ベクトルと視線ベクトルの内積を取って正規化し、
光線ベクトルに内積を描けたものに頂点カラーをうんぬん…
みたいなものなのよ。
そんなものいくらGUIかぶせたところで、
デザイナーが一朝一夕で使えるわけないでしょ。
MayaのHyperShadeみたいなのは
シェーディングモデルを組み立てているのではなく、
「組み合わせて」いるだけなのよ。

37 ：

>>36
>法線ベクトルと視線ベクトルの内積を取って正規化し、
>光線ベクトルに内積を描けたものに頂点カラーをうんぬん…
>みたいなものなのよ。
たぶんこの部分は頂点シェーダーを指していると思うのですが、
大体の場合、頂点シェーダ自体はシェーダそのものというよりは
ピクセルシェーダの前段階のセットアップ処理という理解を私はしています。
たとえば、Environmentマップなどは頂点シェーダの担当になると
思うのですが、これ自体は前出のHyperShadeでいうなら、
「Environment ほにゃらら」みたいな形で一つのノードに閉じ込め
られてますよね？この部分に関しては基本的に組み合わせの中
からひとつを選択する、という考えでいいと思います。（そういう意味
ではその部分から一から作っているプログラマさんには「組み合わせ」
に思えるのかも）
つまりノードの中にEnvironmentがあれば、自動的に頂点シェーダー
側でTexGen処理を行えばよいし、バンプのノードをつけるなら
接線空間の解決を行うコードを生成すればいい。（複数のシェーディング
メソッドがあるのであれば、それを選択できるようにすればよい）
ただ、それを組み合わせる（それぞれのプリミティブなシェーディング
メソッドから得られる結果をクリエーターの任意で合成する）のは
コンテンツ作成者の自由というのはオフラインＣＧ的には決して珍しい
アプローチではないと思うし、オンラインでも現在ならある程度やって
出来ない事ではないと思うのですけれど。
// いや、今の所オンラインＣＧやってないのでどうでもいい話ですけどね。失礼。

38 ：

http://www5.nkansai.ne.jp/users/mitani-sys/

39 ：

'''''''ﾞﾞ´　　　　　 ﾞﾞﾞﾞ'''''-::,,_
　　　　　　　　 ,-''ﾞ　　　　　　　　　　　　　　　 ''!;
　　　　　　　.r'ﾞ　　　　　　　　　　　　　　　　　　 iﾞ''
　　　　　　　l　　　　　　　　 __　　　　　　　　　　　i
　　　　　　　l　　　　 :,,r'''￣￣ﾞﾞﾞﾞﾞ''''''''''''-,,_　　　　i
　　　　　　　i　　　;ri!ﾞ　　　　　　　　　　　 ﾞlll;;,　　i
　　　　　　　 '|　 ;lll|l　,,,,:;iiii;,,,,　　　,,,;;lllii;_　 'll|l　 |
　　　　　　　 .'l, ﾚll'l '''　 ,,,,,￣　　　　,,,,,___　 　l|ﾄ,r
　　　　　　　　'|;i|'ﾄ　　:r:'llll''　　　　 ﾞﾞ'ill⌒　　l ﾞ.r'''
　　　　　　　　.l　ﾞﾄ　　　 　　　　　　　　　　　i .|
　　　　　　　　 'l　.|　　:r'ﾞ　/'　　　 !　＼　　　l　|　　　　　　＿＿＿＿＿＿＿＿
　　　　　　　　　.ll,,) '|!,,,　 .(i;;;;;iiilllii;il)l;'::　,r''| li,,,l　　　　　／
　　　　　　　　　　　|l;,'l||ll!|lll'llllllllllllllllll,'! ||l| ll |!ﾞ　　　　＜　ここは一つ、ワシの長いヒゲをシェーダーで実際に
　　　　　　　　　　　| i‐:ﾘlﾄ:,::;;;;;;;;;;;;;;,,,:l lil　´l!|.;|lﾞ　　　　　＼ 表現してみないかね？影武者募集中。
　　　　　　　　　　　 '!:ﾄ)' 'li, iiiiiiiiiiiii'.､l.｀ll,,|:(｀ |　　　　　　 　￣￣￣￣￣￣￣￣
　　　　　　　　　　　 l|!｀r,.('ﾄ.r　i　lﾞ i　 |.　)ﾞl! |
　　　　　　　　　　　　i'!.'il､.'l; .| i'l l. ; l,i,'!!'l;ﾞ;; '|ﾞ
　　　　　　　　　　　　ﾞ 'l;;;l'llll :ili;|.ﾌ/; ,｀ﾄ.ﾞ;l!.
　　　　　　　　　　　　 ;l i;''ll!|_ |_ li,, !,,l'!.lﾚi!ﾄ
　　　　　　　　　　　　 ﾄ .l|l､.lli;l!i'''!,､ r l!(.／
　　　　　　　　　　　　　ﾞ' '!ﾞﾞ llﾚ|l,.;i,i;| ;ｰ.ﾞ
　　　　　　　　　　　　　　　　 ﾞliﾄ　!:!
　　　　　　　　　　　　　　　　　 '.ﾞ'｀

40 ：

毛にうるさいファーシェーダーヲタ増殖中。

41 ：

実際のとこ、毛をやろうとすると、オーサリングツールなどの
整備から始めなければならないし、時間コストが高すぎかも。
顔がドアップになるようなゲームなら、屈託なくスケジュールに
組み込めるんだどさぁ。

42 ：

http://www5.nkansai.ne.jp/users/mitani-sys/
↑何、罠ってんの？

43 ：

定期age。
>>37のいっている事は
http://www.softimage.com/Products/Xsi/v2/features.htm#rts
のような事を指しているのかな？XファイルもdotXSIをベースに作り直して
みては？＞ＭＳ
あとCG板に、良スレが
http://pc.2ch.net/test/read.cgi/cg/980410607/
シェーダー好きなら見て損はないかも？

44 ：

sageになってたので。

45 ：

質問です。シェ−ダーで、
既にレンダリングされた画像を湾曲させたりって出来ますか？
やっぱ、テクスチャーにレンダ−したり、バックバッファ等から
テクスチャー化とか、複数回レンダ−しないと無理ですかね？

46 ：

クソスレあげるなよ。面白そうだったのは、タイトルだけだったよ。

47 ：

>既にレンダリングされた画像を湾曲させたりって出来ますか？
そもそも、「既にレンダリングされた」と言ってる時点で
複数回レンダは避けられないと思うが？

48 ：

>>45
DirectXとかOpenGLのシェーダでと言う意味ならそういう仕組みは
ないんじゃない？
レンダーマンシェーダならimager shaderというずばりのものがあるけど

49 ：

バックバッファをテクスチャにコピーして
ポリゴンに張って曲げるのが簡単でいいんじゃない？
ポリゴンのＵＶ値を求めるのをシェーダー化すれば
速度的にも実用レベルだと思うけど。

50 ：

あ、既にレンダリングした画像はあるって前提
なんだね。それなら球などのポリゴンの頂点を
スクリーン座標系に変換してから0〜1の間で正規化
してそれをテクスチャのＵＶ値にするって感じかな。
法線で少しづらすと湾曲してみえると思うよ。
実際にはもう少し細工をするけど。

51 ：

みなさん。情報ありがとうございます。
CubeMapあたりのサンプルを見ればいいんですかね。（シェ−ダー関係なさそう）
ただ、NVIDIAのEffectBrowserのサンプルで、
ティーポットがノイズ掛かったようにブレル奴があるんです。（PixcelShaderDemo）
で、ワイヤー表示してみたら、ワイヤー自体がブレテル。
どうやってるんですかね？
ソースコードがないので、挫折してます。

52 ：

ソースコードはありますよ。

53 ：

申し訳無いのですが、教えてもらえないでしょうか？
（何処か解凍するんですかね？）

54 ：

インストールしれ。
http://developer.nvidia.com/view.asp?IO=SDKInstaller

55 ：

ageます

56 ：

覚えること多すぎ。

57 ：

んなこたーない

58 ：

OpenGLで使いたいのですが、初心者はどこから手をつけたらよいのでしょうか？

59 ：

>>58
とりあえず、extensionの使い方について調べましょう。
nvidiaやatiのサイトを回ってみましょう。

60 ：

OpenGLのエクステンションは理解しました。
実際、OpenGLのHello Worldはどれになるでしょう？
分りやすいチュートリアルサイト等はありますか？
nVidiaで考えてます。

61 ：

このスレ廃れすぎ。

62 ：

>>60
NVIDIA extensionの初歩であればNVSDKの中のサンプル
OpenGL/src/demos/vtxprog_*, OpenGL/labs/vertexlab_* を見るのはいかがでしょう？
ドキュメントもNVSDKの中に豊富に揃っています。
# OpenGLそのものの初歩なら赤本をどうぞ。

63 ：

あとはここ
http://www.nutty.org/opengl.html
のここ
http://www.nutty.org/OpenGL/Nvidia/index.html
なんて、比較的短くてソースを追いやすい（glhとか使ってないので）
のではないかなぁと思います。

64 ：

サンクスです。
ところでnVidaのOpenGLのシェーダサンプルはnvparseが
使われていますが、nvparseのリファレンスもしくはチュートリアル
ってありませんか？　これが読めないとシェーダプログラミングは
さっぱりでして…。

65 ：

シェーダーを気楽に管理＆利用出切る機構がホスィ。

66 ：

geforce4mxに換えたんでＳＤＫのサンプルが楽しめると思いきや、
mxじゃピクセルシェーダが使えない罠。

67 ：

>>64
nvparseのソースを追うのが一番いいとおもいますけど、リファレンスらしきもの。
http://developer.nvidia.com/view.asp?IO=nvparse_for_textureshaders
あとはエフェクトブラウザのソレ系のOpenGLサンプルでも見れば大体判るんで
はないでしょうか？
>>66
OpenGLでレジスタコンビナ弄って我慢しよう。

68 ：

nVidiaのサンプルをみて、.vpファイルは頂点シェーダ、.tsはテクスチャシェーダ。
これらはDirectXのヴァーテクスシェーダ、ピクセルシェーダの解説と照らし合わせればおよその見当はつきますが、.rcpは何なんでしょう？
参考ソースを眺めるとこれがレジスタコンビナってやつだと思いますが、これはどう理解すればよいのでしょうか？具体的な役割とは何なんでしょうか？

69 ：

>>68
DirectXでいうピクセルシェーダはNVIDIA OpenGL拡張ではテクスチャシェーダと
レジスタコンビナに分けられます。テクスチャのフェッチなんかの命令（DirectXで
いう所のテクスチャアドレッシング命令）がテクスチャシェーダ、色やα値などの
ブレンディング命令がレジスタコンビナにあたります。

70 ：

>>67
>>68
>>69
スマン。非常にくだらない質問になるんだが宜しく頼む。
Register Combinerを「レジスタコンビナ」と読むのは
やはりこの板で流行っている洒落みたいなものだろうか。
当方この板の事情に疎いので、マジレスカコワルということで
あったら先に謝っておきます。

71 ：

石油コンビナートを襲うタッコング

72 ：

NV_GL拡張にはあって、Direct3Dには無いという
レジスタコンバイナってどういうものなの？
概念的なもんでいいから教えてくれると嬉しいナ。

73 ：

スマソ>>69に書いてあったね。
でもPSにも色およびアルファ ブレンディング命令は
あるみたいだけど・・。

74 ：

元々レジスタコンバイナってのは中間結果を保持するレジスタを
複数しかも自在に組み合わせて使えるよってな意味なので、
ピクセルシェーダのカラーブレンド部分と思ってほぼ問題ない。
ただピクセルシェーダとの大きな違いは、
倍ぐらい演算が強力ってことかな。

75 ：

>>70
くだらん質問で盛り下げるなよ。

76 ：

>>74
ありがとうございます。
よくわかりました。

77 ：

nvparseでパースするレジストコンビナ(.rcp)のリファレンスってありますか？

78 ：

>>77
このあたりは見ました？
http://developer.nvidia.com/view.asp?IO=gdc2001_programmable_texture

79 ：

今からRしてきます

80 ：

　　ｇｙ

81 ：

　

82 ：

ファーシェーディングのやり方１つ解った。
でも、シェーダー使わなくても出来そう。
しかも、重そう。

83 ：

ゲームプログラムを作ってると
シェーダーとか見かけ華やかな部分より
ゲームの基本ルーチンを作る方が
遥かに難しく、重要だとわかってきた。
ここでシェーダーシェーダー言ってる人は
そういった基本部分をクリアした上級者か
D3Dかじった初心者かに分かれるだろう。

84 ：

>83
激しく同意。
描画周りはよく語られるが基本ルーチンを語られることは少ない。
皆さんどうやって学んでいったのでしょうか？私はいつももう少し
きれいにかけないかと悩んでいます。いろんなジャンルのゲームを
たくさん作るしかないのかな？
spinのインタビューでもあったがたくさんのシェーダーの「管理」を
どうするか語りませんか？

85 ：

>>83
商売でないなら同意。
ゲームとしては基本ルーチンの方が全然重要なんだよね。
しかし商売となると見かけの華やかな部分こそ最重要項目なんだよ。
見た目が良くないと売れないんだよ。
なのでシェーダーを研究しないと飯食えないんだーよ！！
悲しいにょ・・・

86 ：

この本買った人いる？
http://www.gamedev.net/columns/books/featuredbook.asp?productid=180
Covers a wide range of rendering techniques, focusing on shaders.
だそうですよ。
洋書一番安く買うのってどうするの?Amazon.comで買うのがいいのか？

87 ：

>>84
実際に自前で組んではいないけど、前使ってたエンジンでは、
シェーダーマネージャークラスにシェーダー追加していって、
各々のメッシュクラスにバインドさせるってやり方してた。
ここら辺って、何でもそう変わらないと思うけどね。
実際、今CUBEで組んでるエンジンでは殆どそうしてる。

88 ：

>>84
質問なんだけど、このあたりの実装って個別に論じるほど特殊なものなのかな？
メッシュの表面のシェーディングに関するシェーダーであれば>>87のようにシェーダー
クラスをシェーダーファクトリークラスからポコポコ作ってメッシュデータクラスにくっつ
けるだけで、これ自体の考え方は固定ファンクションしかない場合でもレンダリング
ステータス/マテリアルクラス（みたいなメッシュのデータに挟み込んでいくものの管理）
が似たような形になるはず。

89 ：

つーかシェーダに汎用性なんか必要なの？
ステージ1のメインキャラ用シェーダ、
ステージ2のメインキャラ用シェーダ、
ステージ3のメインキャラ用シェーダ、
こうやって個別に作って、ステージの切り替わりと共に
シェーダも切り替えた方が良くない？

90 ：

>>86
amazon.co.jpでもその本は売っている。
「発送可能時期：通常4〜14日以内に発送します。」だってさ。
6,932円也

91 ：

>78
ありがとう！見逃してました。

92 ：

ゲイム屋さんでなくてもDirectXやOpenGLは活用する。
自分はグラフィック屋さんなのでシェーダ・シェーダ言ってみる。
でも、ゲイム屋さんが一番技術的に進んでいる。

93 ：

rtrtrtrttrrtrtrtfgfgfgffgffgdddddgdfssfgsdfg

94 ：

NvidiaでOpenGL用プログラマブルシェーダを書く場合、
プログラマがユニークなコードを書くのはレジスタコンビナかヴァーテクスシェーダであってテクスチャシャーダはあまり関与する余地が無いって認識あってますか？

95 ：

>>94
そのバーテックスシェーダーも
少ない引数とステップ数の為に
行う処理を選別するだけって感じだね。
頂点ブレンディングにコンストレジスタをさいて
ライトの数を減らすとか
その逆にするとか。
ユニークと呼べるほど・・。

96 ：

OpenGL、nVidiaのレジスタコンビナ・nvparseの構文に出てくる「.」（ドット演算？）は何を指すのでしょうか？
内積ですか？でも、レジスタコンビナのレジスタはスカラではなくてベクタですよね。
あと、レジスタコンビナで各RBGチャンネルを入れ替えたり、別のチャンネルにコピーしたりってできますか？

97 ：

ドットは内積。
色の入れ替えや複製はかなり制約がある。
詳細についてはレジスタコンバイナの仕様書を嫁。
nvparseは単純にその仕様をラップしているだけだ。

98 ：

>97
サンクスです。謎はとめました。
も一つ初歩的な疑問なんですが、OpenGLのレジスタコンビナを有効化すれば、マルチテクスチャのパスは排他的になると考えてよいのでしょうか？

99 ：

http://oss.sgi.com/projects/ogl-sample/registry/NV/register_combiners.txt

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

-RPGツクール総合スレッド＠製作技術（Part15）- (306)
ゲームのストーリィとその作成技術 (285)
ゲーム甲子園 (439)
モナーＲＰＧを作ろう！　Part 8 (274)
絵が描けない人間が素材を作るスレ (418)
1人でゲームが作れるように修行します。2 (384)
--log9.info------------------
【鑑定】棋具関係ネットオークション【ヲチ】 (441)
なぜ森内名人は棋界最強の呼び名が高いのか (557)
女流棋士総合スレッド 第二十八局 (457)
第19期大山名人杯倉敷藤花戦 Part3 (614)
棋譜貼り専門スレに関する疑問、議論用スレ★2 (318)
【将棋24】指してはいけない【危険人物】その31 (775)
森内の知名度と同じぐらいのものを挙げるスレ2 (933)
第62期王将戦 Part1 (837)
【電王戦】 米長 vs ボンクラーズ　Part28 (519)
名人戦契約更改内容予想スレ (504)
渋渋将棋部みてーになりてーよ！ (250)
アマ強豪の山田茂樹さん その2 (668)
屋敷伸之九段・応援スレPart.２ (797)
【女流】香川愛生【奨励会】 (444)
【将棋24】ソフト指ししてそうな会員　part14 (344)
米長邦雄永世棋聖総合スレ 22th (533)
--log55.com------------------
【西日本】〓SoftBank 新スパボ一括情報★74
【隔離】転売廚通報専用スレ
NTT docomo の恐るべき実態、暴利を貪る営業策略
〓SoftBankを本気で解約したい人のスレ 30人目
〓ソフトバンク今度は「メール自動受信」、ご用心！
純増率ナンバー１は今後もソフトバンク！！
ドコモ関西、基地局建設で古墳・嵐山を破壊　３
ドコモ新料金プラン「カケホーダイ＆パケあえる」39