Texturing with GLSL (in PyOpenGL and Pygame)

Question

After getting frustrated with the fixed-function pipeline being slow in Python, I started looking into shaders to draw my game's parallax backgrounds. However, I can't find any simple way to texture what vertices are drawn.

I currently have a PyOpenGL Vertex Buffer Object with an array of vertices, each of which is like this: [x, y, z, texX, texY, texID]

I'm passing these to the shaders with getAttribLocation/glEnableVertexAttribArray. I'm not sure if it works, since the shaders don't currently compile, but things have been working ok with coloured vertices before I added my probably terrible texture code.

What I want is to draw a textured model with a shader, with multiple textures, but the model is a flat background. It's a large (1600x800 or so) image, which is split into 256x256 textures and quad polys. (Side question: Is it better to have more small polys, so less bits of polygon are off-screen, or big polys so that there's less texture-binding?)

Because it's multiple, related textures, I want to do it all in the shader without having to bind the texture for each chunk on the CPU, so I thought sending texture data with vertex data would be best, but I can't get it to work.

Could someone please give me a simple example of the vertex and fragment shaders interacting to make multiple polys with different textures?

EDIT: shaders, vbo and things here: http://pastebin.com/3LaYiyvh Shaders now compile, but triangles are invisible.

EDITEDIT: Got there! Not sure what finally cracked it, but here's the program: http://pastebin.com/k87sfiEf I think it's something like, so long as you bind all the textures at the start, the shader can swap between them. But I'm not sure. Also of note, it's a bad idea to split a big background into smaller chunks to draw because of swapping textures while drawing. Big textures with wasted space are fine, atlases are better!

Answer 1

After getting frustrated with the fixed-function pipeline being slow in Python, I started looking into shaders to draw my game's parallax backgrounds.

If fixed function is slow for you, using shaders is not going to make it faster.

Probably you're just doing something fundamentally wrong, like using immediate mode, or having no HW acceleration at all (due to lack of properly installed drivers or similar).

Answer 2

Could someone please give me a simple example of the vertex and fragment shaders interacting to make multiple polys with different textures?

Google for GLSL tutorials. Examples were written before, and there's no reason to write them again just for you. Or download NVidia OpenGL SDK, and examine it. OpenGL.org also recommends books. "Orange book" covers shaders.

which is split into 256x256

Traditionally it is recommended to do the opposite - take all textures you can and combine them into single "atlas" texture, which is preferably something like 16384x16384 - to minimize state switching.

What I want is to draw a textured model with a shader, with multiple textures, but the model is a flat background. It's a large (1600x800 or so) image

1600x800 will fit entirely into texture on pretty much any hardware since Riva TNT 2 pro. If you care about "wasted" texture memory, then many cards support non-power-of-2 textures. however, non-power-of-2 textures normally have limitations, and on some hardware (certain ati cards + drivers) using such texture will cause fps to take nose dive. I.e. from 200..400 to 40. It isn't worth it. On hardware with even 256MB of VRam, unused 40 percents of texture is micro optimization. And then again, you could use texture atlases, and fill "wasted" space with something useful, if you feel stingy about vram usage. Also, keep in mind that you never know how efficiently driver uses the video memory.

I want to do it all in the shader without having to bind the texture for each chunk on the CPU,

You can't do that. Shaders don't bind textures. They use textures that has already been bound.

I'm not sure if it works, since the shaders don't currently compile,

Well, make them compile and ask again. It is not possible to assist you without seeing your shader or error message. You do know that shader compiler produces error messages, right?

After getting frustrated with the fixed-function pipeline being slow in Python

Consider switching to compiled language like C or C++. You can easily get 200..400 frames per second with raw fixed function opengl in C/C++ application ("dungeon crawler") without using buffers or display lists - IF you use correct algorithm for hidden surface removal (and vsync is disabled) AND your textures are mip-mapped. well known "fixed function" applications include Quake 1..3, Half-Life 1, Cube and many other games which are blazingly fast. Which means - if it is slow, it is your fault.

Unlike C/C++, Python has larger function call overhead - executing bytecode, extracting value of unknown type from list/tuple (that can contain "anything" by design) then dumping it as a float into something like glVertex3f while finally forwarding it to native API call WILL be slower than similar C/C++ call which has no intermediate steps. You can counteract that by using display lists or buffer objects, but for me it isn't worth the effort. However, using specific language for specific task is a matter of personal preference.

--EDIT--

However, if shaders can't bind textures, how does multitexturing work?

There are N texture stages (at least 2 - se glGet/GL_MAX_TEXTURE_COORDS/GL_MAX_TEXTURE_UNITS), you set multiple textures at once. See glActiveTexture. Without shaders (fixed function) you specify color operation for each stage using glTexEnv. With shaders, you set multiple textures, specify which sampler uses which texture stage using glUniform1i/glUniform1v, then read data from them within shader using Sampler2D and similar functions. Shader cannot switch textures. It can use textures that has been already set by your program. Shader has no knowledge about any textures outside of shader. Technically, shader doesn't even know about "texture" it has "sampler" which is used to read data.

Or texture sampling? Shaders must be able to do some work with selecting/changing textures...

Shader does not switch or select textures at all. This part is done by your program. For more information read OpenGL specifications and GLSL specifications for your version of opengl/glsl. Both are available for download from opengl.org website, "documentation" menu.

As I already said, at this point you need GLSL tutorial or book. Both are easy to find. Get either one and keep reading it until you "get" it. Currently it doesn't look like you did your homework and tried to make a simple shader using book or tutorial. If you can't find a book, then NVidia OpenGL SDK had plenty of examples (in C/C++, but it isn't that hard to convert them).

Answer 3

Perhaps you can find something useful in my Minecraft mapping blog posts. All the examples use Python, Pygame and PyOpenGL. They do lots of stuff in a fragment shader. They only use trivial geometry: just one quad.

From your description, it sounds like you are much better off with one large texture than with multiple small ones. However, there are scenarios where it really does make sense to have lots of small textures and select between them in the shader. Array textures can be useful in this situation, as they don't suffer the same problems with filtering and clamping that you can get when using a texture atlas. (Indeed, the examples in my blog use a texture atlas and suffer some problems with mip-mapping when zoomed out to far. I've recently been using array textures to solve this problem.)