the particular issue is that texture data is in the GPU’s RAM and not in the CPU’s anymore.
You cant read it directly like your data in CPU’s RAM.
If you want to get that data, you need to pull it back into the CPU’s RAM, which is extremely slow. Some functions are quicker than others (e.g. Screenshot does it fairly quickly, but your graphics need to have already been rendered to the screen).
There’s been some discussion of a Bitmap data type, which may be more what you’re looking for.
Also there’s the DirectShow filter route. (i.e. Video In/Out, freeframes). They’re all stored in the CPU’s RAM. Then you can write a FreeFrame plugin.
came across the same topic the last days. in general it would be interesting to have a texture in to implement OpenCv/EmguCv http://www.emgu.com/wiki/index.php/Main_Page stuff in vvvv. … or even better dynamic freeframe/c++ plugin templates ;)
thanks for your explanations ! great, i understood !
well actually i dont have a really precise project.
what i know is that i would really like to extract data from a texture ( video stream) to have rgb values.
i was thinking that dynamic plugin would allow it to me.
better than writting different shaders extrcating then doing a result , i was hopping to extract data, and then feed shaders with its results ( modified of course)
i m not a real developper, just doing things in C++.
freeframe is not at all my friend, too complex, and i experienced by the past too much dirty things when some freeframes are on the same prject with shaders.
for me, it would be really fantastic to access to texture like on a bitmap, and make what i want in sharp, with a dynamic texture
opencv is just an example, there are many different interesting code to transform image that would be accessible ( sometimes its diffiocult tp translate in vvvv a java script)
the last couple of months i experimented a little with the .net bindings of http://www.gstreamer.net/. gstreamer is similar to directshow, with the difference that it’s open source and cross platform and has a very strong community, good documentation and many many plugins. so far i was able to setup a basic filter graph in vvvv and to play a mp3 file from one source and distribute it to many sinks. i think it should also be possible to write gstreamer plugins with c#, but didn’t have time yet to try this. if it works, it would be great, because we could write dynamic plugins for the gstreamer pipeline and use opencv/emgucv to do image processing on video streams or other .net libraries for audio processing.
another thing i played with in the last couple of weeks was opencl. also found great c# bindings for it (http://sourceforge.net/projects/cloo/). the idea would be to do something similar with opencl than we do it now with hlsl. instead of writing pixel and vertex shaders one would write an opencl kernel in the codeditor, and a plugin would do all the heavy lifting. problem so far was that opencl doesn’t provide any information about the arguments of an opencl kernel. so we would need an opencl parser in order to retrieve that information. we would also need an opencl parser for stuff like autocompletion in the codeeditor. it would also be great to have a parser for hlsl of course, i have some ideas but nothing concrete yet.
nvidia added some extension methods to opencl in order to work with dx9 textures, don’t know about amd though. so if all this stuff would work, we could do the rendering in dx9 in vvvv and use opencl to make use of the full power of modern graphics cards.
but well, it would probably be better to start thinking about a new render engine in vvvv, or simply setup all 3d stuff with opengl which works nicely together with opencl.
ok, just wanted to give my two cents to this topic, this is of course nothing official here. just me playing around with some technologies.
Actually I think most of the textures in VVVV are created in the MANAGED POOL, which means a copy is kept in system memory and they are copied to GPU when necessary.
This could mean reading back pixels is not that slow. But a devvvv might know more about it and I might be wrong.
In that case a useful Utils function could be a function that checks if reading back pixels would be slow. That way you can check and inform the user about the performance penalty (and at the same time no one is forced into using managed textures).