[PD-dev] [GEM] update

[Daniel Heckenberg]

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 at 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