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
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. ++
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
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
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
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
Hello Oliver,
I reduce the patch to expose the problem. The different solutions are inside. Hope it helps... ++
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
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
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
-
Jack -
oliver