2024/03/12(火) [n年前の日記]
#1 [python] Python + glfwで疑似3D道路の描画実験中。その9
Windows10 x64 22H2上で、Python 3.10.10 64bit + glfw 2.7.0 + PyOpenGL 3.1.6 + Pillow (PIL) 10.2.0 を使って実験中。疑似3D道路を描画してみたい。
とりあえず、それっぽい感じになってきたので github にアップロードしておきます。
_mieki256/pseudo3d_py: Pseudo 3D road drawing sample using Python and OpenGL.
まあ、 _以前 HSP を使って書いたスクリーンセーバ とほとんど同じ見た目のサンプルではあるけど…。
HSP + 標準描画機能で実装した版と比べると、OpenGL を使ったことでビルボードの拡大縮小がちゃんと滑らかになって、比較的自然な見た目になってくれたかなと…。
HSP の標準描画機能(grotate, gsquare)は、拡大描画すると描画位置がガタガタとずれてしまう仕様なので、ギクシャクした動きになってしまうし、しかも、CPUが頑張ってソフトウェア処理で描画してるから、負荷も大きくてフレームレートも高くできない。それと比べると、さすがにハードウェアで描画してるだけあって…。OpenGL万歳。
今後の予定として、コレをC/C++で書き直して、スクリーンセーバにしてみたいと考えているところ。
一応、動かしてるPCのスペックもメモ。CPU : AMD Ryzen 5 5600X, GPU : NVIDIA GeForce GTX 1060 6GB。
とりあえず、それっぽい感じになってきたので github にアップロードしておきます。
_mieki256/pseudo3d_py: Pseudo 3D road drawing sample using Python and OpenGL.
まあ、 _以前 HSP を使って書いたスクリーンセーバ とほとんど同じ見た目のサンプルではあるけど…。
HSP + 標準描画機能で実装した版と比べると、OpenGL を使ったことでビルボードの拡大縮小がちゃんと滑らかになって、比較的自然な見た目になってくれたかなと…。
HSP の標準描画機能(grotate, gsquare)は、拡大描画すると描画位置がガタガタとずれてしまう仕様なので、ギクシャクした動きになってしまうし、しかも、CPUが頑張ってソフトウェア処理で描画してるから、負荷も大きくてフレームレートも高くできない。それと比べると、さすがにハードウェアで描画してるだけあって…。OpenGL万歳。
今後の予定として、コレをC/C++で書き直して、スクリーンセーバにしてみたいと考えているところ。
一応、動かしてるPCのスペックもメモ。CPU : AMD Ryzen 5 5600X, GPU : NVIDIA GeForce GTX 1060 6GB。
◎ 余談。木のビルボードのテクスチャについて :
◎ 余談その2。テクスチャ補間について :
OpenGLに指定するテクスチャの補間方法として、今回は GL_LINEAR (線形補間)を指定しているけれど。そのせいでビルボードの輪郭に黒い線がうっすらと出てしまっている。隣の色=黒ベタ部分の色を拾ってきて、その黒と線形補間して色の値を求めてしまうので、そういう見た目になるらしい。
解決策としては、GL_LINEAR ではなく GL_NEAREST を指定する方法もあるけれど、その場合ドットはクッキリするものの、拡大縮小時にガタガタというかゴワゴワした感じの見た目になってしまうので、ちょっと気持ち悪い。
他の解決策がないものかとググってみたけど、テクスチャ画像に対して輪郭部分をはみ出すように色を塗っておいて、しかしそのはみ出してる部分は透明になるようにアルファチャンネルの値を指定しておく、という手があるらしい。今回は試してないけれど、できればそのあたり、自動化してみたい作業ではあるなと…。
解決策としては、GL_LINEAR ではなく GL_NEAREST を指定する方法もあるけれど、その場合ドットはクッキリするものの、拡大縮小時にガタガタというかゴワゴワした感じの見た目になってしまうので、ちょっと気持ち悪い。
他の解決策がないものかとググってみたけど、テクスチャ画像に対して輪郭部分をはみ出すように色を塗っておいて、しかしそのはみ出してる部分は透明になるようにアルファチャンネルの値を指定しておく、という手があるらしい。今回は試してないけれど、できればそのあたり、自動化してみたい作業ではあるなと…。
[ ツッコむ ]
以上、1 日分です。