Re: [pygame] PyOpenGL and pygame.display.flip
Oops I hate when I search hours to find an answer and find it right when posting to a forum or mailing list ! I was just calling pygame.init() in another module than pygame.display.flip() and was doing a pygame.display.set_mode() elsewhere too without using DOUBLEBUFF flag. I'm not sure to quite understand what've done here but it surely comes from the fact my pygame.display thing are not at the same place as my first import pygame. Le 2014-11-25 11:10, sylvain.boussekey a écrit : Hi everyone, I'm running into difficulties when using an opengl window in pygame. For reasons I don't catch, sometimes, when I draw quads with pyopengl, I have to call pygame.display.flip to actually display anything, and sometimes, I don't, resulting in a blinking horrific mess when I draw multiple quads overlapping themselves. I really don't know when it happen but it does in one project, not in one another. Can't tell the difference... I'm using flags OPENGL | DOUBLEBUF | HWSURFACE for my pygame window Here's what I execute at the beginning of my drawing state : def clear(): glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) And here's my function to draw quads : def drawtexturedquad(imgid, pos, proj=True, siz=(1, 1), r=1.0, g=1.0, b=1.0, alpha=1.0): if proj: glMatrixMode(GL_MODELVIEW) else: glMatrixMode(GL_PROJECTION) glLoadIdentity() glPushMatrix() glEnable(GL_TEXTURE_2D) glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) glTranslated(-1, -1, 0) glTranslated(pos[0], pos[1], 0) glScalef(siz[0], siz[1], 1) glColor4f(r, g, b, alpha) glBindTexture(GL_TEXTURE_2D, imgid) glBegin(GL_QUADS) glTexCoord2f(0.0, 1.0) glVertex2f(-1.0, 1.0) glTexCoord2f(1.0, 1.0) glVertex2f(1.0, 1.0) glTexCoord2f(1.0, 0.0) glVertex2f(1.0, -1.0) glTexCoord2f(0.0, 0.0) glVertex2f(-1.0, -1.0) glEnd() glPopMatrix() glFlush()
Re: [pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking
On Fri, Feb 11, 2011 at 3:37 PM, amdlintuxo amdlintu...@gmail.com wrote:
Full code is here:
http://bpaste.net/show/13615/
Could some one test the full code or provide the idea what can cause
sporadic screen blinking.
Looking forwards for you support, i have nothing left to try to
resolve this problem, struggling third day, no luck. Maybe this
blinking is my HW config problem.
Whit the full code I got
Traceback (most recent call last):
File E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py, line 32, in glLibTestErrors
function()
File E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py, line 181, in main
tex0, (_w,_h) = upload_texture('data/screenshot.png', True)
File E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py, line 72, in upload_texture
data )
File C:\Python26\lib\site-packages\OpenGL\latebind.py, line 45, in
__call__
return self._finalCall( *args, **named )
File C:\Python26\lib\site-packages\OpenGL\wrapper.py, line 791, in
wrapperCall
raise errGLError: GLError(
err = 1281,
description = 'valor no v\xe1lido',
baseOperation = glTexImage2D,
pyArgs = (
GL_TEXTURE_2D,
0,
4,
640,
576,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
),
cArgs = (
GL_TEXTURE_2D,
0,
4,
640,
576,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
),
cArguments = (
GL_TEXTURE_2D,
0,
4,
640,
576,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
)
)
windows xp, python 2.6.5,
I provided a 640 x 576 data\screenshot.png
OpenGL.version.__version__
'3.0.1'
--
claudio
Re: [pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking
On Fri, Feb 11, 2011 at 5:01 PM, claudio canepa ccanep...@gmail.com wrote:
On Fri, Feb 11, 2011 at 3:37 PM, amdlintuxo amdlintu...@gmail.com wrote:
Full code is here:
http://bpaste.net/show/13615/
Could some one test the full code or provide the idea what can cause
sporadic screen blinking.
Looking forwards for you support, i have nothing left to try to
resolve this problem, struggling third day, no luck. Maybe this
blinking is my HW config problem.
Whit the full code I got
Traceback (most recent call last):
File E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py, line 32, in glLibTestErrors
function()
File E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py, line 181, in main
tex0, (_w,_h) = upload_texture('data/screenshot.png', True)
File E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py, line 72, in upload_texture
data )
File C:\Python26\lib\site-packages\OpenGL\latebind.py, line 45, in
__call__
return self._finalCall( *args, **named )
File C:\Python26\lib\site-packages\OpenGL\wrapper.py, line 791, in
wrapperCall
raise errGLError: GLError(
err = 1281,
description = 'valor no v\xe1lido',
baseOperation = glTexImage2D,
pyArgs = (
GL_TEXTURE_2D,
0,
4,
640,
576,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
),
cArgs = (
GL_TEXTURE_2D,
0,
4,
640,
576,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
),
cArguments = (
GL_TEXTURE_2D,
0,
4,
640,
576,
0,
GL_RGBA,
GL_UNSIGNED_BYTE,
'\x8d\x8e\xbc\xff\x8d\x8e\xbc\xff\x8d...,
)
)
windows xp, python 2.6.5,
I provided a 640 x 576 data\screenshot.png
OpenGL.version.__version__
'3.0.1'
--
claudio
after resampling to power of two (512 x 512) it passes that point, but seems
that this test machine (vga = intel 945g ) don't supports the funcionality:
I got
Traceback (most recent call last):
File E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py, line 32, in glLibTestErrors
function()
File E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py, line 239, in main
''')
File E:\incomplete copia sempron sancle 2010 04
30\scode\shader_test\shader.py, line 101, in compile_program
program = glCreateProgram()
File C:\Python26\lib\site-packages\OpenGL\platform\baseplatform.py, line
340
, in __call__
self.__name__, self.__name__,
NullFunctionError: Attempt to call an undefined function
glCreateProgramObjectARB, check for bool(glCreateProgramObjectARB) before
calling
--
claudio
Re: [pygame] (pyopengl) GLSL fragment shader with arrays uniform cause sporadic screen blinking
My laptop also has a 945gm so I can't test this until I get to my desktop (although glsl shaders will work on os x with a 945gm, intel only supports arb shaders in windows opengl). The http://bpaste.net/show/13617/ is not the same because the glsl compiler will usually compile out (make inactive) all of your uniforms since you aren't referencing them in the shader. I often find this very annoying for testing. I've often had problems with arrays in glsl, and never got them to work correctly in os x. You could try using a 1D texture lookup if the arrays are the problem. I don't really understand what you are trying to do in your pixel shader, you could get rid of all of the else's and just put gl_FragColor at the end of main and it would have the same effect. Your loop just changes the final uv, so in effect you don't even need a for loop because your code will always just make the end color by using imax-1. Everything else gets overwritten. Devon On Fri, Feb 11, 2011 at 12:37 PM, amdlintuxo amdlintu...@gmail.com wrote: Hi all. Strange sporadic screen blinking when using array uniform variables in fragment shader. Unfortunately i have only one HW config to test this(maybe the problem is in my HW) The strange is: The problem occurs with shader http://bpaste.net/show/13616/ even if i pass empty arrays into it (imax = 0), so actually shader should do any distortion work. And the problem DOES NOT occur with shader http://bpaste.net/show/13617/ So it has to be something in my shader, but i was thought that code http://bpaste.net/show/13617/ is the same as (http://bpaste.net/show/ 13616/ + if imax = 0) But why screen blinking occurs? Actually without uniform arrays, by passing only simple uniform shader works great. Full code is here: http://bpaste.net/show/13615/ Could some one test the full code or provide the idea what can cause sporadic screen blinking. Looking forwards for you support, i have nothing left to try to resolve this problem, struggling third day, no luck. Maybe this blinking is my HW config problem.
Re: [pygame] PyOpenGL Release 3.0.0 (final)
Hi Mike! Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or Python extensions written in C to improve performance? Is there a possibility of mixing ctypes with Python extensions in C for the more critical parts? /Peter On 2009-04-01 (Wed) 17:48, Mike C. Fletcher wrote: PyOpenGL is the traditional OpenGL binding for the Python language (Python 2.x series). This release is the first major release of the package in more than 4 years. PyOpenGL 3.x is a complete rewrite of the PyOpenGL project which attempts to retain compatibility with the original PyOpenGL 2.x API while providing support for many more data-formats and extensions than were wrapped by the previous code-base. It attempts to retain the easy approachable API of the original PyOpenGL bindings, focusing more on ease of development (both for client code and the library itself) than speed. Build and installation has been dramatically simplified. It is possible to work directly from a PyOpenGL bzr branch or to merely unpack the package into your PYTHONPATH. To install from source and/or participate in development: bzr branch lp:pyopengl bzr branch lp:pyopengl-demo then add the pyopengl/OpenGL directory to your PYTHONPATH. You can also download the source distributions from: http://pyopengl.sourceforge.net and use standard distutils commands to install. PyOpenGL 3.x is already supported by the PyInstaller exe packaging utility, and can be made to work with Py2exe with inclusion statements. PyOpenGL may be installed using the easy_install script if desired. There are no setuptools/package-resources dependencies in PyOpenGL 3.0.0 final. You can install PyOpenGL on supported platforms (currently Linux, Win32 and OSX) with the following if you have setuptools, PIL and Numpy installed: easy_install PyOpenGL easy_install PyOpenGL-Demo You can then run the scripts in the PyOpenGL-Demo package. PyOpenGL 3.x introduces package-level configuration flags which allow you to modify the behavior of the entire PyOpenGL package, e.g. by introducing extremely verbose logging, or turning off all error-checking to improve performance. Of particular note is a flag which allows you to disable APIs which have been deprecated by the ARB in OpenGL 3.0. Other flags allow you to control the trade-off between ease-of-use and performance during the development and release process. PyOpenGL 3.x provides access to the entire OpenGL 3.0 API, as well as most extensions which have been entered in the OpenGL extension registry. Commonly used extensions can have Pythonic wrappers written easily, and many of the commonly used extensions already have simplified APIs provided. It also provides wrappers for the GLUT, GLE and GLX libraries. The AGL and WGL modules are not provided with PyOpenGL 3.x, as most devs are using window-manager-based GL operations. PyOpenGL 3.x provides a simple plug-in API that allows you to write data-format or platform plugins. These can be used to easily add native support for your array-friendly data-formats (vector classes and the like). There is a sample data-format plug-in which wraps the Vertex Buffer Objects extensions (in the OpenGL/arrays/vbo.py module). PyOpenGL 3.x's documentation has been regenerated and the build process for the documentation has been updated so that it can be easily regenerated to include pointers to other Open Source PyOpenGL project's online code viewers. If you would like to add your project to the list of referenced projects, please contact the author with details of your code viewer's url, code license and project name. Notes in the reference documentation indicates the deprecated entry points for OpenGL 3.0. If you have a PyOpenGL code-base you should be looking at reworking the code in order to eliminate the use of legacy APIs before OpenGL 3.1 drivers become mainstream. At minimum you should be converting away from per-vertex operations and the use of display lists toward using array-based geometry. You should expect a performance decline with the use of PyOpenGL 3.x versus PyOpenGL 2.x! PyOpenGL 3.x will have an accelerator module released in time to provide better performance, but the development method (ctypes) is inherently slower than the C (SWIG) method previously used. If your code is performance critical you should likely use the accelerator module when it becomes available. Also consider using the package-level configuration flags to remove support functionality as you near release, use of these flags can provide more than 2x speedup in most cases. The 3.0.0 final release has a few bugs fixed from the previous 3.0.0c1 release. Users of the release candidate should upgrade. PyOpenGL 3.0.0 is intended for use with the Python 2.x series, porting to Python 3.x is not
Re: [pygame] PyOpenGL Release 3.0.0 (final)
Peter Gebauer wrote: Hi Mike! Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or Python extensions written in C to improve performance? Is there a possibility of mixing ctypes with Python extensions in C for the more critical parts? The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve performance. Yes, you can fairly freely mix C/Cython/Pyrex coded OpenGL-using extensions with PyOpenGL code. The current GL context is used by all PyOpenGL calls (well, the ones that don't explicitly specify contexts, such as those in GLUT or GLX). As for rewriting the core library, I doubt *I* will do another rewrite. But the fact is that someone could easily generate a new Cython/Pyrex wrapper without breaking a sweat. They would just then need to do all the project management and maintenance on the code-base, and I quit working on the SWIG code-base because of the maintenance headaches, so it's not really something I want to go back to. The use of ctypes means that we should eventually be able to run on all of Jython, PyPy, IronPython, Unladen Swallow and CPython with the core Python+ctypes-only implementation. Interpreters that actually *use* the ctypes annotations (PyPy) may eventually be able to use the fact of using ctypes to generate almost-C-level performance from the code. HTH, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] PyOpenGL Release 3.0.0 (final)
On Fri, Apr 3, 2009 at 2:20 AM, Mike C. Fletcher mcfle...@vrplumber.comwrote: Peter Gebauer wrote: Hi Mike! Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or Python extensions written in C to improve performance? Is there a possibility of mixing ctypes with Python extensions in C for the more critical parts? The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve performance. Yes, you can fairly freely mix C/Cython/Pyrex coded OpenGL-using extensions with PyOpenGL code. The current GL context is used by all PyOpenGL calls (well, the ones that don't explicitly specify contexts, such as those in GLUT or GLX). As for rewriting the core library, I doubt *I* will do another rewrite. But the fact is that someone could easily generate a new Cython/Pyrex wrapper without breaking a sweat. They would just then need to do all the project management and maintenance on the code-base, and I quit working on the SWIG code-base because of the maintenance headaches, so it's not really something I want to go back to. The use of ctypes means that we should eventually be able to run on all of Jython, PyPy, IronPython, Unladen Swallow and CPython with the core Python+ctypes-only implementation. Interpreters that actually *use* the ctypes annotations (PyPy) may eventually be able to use the fact of using ctypes to generate almost-C-level performance from the code. A funny side note is that ironpython can more easily run CPython compiled extensions than ctypes code at the moment. This is done by emulating the CPython API. cu,
Re: [pygame] pyopengl sprite/particle performance
Your bottleneck might not be in your rendering code. I don't know wether PyOpenGL is even supposed to be much faster than pygame, but if rendering is not where your bottleneck is, switching will not help at all. I didn't look at the code, but in the profile it seems _collide_bullet is a frequently used method. Are you using a naive collision detection algorithm? In that case, something like a quadtree or cell-based collision detection approach may heavily improve the performance of your game. Hugo On Sun, Jun 15, 2008 at 10:21 PM, flx [EMAIL PROTECTED] wrote: Hi all I've been fidling for some time with pygame on a tryout project [1], it's a fast 2d action game. After a while i switched the drawing code to pyopengl looking for a litle performance boost, but i haven't got the expected results, i have had to lower the global fps from 60 to 30 and even then, it lags with 150-200 sprites on screen. I know there must be something wrong with my code because there are more complicated things drawn with pyopengl. This are the first lines of profiling output (switch to monospace font now ;) ) 6202178 function calls in 52.748 CPU seconds ncalls tottime percall cumtime percall filename:lineno(function) 1480666.5070.000 28.7800.000 gl.py:114(draw) 2006205.5320.000 27.8060.000 wrapper.py:650(wrapperCall) 2006163.8280.0003.8280.000 numpymodule.py:114(contiguous) 2006163.5790.0005.6220.000 numpymodule.py:19(dataPointer) 7665402.8030.0003.0000.000 error.py:167(glCheckError) 4406602.3680.0003.8150.000 ship.py:60(_collide_bullet) code referenced is on [1] or running svn checkout http://pyship.googlecode.com/svn/trunk/ pyship recomended since the tarbal is several days old and there are some particle and sprite especific examples on the svn [1] - http://code.google.com/p/pyship/ -- .__.·º(foolhu!) (oO) / | | \
Re: [pygame] pyopengl sprite/particle performance
2008/6/16 Hugo Arts [EMAIL PROTECTED]: Your bottleneck might not be in your rendering code. I don't know wether PyOpenGL is even supposed to be much faster than pygame, but if rendering is not where your bottleneck is, switching will not help at all. You are right, i'll try something like sprite pooling for particles or something similar. I didn't look at the code, but in the profile it seems _collide_bullet is a frequently used method. Are you using a naive collision detection algorithm? In that case, something like a quadtree or cell-based collision detection approach may heavily improve the performance of your game. The collision detection is a simple bounding spheres method using square distances, I don't think that building a quadtree would be much faster but I'll give it a try too when i have some time Aniway, i believe that particles are what are making the whole thing lag and they aren't counted for collisions, so i'll check the particle updating methods Hugo thanks for your reply [1] - http://code.google.com/p/pyship/ -- .__.·º(foolhu!) (oO) / | | \ -- .__.·º(foolhu!) (oO) / | | \
RE: BUG: pygame.image.save(screen) with pyopengl 3.x Re: [pygame] PyOpenGL Screenshots
Hi, pygame.image.save() of gl Surfaces is still a problem on windows, causing segfaults. I commited a test called image__save_gl_surface_test.py cheers. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of René Dudfield Sent: Monday, June 02, 2008 12:35 PM To: pygame-users@seul.org Subject: Re: BUG: pygame.image.save(screen) with pyopengl 3.x Re: [pygame] PyOpenGL Screenshots hi, I fixed this on the weekend. I stopped using pyopengl to get glReadPixels (since pyopengl 3.x broke the glReadPixels API), and instead loaded the gl functions dynamically with C. Committed revision 1261. You can get auto-built binaries for windows/mac osx here if needed: http://thorbrian.com/pygame/builds.php cheers, On Wed, May 7, 2008 at 2:47 PM, René Dudfield [EMAIL PROTECTED] wrote: Added a bug to the subject. cu, On Wed, May 7, 2008 at 2:44 PM, René Dudfield [EMAIL PROTECTED] wrote: looks like pyopengl 3.x returns a numpy array now instead of a string by default... which breaks pygame.image.save on gl with pyopengl 3.x. Here's a work around screenshot function for gl. def save_screen(screen, filename): def readScreen(x, y, width, height): Read in the screen information in the area specified glFinish() glPixelStorei(GL_PACK_ALIGNMENT, 4) glPixelStorei(GL_PACK_ROW_LENGTH, 0) glPixelStorei(GL_PACK_SKIP_ROWS, 0) glPixelStorei(GL_PACK_SKIP_PIXELS, 0) data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, tostring): data = data.tostring() return data def saveImageData(width, height, data, filename): Save image data surface = pygame.image.fromstring(data, (width, height), 'RGB', 1) pygame.image.save(surface, filename) data = readScreen(0,0, screen.get_width(), screen.get_height()) saveImageData(screen.get_width(), screen.get_height(), data, filename) On Wed, May 7, 2008 at 2:27 PM, René Dudfield [EMAIL PROTECTED] wrote: hi, glReadPixels, make a surface, then use pygame.image.save() Then use ffmpeg, or vlc etc to make a movie out of still frames. cheers,
Re: [pygame] PyOpenGL Screenshots
Hi, I was wondering if the latest solution to render pyopengl from pygame (Alistair Buxton's script) includes off-screen rendering. I want to render something and save it as a sequence of images, but I dont want to display it anywhere. Is there a way to 'hide' this window? Thanks Astan -- Formulations of number theory: Complete, Consistent, Non-trivial. Choose two. Animal Logic http://www.animallogic.com Please think of the environment before printing this email. This email and any attachments may be confidential and/or privileged. If you are not the intended recipient of this email, you must not disclose or use the information contained in it. Please notify the sender immediately and delete this document if you have received it in error. We do not guarantee this email is error or virus free.
Re: [pygame] PyOpenGL Screenshots
hi, You could do this with mesa 3d. I don't think you can do it without an x server. You can also draw offscreen with a software surface by using the dummy video driver - but that won't work for opengl. cu, On Tue, May 13, 2008 at 4:24 PM, Astan Chee [EMAIL PROTECTED] wrote: Hi, I was wondering if the latest solution to render pyopengl from pygame (Alistair Buxton's script) includes off-screen rendering. I want to render something and save it as a sequence of images, but I dont want to display it anywhere. Is there a way to 'hide' this window? Thanks Astan -- Formulations of number theory: Complete, Consistent, Non-trivial. Choose two. Animal Logic http://www.animallogic.com Please think of the environment before printing this email. This email and any attachments may be confidential and/or privileged. If you are not the intended recipient of this email, you must not disclose or use the information contained in it. Please notify the sender immediately and delete this document if you have received it in error. We do not guarantee this email is error or virus free.
Re: [pygame] PyOpenGL Screenshots
hi again, note, you can convert a series of images with image magik, or the gimp most easily I think... convert -delay 20 -loop 0 bla*.tga animated.gif Or opening them as gimp layers, then saving to an animated gif. cu, On Wed, May 7, 2008 at 2:44 PM, René Dudfield [EMAIL PROTECTED] wrote: looks like pyopengl 3.x returns a numpy array now instead of a string by default... which breaks pygame.image.save on gl with pyopengl 3.x. Here's a work around screenshot function for gl. def save_screen(screen, filename): def readScreen(x, y, width, height): Read in the screen information in the area specified glFinish() glPixelStorei(GL_PACK_ALIGNMENT, 4) glPixelStorei(GL_PACK_ROW_LENGTH, 0) glPixelStorei(GL_PACK_SKIP_ROWS, 0) glPixelStorei(GL_PACK_SKIP_PIXELS, 0) data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, tostring): data = data.tostring() return data def saveImageData(width, height, data, filename): Save image data surface = pygame.image.fromstring(data, (width, height), 'RGB', 1) pygame.image.save(surface, filename) data = readScreen(0,0, screen.get_width(), screen.get_height()) saveImageData(screen.get_width(), screen.get_height(), data, filename) On Wed, May 7, 2008 at 2:27 PM, René Dudfield [EMAIL PROTECTED] wrote: hi, glReadPixels, make a surface, then use pygame.image.save() Then use ffmpeg, or vlc etc to make a movie out of still frames. cheers,
Re: [pygame] PyOpenGL Screenshots
AWESOME! That screenshot taker works! Thanks so much! Now, I could copy each frame individually to the animation maker, but I would prefer it automated. Is there a way to make the screenshots be clumped together into a .gif file via a program? (Incidentally, I agree about the implausibility of using a .gif file for a movie. The gif animator I'm working with does exports). Ian
Re: [pygame] PyOpenGL Screenshots
hi, as I mentioned in the other emails you can make gif images with at least image magik, ffmpeg, and gimp. cheers, On Thu, May 8, 2008 at 6:28 AM, Ian Mallett [EMAIL PROTECTED] wrote: AWESOME! That screenshot taker works! Thanks so much! Now, I could copy each frame individually to the animation maker, but I would prefer it automated. Is there a way to make the screenshots be clumped together into a .gif file via a program? (Incidentally, I agree about the implausibility of using a .gif file for a movie. The gif animator I'm working with does exports). Ian
Re: [pygame] PyOpenGL Screenshots
I figured out a way to do it in my program--Animation Shop Pro. It would still be cool to have examples of how to do this without Animation Shop. I was thinking ffmpeg or pil for doing so. I looked around, but couldn't find anything. Thanks everyone, Ian
Re: [pygame] PyOpenGL Screenshots
Here it is. I didn't spend any time making this code nice, but you can just rip out the parts you need. 2008/5/8 Alistair Buxton [EMAIL PROTECTED]: I have a full example of doing exactly this task using python to render to a series of png images (which you can load into something like adobe premier), or a raw RV24 file (which you can transcode under linux using... transcode). Will post it as soon as I've dug it out and tested it still works. Includes examples of using transcode too. 2008/5/8 Ian Mallett [EMAIL PROTECTED]: I figured out a way to do it in my program--Animation Shop Pro. It would still be cool to have examples of how to do this without Animation Shop. I was thinking ffmpeg or pil for doing so. I looked around, but couldn't find anything. Thanks everyone, Ian -- Alistair Buxton [EMAIL PROTECTED] -- Alistair Buxton [EMAIL PROTECTED] #!/usr/bin/env python # Python OpenGL - Video file # (c) 2008 Alistair Buxton [EMAIL PROTECTED] # Handy for doing procedural animations for compositing with other # videos in your favourite video editing package. import os, random, math from OpenGL.GL import * from OpenGL.GLU import * import pygame, pygame.image, pygame.key from pygame.locals import * from PIL import Image ## # render settings # 1 = best QUALITY = 16 # whether to actually write output files or just preview render_on = True # If you don't want to write separate png files, you can just dump the output # from glReadPixels() into one huge file and encode it with transcode: # transcode --use_rgb -i whatever.rv24 -x raw=RGB,null -y xvid4 -o output.xvid.avi -k -z -f 25 # (for xvid) # But beware that whatever.rv24 will be HUGE as it is uncompressed (not even RLE). # the size will be width*height*numframes*3 bytes, that's 31mb/sec for standard PAL video. # Also worth mentioning: RV24 export is RGB, but png export is RGBA - thus if you use # RV24 method, you will loose the alpha channel of your video. # render type # if true, write one big RV24 raw video file # if false, write a png sequence render_rv24 = False if render_on: # size of final render w = 720 h = 576 else: # size for preview w = 720 h = 576 # how many frames to render before exiting max_frames = 25 # framerate of rendered video fps = 25.0 if render_rv24: framefile = file(whatever.rv24, wb) ## # the snowflake animation stuff flakes = [] class SnowFlake(object): def __init__(self): self.x = random.randrange(0,720) self.y = random.randrange(0,576) self.z = 3 + (random.randrange(3,20) / random.randrange(3,25)) self.dy = random.randrange(1,10) self.drift = random.randrange(1,100)/1000.0 self.rad = random.randrange(1,100)/100.0 def draw(self): glColor4f(1.0,1.0,1.0,1.0) if self.z 0: return glBegin(GL_POLYGON) r = math.floor(self.z * 4) for i in range(int(r)): glVertex2f( self.x+(self.z*math.sin(2*math.pi*(i/r))), self.y+(self.z*math.cos(2*math.pi*(i/r))) ) glVertex2f( self.x, self.y+self.z ) glEnd() def update(self, ftime): self.rad += ((ftime*0.5)+self.drift) self.x += math.sin(self.rad) self.y -= 0.7*ftime*(40.0+self.dy)*self.z; if (self.y -10): self.y = 586 if (self.x -10): self.x = 730 if (self.x 730): self.x = -10 # standard opengl stuff init/draw/update/resize def resize((width, height)): if height==0: height=1.0 glViewport(0, 0, width, height) glMatrixMode(GL_PROJECTION) glLoadIdentity() gluOrtho2D(0, 720, 0, 576) #gluOrtho2D(-(width/(2*height)), width/(2*height), 0, 1) glMatrixMode(GL_MODELVIEW) glLoadIdentity() def init(): glShadeModel(GL_SMOOTH) glClearColor(0.3,0.5,0.7,0.0) glClearDepth(1.0) glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST) glDisable(GL_DEPTH_TEST) for i in range(100): flakes.append(SnowFlake()) def update(ftime): for f in flakes: f.update(ftime) def draw(): glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) glMatrixMode(GL_MODELVIEW) glLoadIdentity() glDisable(GL_TEXTURE_2D) for f in flakes: f.draw() ### # write a png file from GL framebuffer data def png_file_write(name, number, data): im = Image.frombuffer(RGBA, (720,576), data, raw, RGBA, 0, 0) fnumber = %05d % number im.save(name + fnumber + .png)
Re: [pygame] PyOpenGL Screenshots
Ian Mallett wrote: Hello, -I have a project which must be finished by Thursday. The project is a movie, for a presentation, and my solution has been to make a program to render each frame in OpenGL. I can now render each frame individually, but now I face the challenge of turning these renders into a movie. (Movie capture programs are no good--free ones have drawbacks, and in any case the renders are slow to update (think 1 fps tops).). -I decided to do it as a .gif animation, as I have several programs for making movies from a series of images Using an animated gif would be dumb. http://www.yourmachines.org/tutorials/mgpy.html shows how to use ffmpeg to create video files from images. --Noah signature.asc Description: OpenPGP digital signature
Re: [pygame] PyOpenGL Screenshots
hi, glReadPixels, make a surface, then use pygame.image.save() Then use ffmpeg, or vlc etc to make a movie out of still frames. cheers,
Re: [pygame] PyOpenGL Screenshots
looks like pyopengl 3.x returns a numpy array now instead of a string by default... which breaks pygame.image.save on gl with pyopengl 3.x. Here's a work around screenshot function for gl. def save_screen(screen, filename): def readScreen(x, y, width, height): Read in the screen information in the area specified glFinish() glPixelStorei(GL_PACK_ALIGNMENT, 4) glPixelStorei(GL_PACK_ROW_LENGTH, 0) glPixelStorei(GL_PACK_SKIP_ROWS, 0) glPixelStorei(GL_PACK_SKIP_PIXELS, 0) data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, tostring): data = data.tostring() return data def saveImageData(width, height, data, filename): Save image data surface = pygame.image.fromstring(data, (width, height), 'RGB', 1) pygame.image.save(surface, filename) data = readScreen(0,0, screen.get_width(), screen.get_height()) saveImageData(screen.get_width(), screen.get_height(), data, filename) On Wed, May 7, 2008 at 2:27 PM, René Dudfield [EMAIL PROTECTED] wrote: hi, glReadPixels, make a surface, then use pygame.image.save() Then use ffmpeg, or vlc etc to make a movie out of still frames. cheers,
BUG: pygame.image.save(screen) with pyopengl 3.x Re: [pygame] PyOpenGL Screenshots
Added a bug to the subject. cu, On Wed, May 7, 2008 at 2:44 PM, René Dudfield [EMAIL PROTECTED] wrote: looks like pyopengl 3.x returns a numpy array now instead of a string by default... which breaks pygame.image.save on gl with pyopengl 3.x. Here's a work around screenshot function for gl. def save_screen(screen, filename): def readScreen(x, y, width, height): Read in the screen information in the area specified glFinish() glPixelStorei(GL_PACK_ALIGNMENT, 4) glPixelStorei(GL_PACK_ROW_LENGTH, 0) glPixelStorei(GL_PACK_SKIP_ROWS, 0) glPixelStorei(GL_PACK_SKIP_PIXELS, 0) data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, tostring): data = data.tostring() return data def saveImageData(width, height, data, filename): Save image data surface = pygame.image.fromstring(data, (width, height), 'RGB', 1) pygame.image.save(surface, filename) data = readScreen(0,0, screen.get_width(), screen.get_height()) saveImageData(screen.get_width(), screen.get_height(), data, filename) On Wed, May 7, 2008 at 2:27 PM, René Dudfield [EMAIL PROTECTED] wrote: hi, glReadPixels, make a surface, then use pygame.image.save() Then use ffmpeg, or vlc etc to make a movie out of still frames. cheers,
Re: [pygame] PyOpenGL and win32screensaver
Thanks Luke, it works great. Luke Paireepinart wrote: What kind of side effect should I expect from the OPENGL flag? Any ideas/workarounds? Happy Everything, Thanks, Ken! Okay, you asked for a workaround :) Don't use win32screensaver! If you just create a py2exe of your program, rename it to .scr, and put it in the right folder, it will work as the screensaver. Now, you won't get to create a cool demo in the preview window. Whenever your program's run, Windows will pass it arguments. SO when it's passed the -p, or whatever the 'preview' argument is, just do nothing. This should eliminate all conflicts, and you don't have to do any weird hardcoding of values! However, as I said, no preview. Also, it doesn't pack everything into a single EXE. Well, that's why it's called a workaround! By the way, does win32screensaver create a single file? I don't really want to take the time to check, so if you could just answer that for me it would be nice. Also, remember you have to handle the inputs yourself. I don't know if win32 screensaver exits on mousemovements or whatever, but your program won't if you just py2exe it. You'll have to check for mousemotion events, or keypresses, and whatnot. Anyway, HTH, -Luke
Re: [pygame] PyOpenGL and win32screensaver
What kind of side effect should I expect from the OPENGL flag? Any ideas/workarounds? Happy Everything, Thanks, Ken! Okay, you asked for a workaround :) Don't use win32screensaver! If you just create a py2exe of your program, rename it to .scr, and put it in the right folder, it will work as the screensaver. Now, you won't get to create a cool demo in the preview window. Whenever your program's run, Windows will pass it arguments. SO when it's passed the -p, or whatever the 'preview' argument is, just do nothing. This should eliminate all conflicts, and you don't have to do any weird hardcoding of values! However, as I said, no preview. Also, it doesn't pack everything into a single EXE. Well, that's why it's called a workaround! By the way, does win32screensaver create a single file? I don't really want to take the time to check, so if you could just answer that for me it would be nice. Also, remember you have to handle the inputs yourself. I don't know if win32 screensaver exits on mousemovements or whatever, but your program won't if you just py2exe it. You'll have to check for mousemotion events, or keypresses, and whatnot. Anyway, HTH, -Luke
Re: [pygame] PyOpenGL
Bob Ippolito wrote: On Aug 8, 2006, at 2:28 PM, Kris Schnee wrote: I'm interested in trying OpenGL again with that sample code just posted, but isn't using PyOpenGL now a problem considering that it seems to require NumPy rather than Numeric, and that NumPy blatantly withholds its documentation? Since when does PyOpenGL require NumPy? The version I see is from Jan 2005, about a year before NumPy even existed (under that name as its own project). The answer to your question is most definitely No. because normal use involves just built-in types... but did PyOpenGL move away from sourceforge, or is your question simply not based on reality? It could be, but I was looking here: http://sourceforge.net/project/showfiles.php?group_id=5988 And saw PyOpenGL-2.0.2.01.py2.3-numpy23.exe (and py2.4) presented as what seemed to be the most recent distribution. Kris
Re: [pygame] PyOpenGL
On 8/8/06, Kris Schnee [EMAIL PROTECTED] wrote: I'm interested in trying OpenGL again with that sample code just posted, but isn't using PyOpenGL now a problem considering that it seems to require NumPy rather than Numeric, and that NumPy blatantly withholds its documentation? Isn't that begging the question? Honestly though, I use PyOpenGL, and I can't see how NumPy is used by PyOpenGL at all... in particular I haven't found any features of PyOpenGL which require me to write any code using NumPy, so I haven't had any need for documentation at all.
Re: [pygame] PyOpenGL
On 8/9/06, Kris Schnee [EMAIL PROTECTED] wrote: I'm interested in trying OpenGL again with that sample code just posted, but isn't using PyOpenGL now a problem considering that it seems to require NumPy rather than Numeric, and that NumPy blatantly withholds its documentation? Last time I checked... I was using Numeric for PyOpenGL arrays, and it worked. As for documentation, you can always use internal docstrings if you need to. I've personally only had to look up documentation for Numeric 3 times over the last 12 months. Everything else I get from docstrings, tutorials, the source and other people's code. Having said that, you will only need to use arrays in PyOpenGL when you are doing things like bulk sending of vertices, texture coords, normals and color data to the video card for use with glDrawArrays and other, similar functions. You can go a long way in OpenGL without needing to use any of these facilities. -Sw.
Re: [pygame] PyOpenGL
On 8/8/06, Bob Ippolito [EMAIL PROTECTED] wrote: Since when does PyOpenGL require NumPy? The version I see is from Jan 2005, about a year before NumPy even existed (under that name as its own project). The confusion is how the PyOpenGL site defines a dependency... PyOpenGL requires NumPy in a lot of the same ways that PyGame requires numeric... looks like most of the optional dependencies have to do with OpenGLContext (I don't know what that is exactly, but you don't need it with pygame + PyOpenGL) see here: http://pyopengl.sourceforge.net/context/numeric_arrays.html The answer to your question is most definitely No. because normal use involves just built-in types... but did PyOpenGL move away from sourceforge, or is your question simply not based on reality? The PyOpenGL Sourceforge home page is the one that lists the dependencies: http://pyopengl.sourceforge.net/documentation/installation.html in particular, that page lists: # Tcl/Tk appropriate for your Python version # GLUT 3.7+ # Python Imaging Library (PIL) any recent version # Numeric Python (Numpy) v. 23 (for PyOpenGL 2.0.1.08) all as dependencies, but each of those is optional
Re: [pygame] PyOpenGL
The whole Numeric / numarray / numpy / scipy thing is getting a bit confusing. I agree. Bloody nightmare. Alan
Re: [pygame] PyOpenGL
On 8/9/06, Bob Ippolito [EMAIL PROTECTED] wrote: Eh? What does scipy or numarray have to do with it? Totally different packages. Especially scipy. They all provide facilities for array manipulation. import Numeric import numarray import scipy n = 1500 a_numeric = Numeric.arange(1., n) a_numarray = numarray.arange(1., n) a_scipy = scipy.arange(1., n) I think the confusion results from people using the word 'numpy' to refer to the Numeric package, and he numarray package. I actually cannot find a package which lets me 'import numpy'... [...5 minutes later with google...] It seems array stuff has been moved out of scipy core, and into a numpy package. From http://numeric.scipy.org/ : For about 6 months, the new package was called SciPy Core (not to be confused with the full SciPy package which remains a separate package), and so you will occasionally see references to SciPy Core floating around.It was decided in January 2006 to go with the historical name of NumPy for the new package. Realize that NumPy (module name numpy) is the new name. Do not be confused by references to scipy_core. These should all be replaced by numpy. Also, because of the name-change, there were a lot of dicussions that took place on [EMAIL PROTECTED] and [EMAIL PROTECTED] On a different node, I've attached CSV file with results from this benchmark program, with a third test for scipy. http://arbutus.mcmaster.ca/dmc/numpy/numcomp.py Interestingly numarray consistently beats numeric and scipy with arrays of length greater than 1500. With arrays smaller than 1500, SciPy and Numeric are often on par with each other. -Sw. Array Size,Numeric,Numarray,Scipy,Fastest 1,1.62123919964e-06,4.67061282635e-06,1.61885501385e-06,Scipy 2,1.64984942913e-06,6.57080890179e-06,1.61170245647e-06,Scipy 3,1.66892291546e-06,5.64097644329e-06,1.65938617229e-06,Scipy 4,1.65938617229e-06,5.55037738323e-06,1.63792850018e-06,Scipy 5,1.67130710125e-06,5.5599141264e-06,3.29970599651e-06,Numeric 6,1.68084384441e-06,5.63143970013e-06,1.68084384441e-06,Numeric 7,1.70945407391e-06,5.59090854168e-06,1.68084384441e-06,Scipy 8,1.69038058758e-06,5.63143970013e-06,1.68084384441e-06,Scipy 9,1.72137500286e-06,6.04867221355e-06,1.69991733074e-06,Scipy 10,1.90972568035e-06,5.72919131756e-06,1.90972568035e-06,Numeric 20,1.85012103558e-06,5.81979037762e-06,1.85965777874e-06,Numeric 30,2.04085589886e-06,5.86032153606e-06,6.92843677044e-06,Numeric 40,2.12907077312e-06,6.11066104412e-06,2.12907077312e-06,Numeric 50,2.17913867474e-06,6.02006198406e-06,2.15052844524e-06,Scipy 60,2.29119540691e-06,6.089203372e-06,2.31026889324e-06,Numeric 70,2.39133121014e-06,6.17980243206e-06,2.37941028118e-06,Scipy 80,2.64167071819e-06,6.21079684734e-06,2.61067630291e-06,Scipy 90,2.52007724285e-06,6.18933917522e-06,3.05175067425e-06,Numeric 100,2.6917386198e-06,6.33954288006e-06,2.69889117718e-06,Numeric 110,2.73942233562e-06,6.33954288006e-06,2.73942233562e-06,Numeric 120,2.83002139568e-06,6.48020984173e-06,2.83002139568e-06,Numeric 130,2.87055255413e-06,6.38961078167e-06,2.87055255413e-06,Numeric 140,2.93015719891e-06,6.45159961224e-06,2.87055255413e-06,Scipy 150,2.97068835735e-06,8.46146823406e-06,3.02075625896e-06,Numeric 160,3.08036090374e-06,6.65187121868e-06,3.03982974529e-06,Scipy 170,3.0898976469e-06,6.49928332806e-06,3.08036090374e-06,Scipy 180,3.3020901823e-06,6.83068515301e-06,3.28063251019e-06,Scipy 190,3.3307004118e-06,6.6995549345e-06,3.3307004118e-06,Numeric 200,3.32831622601e-06,7.67945529461e-06,3.30924273968e-06,Scipy 210,3.43083621502e-06,6.82114840984e-06,3.58103991985e-06,Numeric 220,3.46898318768e-06,6.8592953825e-06,3.44990970135e-06,Scipy 230,4.68968631268e-06,6.89028979778e-06,3.57865573406e-06,Scipy 240,3.65971805096e-06,6.84975863934e-06,3.71932269573e-06,Numeric 250,3.74078036785e-06,7.56978274822e-06,3.73839618206e-06,Scipy 260,3.82899524212e-06,6.95943118572e-06,3.82184268475e-06,Scipy 270,3.85045291424e-06,6.97135211468e-06,4.06979800701e-06,Numeric 280,3.96012546062e-06,7.18831302166e-06,3.9410519743e-06,Scipy 290,4.0197301054e-06,7.12155581951e-06,4.0197301054e-06,Numeric 300,4.95909930706e-06,7.25983859539e-06,4.10079242229e-06,Scipy 310,4.15801288128e-06,7.16923953533e-06,4.19139148235e-06,Numeric 320,4.24861194134e-06,7.94886828899e-06,4.27006961346e-06,Numeric 330,4.27006961346e-06,7.41957904339e-06,4.32967425823e-06,Numeric 340,4.42027331829e-06,8.25165988445e-06,4.32967425823e-06,Scipy 350,4.49179889202e-06,7.3909688139e-06,4.47987796307e-06,Scipy 360,4.60862399578e-06,7.64846087933e-06,4.58955050945e-06,Scipy 370,4.62054492474e-06,7.51017810345e-06,4.59908725262e-06,Scipy 380,4.65869189739e-06,7.47918368816e-06,5.1617550993e-06,Numeric 390,4.88995791912e-06,7.59124042034e-06,4.7898221159e-06,Scipy 400,4.87088443279e-06,7.59124042034e-06,5.74826480389e-06,Numeric 410,4.91141559124e-06,7.61031390667e-06,4.91141559124e-06,Numeric 420,4.99009372234e-06,7.74144412518e-06,5.53845645428e-06,Numeric
