Tom Schouten wrote:
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.
true. still i think that "pdp" should be in the name too, as [gem_set] wouldn't necessarily have something to do with pdp packages. so probably [gem_pdpout} and [gem_pdpin] would be more apropriate ? (or [gem_pdp.out] and [gem_pdp.in])
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.
thanks for the clarification
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.
which is clear from your sketch.
so the templates are almost done; just want to settle the name before i check them in
mfg.a.sdr IOhannes