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:

1. the plugin was limited to one texture output. if there was the necessity to have more than one texture output one had to go the long route by implementing IPluginDXTexture2 and doing the resource management manually.
2. it wasn't possible to reinitialize the textures on a slicewise basis. for example if the size of one texture changed all textures had to be recreated.
3. dealing with a pin of type texture was completely different than all the other data types. wouldn't it be nice to simply write ISpread<Texture> and be done with it?

well it's nearly as simple as that now. you can create a texture output by writing

[Output("Texture")]
ISpread<TextureResource> FMyTextureOut;

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:

1. some arbitrary user data which will be supplied as the first argument to the following functions
2. a function which creates the texture, taking as first argument the user data, as second the device for which a texture was requested and returning the newly created texture.
3. a function which updates the texture (optional), taking as first argument the user data and as second argument the texture to be updated.
4. a function which destroys the texture (optional), taking as first argument the user data and as second argument the texture to be destroyed.

so in order to create a texture we need to do this:

FMyTextureOut[i] = TextureResource.Create(i, CreateTexture);
...
Texture CreateTexture(int slice, Device device) {
  return new Texture(device, ...);
}

if we want to update the texture when some input changes:

FMyTextureOut[i] = TextureResource.Create(i, CreateTexture, UpdateTexture);
...
void UpdateTexture(int slice, Texture texture) {
  // Do something with the texture
}

and if something special needs to be done when destroying the texture:

FMyTextureOut[i] = TextureResource.Create(i, CreateTexture, UpdateTexture, DestroyTexture);
...
void DestroyTexture(int slice, Texture texture) {
  // Destroy 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.

hola,

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:

• MouseState (System Split)
• KeyboardState (System Split)

to use the data conveniently inside the module.

plugin writers simply use:

ISpread<MouseState> FMouseState;
ISpread<KeyboardState> FKeyboardState;

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:

• Mouse (System Window)
• Keyboard (System Global)
• Mouse (System Window)
• Keyboard (System Global)

internally those modules use:

•  MouseState (System Join)
•  KeyboardState (System Join)

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:

• Cursor (DX9)
• TypeWriter (String)
• Button (3D Mesh)
• Button (3D Quad)
• TagPoints (3D Vector)
• PickPoints (3D Vector)
• the series of Point- and MeshEditor modules

so for the developer this provides a standard interface for mouse/keyboard input and for the user it will save some clicks. win/win.

for some advanced plugin usage scenarios we introduced two new interfaces in the upcoming 28 release of vvvv:

• IDXDeviceService
• IMainLoop

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.

helo nerds,

this is to inform you that latest alphas come with a new commandline: argument

 /dx9ex

starting vvvv with this option (on windows >= vista) brings you:

• a VideoTexture that works on two heads of one graphiccard (as you'd have always expected)
• texture sharing
• broken Flash (EX9) as long as original movie's resolution is non-power of two
• broken Text (EX9.Geometry)

texture-sharing can be used to share textures e.g. between two instances of vvvv (without noticable performance penalty) and even with any other software that also supports DX9EX. check the helppatch of SharedTexture (EX9.Texture) for instructions.

apparently this can also work as a bridge to opengl if someone wants to give this a try...and for those wondering, yes this enables stuff on windows your macfriends have been bragging about for a while now using syphon.

depth rendering

another new thing (not related to dx9ex) is the possibility to render the deph of scenes directly without using an extra pixelshader pass. just set the Texture Format of a DX9Texture (EX9.Texture) to INTZ and you should get the depth of your scene rather than a colorbuffer. disclaimer: may not work on certain graphiccards, see here

available now in latest alphas, enjoy.