i think performance may not be a problem… You guys just need to get yourselves some good nvidia cards :D
and, i still cant find a way to retrieve texture format from texture input… Personally i’d like to always work with A16B16G16R16F, but that is not always needed, and quite hungry for videomemory
maybe we also need some “conversion” modules, to change resolution/textureformat
hi unc, from what you have written this morning, the Edge question is complete, playing with the 5 shaders you wrote gives all ( and more ) look aspect than a Gimp would do. Ah yeah… that is great !
TGPosterize is great !
about texture mode, well, its you that are knowing what should be done… maybe as you suggested coversion modules would be better ?
the point is, each module should output exactly the same type of surface it gets on input. And if user wants to change the format or resolution at some point (for optimization purposes or anything else), all it will take is to add one conversion module where it is needed
i totally dont like the idea of adding one additional input pin for each module, just to specify its output texture format
it would be nice if each module would have just texture in/out and effect-specific parameters, and nothing else
@karistouf
can you run some kind of a stress-test for those effects? How much of them you can stack until it kills performance? Which ones are most slow?
I need to have some clue to know what to optimize there…
ok, understood. ;-)
TGP Posterize with your quick blur is giving vectorized results ! very very very nice.
I have also a real question, i dont know if this can be achieved in VVVV with shaders:
Is it possible to set a transparency channel to the video ( like a png have ), and to separate in 3 component RGB the information ?
Treatement, then recomposite it.
I dont know if EX9 renderer and DX9 texture will keep it or not.
For versatility question, specific treatment on the plan of the image channel should be also interresting and very powerfull, enabling displacement, color effects and compositing very weird.
@unc: brilliant, this is exactly what i was preaching.
Info (EX9.Texture) has a Format output. ok it is a string including the format descriptor + additional stuff which could easily be truncated before the ‘:’, ja?
hosting
to answer xd_nitros question: lets host this on sourceforge, so it will be automatically included with the addonpack. i’ve added a directory there which can be checked out via:
http://vvvv.svn.sourceforge.net/svnroot/vvvv/modules/trunk/common/TextureFX
in order to commit you’ll need a sourceforge account and tell me your username so i can add you there.
directory structure
instead of one directory per module how about:
TextureFX\effects (which will include all the .fx files for use by any of the modules)
TextureFX\ (which will include all the modules that can reference any of the \effects)
because else in the case of two modules using the same effect we’d need to duplicate those!?
naming
lets stick to vvvvs naming conventions. most importantly all modules should be named like this
Name (EX9.Texture FX)
where name should not include any prefix like TG. note that there are explicit author and tag fields in the module-info (via ctrl+M in a module). same for the effects themselves where that info is specified via comments.
concerning the pins names please start them with capital letters and don’t use camel casing but separate words by space.
pins
as it looks every module will have the following inputs:
- Texture In (in case of multiple inputs name them ‘Texture A’ , ‘Texture B’, …)
-
Enabled (rather than Bypass i suggest)
and outputs - Texture Out
-
Compiled (as unc suggested, which i think is a good idea. just make sure then that even modules not using any effect also have this output, always set to 1)
internally the Enabled and the effects Compiled flag can be ANDed to switch the module to bypass in case either is false.
additionally modules have parameter inputs. those must not be of types: mesh, renderstate or transform but only of types: string, value, color, enum
any additions objections to those specs? lets keep the discussion here and i’ll move this to a wikipage.
@unc: would be great if you could then adapt your samples to this spec and commit your stuff to the repository mentioned above.
A suggestion: Would it maybe make sense (performance and texture-format-wise) to code all the effects into one shader, and give this shader a string describing the effect chain and a spread with the params? e.g. “blend+levels+edgedetect+blend” and “0.5 0.1 1.0”
then the effect chain could easily be parsed/constructed/patched, but it’s effectively all in one shader with only the relevant parts switched on. i’m just not sure how to handle the parameter list in an effective way.
edit: OK too much activity in this thread, I think you can partially disregard what I wrote.
One question remaining: is there a performance overhead by chaining many effects together, as opposed to all of them in one shader?
Also: Please, when implementing and naming effects and blend modes, please stick to some kind of standard (the photoshop way would be best). In Resolume Avenue, for example, some blend modes have a different effect. Very confusing and frustrating sometimes.
Also II: icanhas lumakey FX (I only saw chromakey)?
@hunc: i will do “stress-tests” tonight. some job to do in a theatre today
but what i already feel by putting them of 2 different computer is that already they are simple, precise, and not consuming a lot !
@joreg:
About naming variable inside, are you of this point of view, of a unified naming ?
cheers
@joreg
yep, that spec looks totally fine
i’ll convert those effects to it, and will stick to in future ones
and btw Info (EX9.Texture) does not output all texture types… A16B16G16R16F for example - it says 64-bit float format blablabla
i’m starting to think of some stupid way to solve this:D
@bilderbuchi: please link us to a naming scheme in written form. “like in photoshop” is difficult to conform to. also probably just have a look at the naming in progress and make specific suggestions.
@unc: for me it says:
A16B16G16R16 : 64-bit pixel format using 16 bits for each component.
so you could easily cut this string after the first ’ :’ and stay with the format alone. no? or you mean it is not an enum? but from that formatstring you can convert it to an enum using String2Enum. also please join IRC for something vaguely related… ending in _38.dll
@karistouf: not sure what you’re asking here but yes, naming-conventions are important.
@joreg
Oh yeah, now I understand why they should be named that way=) yet another sweet feature of vvvv discovered
as for the texture format string - maybe thats because i’m using 40beta23?
@joreg: sry, i should have done it properly the first time around:
blend modes: http://en.wikipedia.org/wiki/Blend_modes http://www.vanderlee.com/tut_fm_mixingmodes.html
some GLSL and HLSL for that: http://mouaif.wordpress.com/2009/01/05/photoshop-math-with-glsl-shaders/
Gamma correction: http://mouaif.wordpress.com/2009/01/22/photoshop-gamma-correction-shader/
Levels: http://mouaif.wordpress.com/2009/01/28/levels-control-shader/
svn… ugg
heres a couple of keyers…
I’ve taken out the unneeded vertexshaders, is this a wise thing to do? Figured it make save some cycles along the way…
for blurring them I suggest daisy chaining!
Adding an alpha channel to a texture is easy enough, question is should theses output just an alpha channel or a 1 channel greyscale image, thereby saving some more ticks?
Chroma and Luma Keys EX9.Texture FX (5.6 kB)
fixed modules/parameters names according to spec
dunno how to upload it to repo now, so here it is
TextureFX_unc.rar (14.4 kB)
No worries about different modules using different versions of the same effect?
very good things are happening here…
i combined uncs and cats modules, did a minor cleanup in them, added a _Template (EX9.Texture FX).v4p and a .Tester.v4p and it is all up at:
http://vvvv.svn.sourceforge.net/svnroot/vvvv/modules/trunk/common/TextureFX
and also attached. since they are now versioned it’s best to work from the repo or at least make sure to work from the attached ones!
@unc: jo seems format output of Info (EX9.Texture) was different in beta23. why are you still using it? i’ll check to get a proper format-enum output of the Info node. please get yourself a username on sourceforge and tell me it. then read version control with subversion so you’ll be able to commit your stuff. missed you on IRC…
@cat: taking out VS is fine. concerning sole alpha-texture outputs…should make sense to use grayscale formats in those cases am only not sure if most graphic-cards support them. but for our alpha-phase now just use them if applicable.
@karistouf: didn’t go so far as to check shader coding conventions as really to this project it doesn’t matter so much if there is a mess in the shader. of course it would be nicer if there wasn’t but there we can only hope that contributers will conform to addonpack.effects and conventions.nodeandpinnaming
@gilbi: nope. different versions of the “same” effect should definitely have a different name.
@bilderbuchi and all: what do you think of the node/pin namings so far? is it smart to name ‘FastBlur’ so or could it simply be ‘Blur’?
@all: please comment on the functionality/pin-value-ranges of the individual modules.
TextureFX.zip (26.3 kB)
@unc: not seing any performances problem until 24 levels of fx on a 20fps webcam.
your shader code runs like hell…
the edge one is really impressiv. many thanks for this contribution
@joreg: I’m currently up to my elbows in matlab/octave/android/whatever… I will comment later, hope until the weekend.
Only judging from “FastBlur”. There should either be a switch on the module to select the “technique”/implementation (Fast, Gaussian, whatever), or different names. If different names, I vote for “BlurFast”, “BlurGaussian”, etc…, so that all the different kinds for one effect stay together (in an alphabetic list). More later.
I did wonder whether the colour transform should be exposed to, as you might well get some unexpected, but useful results using it in combination with an effect?
Also do all the renderers need a background colour with 0 alpha to preserve an alpha channel coming in?
@unc, great shaders :) The edges and blurs look like an old aftereffects plugin I used to death years ago, doesn’t work in any recent versions, so its nice to have something like that back too :D
Suppose I’ll have to install svn now… Don’t like having system wide apps running in the bg :(