[PD-dev] [GEM] update

chris clepper cclepper at artic.edu
Sun May 11 08:04:55 CEST 2003


Hi

i thought i would post an update concerning some of the things i have 
been working on.

- new object [pix_motionblur] which is a revised version of pix_blur 
with a slightly revised algo for improved performance and image 
quality.  this also frees up pix_blur so it can be changed to an 
abstraction based on pix_convolve.  i already committed this object.

- i have changed, but not committed, pix_texture so that the user can 
switch between power of 2 and rectangle textures on the fly via a 
'mode' message.  one question i have is whether or not rectangle 
textures actually work on linux or windows at the moment.  the tests 
in pix_texture use GemMan::texture_rectangle_supported which works 
fine on OSX but i'm not sure how that would affect the other 
platforms.  let me know if this looks ok for linux/windows, i don't 
want to break a critical object on another platform.

- i have pix_filmNEW playing in auto mode right now, but i have to 
agree with jamie's assessment that the new system really does nothing 
at all for OSX.  it may solve some problems on linux, but it seems to 
actually have many of the same cross-platform issues; i've had to 
ifdef some stuff in order to get it to even compile.  also, i don't 
think the structure is very clean or transparent since the various 
libs and APIs need to be taken care by platform. so doesn't it make 
more sense to have each platform manage the libs/APIs internally 
rather than do it in pix_filmNEW??


to maybe open up the communication a little bit, here are a few items 
i'm working on, or plan to work, on in the near future:

- an object for loading pixel shaders from a file.  i only have an 
ati 9000 right now so i can only do support for the ati extensions.

- some sort of object that will use glCopyTexImage2D to grab part of 
the framebuffer and apply it directly to a texture.  this would be a 
faster version of pix_snap and also enable some nifty feedback type 
effects.

- adding some sort of alpha info to the particle system for blending.

- figure out a way to easily exchange info between pix, particles and 
geos.  part_info is a good start for applying data generated by the 
particle system to other elements in GEM, but what about using pix_ 
data as a basis for the particle system?  or having the particle 
system manipulate vertices and texcoords?  or how about rendering 
each frame of video as an array of triangle or spheres or even 
texture mapped cubes?
i don't think that this means a type of system that requires the user 
to explicitly manage the data and do all the housekeeping like 
creating buffers, type and bounds checking, etc (a la jitter). 
instead a series of bridge objects can be constructed either in code 
or by abstraction to translate and guide the data around.  admittedly 
i don't have much concrete code to offer at this point, but just 
wanted to bounce the idea off the others devs to get some input.

check out this for an example of particles and pixel interaction:
http://www.shiffman.net/portfolio/reactive.html

cgc




More information about the Pd-dev mailing list