Something like Syphon on Windows (currently called Wyphon)

Great work!

Have you managed to share textures between dx11 vvvv and dx9 vvvv yet?

Hey! Cool! I’ve tried this out in md.vis it’s working much better than the previous but still have several issues like the wyphon.dll and the standalone examples are searching for the full visual c++ dll’s and not the redistributable ones.
Also i’ve noticed if the handle changes from the sender node the receiver won’t forget the old handle but add it to the spread this appears the most when turning texturefx on and off.
@joreg: nah don’t worry the raw version works fine only the string version didn’t make it every time but that’s unfortunately totally random.
@mrboni: dx11 textures can be shared with dx9ex and vice versa

@mrboni:

Is there already a DX11 vvvv version available somewhere?

I thought only the people at node did get a preview? I didn’t find any code in vux’s github.

@microdee:

‘vice versa’ is not really true. If you want to share a texture with dx9ex, you should create it as a shared texture with dx9ex, then use that handle to open the texture as a dx11 texture. I have created a WyphonUtils dll, that should make it very easy to open a DX9ex device and create a correctly shareable DX9ex texture, whose handle you can then use in your DX11 app to create a DX11 texture.

@ft - not sure if it’s available to download yet. Presumably it’s ok to share?

@micrdee - have you used the wyphon.dll in the dx11 build yet?

Hi… Im getting MSVCR110D.dll missing error… :)

@mrboni: nope but it worth a try.
@vdmokstati: same here i searched for them with Google i found several working but I don’t really trust them.

Hello, about the MSVCR110D.dll, that’s probably because I included the Debug version of a dll (I guess that is only with the vvvv nodes, I think the example programs us the proper dll’s?).
And that seems to try to use a Debug version of some dll’s, which is a pain. I’ll try to upload a new version soon that uses the proper version.

Just for now: if you have Visual Studio installed, I guess you will find these dlls somewhere on your harddisk already (something like C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC110.DebugCRT), and you could safely copy them to the plugins directory.

I guess this download contains all the correct versions of all dlls :) Sorry for that.

wyphon.zip (127.5 kB)

hello ft, sorry for bugging you here, i found no way to contact you elsewhere and time is critical. could you give me a hint how i can play back a rtsp stream with the vlc plugin in this thread: https://discourse.vvvv.org/

hello microdee,

I was wondering: did you get a chance to test it, and are there still problems that I should know about?

If all seems to work well for you, I wanted to send a pull request to the vvvv team, so that it becomes part of the alpha builds.

I’m currently on other projects i will have time to try it next week probably.

Sounds like a really great idea!!!

Some questions: Is there any chance to support this syphon via network? http://vjforums.com/forumdisplay.php?f=8

Second one: Is it possible to put the transmitter into a freeframe plugin? I have plenty of stuff in VJO, it would be great if I could route it into V4.
Or maybe FFGL, so Resolume would work without hassle?

@Meierhans:

  • Via network: currently nothing is ‘sent’, 2 applications are actually opening the same texture on the GPU. So the only information that gets sent between 2 applications is this shared texture ‘handle’ (and some other info like format etc.) This means over a network will be something completely different, and I have no plans to implement that at this time.

  • It should be quite easy to implement a freeframe plugin, that copies its data to a texture, and shares this texture’s handle using Wyphon. The WyphonUtils dll should help you setup a D3D9ex device, and create a texture that you can share.

  • FFGL: will be harder, because I only know about an addition to OpenGL that would allow you to share stuff between OpenGL and DirectX from nVidia, so that would only be possible (for now) on nVidia hardware (unless, but that will be too slow, you copy the OpenGL texture data back to system memory, and copy it back to a D3D texture on the GPU). But, if some software is actually using this, we could put pressure on ATI to implement their version too. See here: https://sites.google.com/site/snippetsanddriblits/OpenglDxInterop

Bah I’m getting blue screen page fault errors when loading the sender module, in both b29.2 and a29.3…

dlkmd.sys “page fault in non paged area”

Only happens in dx9ex mode, and when I open the wyphon sender.

No crashes when I open the plugins manually, though they don’t seem to work after that (but I might not have used them correctly)

@mrboni: are you opening the sender patch only? Because you need to have 1 instance of the ‘Wyphon’ node, only then can a sender or a receiver module work.

If it’s something else could you show me through a patch what you are doing exactly?

Hi ft!
This looks pretty exciting!
Are you working on a library for Processing as well?
I mean are you planning on expanding this patch to other applications or are you staying in vvvv? Cause I could REALLY use such a library for Processing :) I almost considered buying an Apple just for Syphon alone.
But nonetheless, keep up the great work!

Hi Martijn,

From what I understand, this essentially uses DirectX, whereas Processing uses OpenGL - I think some work may be done with OpenGL in the future, however for now is for use with DirectX (DX)

Hi,
this is a real breakthrough, congratulations on finally filling the lack of texture sharing on Windows !
I’m really excited and motivated to extend the capabilities of your work to other frameworks such as Unity3D or Adobe AIR (through native extensions and ByteArrays).

However, i’m not an expert in C++ / CS / CLI programming… and i think i need a bit of help to begin !
I successfully created a brand new CS Project and got it communicating with the sender test app (basic wyphonPartner creation and callback functions test, no rendering but it’s not the point now).
However, in order to create native extensions for Adobe AIR, i need to be able to create a C++ project.

  • I’ve tried to create a pure C++ project but have a problem on how i’m supposed to use/create the CALLBACK functions.

  • I’ve tried to create a C++/CLI project to use the C# dll that i already used in my pure C# test, but i don’t know hot to importe the WyphonDotNet.dll to access the methods in it…

Thanks for your work, any idea / help would be much appreciated.
I’ll post here my work as soon as it is usable.

Ben Kuper

Little update here,
after some work, i successfully created a CLR project and got the callback mechanism working, i now am aware of the 4 event (joined, left, shared, unshared) and got the parameters associated.

I’m getting closer to be able to create an Adobe AIR extension from that, but i need to understant how to get a ByteArray from the parameters passed in the textureShared callback.
I guess it has to do with the handle param, but i can’t find clear resources on how to convert from a texture handle to a byte array.

I know this is not exactly what this lib is supposed to be about, because i won’t be reading directly into the d3d shared memory, but Adobe AIR is not working with Direct3D and there is no way to share bitmapDatas between softwares. Even if it’s not the most optimised way to share textures between softwares, it’s clearly be better than nothing.

Any help on that ?
Thanks

maybe this amazing little thing can help: Unmanaged Exports