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

Tom Schouten doelie at zzz.kotnet.org
Wed Sep 8 20:51:11 CEST 2004


On Wed, Sep 08, 2004 at 10:31:21AM -0500, chris clepper wrote:

hi chris,

> The pix stuff is probably not too difficult as it will just be another 
> blitter loop to go from one image buffer type to the other.  There is 
> already an object or two that does this correct?
> 

i'm not sure which object you mean here. 

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

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?

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


> I have 
> recently added some vertex array objects to CVS which do in fact pass 
> raw vertex, color, texcoord and normals between objects much like the 
> pixel processing objects.  All of the processing is done by the CPU, 
> but this arrangement makes for very nice and flexible possibilities 
> (and is actually much faster than immediate mode).  I would suggest 
> finding a way to integrate your 3D objects into that rather than spend 
> a lot of time with the somewhat obsolete Geos and so on.
>

ok. this is a lot different than i assumed. a lot of ideas to steal :)
i have a matrix object to store most of these data objects so in principle
there should not be a problem. though i need to do more code reading..

 
> Another possibility is the creation of display lists out of user 
> defined chains of objects.  This would be more flexible and faster than 
> immediate mode, but really only useful for static data like models, and 
> collections of basic shapes (rectangle, cube, triangles).  It would 
> interface very nicely with Cyrille's pmpd package and help performance 
> immensely.
>

this could be interesting. i can 'compile' to display list in pf, and they
are represented using a wrapped gl datatype, so this is another level that
could be plugged. thanks for the hint.


this looks very doable. just need to solve them practical problems..

so, where do i start? gem 0.90, cvs, some branch?
i tried gem cvs yesterday but the default branch did not compile..






More information about the Pd-dev mailing list