Re: [PD] [gemframebuffer] and [pix-film] ... weirdness
Le 04/03/2018 à 19:47, oliver a écrit : > Jack wrote: >> Hello Oliver, >> >> I reduce the patch to expose the problem. >> The different solutions are inside. >> Hope it helps... > > it does ! > > thanks a lot for your explanation, > your method also works with the chained shaders ! > > even though my ambition was to use one gemhead for everything, i see > that your preferred solution with a second gemhead is much better and > also looks more logical to me. > > > > one last question: > > wouldn't the [pix_buf] method be more cpu intensive ? > > because it says in the help file: > > "[pix_buf] is only effective if it is storing a static image. If you are > continually modifying the buffered pix, then pix_buf is going to be > spending a lot of time copying pixels." If i am right, here there is no [pix_image]/[pix_video]/[pix_film] before [pix_separator] so there is no risk to buffered pix. The aim of [pix_separator] in your case is to "isolate" [pix_film] to the rest of the gemchain like [separator] does about transformations (that's why I prefer to use two gemchain in your case). ++ Jack > > ... which i think i do when i'm feeding a film into it, isn't it ? > yet i didn't notice any raised cpu power with [pix_buf] even though i > used a 1280x720 film. > > > > best > > oliver > > > > > >> ++ >> >> Jack >> >> >> >> Le 03/03/2018 à 14:58, oliver a écrit : >>> Jack wrote: Hey Oliver, Do you have a minimal patch with a shader that described your problem >>> >>> ... no minimal approach with chained glsl shaders ;-) >>> >>> nonetheless, i managed to pack everything together (it's a zipped folder >>> with all needed ingredients, just a pd patch and the required shader >>> files) to demonstrate the problem. >>> >>> if you can spare the time to take a look at it, >>> that would be very nice ! >>> >>> but as i said, i already got my task working with my little hack, so no >>> sweat, please (even though it "feels" a little fragile). >>> >>> best >>> >>> oliver >>> >>> >>> >>> >>> ___ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list >>> >> >> >> >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [gemframebuffer] and [pix-film] ... weirdness
Jack wrote: Hello Oliver, I reduce the patch to expose the problem. The different solutions are inside. Hope it helps... it does ! thanks a lot for your explanation, your method also works with the chained shaders ! even though my ambition was to use one gemhead for everything, i see that your preferred solution with a second gemhead is much better and also looks more logical to me. one last question: wouldn't the [pix_buf] method be more cpu intensive ? because it says in the help file: "[pix_buf] is only effective if it is storing a static image. If you are continually modifying the buffered pix, then pix_buf is going to be spending a lot of time copying pixels." ... which i think i do when i'm feeding a film into it, isn't it ? yet i didn't notice any raised cpu power with [pix_buf] even though i used a 1280x720 film. best oliver ++ Jack Le 03/03/2018 à 14:58, oliver a écrit : Jack wrote: Hey Oliver, Do you have a minimal patch with a shader that described your problem ... no minimal approach with chained glsl shaders ;-) nonetheless, i managed to pack everything together (it's a zipped folder with all needed ingredients, just a pd patch and the required shader files) to demonstrate the problem. if you can spare the time to take a look at it, that would be very nice ! but as i said, i already got my task working with my little hack, so no sweat, please (even though it "feels" a little fragile). best oliver ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list -- /// http://pendler.klingt.org // \\\ http://oliver.klingt.org \\ ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [gemframebuffer] and [pix-film] ... weirdness
Hey Oliver, Do you have a minimal patch with a shader that described your problem ? It should be more easy to find a workaround if it exists but it seems yours works perfectly. ++ Jack Le 03/03/2018 à 12:23, oliver a écrit : > Jack wrote: >> Hello Oliver, >> >> As workaround you can put a [pix_separator] between the [t a a b] and >> [pix_texture]. >> But yes, the bahavior is weird. > > hi, jack ! > > thanks for your suggestion. > > this "sort of" works, meaning that with one [gemframebuffer] this method > does what you say. > > if i am using more than one glsl shader in a row, each with a > gemframebuffer, it doesn't work anymore. > > anyway, my strange "[pix_image] after [pix_film]" method still does what > i want so i will stick with that for the moment. > > best > > oliver > > >> ++ >> >> Jack >> >> >> >> Le 02/03/2018 à 01:33, oliver a écrit : >>> hi, list ! >>> >>> PD 0.48-0 >>> GEM 0.93.3 >>> WINDOWS 7 / 64bit >>> >>> i encountered a weird thing in GEM recently: >>> >>> when i use [gemframebuffer] with a still image (using [pix_image]) i can >>> work with glsl shaders like shown in the GEM tutorials. >>> >>> however, i recently tried to do the same with a movie (using [pix_film], >>> but only the first frame of the loaded film showed up ! subsequent >>> "frame" messages did not work. >>> >>> by chance i found out that when i connected an empty [pix_image] object >>> to [pix_film]'s left outlet, it suddenly DOES work as expected ! >>> >>> is this the way it's supposed to be ? >>> >>> am i missing something ? >>> >>> or is this a windows thing again ? >>> >>> >>> >>> i attached a patch that demonstrates the problem >>> (btw: using [pix_movie] instead of [pix_film] didn't change anything) >>> >>> >>> >>> thanks for any help >>> (or deeper insight into [gemframebuffer]'s mysteries) >>> >>> >>> best >>> >>> oliver >>> >>> >>> >>> ___ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list >>> >> >> >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [gemframebuffer] and [pix-film] ... weirdness
Jack wrote: Hello Oliver, As workaround you can put a [pix_separator] between the [t a a b] and [pix_texture]. But yes, the bahavior is weird. hi, jack ! thanks for your suggestion. this "sort of" works, meaning that with one [gemframebuffer] this method does what you say. if i am using more than one glsl shader in a row, each with a gemframebuffer, it doesn't work anymore. anyway, my strange "[pix_image] after [pix_film]" method still does what i want so i will stick with that for the moment. best oliver ++ Jack Le 02/03/2018 à 01:33, oliver a écrit : hi, list ! PD 0.48-0 GEM 0.93.3 WINDOWS 7 / 64bit i encountered a weird thing in GEM recently: when i use [gemframebuffer] with a still image (using [pix_image]) i can work with glsl shaders like shown in the GEM tutorials. however, i recently tried to do the same with a movie (using [pix_film], but only the first frame of the loaded film showed up ! subsequent "frame" messages did not work. by chance i found out that when i connected an empty [pix_image] object to [pix_film]'s left outlet, it suddenly DOES work as expected ! is this the way it's supposed to be ? am i missing something ? or is this a windows thing again ? i attached a patch that demonstrates the problem (btw: using [pix_movie] instead of [pix_film] didn't change anything) thanks for any help (or deeper insight into [gemframebuffer]'s mysteries) best oliver ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list -- /// http://pendler.klingt.org // \\\ http://oliver.klingt.org \\ ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [gemframebuffer] and [pix-film] ... weirdness
hi, list ! PD 0.48-0 GEM 0.93.3 WINDOWS 7 / 64bit i encountered a weird thing in GEM recently: when i use [gemframebuffer] with a still image (using [pix_image]) i can work with glsl shaders like shown in the GEM tutorials. however, i recently tried to do the same with a movie (using [pix_film], but only the first frame of the loaded film showed up ! subsequent "frame" messages did not work. by chance i found out that when i connected an empty [pix_image] object to [pix_film]'s left outlet, it suddenly DOES work as expected ! is this the way it's supposed to be ? am i missing something ? or is this a windows thing again ? i attached a patch that demonstrates the problem (btw: using [pix_movie] instead of [pix_film] didn't change anything) thanks for any help (or deeper insight into [gemframebuffer]'s mysteries) best oliver -- /// http://pendler.klingt.org // \\\ http://oliver.klingt.org \\ #N canvas 0 50 977 403 10; #X declare -stdlib Gem; #X obj 318 167 cnv 15 100 80 empty empty empty 20 12 0 14 -204786 -66577 0; #X msg 222 91 rectangle 1; #X obj 312 54 gemhead 50; #X obj 328 255 pix_texture; #X obj 312 302 pix_texture, f 16; #X obj 312 75 t a a b, f 10; #X floatatom 518 163 5 0 0 0 - - -, f 5; #X obj 328 177 pix_film, f 13; #X obj 340 108 gemframebuffer; #X obj 340 130 translateXYZ 0 0 -4; #X obj 328 277 square 4; #X obj 14 11 cnv 14 128 15 empty empty empty 2 2 0 9 -253181 -66577 0; #X obj 13 10 declare -stdlib Gem, f 21; #X msg 25 287 0 \, destroy; #X text 20 196 GEM WINDOW; #X obj 13 140 del 300; #X obj 13 337 print g; #X obj 13 312 gemwin 25; #X msg 13 217 dimen 480 270 \, offset 10 550 \, color 0.5 0.5 0.5 \, create \, 1, f 14; #X obj 13 116 loadbang; #X msg 426 212 dimen \$2 \$3; #X obj 222 70 del 300; #X obj 222 46 loadbang; #X obj 344 212 pix_image; #X msg 199 134 open extra/Gem/examples/data/homer.avi, f 18; #X obj 476 92 f; #X obj 503 92 + 1; #X obj 485 116 sel 85; #X msg 474 139 0; #X obj 312 350 square 2.5; #X obj 312 327 translateXYZ -3 0 0; #X obj 688 167 cnv 15 100 80 empty empty empty 20 12 0 14 -204786 -66577 0; #X msg 592 91 rectangle 1; #X obj 698 255 pix_texture; #X obj 682 302 pix_texture, f 16; #X obj 682 75 t a a b, f 10; #X floatatom 888 163 5 0 0 0 - - -, f 5; #X obj 698 177 pix_film, f 13; #X obj 710 108 gemframebuffer; #X obj 710 130 translateXYZ 0 0 -4; #X obj 698 277 square 4; #X msg 796 212 dimen \$2 \$3; #X obj 592 70 del 300; #X obj 592 46 loadbang; #X msg 569 134 open extra/Gem/examples/data/homer.avi, f 18; #X obj 846 92 f; #X obj 873 92 + 1; #X obj 855 116 sel 85; #X msg 844 139 0; #X obj 682 350 square 2.5; #X obj 682 327 translateXYZ 3 0 0; #X obj 682 54 gemhead 52; #X text 312 31 WORKING:; #X text 681 31 NOT WORKING:; #X text 141 193 this extra [pix_image] (that seems to do nothing at all) apparently makes all the difference. how so ?, f 28; #X connect 1 0 3 0; #X connect 1 0 4 0; #X connect 1 0 8 0; #X connect 2 0 5 0; #X connect 3 0 10 0; #X connect 4 0 30 0; #X connect 5 0 4 0; #X connect 5 1 8 0; #X connect 5 2 25 0; #X connect 6 0 7 1; #X connect 7 0 3 0; #X connect 7 0 23 0; #X connect 7 1 20 0; #X connect 8 0 9 0; #X connect 8 1 4 1; #X connect 9 0 7 0; #X connect 13 0 17 0; #X connect 15 0 18 0; #X connect 17 0 16 0; #X connect 18 0 17 0; #X connect 19 0 15 0; #X connect 20 0 8 0; #X connect 21 0 1 0; #X connect 21 0 24 0; #X connect 22 0 21 0; #X connect 24 0 7 0; #X connect 25 0 26 0; #X connect 25 0 27 0; #X connect 26 0 25 1; #X connect 27 0 28 0; #X connect 27 1 6 0; #X connect 28 0 25 0; #X connect 30 0 29 0; #X connect 32 0 33 0; #X connect 32 0 34 0; #X connect 32 0 38 0; #X connect 33 0 40 0; #X connect 34 0 50 0; #X connect 35 0 34 0; #X connect 35 1 38 0; #X connect 35 2 45 0; #X connect 36 0 37 1; #X connect 37 0 33 0; #X connect 37 1 41 0; #X connect 38 0 39 0; #X connect 38 1 34 1; #X connect 39 0 37 0; #X connect 41 0 38 0; #X connect 42 0 32 0; #X connect 42 0 44 0; #X connect 43 0 42 0; #X connect 44 0 37 0; #X connect 45 0 46 0; #X connect 45 0 47 0; #X connect 46 0 45 1; #X connect 47 0 48 0; #X connect 47 1 36 0; #X connect 48 0 45 0; #X connect 50 0 49 0; #X connect 51 0 35 0; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
