so, who is motivated to help me out here by adding the templates? i don't have time to learn the build and init process.
shouldn't be too much of a hazzle, so (i guess) i volunteer..
thanks johannes!
- [gem.get <thing>] : forks off one gemstate object as pdp packet
- [gem.set <thing>] : inserts one pdp object in gem state
the names are of course open to discussion. anything sane and short.
i'd rather have "pdp" somewhere in the name, as [gem.set] and [gem.get] could be anything (not necessarily related to pure data packets)
for me the most simple names i can think of right now are [gem_pdp] : gem->pdp (or probably [gem_3dp] ?) [pdp_gem] : pdp->gem
since it's really only 'get' and 'set' (just about exchainging data with a gem render chain) i think this should be clear in the name.
the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx] seems confusing.
the first 2 need to be written from scratch as gem objects, possibly just derived from GemBase.
i suggest someone helps me with setting this up, by adding templates for the gem.get and gem.set objects in the source tree and add them to the build process.
so what exactly should these do (aka: what do you want me to make them do) ?
how would a patch look like ?
<snip> [gemhead] | [gem.get] | [pdp_noise] | [gem.set] | [pix_texture] | [square] </snip>
a getter would look like:
[gemhead] | [gem.get pixbuf] | | | [pdp_gain 2.0] | | | [pdp_blur] | | [gem.set pixbuf] | [pix_texture] | [square]
this would fork off the pixbuf as a pdp packet, then process it using pdp_gain and pdp_blur, and insert it back into gemstate.
and the pdp packet would just hold (additionally) the data of the gem_list (?)
and i guess, that [gem.get] should *not* output the gem_list anymore ?
i think it should, because the get/set objects are really renderchain objects.