hi.
a few commits i made to the gem-cvs (and probably a lot i have commited but haven't kept in mind) i tried to comment all of them (and it was very tiresome...)
Pixes: 1. merged [pix_texture] and [pix_texture2] again. still the old pix_texture2.cpp is not deleted (but [pix_texture] already adds an alias to [pix_texture2]) i have added the rectangle-texturing for nvidia-cards. however, it might work or not on other machines than mine. please ! do test it. also i think i have fixed a bug, that crashed [pix_texture] when no image was present.
2. pix_video (under linux): now has a message for setting the colour-space (like [color grey( or [color RGBA() apropos: chris said something about openGL not liking to swap colour-spaces on the fly. i think this was a bug in [pix_texture] (i think). the base-texture has to be the same colour-space as the sub-texture. after i had changed this, i could switch between colour-spaces. (but unfortunately the yuv422 provided by the video4linux-drivers seem to be something different to what an nvidia-card expects as yuv422-texture)
Particles: 1. the long awaited [part_render] (couldn't think of a better name) ! everything that is below the [part_render] will be used as a basic particle (like textured models (ok, this might be a little bit exhaustive)) 2. [part_info] is similar to [part_render] but doesn't actually transform a render-list but rather provides all particle-properties as lists. 1+2. there are 2 demo-patches in particle i hope, this will make the particle-system finally "useful" (personally i didn't like the dot/line particles)
the rest i cannot remember...
mfg.as.d IOhannes
this seems to work with pix_filmYUv but not pix_film for me. maybe something is broken for pix_film? i'm still using the old pix_film stuff since i had trouble loading the new one due to some undefined symbol errors.
i'll try adding a message to switch color spaces between loading movies. that would be a nice feature to have.
there are a few types of 4:2:2 formats out there so that's not too surprising. we use 2vuy in GEM, but maybe the card wants yuv2? i initially wrote all of the yuv stuff on a Geforce4MX card so i can't imagine that the hardware support for the textures would be different on a Mac vs Linux or Windows. I guess the drivers could be changing the order of the pixels, but why??
this is really nice. i have changed the demo patch to include a pix_filmYUV and pix_texture and it workds really great even with DV! very little extra CPU load for 5 generated particles and a killold of 10 to 20. make your own particles is the way to go.
this is great too. so dead simple i couldn't believe it. now the thing i want to add is doing some sort of alpha blending and color fading on the particles as they 'age'. so instead of just disappearing when they die they fade to black. i have tried to do this using the position output and the 4th arg to [color] but it's not very effective. the particle lib doesn't seem to do much with alpha channels that i've found so maybe this has to be added in.
yeah this is an improvement, a big one. thanks.
cgc
Excellent work with the particles - this will be a great improvement.
GEM really needs this sort of thing to allow visual complexity without incredible patch complexity.
I think it would be interesting to have other sorts of geometric collections as well... the path is clear now!
daniel
On 29/4/03 6:12 PM, "chris clepper" cclepper@artic.edu wrote:
Zitiere Daniel Heckenberg daniel@bogusfront.org:
the nvidia-drivers for linux (from nvidia) come withthere own GL/gl.h (et al.) files that have support for this.
mfg.as.dr IOhannes
----- Original Message ----- From: zmoelnig@iem.at
al.)
files that have support for this.
Which version do you have?
The v1.0-4349 driver I have on my laptop does not seem to have this feature - neither mentioned in the nvidia gl.h nor as a supported extension - so far as I can establish.
Thanks, Daniel