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...they're slow, due to the "copy planar YUV to RGB or vice versa" loops...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)...
The GL stuff is a bit trickier. GEM currently does everything in immediate mode or using display lists, and none of the actual vertex rendering information is passed between objects.
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...
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!
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 :-)
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...
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? 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)...
hop on board! I know I'm following what you're doing with pf/pdp/whatever!
james