hi john,
I just looked at your patches, here's what I think:
1) pix_buffer_write seems to copy and clear the pix buffer. so if your
pix_video is connected to pix_buffer_write it is gone and you don't
see it anymore (rectangle stays white). I am not sure if this is a
bug, it seems strange to me, too. but as soon as you disconnect the
pix_buffer_write the image will be shown on the rotated rectangle.
Yes I also noticed that disconnecting the [pix_buffer_write] fixes the problem. i see that sort of thing in Gem all the time ([pix_mix] for example.) But wouldn't a [pix_separator] fix this then? It doesn't...
2) the rotateXYZ does not rotate the pixels, but only the geometry
that this texture is mapped to (the rectangle). so in your left
example you go from gemhead through buffer_read, texture to the
rectangle. in that line no rotationXYZ is applied to the rectangle.
marius.
So why does the right example work? Because the rotation happens after the [pix_buffer_write] even though [pix_buffer_write] is later in the rendering chain? Or perhaps the rotation is ignored by [pix_buffer_write]? And at the same time [pix_buffer_write] sends the output of the rotation as a "passthrough" on its outlet? And also you are saying it would be normal and expected for the output of [pix_buffer_write] to be different than what [pix_buffer_write] is actually storing? If that isn't the case, example 1 and example 3 should produce the same results.
Perhaps I need some rules about how Gem is different than Pd in terms of dataflow. So far it seems to me that a rendering chain in Gem shows conections but does not reveal the order in which these connections are processed i.e. if 3 objects are all connected to each other in a rendering chain in Gem i.e.
[Gemhead]
|
[object 1]
|
[object 2]
|
[object 3]
we cannot conclude that the output of [object 1] feeds the input of [object 2] and the output of [object 2] feeds the input of [object 3]. We only know that the data will be processed by objects 1, 2 and 3 but not in what order they will be processed.
Further perhaps we cannot conclude that the output of an object is actually the result of the object having processed the data. Demonstrating this: in my patch example, [pix_buffer_write] outputs different data than it stores, or examples 1 and 3 would be the same.
And this leads me to a more general statement of my original question: how can I determine the order in which objects are processed in Gem?
And my specific example which started this thread: how would one apply a rotation to an image, then apply [pix_rtx] to the rotated image?
-John
2009/3/24 John Harrison <john.harrison@alum.mit.edu>:
> Attached is a small example patch of how I just don't get Gem...still...
>
> [pix_rtx] has a steady wave that normally flows from left to right.
>
> I would have thought that the attached patch shows me rotating the image
> first, then applying [pix_rtx]. So it would stand to reason in my mind I
> would see a rotated image with [pix_rtx] flowing from left to right.
>
> But that isn't the result I see. The patch has [pix_rtx] flowing from right
> to left now. It is as if [pix_rtx] is applied *before* the rotation instead
> of *after* as I would have expected.
>
> Grasping at straws, I have tried [pix_separator] between just about every
> object, but that makes no difference.
>
> What am I misunderstanding that makes the behavior of the patch make sense?
> And...how would I get [pix_rtx] to flow from left to right on a mirrored
> image?
>
> -John
>
> P.S. Are questions like this better on the Gem-dev list? That's a developer
> list but at the same time I feel a bit awkward putting too many Gem
> questions on a Pd list
>
>
> #N canvas 962 171 305 227 10;
> #X obj 29 -58 gemhead;
> #X obj 29 -35 pix_video;
> #X obj 29 44 pix_texture;
> #X obj 28 72 rectangle 4 3;
> #X obj 159 9 gemwin;
> #X msg 136 -34 create \, 1;
> #X msg 214 -33 destroy;
> #X obj 135 -57 loadbang;
> #X obj 29 17 pix_rtx;
> #X obj 29 -10 rotateXYZ 0 180 0;
> #X connect 0 0 1 0;
> #X connect 1 0 9 0;
> #X connect 2 0 3 0;
> #X connect 5 0 4 0;
> #X connect 6 0 4 0;
> #X connect 7 0 5 0;
> #X connect 8 0 2 0;
> #X connect 9 0 8 0;
>
> _______________________________________________
>
Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
>
http://lists.puredata.info/listinfo/pd-list>
>