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.
thanks to MESO for sponsoring and CEF and Chromium for doing the hard work, it's finally possible to render web content (HTML, Flash, WebGL, etc.) directly into a texture using one of the two new nodes:
HTMLTexture (EX9.Texture String)
HTMLTexture (EX9.Texture URL)
as there's no window involved at all in the rendering process this is also known as offscreen rendering. and, probably the best feature, the generated texture contains an alpha channel. so for example setting no background color on the <body> element of your HTML content will result in a completely transparent texture.
the new possibilities are of course endless:
the nodes are fully spreadable, so for example feed it with a spread of urls you last visited, add some scale/translate magic and voila, you patched the welcome screen like we know it from firefox or chrome.
with the key and mouse inputs you can redirect user input wherever it needs to go, so you could display several websites at once, but redirect user input to only one of them.
if you want to test these new nodes download the latest alpha build of vvvv including the addonpack.
We added nodes that ease the creation and analyzation of xml documents.
Documents are represented by Elements and Attributes - not strings, which helps performance...
You now can easily get some parts of your document and route those as a spread of Elements to other parts of your patch, where they get further analyzed.
You always can convert an element to a simple string via AsString (Object) - or back to an element via AsElement (XML). But typically you only want to do that once: when reading from disk or writing to disk. For the rest working with Elements and Attributes is much more comfortable.
Note that by concatinating several Element (XML Split) nodes - which also outputs an elements' child elements - will give you the possibility to dig into the xml structure. E.g. you could retrieve all child elements of an element, check its properties and dependant of some test select some of the childs via Select (Node). You therefore could patch a query into your xml structure...
However this can get complicated and so we added some more nodes:
With GetElements & GetAttributes we added different ways of searching for child tags and attributes.
When searching by name you get those that have a certain tag or attribute name and are direct child elements or attributes of the specified element.
do that with GetElements (XML ByName) & GetAttributes (XML ByName)
While those nodes are flexible and spreadable in means of what you are searching for, they might be a bit unhandy when you already know that at a certain point in your patch only a certain tag with certain attributes are of interest.
For those cases we added Prune (XML) which lets you set those tag and attribute names statically in configuration pins with the bonus that you get friendly pin names and dont need to further process your attribute data.
For being really sure that your patch system can work with a certain xml-File or string you can check validity with IsValid (XML RelaxNG). link: RelaxNG
Both XML Syntax (.rng-Files) & Compact Syntax (.rnc-Files) are supported.
Thanks to our MESO for putting those node on our agenda and for sponsoring.
For analysing small textures there is a new node that let's you do that in a patch:
Texture (EX9.Texture Split) gives you all RGBA-Values for each texel of the texture.
Even for small textures this results in quite big spreads. So typically this is useful when you can identify the interesting texels with just a few nodes. E.g. you could check if the alpha value is > (Value) 0. You then can Select (Value) those texels and operate on just those few texels.
there're situations were one needs to create pins at runtime depending on the value of some config pin. for example consider the Expr (Value) node. it creates input pins for each given variable name.
with beta28 coming up this kind of task got considerably easier to do with a new interface called IIOFactory.
it basically provides a method to create so called IO containers, containing the actual "view" on the pin data (such as ISpread) and controlling the lifetime of it.
say we want to create an ISpread<ISpread<T>> during runtime, we do something like this:
in case we decide to get rid of those two pins which are used by inputFooSpread we simply call Dispose on the associated IO container:
for details and as a starting point have a look at the new dynamic plugin template contained in beta28, which creates inputs and outputs on the fly, when changing the associated config pins.
the easiest way to write a plugin with a texture output was by extending the DXTextureOutPluginBase class and overriding the CreateTexture and UpdateTexture methods. this approach lead to several issues though:
well it's nearly as simple as that now. you can create a texture output by writing
the TextureResource class takes care of the resource management, for example if a renderer is moved to another screen, the directx9 device changes and therefor the texture on the old device needs to be disposed and recreated on the new one.
the constructor of the TextureResource class takes up to four arguments:
so in order to create a texture we need to do this:
if we want to update the texture when some input changes:
and if something special needs to be done when destroying the texture:
in many cases the UpdateTexture call can be quite expensive, in order to disable it set the NeedsUpdate property on the TextureResource to false and set it back to true under a certain condition.
for a full example have a look at the rewritten dynamic plugin template.
oh and all this stuff works for meshes too, simply replace TextureResource with MeshResource.
here is the thing: until now, when creating modules or plugins that take mouse input you'd always have to cons XY and the mousebuttons together somehow so that you'd not need 5 connections to the node. also with the keyboard it was quite messy to parse the actual keystate only given a keycode. no more. we're introducing a special datatype for those now, and we call them "MouseState" and "KeyboardState".
so now, when creating a module that takes mouse or keyboard input use:
to use the data conveniently inside the module.
plugin writers simply use:
to create pins of the respective types.
and as a user you'd notice how the following have turned into modules that return an additional handy Mouse or Keyboard:
internally those modules use:
which of course you can use to simulate mouse/keyboards from any arbitrary input. and note that of course those are spreadable.
nodes that already take that input now include:
so for the developer this provides a standard interface for mouse/keyboard input and for the user it will save some clicks. win/win.
the upcoming vvvv release (beta28) will contain a new way of accessing pin data by using the IStream interface. please note that it's just "a new way" and not "the new way" as its usage is much more complicated than ISpread and it will only be superior to ISpread if the plugin you want to write accesses its data sequentially.
if you don't mind writing much more complicated code in order to squeeze out every last bit of performance, read on, otherwise you can safely skip this blog post.
for some advanced plugin usage scenarios we introduced two new interfaces in the upcoming 28 release of vvvv:
the device service can be used to enumerate all directx9 devices created by vvvv (for example through a renderer) or to get notified when a device was created or destroyed. this might come in handy if plugins do some kind of background work using a directx9 device (like texture preloading) and need to know when a device got lost in order to stop all processing scheduled for that device. another future use case would be for some sort of directx9 sink node, like a pipet for example, which needs a device in order to be able to evaluate its inputs.
the second interface can be used to get various notifications about all the different stages the main loop goes through when computing one frame. a possible use case could be a custom set of classes/nodes running in some kind of special "subgraph".
both can either be imported or retrieved via two new properties on the IHDEHost.
anonymous user login