Credits: dottore for testing, helping, m4d for all night support, testing...,devvvvs for fixing bugs and adding features, unc and lecloneur for porting texturefx many other I forget, ping me :)
DirectX11 rendering for vvvv (update 1.3)
See changes here: directx11-1.3-update
General Changelog here :
Requires vvvv beta33.7 or newer.
Many thanks to people who are currently supporting development :
Removed that comment, path are on b30 by default.
Let me be the first to say- Yay!
You rock Mr Vux :)
all hail vux!
everything we know is wrong again \o/
un grand merci!
OMG, its really happening!
Ça envoie du steak ! Merci :)
new tools - new horizons, thank you Mr Vux !
thanks vux ! we owe you so much !
thank you vux vvvvery much! you are great!
i got it working, but my old dx9 nodes are not listed any more
but if i open an old patch, they are there, and they work, i can control c+v and use them,,, is this normal or i made a mistake on the installation ?
and is there a way to convert a dx11 texture into a dx9 texuture to use the old patches ?
for the dx9 nodes not showing it is normal. i would love to have the option to activate them as many times i want to copy paste something from a help patch for fast patching and i have to go to files and search them.
all dx11 nodes are red for me :/
@vjc4 @colorsound : In next release you'll be able to filter normally, so you'll be able to view those nodes again.
@Stix : are nodes appearing in nodelist?
i did some tweaking and it works, sorry to rush here so fast -_-
altough is dx11 heavier on performance?
@Stix it performs much more fast in general.... look the pipet example
"yay" is exactly what I wanted to say too :)
@geometrica: No "pipet" node except for OpenCV now, all DX11 stuff seems to be here fine. Is there a DX11 pipet?
it's in examples from workshop
Sorry to be dense/blind, but I cannot find it in the node13 workshop DX11 rendering techniques I zip. Am I missing it? Thanks!
Strange thing on my laptop with AMD Radeon HD 6470M: when I try to set the renderer's input pins AA Samples per pixel to > 2 or AA Quality to > 0 vvvv 'freezes' (the UI gets really really slow), and the renderer stops updating. With some difficulty because of the unresponsive UI, I am able to reset these values, and then everything goes back to normal.
Anyone else experiencing the same issue?
You have to be careful with this two pins. Thouse buggers can brake render.
@ft : I changed AA for next build, so it will be easier to use (Now AA Samples per pixel is an enum, and i removed quality, since it never looked like to make any difference).
Quite decent amount of other fixes in next build, including:
Also now feraltic is included as submodule, so check out should build out of the box.
Thanks vux... can't wait :)
great news vux :)
sounds great thx vux
hi, i'm very happy about the new pack, so finally we can have dx9 and 11 with th same vvvv. I really like and appreciate your hard work ;)
the only thing i'm not able to use is the facetracking of kinect (no dx9 and no dx11).
The node becomes red after i activate rgb, depth and skeleton (but i think they are needed to facetrack).
am i doing something wrong? or it's not working ?
cheers, and big work.
was a pleasure to meet you, vux, in london some days ago :D
well, i can say congrats, but i say it everyday :)
...did anybody see pinOut for readback node ?
Solved : has to be specified layout in inspector, very stylish :D
in case someone stumbles across this too, vertical sync only works when windows7 runs in aero mode
Next release on the way, still few bits to sort, but here is little teaser:
ouhyeah! great stuff!
looking forward to it
The most recent (30.2) works fine on Win7 x64, but hangs vvvv on startup on both Win7 x32 and WinXP x32. Just sits at the grey splash square. Anyone else see this?
Hi this is amazing.
All my DX11 nodes are red. TTY states:
00:00:36 ERR : Exception occured during creation of plugin: Could not load file or assembly 'file:///C:\Program Files (x86)\vvvv_45beta30.2_x64\packs\DX11\nodes\plugins\VVVV.DX11.Nodes.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.
00:00:36 - : To help us track this error down, enable the ExceptionDialog via the menu or starting vvvv with /showexceptions.
Could you help please.
Ah seems you use the 64 bits version for vvvv, but i guess you downloaded the 32 bits for dx11. Please note that 64 bits for 30.2 is coming soon, just need couple more sorting around.
i found a problem in ToSharedTextureNode.cs line 71:
this often fails and the catch clause is fired which sets the pointer to 0.
mr.vux, do you have an idea how to fix this?
i saw that one, too. and tried somewhat fix it https://github.com/sebllll/dx11-vvvv/commit/a8f0df8e83342e6bbc7dc5a62f69728ab956e51c
should be related to this thread: assharedtexture-renderer-temptarget
@sebl ah forgot that, please do a pull request and i'll integrate it
Metaballs is missing dragging and dropping vvvv.dx11.nodes.dll doesn't fix it...
32 or 64?
can you screenshot and post on github?
hi first of all thanks again for the great work all the time!
Just one problem. When I upgrade to the latest release all connections to quads are missing in my project.
Is it somehow avoidable so that you can smoothly migrate projects over the upcoming DX11 releases? Anyone else had this problem?
@tekcor: this is actually handled grazefully, if you:
the node had some renames and they are reflected in the diffff.xml of b31.2
also i just tested and it works as advertised.
ah okey I checked and you are right I installed b31 dx11 pack in b31.2 vvvv and replaced one day dx9 quads to dx11 quads. So there is no way around doing the same procedure again you are saying?
not sure what you mean. anyway this is not a dx11 topic, so please move into forum if still a problem.
I keep getting an error in the TTY renderer from one of the DX11 nodes. Not really sure what is happening but this is the error:
at VVVV.PluginInterfaces.V2.Spread`1.get_Item(Int32 index) at VVVV.DX11.Nodes.Renderers.Graphics.DX11VolumeRendererNode.Update(IPluginIO pin, DX11RenderContext context) at VVVV.DX11.Nodes.Renderers.Graphics.DX11VolumeRendererNode.Render(DX11RenderContext context) at VVVV.DX11.Lib.RenderGraph.DX11DeviceRenderer.ProcessNode(DX11Node node)
04:39:39 ERR : System.DivideByZeroException in VVVV.PluginInterfaces: Attempted to divide by zero.
It is logged a few times per second and also makes "ML?" blink constantly in the Perf Meter.
I am using 32.1 64bit with the latest DX11 pack release (05.12.13) and all this is happening while the rendering (using mre.mdmod 2.1) is working fine.
The problem is that its making the TTY render useless for debugging, as this error gets logged so often.
@seltzdesign : still need a help patch if possible, since giving me exception is not much help (sounds like you send a nil somewhere tho).
And please as mentioned ;)
I wanted to use DX11 videoin in b32 but it missed.
Do you know why?
sorry but can i bumb this? its on page 100 or something
seems that the 64Bit (33.3) version has a problem findig assimp.dll
alright. you need to install vc2012 c++ redist either 32 or 64bit to make it work
First time install vvvv 32bit on win8 64, than add DirectX11 Nodes Alpha
Now cant open vvvv. Just grey squer of vvvv opening permonently and nothing .
Never use vvvv befor today. Maybe i`am doing smth wrong?
@ujif: That's what happens to me if I try and run on a PC that the gfx card does not support DX11, like an older laptop. What graphics do you have?
anybody have a flat directional shader lying around? :3
u can do GSFX Per vertex normals from contribs and u will have flat shading on any directional shader
With the new b33.7-x85 vs. b33x-86 pack, I am getting about half the framerate, and frequent system crashes and stacktraces when I have renderers on outputs of two graphics cards (GTX780s). With 33x, I get roughly 70fps, and 33.7 I get about 32fps. But the worst part is the hard system crashes, which can happen in minutes to hours, but almost always within 12-24 hours. While I usually get a crash, sometimes vvvv just starts getting stacktraces:
This is happening in a patch that is sending one layer to six renderers, three on each graphics card, using the ViewPort node to map the displays. The above happens for each of all six renderer nodes, not just the second card.
I have updated nVidia drivers, and tried SLI on, off, and activate all displays with no change. By just changing the DX11 pack back to 33x, I do not see the problem (but then see spurious black textures from DX9->DX11 video).
If needed I can try to isolate the problem into a patch, but as it can take hours to see the problem it may take a bit.
This is a total and literal show-stopper - any help greatly appreciated!
Where can I find c++ 2012 redistributable for Assimp????
I know its a simple question, but Ive been struggling for a long time to find it.. All DX11 nodes are not working, so I hope this could solve it..
@juan if you run setup.exe it will tell you if you have that installed and if not you can install it from there. it really only for the assimp nodes though. so if all others are not working, that will not help.
In the latest version (33.7) Text nodes are red on two systems that have never had Visual Studio installed on them, they are OK on systems that have. This is with 33.7_x86 and 34.2_x86, in all cases setup.exe is all green.
Running Dependency Walker on VVVV.DX11.Nodes.Text.dll shows two DLLs as missing: MSVCP120D.DLL and MSVCR120D.DLL. Note these are debug version of the C runtime libraries.
Looks like this package is distributed as a debug build, and should not be?
OK this is weird - I went to check if there was the same problem with 33.7_x64, and there was not. Went back and tried the x86 version, and the problem was gone there too. So after installing the x64 CRTs, the problem with the x86 version went away.
So it looks like the x86 DX11 version of the text DLL is dependent on some DLLs installed with the x64 CRTs.
So the important difference was not that VS had never been installed, but the machines showing the red nodes had never had an x64 version of vvvv installed before.
for version 0.7 on latest alpha: all layer space nodes stopped working for me and I was using them as crazy. No red nodes no tty. Screenshot:
3D text didn't make it to the last update? :(
It's on github, but it doesn't work for me yet, probably that's why it's not in release
Thanks for this great update!
Text (DX11.Geometry) isn't working for me though.
Renderer in Girlpower is black.
On Windows 10, x64, NVIDIA 1080.
vl breaks 3D text. probably because of dll version collision.
added the 1.0.1 x64 pack to a clean install of beta5 and v4 wont start anymore. remove the pack and it works again.
same problem like kamanlam ㅠㅠ
There seems to be a assimp issue with x86 geometry loaders are red
you should double check, if you downloaded the right version of the pack: x86 or 64.
Also I recommend to use 7-zip for decompression.
I had trouble playing H265 and ProRes files with the VLC node.
To fix it i went to \packs\dx11\nodes\plugins\vlc folder and removed the following files/folders:
Then i downloaded and installed the latest VLC from their site and copied the above files from VLC install folder back to DX11 pack in their respective places.
So far is working fine :)
The Cylinder (DX11.Geometry) node is not acting how I expected; I thought it would follow the behavior of the Segment node, but it only sort of does. When cycles is < 1 and > .5, it closes the edges instead of creating a wedge opening. But when cycles is < .5, the caps form the expected segment, but the edges are directly closed to each other and do not follow the cap edges.
I would expect the caps to follow the Segment behavior, and in all cases where Cycles is < 1, the cylinder faces follow the caps. The current behavior just does not seem sensical. This is with 38.1 and DX11 1.3.1.
the most recent build
Is there any reason why this isn't just included in the core (or at least the addonpack) these days?
@mfan, i totally agree. Especially since beta39 includes PBR shaders which need the DX11 pack. maybe there is a reason for the this but i'd like to see the dx11 pack included in the installer or at least having the option to get it via the installer.
@devs, would this be possible ?
@mfan and @u7angel since dx11 is not created by us, we don't own the redistribution and selling rights to it. hence we cannot include it in the official download which is sold under the vvvv licensing conditions.
however, i think if @vux would request that we do so, it would be possible. but that needs to be discussed in more detail.
may I suggest devvvvs pull their heads out of their own bubble, grow some balls, break this communication and licensing deadlock, stop the fingerpointing and take the first steps writing to vux the following letter: ahem
Dear Mr. Vux!
I hope we find you in good health! We noticed after all these years that anyone who downloaded vvvv and wanted to draw more than 15 quads on the screen also needed to install your DX11 for vvvv pack. We also noticed that lately the aforementioned pack didn't receive as much care and update as it used to be. For this reason we would like to request your permission to make your wonderful and irreplaceable contribution an official part of vvvv which means we would continue maintaining it and it would be covered by the vvvv licensing terms. This would also mean we would include the DX11 codebase in the vvvv-sdk repository. We're aware that by this "merger" the DX11 pack would lose its own licensing which is different than vvvv is using, however we're sure we can find an agreement regarding compensation. Especially this became important matter for us when we included our first DX11 shader in the officially endorsed addon-pack.
Thank you in advance, and looking forward to hearing from you!
The vvvv Development Team
now copy paste this and send it to Vux. To which he will probably respond
"yeah do whatever you want, I don't care about any of this. Peace!"
and by this minimal amount of social and communication effort the world would become a better place for many.
I know devvvvs attention now is 75% at VL shenanigans but please, after 7 years of legal/personal/philosophical dispute regarding "dx11 becomes vvvvanilla" topic, can you put it behind, and stop playing 3D chess against your own minds, and just do it?
@microdee I agree.
In vvvv beta, DX11 is essential and it would be sad to see it stagnate. so a sustainable solution where it can continue to be maintained would be desirable. I just hope that it can be worked out somehow. Unfortunately I am currently not in a situation where I can provide anything other than moral support, so I can just hope that it will work out somehow.
PS happy new year
I believe, that vvvv license sales would have stopped around 2017, if it weren't for vux' and his dx11.
It was always weird to me, that devvvvs never truely appreciated or even properly acknowledged that fact (besides a spraypainted quad).
This had bothered me so much, that I took the opportunity to call for financial reimbursement when I was on stage last NODE. Fortunately, a few users responded, either with one-time-payments to vux, or his patreon.
But again, this relates more to the gnarly relationship between the devvvvs and vux. While devvvvs didn't hesitate to become gold sponsors of Virgile, they never seemed to even consider something similar for vux, even though their product has been heavily depending on this very contribution.
So yeah, I endorse microdee's initiative whole heartedly, and would love to see an improvement to the status quo.
@mfan @u7angel: the two reasons dx11 (and other packs) are not included with the core download:
then of course true, installation of vvvv and its contributions has historically been.. a pain. that is why with b39 we finally added an installer to solve the first part. now, instead of adding more stuff to the installer (again tying it to vvvv releases), we're interested in improving the situation more generally. so we're exploring the idea of a primitive package downloader/unzipper that should heavily reduce that second pain of managing contributions. more on this soon...
@microdee: language! this is not the way we're used to talking around here. but i hope the above answers.
@velcrome: re "never truly appreciated or even properly acknowledged"
it is odd to hear that but if you feel so, it apparently wasn't enough. the mentions of king-of-code vux and his unprecedented contributions to vvvv have never come without a superlative. most notably we've never heard vux himself complain about a lack of appreciation for his work. we had our differences about code and maintenance but i don't believe ever regarding appreciation. in fact, last time we met two months ago at the december meetup he mentioned he wanted to do another release soon..
re "devvvvs didn't hesitate to become gold sponsors of Virgile, they never seemed to even consider something similar for vux"
we obviously talked to vux early on, before the initial dx11 release (and i believe even on stage at node13) as to how he would charge for it and his answer was along the lines (@vux correct me if i'm wrong) he didn't want to maintain it as a commercial library but instead stay more flexible by offering custom services around it (classic opensource business strategy). so instead of supporting him financially, we supported his development of dx11 by adapting the plugininterface for his needs, so that he was able to build his business on top of it.
note how with xenko the situation is quite different: xenko didn't know vvvv. it is an independent opensource project with no special interest in vvvv.
You are arguing, that you've highlighted the quality of vux' contribution, but that was never in question. My point was that you never fully acknowledged what an essential cornerstone the contribution was and is to the well-being of vvvv group.
Why would you rather bloat the "slim core" with comatose ex9 for years than just admitting that vux has been providing the gpu features that vvvv group could have but didn't.
Now, vux never asked for anything in return, but it fills me with worry that you seem to think that means he does not need anything. What happened to T.R.U.S.T.?
Now, you got much better data than anyone to check how many commercial licensees are using dx11 (from your annual surveys), so please doublecheck. But just believe me when I tell you that EX9 does not deliver enough grapic punch that would have justified buying vvvv licenses ever since Instancing, Kinect2, Particles, Noodles, etc was common place. In some cases you gave head nods to that fact (see Spout, PBR, Craftlie).
That should tell you that vvvv group did benefit in an extraordinary way; intellectually, commercially, and financially.
Before you try to lecture David, you could rather look inside his frustration. Sure, draw up your own letter to vux instead of copy and pasting it, but make tabula rasa. Find out how you can help him, maybe it is not even money he needs, but please for the love of tasty vanilla code and streamlined installs, show some earnest gratitude that this man has silently saved your beta sales for the last couple years and will continue for at least another year.
I really hope you end up with a refreshed collaboration, that does not feel like a one-way-road to many around here. Now this was a lot on the interpersonal level of the issue, so let me get back to the factual:
DX11 is the de facto standard gpu pipeline for beta (even including vl), it would only be honest and helpful for everybody if this would be reflected in the vanilla beta as well.
I think the problem people have is that to use vvvv beta commercially, you need dx11 pack. And it looks like the continuity of dx11 is independant of the vvvv group, ergo, vvvv beta depends of outside development to be a valid commercial product.
Dont know about the more acute feelings some of the people express, im in another continent so not really involved in that drama, but at least thats what I get from here.
@joreg thanks for your response, that was insightful
my short reaction: my point was making DX11 the vanilla rendering path in VVVV and deprecating DX9 all-together (or at least tag it as legacy) a 1.5 decades old technology, the world moved on since by a landslide, twice even! A package manager will not solve that. Especially because the community already has one, VPM, and many creators are using it for their own packs, and many times I received the feedback "this should be included in the vvvv download" (which is btw under MIT so you do whatever you want, again without any permission, just saying... :P). Sure from hindsight it might have many bad design decisions, and a terrible codebase, but it works so far, and showing some official interest for it, I might jump back onto that band-wagon. But back to the point "you can download it via package manager" != "vanilla"!!!
DX11 for vvvv implementation is under BSD license which implies: You don't need Vux's permission to do whatever you want with it, including using it without credit/association in a closed source commercial application.
After this it's just a case of "yeah but we don't wanna" in which case, I don't even comprehend how you guys imagine making money with that attitude in the coming decade???
Btw, I don't think so Vux needs any help or more grattitude, that'd be too little too late. He moved on, working for Epic now on ray-tracing in UE4, and vvvv is far-far beyond his focus already. That's why I'm also so loud with "DX11 needs to be vanilla" in the first place, because when that repo bit-rots away in the next decade, that's the end-of-life for old-school vvvv too.
For the last 2 years I've been constantly writing these long ass, ranty comments (I also did for this one and figured I will just scrap it, what's the point anyway). It's not great. I'm not doing this because I enjoy shouting at people. But please do not consider this as "ah this soviet-eastern block asshole again is doing a tantrum". There are people who feel the same frustration as me, but instead of causing a fuss (oh god not the fuss, please not the fuss :P) they simply leave without a word, and consider vvvv as a finished episode in their life. You don't get any real feedback from that kind of behavior, until too late.
If I see early signs of shit going down, you can bet, I'll cause a big and loud fuss!
Including DX11 "new standard" shader into addons while not having DX11 is one of the strangest software development decisions I have seen. I do not think I used vvvv once last 6 years without using DX11, and having any version included is still better then having none. People who are advanced and need latest dx11 iteration use github anyway.
I do not see any reason to actually include DX9 apart from people in developing countries using vvvv on recycled PCs.
Every time I suggest vvvv in facebook groups focused on live content creation (even posting your showreel video), there is someone who chimes in how vvvv is pain to work with compared to competition, and I think decisions like these are big part of it. And I would even say it is too late to try "solve" any of this when xenko is on horizon, and I hope it will aim to fix issues like these.
anonymous user login