Thread: [PyOpenGL-Users] Pygame surfaces as PyOpenGL textures?
Brought to you by:
mcfletch
From: Jan E. <ch...@in...> - 2001-11-10 11:59:31
|
Hi, Well, I got bitten by the OpenGL bug, and did some small tests with pygame and pyopengl. All works just fine, and speed of development is way faster than with C/C++. Did a small terrain rendering that is both slow and ugly, but which seems to do what it should do. See a snapshot at: http://www.infa.abo.fi/~chakie/cm/snapshot4.jpg However, no terrain without trees. Simple trees are easiest to do with a single billboarded texture. It does need to be partially transparent though. So, the problem is how I can get pyopengl to use a texture that is partially transparent. Ideally I'd like to use simple colorkey transparency, i.e. set a color as transparent. That part works nicely in pygame. I can do this: surface = pygame.image.load ( 'tree.bmp' ) surface.set_colorkey ( (255, 0, 255) ) to set magenta as transparent. Works fine as long as blitted within pygame. To create a texture I use the folloing black magic: # convert to a string image = pygame.image.tostring ( surface, "RGBA" ) ix, iy = surface.get_size () # generate a texture id tree = glGenTextures(1) glBindTexture(GL_TEXTURE_2D, tree ) # do some Rocket Science(tm) glPixelStorei(GL_UNPACK_ALIGNMENT,1) glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR) glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST) gluBuild2DMipmaps(GL_TEXTURE_2D, 4, ix, iy, GL_RGBA, GL_UNSIGNED_BYTE, image) Now, this works quite fine, but no transparency is still visible. Before rendering the quads for the trees I do the following spells: glEnable(GL_BLEND) glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) Depending on how I fiddle with all kinds of parameters I end up with either trees with magenta borders (no transparency) or then just a few pixels visible (too much transparency). :) Has anybody done this before? I looked at NeHe:s tutorials, where the above code partially comes from, but he uses "pil" for loading the images, and I found no way to set transparency using that. Pil didn't seem to like any kinds of images that has an alpha channel in the image, which was the reason for trying to it using pygame. I know I do something very wrong here, but it's very easy as OpenGL texture handling is a deep, deep swamp until you have learnt the rules of the game. Apart from this little problem the rendering was way faster than I thought it would be. Loading data from disk and doing normal calculations is a bit slow, but that's done only once. By using display lists heavily I have IMHO quite ok performance when doing software rendering only. I don't think my old G450 can even do 3D, and at least not on Linux. A feature I like very much with pyopengl is that it reports errors, i.e. when I try to do something illegal in, say, a glBegin(GLFOO) I get a stack trace if I do something that's not allowed. In C/C++ I have to manually check the error flag after each call to see if something is wrong. Regards, Chakie -- Many an ancient lord's last words had been: "You can't kill me because I've got magic aaargh...." -- Terry Pratchett, Interesting Times |
From: Richard J. <ric...@op...> - 2001-11-10 22:11:53
|
On Sat, 10 Nov 2001 22:59, Jan Ekholm wrote: > Hi, > > Well, I got bitten by the OpenGL bug, and did some small tests with > pygame and pyopengl. All works just fine, and speed of development is way > faster than with C/C++. > > Did a small terrain rendering that is both slow and ugly, but which seems > to do what it should do. See a snapshot at: > > http://www.infa.abo.fi/~chakie/cm/snapshot4.jpg There was a really useful article either on gamasutra or gamedev regarding texturing of landscapes. Number one tip is to blend - use a large texture that gives a change over a large area and then the smaller texture like the one you're currently using to give some finer detail. Makes the repetition of the finer detail texture much less apparent. Richard |
From: Jan E. <ch...@in...> - 2001-11-11 12:26:18
|
On Sun, 11 Nov 2001, Richard Jones wrote: >On Sat, 10 Nov 2001 22:59, Jan Ekholm wrote: >> Hi, >> >> Well, I got bitten by the OpenGL bug, and did some small tests with >> pygame and pyopengl. All works just fine, and speed of development is way >> faster than with C/C++. >> >> Did a small terrain rendering that is both slow and ugly, but which seems >> to do what it should do. See a snapshot at: >> >> http://www.infa.abo.fi/~chakie/cm/snapshot4.jpg > >There was a really useful article either on gamasutra or gamedev regarding >texturing of landscapes. Number one tip is to blend - use a large texture >that gives a change over a large area and then the smaller texture like the >one you're currently using to give some finer detail. Makes the repetition of >the finer detail texture much less apparent. Hmm, this sounds like a good idea. I'm a total newbie when it comes to issues like this. Unfortunately I think that performance would suffer a great deal from additional blending? My ultimate goal with this project is to see if it is feasible to build something like the terrain in Combat Mission (my favourite game) in pygame and pyopengl. After a year or so (if all works) I'd change the terrain rendering in our game from the current 2D to this 3D engine. See a few shots at: http://www.combatmission.com/mods/grass.asp Richard, I'll try your code tomorrow when I get back to the machine where I installed pyopengl. Do you happen to have access to a png where the alpha channel definitely works with your code? Could make it easier to debug if I know the file is absolutely ok. -- - "Remember -- that which does not kill us can only make us stronger." - "And that which does kill us leaves us dead!" -- Terry Pratchett, Carpe Jugulum |
From: Richard J. <ric...@op...> - 2001-11-11 20:32:14
Attachments:
point_64.png
|
On Sun, 11 Nov 2001 23:26, Jan Ekholm wrote: > On Sun, 11 Nov 2001, Richard Jones wrote: > >There was a really useful article either on gamasutra or gamedev regarding > >texturing of landscapes. Number one tip is to blend - use a large texture > >that gives a change over a large area and then the smaller texture like > > the one you're currently using to give some finer detail. Makes the > > repetition of the finer detail texture much less apparent. > > Hmm, this sounds like a good idea. I'm a total newbie when it comes to > issues like this. Unfortunately I think that performance would suffer a > great deal from additional blending? Most 3d cards will do multitexturing with almost no performance hit. > Richard, I'll try your code tomorrow when I get back to the machine where > I installed pyopengl. Do you happen to have access to a png where the > alpha channel definitely works with your code? Could make it easier to > debug if I know the file is absolutely ok. Attached. It's not very good (should be white), but it does have the transparency :) Richard |
From: Jan E. <ch...@in...> - 2001-11-12 09:41:34
|
On Mon, 12 Nov 2001, Richard Jones wrote: >On Sun, 11 Nov 2001 23:26, Jan Ekholm wrote: >> On Sun, 11 Nov 2001, Richard Jones wrote: >> >There was a really useful article either on gamasutra or gamedev regarding >> >texturing of landscapes. Number one tip is to blend - use a large texture >> >that gives a change over a large area and then the smaller texture like >> > the one you're currently using to give some finer detail. Makes the >> > repetition of the finer detail texture much less apparent. >> >> Hmm, this sounds like a good idea. I'm a total newbie when it comes to >> issues like this. Unfortunately I think that performance would suffer a >> great deal from additional blending? > >Most 3d cards will do multitexturing with almost no performance hit. Apparently my code runs ~40fps on a p300 with a vodoo3. Which is basically good news. >> Richard, I'll try your code tomorrow when I get back to the machine where >> I installed pyopengl. Do you happen to have access to a png where the >> alpha channel definitely works with your code? Could make it easier to >> debug if I know the file is absolutely ok. > >Attached. It's not very good (should be white), but it does have the >transparency :) Hmm, it doesn't look ok either. I get either a white rectangle and something yellowish with the "flare" in the middle. -- "Students?" barked the Archchancellor. "Yes, Master. You know? They're the thinner ones with the pale faces? Because we're a university? They come with the whole thing, like rats --" -- Terry Pratchett, Moving Pictures |
From: Richard J. <ric...@op...> - 2001-11-12 10:35:30
|
On Mon, 12 Nov 2001 20:41, Jan Ekholm wrote: > >Attached. It's not very good (should be white), but it does have the > >transparency :) > > Hmm, it doesn't look ok either. I get either a white rectangle and > something yellowish with the "flare" in the middle. Well, it has an alpha channel - I use it in that code I sent to the list... Richard |
From: Jan E. <ch...@in...> - 2001-11-12 11:06:10
|
On Mon, 12 Nov 2001, Richard Jones wrote: >On Mon, 12 Nov 2001 20:41, Jan Ekholm wrote: >> >Attached. It's not very good (should be white), but it does have the >> >transparency :) >> >> Hmm, it doesn't look ok either. I get either a white rectangle and >> something yellowish with the "flare" in the middle. > >Well, it has an alpha channel - I use it in that code I sent to the list... Well, then the fubar is in my OpenGL code somewhere. I tried to see what the code you sent and the one I use do differently, but can't come up with anything that would differ in any major way. I'll try to use your particles in my code and see if they turn up ok. Of course it could be the XFree86 4.1.0.1 drivers for this Matrox G450 that just don't work ok, but I doubt that. Richard, thank you so much for all your patient help. This seems to be an issue where the faulty link is the one located between the screen and the chair. :) -- "Stercus, stercus, stercus, moriturus sum." -- Terry Pratchett, Interesting Times |
From: Richard J. <ric...@op...> - 2001-11-10 22:18:48
Attachments:
exhaust.py
|
On Sat, 10 Nov 2001 22:59, Jan Ekholm wrote: > Has anybody done this before? I looked at NeHe:s tutorials, where the > above code partially comes from, but he uses "pil" for loading the images, > and I found no way to set transparency using that. Pil didn't seem to like > any kinds of images that has an alpha channel in the image, which was the > reason for trying to it using pygame. PIL honours the alpha channel in images just fine. Here's the relevant code from one of my object's __init__ method (complete class is attached): # texture self.texture = Image.open('point_64.png') ix, iy = self.texture.size image = self.texture.tostring("raw", "RGBA", 0, -1) self.pointtex = glGenTextures(1) glBindTexture(GL_TEXTURE_2D, self.pointtex) glPixelStorei(GL_UNPACK_ALIGNMENT,1) glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, ix, iy, 0, GL_RGBA, GL_UNSIGNED_BYTE, image) and then in the draw() method: def draw(self, world): glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR) glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST) glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE) glBlendFunc(GL_SRC_ALPHA, GL_ONE); glEnable(GL_BLEND) glDisable(GL_DEPTH_TEST) glEnable(GL_TEXTURE_2D) glBindTexture(GL_TEXTURE_2D, self.pointtex) glDisable(GL_LIGHTING) glColor(1, 1, 1) glBegin(GL_QUADS) for life, position, velocity, colour in self.points: if colour[3] <= 0: continue glColor4f(*colour) x, y, z = position glTexCoord2f(0, 0) glVertex3f(x, y, z) glTexCoord2f(1, 0) glVertex3f(x+4, y, z) glTexCoord2f(1, 1) glVertex3f(x+4, y+4, z) glTexCoord2f(0, 1) glVertex3f(x, y+4, z) glEnd() glEnable(GL_LIGHTING) glEnable(GL_DEPTH_TEST) glDisable(GL_BLEND) glDisable(GL_TEXTURE_2D) (sorry about the complete lack of commenting :) Also, the code attached isn't very optimised. I'm still learning OpenGL, no time to make it fast or pretty :) Richard |