Thanks IOhannes,
On the question of "procedural" gem list generation in double buffer mode: I've recreated the patch using the [render_trigger] object to avoid the viewport movement and other problems, so there's no immediate time pressure from me. I think it would be nice for single buffer and double buffer modes to behave more consistently in the long term tho.
Unfortunately there are some other peculiarities: b) the view position moves from the default to 0 0 0
this i cannot reproduce, what does it mean ? when does it change ? from below i can see, that you are using the "view" message. the default viewing position is at "0 0 4" (or -4, i don't remember)
The viewport shifts when the (double buffered) viewport is banged... I've attached a sample patch to demonstrate.
c) it is not possible to change the viewing position (As far as
i can tell)
using the view message to the gemwin at any stage of the
render/flip cycle i have looked at the code, and i see what you mean. i think, i will pull the behaviour of "bang" towards "render" rather than "swap-buffers". does this break anything ???
hmm. not sure. i'll leave that one to you ;-)
d) the pixel or texture format seems to get confused... i'm
using pix_data
to pull colours to give to my objects and i need to reverse the
order of the
triple in order to get the right colours to appear.
this might depend on your data. from your DV-bugs i guess, that you are working with movies. lot's of movies are stored in BGR-format. i decided to not change the format directly in the [pix_film]-objects because of performance issues. obviously the pix_data does not know about this and interpretes your images are RGB. you can either reverse the triples by hand (as you do it know) or use [pix_rgba] to convert it automatically. i guess you will need only few pixels of the image, so maybe the doing-by-hand is way faster (i do not know, whether your patch is consumptive or not)
I did try to use a [pix_rgba] to convert the data before I used [pix_data] to sample the pixels and it seemed to make no difference. In fact, I've cooked up a little patch to demonstrate (either my lack of understanding, or some problem).
From what I can see, the [pix_rgba] doesn't have any effect on the pixel
values read by [pix_data]. The sample patch (which I'll send to IOhannes) has two [pix_data] objects: one before and one after the [pix_rgba]. They both return the triplet in the same order.
Thanks again, Daniel
-----> start patch "viewmove.pd" #N canvas 661 424 826 404 12; #X obj 29 190 gemwin 0.001; #X obj 261 93 gemhead; #X obj 203 180 gemhead; #X obj 197 222 translateXYZ 0 0 -4; #X msg 37 22 create; #X msg 48 54 destroy; #X obj 61 85 tgl 15 0 empty empty empty 20 8 0 8 -262144 -1 -1 0 1 ; #X msg 28 217 print; #X msg 138 15 frame 0.01; #X msg 96 158 frame 20; #X obj 186 62 t b b b; #X obj 267 125 sphere 1; #X obj 196 270 cube 1; #X text 231 14 click to "disable" auto refresh and start a manuual render.; #X connect 1 0 11 0; #X connect 2 0 3 0; #X connect 3 0 12 0; #X connect 4 0 0 0; #X connect 5 0 0 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X connect 8 0 0 0; #X connect 8 0 10 0; #X connect 9 0 0 0; #X connect 10 0 0 0; #X connect 10 1 2 0; #X connect 10 2 1 0;