[GEM-dev] [PD] snapshot misteries, bang to gemhead

[cyrille henry]

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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_forcerender.zip
Type: application/zip
Size: 741 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20091207/2c00cbae/attachment.zip>