[PD-dev] gem & 3dp/pf/pdp/pidip

[Tom Schouten]

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