Hi all,
Looks like I have a bit of work on my plate to keep things moving in the Windows world!
From: "chris clepper" cclepper@artic.edu
- 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.
This sounds good. I'd also like to implement texture naming to allow loaded textures to be shared easily - good for particles and all sorts of things.
- 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??
Hmm.... I think it should be possible to do things in the modular way that pix_filmNEW attempts and without making the implementation and maintenance harder for the OS/lib module than it would be for a separate object in the old pix_film system. Given the advantages of this and the fact that most of the libraries can in fact be used on most platforms this seems to make the effort worthwhile to me...?
On this subject - have the Mac folks managed to convince QT to play mpegs and flash files yet? If so it's probably time for me to do the QTML port so we can get QT playback on Windows.
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.
excellent - sounds very promising. any thoughts about how to move the shader program into the patching domain?
- 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.
yup - as promised I'll put my version of this into CVS. I was waiting until I'd had a chance to get the performance of this up to scratch on OS X and linux but there are other people here better equipped to do this. Look for [pix_snap2tex] later tonight (my time).
- 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.
Yup - I've done some similar things in patches and externals. Easy to do the hard way with [counter]s and [pix_data] but slow. So I then went all the way to a monolithic external with lots of messages for control.
The particle system style approach is definitely more flexible however. It would be good to have geometric particle generators which could also be parameterised on lists, tables or pix_ data. E.g. generate grids of particles and have the color/ size/ displacement of each etc based on the sampling the data.
For good performance, it's probably necessary to use display lists for the particles, I imagine. Altho there's quite a lot of code in GEM devoted to caching branches in display lists they don't seem to be used often/at all - is that right?
ideas for particle system generators: - halftone screens: - grid with variable angle. - concentric circular screen - (animated) paths - circles loops, spline curves - geometric objects ... - 1-d to 3-d density function based on input list/table/pix_data - openGL feedback based system where you can define the generator as a GEM render chain using normal GEM / openGL primitives which is run in feedback mode to generate particle positions. Imagine being able to have a mesh turn into a swarming mass of particles...
other ideas: Of course it would be nice it were possible to interpolate smoothly between the different particle system generation functions somehow... so that the particles themselves move consistently.
Daniel