hello,
the work around also does not work for me (even with nvidia). as soon as one starts to work with higher resolutions and non square gemwins it becomes slow and tricky.
pix_snap2tex should not impose much of a performance hit unless the window resolution is really huge (2048x1536 or larger). If it does then it has probably fallen back to software to do a pixel format conversion or there is some other hardware incompatibility.
exactly, i work at the moment for a project with 2048*768 (2 screens). to be able to make fullscreen motionblur i need to snap 2048*2048 which puts cpu to 98%.
anyway i found a workaround for the workaround which delivers a good result for just 10% cpu; i compose the fullscreen motionblur out of 2* 1024*1024 snaps, textured on 2 squares.
You need to get the GL_COLOR_BUFFER_BIT and related constants and make a mask. A better interface could be made for the message.
i really need to figure out how to use the GEMgl* objects
All it really does is enable or disable a buffer for clearing by glClear(). I recall that someone posted a patch not long ago that used the GEMgl calls to disable clearing the depth buffer, which does the same thing.
i remember - but it did not work on my nvidia (not linux not windows) but it worked on an ati card osx G4. it also was a single buffering patch but i would like to control the clearing with double buffering.
best
erich
exactly, i work at the moment for a project with 2048*768 (2 screens). to be able to make fullscreen motionblur i need to snap 2048*2048 which puts cpu to 98%.
anyway i found a workaround for the workaround which delivers a good result for just 10% cpu; i compose the fullscreen motionblur out of 2* 1024*1024 snaps, textured on 2 squares.
i forgot to mention that i also had to scale down the gemwin to 1600 * 600 for the 10% cpu
e
Perhaps 2048 hits a limit on your hardware and it falls back to software. You don't need to scale up to a power of two for the capture though since pix_snap2tex uses subtexturing or rectangle textures when available. Even at powers of two the 2048x768 is 2048x1024 which is the exact same number of pixels as the two 1024x1024.
cgc
On 8/19/06, Erich Berger eb@randomseed.org wrote:
exactly, i work at the moment for a project with 2048*768 (2 screens). to be able to make fullscreen motionblur i need to snap 2048*2048 which puts cpu to 98%.
anyway i found a workaround for the workaround which delivers a good result for just 10% cpu; i compose the fullscreen motionblur out of 2* 1024*1024 snaps, textured on 2 squares.
i forgot to mention that i also had to scale down the gemwin to 1600 * 600 for the 10% cpu
e
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Perhaps 2048 hits a limit on your hardware and it falls back to software. You don't need to scale up to a power of two for the capture though since pix_snap2tex uses subtexturing or rectangle textures when available. Even at powers of two the 2048x768 is 2048x1024 which is the exact same number of pixels as the two 1024x1024.
yes i know that it would do that, but i did not get the motionblur effect when not using power of 2 snaps sizes and it also needs to be textured on a square.
one effect is also that the closer the alpha is to 1 the more the blur starts to behave like running ink.
the "real" effect i only achieved with square gemwins, pw2 snap sizes and fullscreen squares.
some tests for 1600*600 you can see at randomseed.org/view/bunt/ they are rendered with a alpha 1 - which gives this inky effect. in a patch where everything has square dimension this would look very different - like single buffering. it looks quite funky - but is not intended :-) .
if one takes the alpha lower the motion blur works really well though.
best
erich
On Sat, 19 Aug 2006, Erich Berger wrote:
i forgot to mention that i also had to scale down the gemwin to 1600 * 600 for the 10% cpu
1600*600 is just below one megapixel. there might be a 4 megabyte limit somewhere.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
chris clepper -
Erich Berger -
Mathieu Bouchard