++C;この広告は、90日以上更新していないブログに表示しています。2017-09-21光と闇が両方そなわり最強に見えるいい感じにできた複数光源のシャドウマッピング虚像っぽいのシャドウマッピングにおいて光源視点で全てのポリゴンを視野に収めていない場合、光源方向のちょうど反対側に虚像?(逆さ影)みたいのができてしまう。曰く、デプスバッファとの比較時に負のデプス値(光源後ろ側)は無限遠の値を取るらしい。これによって、光源視野外の後ろ側にも影ができてしまう。推測ではシェーダでさらに判定をかませば解決できそうだけど、めんどくさいので光源のスポットカットでごまかした*1。variable組み込み配列は、変数でインデックスを付ける前にサイズを再宣言する必要があります配列に変数の添え字を使おうとしたら出たエラー、再宣言の仕方分からなくて適当にfor分を平文に展開した。シャドウマッピングをすべての光源に対して行おうとした場合に自分の環境だと、光源数が8個に加えてオブジェクトに適用するテクスチャがあるので、テクスチャが合計9枚必要になる。gl_TexCoord[8]でテクスチャ座標にアクセスしようとしたらアウトオブレンジではじかれた。これも再宣言すれば解決するのかもしれないけど、めんどくさいので自分で変数を用意してごまかした。gl_TexCoord[gl_MaxTextureCoords];を書けばコンパイルが通った。想像の10倍以上時間かかってめんどくさかった影を作るということで描画の回数が増えたんだけど、そこらへんの柔軟性は考えてなかったのでメインループ一回壊してから再構成した。マルチテクスチャということでシェーダも同じ感じのことした。glslの書籍とか持ってないのでネットをさまよったけど、自分の欲しい情報が見つからなくて困った。glslは本買って体系的に理解した方がいいのかもしれない。ちなみに、とあるOpenGL系のサイトの逆行列の計算式まちがってるので気を付けよう(3時間もっていかれた)。ソースコードはいまからリファクタリングして上げるかもしれないし上げないかもしれない。21:32光と闇が両方そなわり最強に見えるTweet広告を非表示にするもっと読むコメントを書く2017-09-02.objとIBO.objのフォーマット.objファイルは主に頂点座標とテクスチャ座標、法線の3つの情報から構成されていて、それを表面情報でインデックス付けしている。これによって同じ座標の頂点はひとまとめにされ、同様にテクスチャ座標なんかも一つにまとめられて扱いやすくなっている。IBOとの親和性フォーマット的にインデックス付けされてるし、一番最初にIBOを使おうと考えるんだけど、結論から言えばOpenGLでは無理っぽい。無理とは言ったけど、たとえば頂点だけを利用して描画する分には可能。この場合、法線は一方向のみでテクスチャなんかも使えない。作ったのだから、法線で陰影付けしたいしテクスチャだって貼り付けたい。この場合、.objでは一つの頂点に対して3つの属性(頂点/テクスチャ/法線)が付与されていて、それぞれが別のインデックスで表されているため一つのIBOでは対応できない。同じ頂点(ここでの同じとは3属性すべてがおなじであること)が限りなく少ない.objファイルではIBOの仕組みを使うことに意味がないということになる。.objを展開IBOが使えないということで、頂点情報をインデックスではなく実際の値として展開する必要がでてくる。0.21の形式に展開しなければならない。このとき、モデルのポリゴン数が仮に4000ポリゴンだとすると頂点数は3倍の12000でかなり多い(純粋な頂点数はカエルの場合8000弱)。メモリの消費が激しいこの方法だが、調べた限りでは展開することが一般的なようだ(展開以外のいい手法がない?)。上記の通り、ポリゴン毎に頂点を展開していくとメモリを消費することは妥協するしかないにしても、データの変更にかなりのコストがかかるという問題が生じる。本来8000頂点に対してだけ行えばよかった演算を、1.5倍の12000頂点に対して行う必要が生じてしまう(回転の場合、さらに法線にも処理を行うので約3倍以上の処理)。展開すること自体泥臭かったが、解決策はもっと泥臭く、自分の考えた方法はインデックスを処理毎に展開しなおすことだ。回転にしろ移動にしろ、処理を行うのは純粋な頂点(重複のない展開前の頂点)だけにし、処理を行った後に随時描画用の頂点に展開しなおすということだ。遅くなりそうなこの方法だが、自分独自のプログロムのフレームレートでは、展開済みの全頂点に対して処理を行う場合の20fpsから設定値の50fpsまでに上昇した。終わりに今回書いたのは、自分の調べた範囲の情報と解決法であり、不確かだったり至らない点が多いと考えられ、多分恥をかくような内容かもしれない。そもそも、こんな冗長な方法しかなくOpenGLに適切な方法が用意されていないのはにわかに信じがたい。仮にOpenGLに用意されてなくても上記以上にいい方法がある、もしくはOpenGL自体にこの問題を解決するスマートな方法がある場合、是非とも教えて欲しいし知りたいと思う。普通にオプション変えて出力したらいい感じになった。シェーダを疑ってたけどOpenGLではデフォルトでスムースシェーディング有効らしい。00:19普通にできたTweet広告を非表示にするもっと読むコメントを書く2017-08-31.objファイルを読み込んでみた法線がない!法線が弱い!ポリゴン丸見え!ボーンつけるの(どっちかっていうとblenderが)めんどくさいから、代わりにobjファイルを読み込むプログラムを書いていた。blenderというか結構年季のあるソフト全般ってできること多すぎて、結局何していいかわからなくなるから大変。objファイルを読み込むとこまではいけたけど、ポリゴンが丸見えになってしまった(足の付け根付近)。3Dモデリングだったので10時間かかりました。初心者でもここまで作れるなんて素晴らしい時代ですね。わかんないけど、このあとBlenderでボーンとかアニメーションとかつけるんすかね?Blender、そこまで触ってないけど字が小さくて嫌です。04:56かえるをつくったーTweet広告を非表示にするもっと読むコメントを書く2017-08-02ゲームをアップロードしてましたPurPoseゲームwww.freem.ne.jpソースコードgithub.comゲーム概要3Dのローグライクゲームです。・・・ゲームの説明はめんどくさいのでリンク先のページでダウンロードして見てください。この記事は説明書に連絡先として書いたのに、ブログにゲームのこと書いてなかったから書きました。不具合とかはこの記事にコメントしてくれるとありがたいです。本当はゲームを宣伝しなかった場合のダウンロード数について書こうと思ってたけど、書けるほどの材料が集まらなかった*1ので諦めました。44(+5)これを見て少ないと思うかもしれないけど、自分の想像より多い。なんでかっていうと、このブログの閲覧数が20もいってないから。考えると、フリーゲームの需要は結構あるのかな?それとも夏休みの開始に投稿タイミングが重なったからかな?多分、後者。はじめました円筒と球の衝突判定って簡単なのでは?円筒って便利ですよね?キャラクター同士の衝突判定を考えたとき、「キャラクターの当たり判定を球にして移動の軌跡を円筒にする」っていうのが一番最初にぱっと思いつきますよね?そうでもないですか?だけどネットにそこまで落ちてないネットで衝突判定のアルゴリズム探すんだけど、検索方法が悪いのかいまいち見かけない気がする。簡単だから仕方ないので図を書いて考えると、あっさり答えが出てしまった。線分と球の衝突判定をほんの少し拡張しただけなので、あえてネットにまで書く必要がないんですね。(というか、円筒って太さ持った線分だから、そんなの当然の如く分かるでしょ的スタンスなのかもしれない。seg;}円筒と球の衝突判定ってどちゃくそ重い見たらわかるけど、分岐処理があほみたいに多い。「キャラクターの当たり判定を球にして移動の軌跡を円筒にする」みたいなことは、処理が重すぎて毎フレームできたものじゃない。本末転倒だけど、ネットにないのは実用性がないからなのかもしれない。妥協案として、キャラクターは自分の半径以上1回の処理で動けないってルールを追加するのが妥当な*2気がする。*3キャラクターを速く動かしたいなら、球と球の衝突判定にしてフレームレート上げましょう!!いつ使うんですか?めったに使えたものではないので、銃弾とかの稀に発生するオブジェクトなら使えるかもしれない。それでも線分として処理をした方が速い。極太レーザーならありなのかもしれない。*1:そこまで検証してない*2:アニメーション的にも無理がなくなる*3:もっといい方法、あったら教えてください。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。