Blog-posts are sorted by the tags you see below. You can filter the listing by checking/unchecking individual tags. Doubleclick or Shift-click a tag to see only its entries. For more informations see: About the Blog.
And here we are, another fresh DirectX11 release, which gives a nice 1.3 bump.
Two small issues decided to hide themselves in latest 1.3, and since they are annoying enough they deserved a quick fix and a 1.3.1 bump:
Also since it got implemented, TextureFX shaders that can use "wantmips" now do so (Edge, Blur, BlurDirectional, BlurGlow, BlurPerfector, DistortFlow, DropShadow, UnsharpMask)
.They are all faster in that scenario.
For impatient people, here are release highlights:
For spreadable technique example, see: girlpower\misc\texturefx_technique_spread folder
I of course wanted to say thank you to people who did either a Patreon subscription, or by doing private yearly invoice.
There is now an About (DX11) node, which has the names of all Contributors and Supporters.
For next release, the main aim is to upgrade to latest version of Assimp (and it's c# wrapper).
This will allow to import the newly supported formats (gltf), and use more complete wrapper version (specially for loading options).
Please note that latest Assimp binaries will be incorporated in next alpha build (github).
Download Here :
It's been a little while again, but here it is, new Directx11 version.
There are many changes around, so I'm not too sure where to start.
First thing, versioning has been updated, no more alpha/beta, that joke about "software is always beta" made it's time, but as we say, shortest jokes are the best, and for many users that sounds pointless and confusing, so now build is adopting a more formal version naming eg : release, with beta and alpha being used for in between releases.
Second thing, build system has been reworked and now uses a build server, which allows direct update to git releases, so users who want to try out early releases can do so much more conveniently viahttps://github.com/mrvux/dx11-vvvv/releases
No more need to build the pre releases yourself.
This also means that users can expect more frequent releases.
Second thing was in the list for a long time, interface has been changed (basically
IDX11ResourceProvider and friends have been replaced by IDX11ResourceHost version and friends. Removing IPluginIO is necessary as it creates some major issues going forward (and never got used anywhere inb the codebase anyway).
For this release ResourceProvider is working alongside Host (it is now marked as deprecated and will be removed from git version pretty much as soon as I finished this post.
Sadly, LayerProvider could not be made to work alongside Host version, so those have been removed already. From what I know there's no custom plugins using it (or they already move to new interface), so on a user perspective there should be no transition issue.
As usual, I think I should have a ready to paste version, and maybe an auto bot to reply in forums, bugs are to be submitted herehttps://github.com/mrvux/dx11-vvvv/issues
Ok now let's go past those (boring) announcements details and go through what every user wants eg : What's new (and download obviously)
New Nodes (or new options in node):
Lot of new examples and help patches (20+ from Assimp, Semantics...)
So for users who did read all and did not scroll hear (or just skipped and went straight into contribution page):
Not many will remember the times when vvvv's 3d rendering was based on Direct3D 8. Not important really, because at the same time we released vvvv 33beta1 in December 2002, Microsoft released Direct3D 9 with a lot of new features, so we knew what we had to do..
Luckily vvvv's DX9 implementation proved powerful enough to be quite useful for many years. Then it took Microsoft 5 years to release its successor DX10 which was only available on Windows Vista, which nobody wanted. Also graphic-card adoption took quite a while so we didn't really feel an urge to start working on it right away.
A year later in 2008 Microsoft released Windows 7 and with it DX11, which altogether looked more promising. But still a lack of adoption of supported hardware and Windows 7 didn't put too much pressure on us to implement it. Instead we thought it would be smarter to improve the plugin-interface for vvvv to make it easier for users to contribute to the library of nodes.
In parallel we had already secretly started work on our next big thing that would become VL, which we first announced at the keynode during NODE13. Since with VL we've mentioned from the beginning that we wanted it to eventually run across platforms, for us, implementing a new renderer based on the windows-only Direct3D api became less and less appealing.
What happened next couldn't have been more fortunate: besides many other major contributions, using the possibilities of vvvv's plugin-interface, power-user vux took it in his own hands to create a set of nodes for rendering with the features of DX11, which he released on vvvv's 10th birthday in December 2012. And the vvvvorld was a better place.
DX11 for vvvv is amazing, but innovation in the world of computer graphics started moving faster and faster. Despite the magic that DX11 brought, users demanded more and more bling, but all we were talking about was how VL would revolutionize visual-programming, which brought us all together in the first place.
With the cross-platform goal in mind, for years it seemed the only option was going for OpenGL instead of Direct3D as rendering API for VL. But all those years, following OpenGLs development and stories about bad support by Microsoft and Apple never got us excited enough to just go for it. Meanwhile a new player has appeared as a modern cross-platform graphics API, called Vulkan, but since it is still in its early stages and support for MacOS seems not official yet, again we were reluctant to jump on it.
All the years we knew there would be another option: Instead of using Direct3D, OpenGL or Vulkan directly, we could base a rendering library for VL on a game-engine API that would deal with different graphics APIs under the hood and would possibly have all 3 as back-ends that can be used on different platforms without us needing to worry about it.
While this sounds brilliant, it obviously has other potential drawbacks (out of scope for this post). But also the range of options for game-engines we could have used wasn't too overwhelming. Until recently. Enter Xenko.
We've had an eye on this engine for a while already but it being targeted at commercial game-studios would mean that every user of vl would also need to buy a license for it, so again we were hesitating and looked for alternatives.
But what just happened could again not have been more fortunate: The company behind Xenko, Silicon Studio, removed its commercial licensing and released it to the community under the MIT license, which is a very permissive open source license. This would allow us to base a renderer for VL on it without any licensing restrictions.
Initial tests look very promising. Within just a few days we were able to patch a little interactive scene and export the project as an executable so it could be distributed via the Steam store and run on a VR device.
Hence our plan is to investigate further in this direction and at the moment we see two interesting workflows between VL and Xenko:
For both scenarios what will be important, is a proper library design wrapping the original Xenko functionality into a comfortable set of nodes, similar to what we just did for Skia.
We'd usually not water your mouths before we are more sure about things. But with Xenko just having gone full open-source and looking to build a community of developers and users, we thought it would be a good idea to talk about this now and try to involve you from the beginning.
So if you're curious about Xenko's universe, just head over to its website and see what it has to offer. You can even download and play around with the editor and if you're familiar with C# create a little game with fancy graphics and assets in no time.
Next we'll demo what we've got so far to participants at LINK and start a discussion there. If you're not at LINK please still join the discussion with your thoughts using this thread. If all goes well we should also be able to share our proof of concept sometime after LINK.
So we hope you understand that at this stage it is too early to promise anything but at the moment we are confident to having found the right library for implementing a 3d rendering system for VL. Just as we were happy when we finally found Skia as the perfect library for VLs 2d rendering system.
We'll update you about developments as we progress...
here we go.
in an attempt to save the collected wisdom of node13 for posterity this blogpost aims to provide a reference of where all the stuff that was handed out during node13 workshops went.
more is promised...will update this posting as material comes in.
just in time for the weekend we are super happy to share the NODE17 Workshop Video Captures!!!111
In total we have been able to capture 22 workshops. And chrisr spent the last weeks editing the video and sound, uploading, adding video descriptions and bringing it all together.
Happy binge watching!
And if you are searching for the workshop materials, here you go: node17-workshop-material
3D basics & building interaction - Part 1
3D basics & building interaction - Part 2
Advanced DirectX11 shading - Part 1
Advanced DirectX11 shading - Part 2
Cutting & Folding Paper
Forward+ or how to bring thousand of lights to VVVV
How to use a statemachine - Automata UI
Introduction to DX11 rendering
Introduction to VVVV message awesomeness
Supershiny Motion Graphics with Superphong
VVVV.js Game Engine
Programming DMX and visualizing with grandMA2 - Part 1
Programming DMX and visualizing with grandMA2 - Part 2
So where to start...
After a couple or years of bugging devvvvs for features, creating/fixing new bugs, it's finally there.
So there's a little nice hefty number of nodes around already, but let's speak about what to expect from it, except the fact of joreg already being in the starting blocks to submit bugs :)
As usual going to a new API also means there's some changes (bugs) around the corner.
So let's see a bit of (non ordered) features list.
photo by benju
this one took us longer than planned, but it was a difficult one in a way that it includes so many new details. if you are following the devvvv blog you should already know about most of the new stuff thats coming with this release. here is a feature-summary:
here is a list of the latest blog-posts with infos regarding changes to the plugininterface for beta28 that should make your devvvvs lifes easier:
for a full list of fixes and changes check the change-log as usual.
Rolls-Royce Motor Cars Ltd. delivered more vehicles in 2014 than ever before in its 111-year history, marking the fifth consecutive annual sales record for the ultra-luxury brand.
via yahoo finance
definitely in the wrong business.
helo and welcome to the 4th in a series of year-in-review articles about the numbers that make your favorite multipurpose toolkit that is vvvv. new to this? for last years rant see: vvvv-in-numbers-2013
so lets first have a look at where you come from. as you can see for the second year in a row the first 4 spots have not changed. the exciting bit happened with japan which climbed into the top 6 and settled on spot 5. 脱帽! shall we say thank you to mino and team for creating their vvvvook? oh, 確かにどうもありがとうございました.
|germany (-)||16.82%||germany (+)||16.99%||germany (+)||17.02%||germany (-)||13.81%|
|usa (+)||11.36%||usa (-)||10.72%||usa (-)||9.87%||usa (+)||10.74%|
|uk (-)||6.33%||uk (-)||6.31%||russia (+)||5.78%||russia (+)||7.39%|
|france (-)||5.17%||russia (+)||4.98%||uk (-)||5.64%||uk (-)||5.37%|
|italy (-)||4.66%||italy (+)||4.97%||france (+)||4.93%||japan (+)||4.85%|
|russia (+)||4.17%||france (-)||4.92%||italy (-)||4.56%||france (-)||4.12%|
the number of unique visitors still seems to increase though it gets harder and harder to tell due to a constantly growing number of spam (most of which you luckily don't get to see). on a normal weekday vvvv.org has ~1500 unique visitors. on march 6th 2014 it had 61.410 and not a single one of them bought a license! so i removed that number from the total amount for 2014 and still we see quite an increase compared to the years before:
my guess: the number of non-spam unique visitors did indeed increase. just probably not as much as the number pretends (>50k) but rather in a range of ~15-20k like in the years before. sigh.
i spare you the sad details about what browsers you're using. when will they ever learn...
the spam-attack also destroyed the session-overview of the whole year. what you see below is starting from march 7th and compares 2013 (orange) and 2014 (blue).
you had even less interest in vvvv.org during the summer than last year but then made a strong finish towards the end of the year. see the strange spike (marked) end of november? that was when the combined tags of #vvvv and #photoshop in a facebook posting attracted >13.000 people to have a look at vvvv.org according to the click-stats of facebook. speaking of which: na, couldn't care less..
this diagram shows we had a sharp decline in questions asked in the forum. and also all other numbers regarding using features on the website (blog, screenshots, shouts) went down (i'll omit the depressing shot of those stats). the only numbers that went up were new and edited wiki-pages, ie. we put quite some effort in our Documentation and also the translators, most notably h99 (italian) and sebescudie (french), were quite active. grazie mille et merci beaucoup for that indeed.
and apart from the wiki-documentation robotanton has continued his дотошный work on the \girlpower demo patches shipping with vvvv. i can only hope that those efforts have at least contributed to the diminishing numbers of questions asked in the forum.
probably the best indicator of a user-count is the downloads because spambots don't do that. then of course every download is not an individual user but still we can make out two things from the statistics:
* x86 and x64 combined
as we often heard that people wanted to support vvvv even when using it non-commercially (nobel) early in 2014 we added the possibility to support our development via flattr, a practical and simple way to give and accept micropayments. and really all of the 17 people who requested that, flattred us at least once. some even multiple times so that in the first year we earned 30 flattrs worth 74.60€. now stop laughing already and get yourself an account and join in. then try here, it is fun:
actually a value of 2.48€ per flattr is quite something. like for example a slice of pizza at our downstairs dealer. very much appreciated.
if you're still not convinced. just have a look at the download-numbers again. if every download was a flattr we'd actually fly quite high. don't mistake the actual numbers we have so far with the potential this can have if people understand that it is a good thing to support something you like/use/benefit from not just with a +1/like but some actual micromoney. the crowdfactor then does the rest.
also remember that other vvvv users and contributors can be flattred as well. here are the stats:
1. vux 95 from 23 people
2. tonfilm: 38 from 10
3. joreg: 35 from 10
4. woei: 27 from 10
5. westbam: 25 from 11
6. elliotwoods: 25 from 7
7. velcrome: 8 from 3
8. microdee: 6 from 2
9. u7angel: 3 from 3
10. gregsn: 3 from 2
11. elias: 2 from 1
12. colorsound: 2 from 2
13. dottore: 1
14. robotanton: 1
makes a total of 299 flattrs which i'd like to argue is not nothing. still of course should be at least 10 times as many but it is a start. and btw flattr has announced improvements to their service. looking forward to those.
now first the bad news. as you can see the blue bar is below even its level of 2009. even though for the first time it includes the numbers of our new big business mainstay that is El Protektor. hmm...how can we talk that up..?
how about like so: licenses were bought by 81 (thats one more than just eighty) different companies from 17 different countries on this wonderful planet. compare this with the previous three years:
see a trend there? mhm, apparently more and more companies out there are using vvvv and are so happy with it that it feels totally natural to them to pay for their licenses. so proud of you people! (that just gave me the chills). so ja, if everyone just concentrates to get that number up, the other numbers will follow...
here is how the licenses spread over the world. germany and the uk hard to compete with in the top ranks. but then, switzerland made it again to spot three and most amazingly japan doubling its share. 驚くべき! あなたの努力のためにもう一度感謝 mino and team.
|switzerland||4%||austria||3%||austria||3%||russia||2.5%||aut, aus, usa||4.22%|
|south korea||3%||switzerland||2%||spain||2%||france||2.5%||russia, norway, czech||2.8%|
hey usa, glad to see you back on the ranks. according to website-access-statistics you should be on rank 2 though, or are you just doing all the spamming?
all in all you see we are facing some gravity, but thats exactly why on april 28th this year we'll release our second album!. why did that take so long? hey it took guns'n'roses 15 years to release their last album. clearly good things take a while..
in the meantime get your node15 ticket and prepare for the best. so much looking forward to seeing you all again in frankfurt this year, horray. thanks for every single bug report that helps us polish vvvv and thanks for all your contributions that make vvvv so much more valuable to everyone than we could ever make it alone.
nur das beste im neuen jahr.
It's been a while again since we last dropped news about that next big thing we still call vvvv50 (50). So in order to get the hype slowly started here are some further notes...
First a quick recap of what we have with vvvv45 (45) so far: For the first ~6 years in existence vvvv was a rather monolithic thing. We sloppily called it "a multipurpose toolkit" and really only later found out ourselves that it was actually made of 4 parts:
Still very much monoltithic in that there was no way for the user to change any of those. Only when in 2008 we introduced the plugininterface vvvv became more modular in that it allowed users to create their own nodes, and boy they did (->addonpack, dx11-pack, cv.image-pack, ...).
So the library part was addressed but critizism remained:
According to the great Joel Spolsky the single worst mistake you can do when writing a software, is starting from scratch. So we did.
So here is our bold plan, this is what we're aiming at (longterm):
Now if that sounds familiar as in "so whats the big difference?" then exactly. Instead of saying it will be completely different we can also say that it will be very much the same only much better. People tend to prefer hearing either. We couldn't decide...
Anyway we're at a point with this where we have bits from all 4 parts implemented and can do simple demos. But mostly we're still focusing on the "visual programming language" which we consider the foundation of the pleasure we want you to have with 50.
The great thing about 45 is still that it is simple to learn. Say that again..!? No really, if you approach it the right way (arrogant!) it actually is. There is a huge library of nodes that is hard to grasp, true, but the things you have to know about the visual language vvvv are only a few:
Those are basically the language features of 45. Specifically the concept of Spreads is what makes vvvv stand out. It allows you to do simple things quickly but as things get more complex they are quite cumbersome to work with. We call this "low-level" while the goal of our new visual language is to be able to work more "high-level", ie. less thinking about concepts that make things easy to understand for the computer but more thinking in human terms.
So with 50 we're introducing a number of new language features that will make it easier for the user to create more complex programs. Here is the buzz of what we have so far:
Sounds scary? Naa... you'll see, all a breeze. Really the basics are not changing: You'll have nodes and pins to connect, a renderer, a quad, ... nothing new. If you're not using any of the new features you can still work kind of 45-style only then you'll not be seeing any of the productivity-increase you can gain from using them.
Specifically as you'll not need to use them all right away and you'll be using them without noticing anyway. But in order to talk about them we need to call them names.
In a forthcoming series of blogposts we'll show you how working with those features will feel like. If you already like what you've read so far and want to buy the cat in the sack we're always up for a /downloads|vvvv?.
previously on VL: vl-progress-report-4
the vivid blog reader already knows the drill: everything stays the same if you liked it just the way it was.
Specify remote host (IP address), a nice port number, connect some data and bang the send to let your UDP packets travel over the network. Or open a server to receive bytes arriving on the specified port. The only difference to vvvv you might see is, that here you also get infos about the sender of the packets via the Remote Endpoint output (which is an IP Address and a port)
same same for the TCP nodes: The client will try to connect to a server. And once the connection is established, you can send and receive bytes.
The TCP Server awaits incoming connections to talk to. The subtle difference here is the Tuple input, where you would expect the data pin. No one ever requested it, but now you can decide which packet should be sent to which client by specifying IP address and port together with the message. In case you still want to send the same packet to all of your clients, just set the address to 0.0.0.0 and port 0
so why did it take so long, what's the goodies behind that?
Unlike the monolithic networking nodes in vvvv you can peek inside the VL ones. The goal was modularizing on a much lower level to be able to provide the very basics as nodes for the patcher:
anonymous user login