[PD] [Gem] delay line for geos?

[Peter Todd]

> Hi there:
>
> I would like to draw the trail of a geo in motion, how can I do this? I am
> thinking of delay the gemlist to the specified amount but having no luck 
> in
> doing so.

I think that it is not as easy as one might hope (but I look foward to a 
discussion on the subject).  What I can say, is that the 'gemlist' is a 
pointer to the data in the graphics hardware (I'm not clear of details 
here), rather than actually the data itself.

I wrote this off-list recently, perhaps it can help explain.

"I don't vouch for the total accuracy of all of this information, but I'm 
sure trying to explain will help me understand, too.  I don't know what you 
know already, either, so I'll try to be quite comprehensive, but it should 
be relavent.  All the geometric transformations and so on that one performs 
with OpenGL are carried out within the GPU.  As such, the software maintains 
a pointer to the place in the graphics hardware where the geometry is being 
computed, rather than working directly with the actual 3d matrices.  When 
you use a [gemhead], it initialises a pointer with the 'identity matrix' 
(the origin of the scene) and triggers a new set of computations every 
frame.  When the gem message, containing the pointer to the relevant 
information in the graphics hardware, reaches a geo, that causes a new shape 
to be rendered in the appropriate place (and color, texture, scale, 
shininess...).  When it reaches something such as a rotate
or translate object, it causes that geometric transposition to be carried 
out on the data to which its pointer points."

So I think you can see the difficulty in delaying the gemlist...

As far as motion blur goes, I have implemented a crude implementation for 
the whole scene with  [pix_snap2tex] feedback on a rectangle (alpha controls 
the strength of the effect).  This is a bit fiddly, as it's sensitive to 
screen dimentions, for which there is no 'get' method or callback if the 
window size changes.  Worse still, [perspec] messages really mess it up, but 
maybe [ortho] would sort that out.  It can be a bit slow, too, and is 
generally far from perfect (but quite pretty, sometimes).  I think an 
accumulation-buffer based effect sounds more to the point (for full scene 
motion blur), which I think can be done with GEMgl stuff, but it strikes me 
as very fiddly to code in pd (especially trying to relate online tutorials 
for c++ or whatever back), so I haven't done it.

I have wondered a bit about individual geos leaving trails, and delay line 
type things, but I haven't reached much conclussion (or done much 
experimentation).  You could use a table to store the previous frames data, 
and have diminishing alpha for older elements, but again it would be far 
from perfect.  Could be workable, though.  I might see what I can hack 
together this afternoon, otherwise it won't be for a few days.  As far as a 
generalised 'delay line' goes, I think this could turn out to be a good 
approach.


> Cheers
>
> CHUN

Cheers,

Peter