On Wed, Sep 08, 2004 at 03:40:49PM -0400, James Tittle II wrote:
On Sep 8, 2004, at 2:51 PM, Tom Schouten wrote:
i'm not sure which object you mean here.
...I'd guess pdp2gem/gem2pdp, which have worked in the past...
ok. of course. i was thinking about an internal gem object. i plan to use yves' object as a template because it already solves most gem<->pdp interface and build problems.
they're slow, due to the "copy planar YUV to RGB or vice versa" loops...
yes. and the gem2pdp bridge uses glReadPixels, which is i think slow for almost all video cards/drivers..
something I've been meaning to look into would be adding support for just planar YUV to YUV 4:2:2, or also allowing straight planar YUV copies (there's recently been a planar YUV quicktime codec released 3rd party, IIRC)...
you mean as a pix buffer, or a texture?
what exactly is passed from one gem object to the next, looking from the outside (i.e. pd messages)
...GemState is passed, which includes flags for dirty states, displaylists, lighting, smoothing, texture mapping, etc...and of course now vertex array versions of the similar...
so, basicly, if i wrap the gemstate object, i should be able to get to everything. i think this might be what i'm looking for.
suppose i do this: just echo the render message and pass it on, and then execute some direct GL code before passing it:
[gem...] | [3dp ...] | [gem...]
so if the 3dp object would echo anything that comes in, but use the message just as a synchronization for when to execute the GL code, would this work?
...seems like a place to start!
perfect.
one thing i don't understand is wether gem 'compiles' a pd network into some other structure where a sequence of functions are executed, or if the drawing happens at the moment the 'context' comes in the left inlet.
...I don't think it's that complex, yet :-)
ok.
I suppose you could insert other types of viewport, lighting and texture manipulation objects into the chain, but GEM has all of the basics covered.
yes. this is supposed to be an addition, not a replacement.
the thing i'm most interested in, is to keep one of the two (gem or pdp) as the master 'sequencer', and plug in objects from the other in the render chain. doing this with gem as the master seems easier atm. i don't think it will be easy for 3dp objects to feed the necessary context to gem objects.
...the gemhead basically allows for sequencing the order of gl operations: don't forget that each gemhead can have a different "priority" via [set $1<, with 1 being highest priority and default being 50...so it sends out a render GemState for every [frame $1< slice (ie. fps)...I'd think the important files to check out are GemState.h and GemMan.h/GemMan.cpp...
thanks. this should keep me budy for a while.
so, where do i start? gem 0.90, cvs, some branch? i tried gem cvs yesterday but the default branch did not compile..
...what platform were you trying?
linux.
CVS head is slightly garbled atm, because of an accidental (yet unfortunately incomplete) commit of some vertex array stuff...I'd try again with the "vertex_array" tag, tho it also has it's problems (osx project files aren't up-to-date plus it was merged from a not-quite-up-to-date HEAD)...
hmm. maybe it's a better idea if i use the stable version of GEM, (which is 0.90, right?)
so it can be tested by more people. i don't think i can get this right and forget about it in a couple of hours, so it would be best to aim at easy testability instead of hot features for now.
hop on board! I know I'm following what you're doing with pf/pdp/whatever!
thanks :)
tom