blending modes (like photoshop) in jitter?
Can anyone point me in the right direction for any jitter objects that
can duplicate the transparency and masking effects with Photoshop and
After Effects's blending Modes?
Any thoughts or referrals would be really appreciated.
Many thanks in advance! Robert.
jit.gl.slab. Have a look in the c74/jitter-shaders/composite folder.
There's even a nify example patch in the
examples/jitter/render/slab-helpers folder.
wes
On 5/21/07, Robert Griffin Byron wrote:
> Can anyone point me in the right direction for any jitter objects that
> can duplicate the transparency and masking effects with Photoshop and
> After Effects's blending Modes?
>
> Any thoughts or referrals would be really appreciated.
>
> Many thanks in advance! Robert.
>
Hello,
Cycling'74 people(also part time wall painters), made it incredibly
easy for us:
checkout jit.gl.slab-composite patch in jitter examples folder.
best,
nesa
has anyone implemented an object which does this on matrices which is compatible with the latest jitter? i know that the auv-i library has objects that do this, but hasn't been made friendly with recent jitter versions.
thanks!
m
Quote: Mark H. wrote on Tue, 22 May 2007 06:52
----------------------------------------------------
> has anyone implemented an object which does this on matrices which is compatible with the latest jitter? i know that the auv-i library has objects that do this, but hasn't been made friendly with recent jitter versions.
>
> thanks!
> m
----------------------------------------------------
How about this? Wesley, could you explain why this works? Is the texture automatically captured back to ram?
Mattijs
(note, there is a loadbang inside)
yes, that's one way to do it, my concern here is the brief hiccup when changing the blend modes, at least that's the case on this machine. however, i am running max 4.5.7 and jitter 1.5.2. does the brief hiccup occur with more recent versions of jitter? the other concern is widespread use of this .jxs could overly burden the GPU which i'd like to reserve for other tasks. are these reasonable concerns? i'm new to the glsl/gpu world and am just beginning to integrate it into my video work. my habits want me to find a CPU method of resolving this issue for maximum flexibility. any other possiblities out there?
macbook pro 2.33 ghz
mark.
On May 22, 2007, at 2:33 AM, mah wrote:
> my habits want me to find a CPU method of resolving this issue for
> maximum flexibility. any other possiblities out there?
GPU version will be way faster, but I decided it was about time to
make an example of how to do this stuff with a combination of
primitive Jitter operators on the CPU. Everything done here could
also be done in a set of patchers, but I found it easier to manage in
JS. A dedicated object in C wouldn't be that hard to write, and would
be faster (though not as fast as GPU), but this example shows a
variety of tricks for the not so C savvy, or those that wish to
prototype in JS before coding up in C.
It's not rigorously tested, but I compared with the JXS variants, and
it's pretty much the same except for a few places where there's
resolution issues with 8bit data. It should work for both floating
point and char data, but I also haven't tested on floating point data.
The trickier parts of it were dealing with division (the blendmodes
which require this are slow since we have to convert to floating
point using jit.expr to get the type of division desired for this
task), and the luminance based logic of the hardlight and overlay
blendmodes.
Hope someone finds this sort of thing useful.
-Joshua
Hi Mattijs,
your patch works because the loadbang builds a render context in
jit.gl.render enabling jit.gl.slab to do RTT stuff internally and
shoot it back to a matrix. When using RTT, you're basically creating
a context within a context, so jit.gl.slab has a context within itself
(which is actually in the out_texture) that is uses to do the fragment
processing.
wes
How does the FBO backend deal with @context and render to texturing?
I wonder if that is partially why I get so many texture binding
errors is because of one backend vs the other.
How do I query what backend is in use? is RTT the default?
On May 22, 2007, at 5:49 PM, Wesley Smith wrote:
> Hi Mattijs,
> your patch works because the loadbang builds a render context in
> jit.gl.render enabling jit.gl.slab to do RTT stuff internally and
> shoot it back to a matrix. When using RTT, you're basically creating
> a context within a context, so jit.gl.slab has a context within itself
> (which is actually in the out_texture) that is uses to do the fragment
> processing.
>
> wes
v a d e //
www.vade.info
abstrakt.vade.info
what does @context refer to. rtt is default, by RTT i meant render to
texture in general, not a specific implementation.
wes
On 5/22/07, vade wrote:
> How does the FBO backend deal with @context and render to texturing?
>
> I wonder if that is partially why I get so many texture binding errors is
> because of one backend vs the other.
>
> How do I query what backend is in use? is RTT the default?
>
>
>
> On May 22, 2007, at 5:49 PM, Wesley Smith wrote:
>
> Hi Mattijs,
> your patch works because the loadbang builds a render context in
> jit.gl.render enabling jit.gl.slab to do RTT stuff internally and
> shoot it back to a matrix. When using RTT, you're basically creating
> a context within a context, so jit.gl.slab has a context within itself
> (which is actually in the out_texture) that is uses to do the fragment
> processing.
>
> wes
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>
>
>
>