Forget this message, I was looking at the wrong example, and I have no clue about gemframebuffer because it has always crashed pd when rendering is turned on. ( win32,S3 Graphics UniChrome GEM: ver: 0.91-cvs GEM: compiled: Dec 11 2006 GEM: using SSE2 optimization )
Patco a écrit :
maciej wojnicki a écrit :
well no pix_snap will not do this pix_snap2tex as well
in both situation raw rendered object is still in the gem window gemframebuffer might do this (there is an exaple .in textures catalog - 10.framebuffer.pd, that does almost what i need)
Hello, I guess you mean 10.pixdatasimple.pd in Gem pix example, if what you need is something that is not in single buffering, you'll need [Gem/pix_data] as well for extracting RGB information to redraw the image with colored geos [zexy/repeat], at least that what I need for animating the pixels. You can use some RGB filters, for example, at the output of pix_data a filter that only allow red or green, then it would reduce the number of repeated objects, and it might avoid to blow up the processor. for reducing the cpu process it's also possible to store pixel values in a table and reading different parts of the table with several [repeat] and [counter] objects, If you want to see how it looks like, take a look at this movie:
http://megalego.free.fr/pd/YI.mov
and you might have somewhere to start with this:
http://megalego.free.fr/pd/YI.rar
Apparently is also possible to reduce the CPU processing with using the gl objects, like Cyrille Henry have shown once(, but I couldn't help with this because almost all gl doesn't work on my computers, on linux, windows, with a Nvidia, an openchrome, with last cvs snapshots...).
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Patco