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