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
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
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
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
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
