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