hi.
Zitiere chris clepper cclepper@artic.edu:
Hi
- new object [pix_motionblur] which is a revised version of pix_blur
i have noticed this, great.
quality. this also frees up pix_blur so it can be changed to an abstraction based on pix_convolve.
which reminds me, we have to make ánd abstraction-folder.
- 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
rectangle textures work under linux if you have an nvidia-card, recent drivers and are compiling agains the GL-include files provided by nvidia. but there is still some bug in the [pix_texture] object, which refuses to display rectangle-textures on nvidia-cards if they are not compiled against nvidia-sources.
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.
works great. (but of course, the underlying check for rectangle-support has to be adapted to meet (say) nvidia's extensions)
- i have pix_filmNEW playing in auto mode right now, but i have to
great (thanks a lot!)
agree with jamie's assessment that the new system really does nothing at all for OSX.
which might be true. however is there no chance that there might be other decoder-libs under mac some day ?
it may solve some problems on linux, but it seems to
it does ;-)
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??
actually that was the idea. maybe it is just really bad "design" what i have done. i (hope that i) am free for any suggestions. (but of course don't want to break your work again)
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.
this really sounds cool
- 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.
long on my todo list (since daniel talked about this) - but never had the time.
- adding some sort of alpha info to the particle system for blending.
i thought the new libparticle already had alpha-support (the colors are now rgba instead of rgb) so this might be solved already.
- 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
.... sounds great!
have a go (don't curse too often) ;-) i'm looking forward to the next time i have access to the cvs.
mfg.as.r IOhannes