[PD] snapshot misteries, bang to gemhead

Matteo Sisti Sette matteosistisette at gmail.com
Mon Dec 7 14:51:49 CET 2009

Oh I see!

Thank you very much :)

cyrille henry escribió:
> here is a small patch that show the problem : when gemhead receive a 
> bang while in double rendering mode, the transformation matrix send is 
> incorrect.
> so, finding a workaround is easy. just replace gemhead with the _gemhead 
> abstraction that always output the correct transformation matrix.
> c
> cyrille henry a écrit :
>> are you sure you send the good patch?
>> this one is not "very simple" and does involve pix_snap.
>> c
>> Matteo Sisti Sette a écrit :
>>> Yes the issue is indeed much simpler and [pix_snap] is not involved.
>>> Attached is a very simple patch with a square and a sphere. The bang 
>>> forces a render. If you move the sphere far behind the square and hit 
>>> the bang, you can see a "flash" of the red sphere just close to the 
>>> eye, as if it was in the opposite position than usual.
>>> Is it normal, and if so, what is the explanation???
>>> Matteo Sisti Sette escribió:
>>>> Hi,
>>>> I'm working on a patch (not the attached one which is an example 
>>>> that isolates the problem), where from time to time I need to take a 
>>>> snapshot of the whole scene and "draw" it as a texture on a 
>>>> rectangle which is on the background.
>>>> (when the patch is finished I think I will be allowed to share it, 
>>>> for what it's worth)
>>>> I have it all working fine, but than I came into a problem: 
>>>> sometimes, I have to send a message to take the snapshot, and 
>>>> immediately after, send some other message that changes something on 
>>>> the scene, which has to happen AFTER the snapshot.
>>>> Since I am taking snapshots in the "classic" way, that is, opening a 
>>>> spigot on the gemlist that comes to the [pix_snap], the snapshot is 
>>>> actually deferred until the next render; this is a problem because I 
>>>> need to "defer" any other message that has to take effet just after 
>>>> the sbapshot; this can be done but i'd like to avoid all the 
>>>> complications.
>>>> I thought that a solution would be to force a render just after any 
>>>> snapshot, by sending a bang to the gemhead that is rendering 
>>>> everithing.
>>>> However, the result is not what I expected and I really can't 
>>>> understand why.
>>>> That's why I am asking for your help.
>>>> So, the attached patch is a simplification, in which I draw an 
>>>> initially white square and a sphere. If you hit the big bang (sorry 
>>>> for the pun), a snapshot of the scene is taken via [pix_snap] and it 
>>>> becomes the texture of the square. You can use the number box to 
>>>> move the sphere around.
>>>> Now, if I make the connection where it says "connect this", what I 
>>>> am doing is just provoking a bang to the gemhead just after opening 
>>>> the spigot to the pix_snap. What I would expect is that it should 
>>>> work exactly the same as before (with the difference that an extra 
>>>> frame is rendered between two "normal" frames, and that's the moment 
>>>> the snapshot is taken; but this difference should not be "visible").
>>>> However, the observed behaviour is not this. The snapshot that is 
>>>> taken and "printed" on the texture is not the scene, but some 
>>>> aberration of it. If you leave the sphere wher it is, it will 
>>>> usually render and snap an all-black scene; but if you move the 
>>>> sphere to the back, behind the square, the snapshot will take the 
>>>> sphere very near to the "eye"......
>>>> I really don't understand. Doesn't the bang to the gemhead provoke a 
>>>> full render of everything just the same as it is rendered when a new 
>>>> frame occurs? Then why is the scene rendered differently when I do 
>>>> the bang????
>>>> I guess this could be further isolated to something regarding the 
>>>> bang to gemhead, i.e. without involving pix_snap; of course with a 
>>>> "fast" enough to see what happens during a single extra frame....
>>>> Thanks in advance
>>>> By the way, thanks to all who gave me example patches some days ago 
>>>> which have helped me building this patch.
>>>> m.
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> http://lists.puredata.info/listinfo/pd-list
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list

Matteo Sisti Sette
matteosistisette at gmail.com

More information about the Pd-list mailing list