First installment of Some Thoughts about VUO

First off, VUO is extremely promising and awesome, and the reader should keep that in mind in deference to any negative comments.

My perspective on VUO is bound to be unique.

As a QC user, one of the things I regularly bugged Chris Wright about was the idea of a cross platform compatible QC, with the idea that the graph (the arrangement of QC patches) could be abstracted away from OS X, and have code that worked on a given platform. I also had many things that irritated me about QC, like the way layering worked, the way that render patches were geometry specific, and the way there wasn't a way to deal with dropped events well/coalesce incoming data. In my mind, much of this would revolve around making geometry happen before the final patch that dictates "enable" of the chain. So in QC, maybe this would involve taking the "enable" port of a Consumer patch off of the patch, and making it more like a "bang" is in MaxMSP parlance, and removing the QC layer scheme with something that deals with Z sorting better (like kineme depth sort sprite/depth sort environment).

Many ideas were bandied about for improvement of QC, and cross platform implementation over the years, but when C. Wright moved to Apple, much stopped. Some time before C. Wright moving to Apple, Steve Mokris was pretty hot about actually making a system for QC to work in iOS in some fashion, so for it all to stagnate was a bummer.

At some point, talks about VUO started informally, then more formally, and a website was established where ideas were put together. Much of this was based on the idea that a node language could eventually become turing complete, and be a real computing language, and thus be more efficient and less hackily cross platform compatible through LLVM.

At some further point, some of the ideas about VUO started to rub me the wrong way, and I guess I got pretty obstinate and mouthy about it, and also about what I perceived as a lack of talent of one of the (then) team members. It is what it is.

A pretty good chunk of time went by, and things sort of resolved themselves.

I've been testing VUO since the current VUO team has decided to start making alphas available to subscribers.

It's real interesting to see what has come of, what to my mind, was initially a drive for a QC system that would be cross platform compatible, and also eliminate some of that system's problems.

In many ways, QC is super pragmatic, and aimed at making bits of visual candy.

What I mean by that is, suppose you have written an app using OpenGL, maybe fixed pipeline, or OpenGL shader based. When you want to switch between, you're going to setup some conditionals or switch case. The QC consumer patch scheme is basically a user friendly way of doing this. Say you wanted to modularize a step further and have a way of switching geometry on the fly - you would wind up with something much like a QC provider patch. If you wanted to process the geometry in various ways, you would wind up with a processor patch. It's all very driven by need, and to my mind, from having OpenGL programs that need various parts of them to be manipulated across a node graph.

The other real user friendly thing in QC, is the iterator, and the ability to iterate the code runs. The QC iterator is amazingly useful and sensible, and many things could be done with just that iterator scheme, if it was more performant, from image processing, to raymarching.

So, for me, seeing the initial VUO is almost insane. No way of making a shader or OpenGL code, and no way of iterating right now. The pragmatism of "being able to do stuff" has been entirely thrown out the window. It's somewhere between head scratching and infuriating. It has many concessions that seem aimed at "real coders" like ability to time each chain, but big building block patches like "wave" that allow no fine tuning of the wave creating code that powers it. It's a puzzling mix to me at the moment.

I think the #1 feature I would have liked would be "run shaders/be able to switch between/be able to link hardware value output to shader input uniforms". A system that did just that could pretty much replace my use of QC immediately.

What VUO really has going for it though, is the scene graph. Spending time on making the scene graph work correctly should really yield improved performance overall, and is a smart tact, just extremely frustrating to me, in wanting the system to do useful things right off the bat.

What VUO will likely be able to do, that other systems don't and probably won't - given their technical underpinnings, is render a ton of objects speedily, in an efficient manner(and between nodes), in the way a good gaming engine can.

This is a really cool thing, and being able to implement things like deferred rendering in a reasonable way, or do skeletal animation without crazy nesting of transforms, will be the cat's meow for many.

Right now, I don't really have a need for that, and don't really need or desire to make video game-like scenes or logic. Most of the time, I'd rather setup some shader code that's not inter-related to anything save for some values coming from hardware, and just switch between shaders. If I want to render a ton of objects, I will tend to just code it all up in one patch, and it's fine.

Despite my hesitations and frustrations, I'm looking forward to the expressivity that may come with the scene graph and starting to think in that way though. Looking at the roadmap for VUO is pretty darn exciting, because it could just about cause a revolution in interactive realtime coding if people embrace it.