@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.
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?
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.
@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 :(
@cat: there could of course be one module that exposes a color transformation pin. only thing with this is that potential GUIs will have troubles offering an interface for that…
good point with the alpha=0 for the background color. i fixed that for all fx and also for the template.
@svn: probably it is even better if you just post your stuff here and i am the only one committing to svn to avoid conflicting patches. i am quite certain there are other svn clients that don’t run in the background btw.
@unc: not sure anymore about the Compile output. using it internally to bypass the effect is great, but i can’t see any usecase for the extra output anymore?!
@joreg
This compile output pin was mostly for testing - to quickly see if shader is working or not.
But if we have shaders well-tested, this pin is no longer needed.
Btw I’m not so sure about removing the vertexshader - I did that in my postprocessing effect, and microdee reported a bug (on ati), so i had to add minimal vertexshader there…
And i cant get to irc because irc client on my phone is not working properly, dont know what the hell is wrong. Cant get to a pc atm
@karistouf
remove “vertexshader=…” from technique from any of my shaders, and then it may cause this bug
hmm… maybe that happens only with ps&vs 3_0, so it might be ok to remove vertexshader if pixelshader is 2_0…
@unc its because your scaling up with
void vs2d(inout float4 vp:POSITION0){vp.xy*=2;}
I presume thats a vertex operation? I scaled the render instead…
In fact just tested and it is ;)
I did it as I figured if we’re going to use a lot of shaders we ought to minimise the gfx card calls as much as possible, but your shaders seem to be pretty minimal anyway!
i just thought of something (please tell me if this is a stupid idea or not):
what if we also implement a bunch of texture generation modules (those having no input texture at all), maybe even some “drawing tools” - so all this will be more like “procedural texture generation environment”, so then if you need some (rather simple) texture, you dont have to run photoshop, or start looking for a suitable texture - you can generate it right there, and most important - tweak it right on its place, in realtime
this “texturegenerator” might get very slow/memory consuming at some point (very soon i’d say=) ), so here we will need some mechanism to dump static textures to hdd, and only render on demand (or smth)
