This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.


pack vive oculus VR htc



The OpenVR pack contains nodes to get pose data and render a 3D scene into any VR headset supported by SteamVR. Currently HTC Vive, Oculus Rift DK1, DK2 and CV1.

Commissioned by Marshmallow Laser Feast:

Special thanks goes to these members of the vvvv community who also supported its development with various amounts:

Chris Engler
Hamburg, Germany

Paul Scheytt
Hamburg, Germany

Bucharest, Romania

Andres Alvarez
Rosario, Argentina

Thomas Bouaziz
Paris, France

Louis Mustill & Will Young
London, UK

Granada, Spain

Berlin, Germany

Eno Henze
Frankfurt/Main, Germany

Christoph Schmid knaif
Vienna, Austria

Code Contributions

  • additions to controller nodes by herbst
  • trigger haptic pulse by sebl
  • disable wait for sync microdee


Poser (OpenVR) returns all tracking poses from the headset, lighthouse stations and controllers as transformation. Also has a pin to disable wait for OpenVR sync, but the sync needs to run a few times in startup to get the compositor up and running.

Camera (OpenVR) calculates vvvv conform view and projection matrices for the left/right eye. It also outputs the recommended texture size and a hidden area mesh that masks out unnecessary pixels to safe shader performance.

Compositor (OpenVR) receives a texture handle and submits it to the HMD.

TrackedDevices (OpenVR) outputs all OpenVR events and an object oriented view on the tracked devices. Might be merged with Poser in the future.

Controller (OpenVR Split) splits a tracked controller from the TrackedDevices node into pose transformation, trackpad axis and all button states.


Renderer (OpenVR DX11) Combines Camera and Compositor into one handy node that only needs a layer to be rendered. It exposes quality settings and returns the rendered texture for preview.

HiddenArea (OpenVR DX11.Layer Viewport) constructs the hidden area mesh to cast out unnecessary pixels.

ViveController (OpenVR DX11.Layer) renders a life-like model of the vive controller. It gives a pretty good eye-hand coordination feeling when seeing the actual controller in VR.

ViveLighthouse (OpenVR DX11.Layer) renders a life-like model of the vive lighthouse tracking station.

HMD (OpenVR DX11.Layer) renders a life-like model of a generic VR headset, helps to build a third person overview on the scene.


  • Make sure the DX11 pack is installed
  • Place the VVVV.OpenVR folder into vvvv's packs folder
  • Use SteamVR to calibrate your room
  • Start the patch 01_OpenVRDemo.v4p in the \girlpower folder to test the setup


Sources are available here:

If you encounter bugs, then github issues instead of comments are welcome:


18.01.17 [23:33 UTC] by tonfilm | 499 downloads
Fixed a important bug when vvvv was in background. updated to OpenVR 1.0.5
Show 3 older revisions

Older Revisions

03.10.16 [05:19 UTC] by tonfilm | 373 downloads
WaitGetPoses in MainLoop events, spreadable haptic pulse, color space pin for compositor
16.09.16 [14:45 UTC] by tonfilm | 103 downloads
added disable sync, trigger haptic pulse, near/far plane for camera
01.08.16 [02:27 UTC] by tonfilm | 201 downloads
initial version

StiX 01/08/2016 - 19:24

1@#!@$@#$%^$^& waaaaaaaaaa! let the dogs out!

velcrome 01/08/2016 - 19:27

so good to see this! thanks to tonfilm, and everyone involved

microdee 01/08/2016 - 20:06

how about a vveekend vvorkshop about this? who should keep it?

vasilis 01/08/2016 - 20:12

Well Done boys!! respect.

isdzaurov 02/08/2016 - 09:23

omg! cool

Noir 02/08/2016 - 11:36

well done!

screamer 02/08/2016 - 12:32


graphicuserinterface 02/08/2016 - 13:23

amazing, grand tonfilm and supporters

guest 05/08/2016 - 09:33

Thanks tonfilm,
Trying this with an Oculus DK2. Installed SDKRuntime 0.80. OR Configuration utility seems happy but OpenVR girlpower never detects HMD.

Have I missed anything?


metrowave 06/08/2016 - 00:56

GREAT...just awesome!

tonfilm 06/08/2016 - 14:20

@guest you need to calibrate oculus with SteamVR, if that's all fine vvvv will detect it. and i also think its better to use latest oculus runtime, if your graphics card is supported.

guest 06/08/2016 - 15:20

everything works fine in SteamVR/vvvv with oculus runtime 0.8 + latest Leapmotion Orion Version: 3.1.3+41910...
btw failed with the newest v1.6.0 oculus runtime (even if gtx 780ti should work)
now of course the challenging part is to make vvvv patches that runs at 75/90 fps ;)

ggml 12/08/2016 - 18:09

there seems to be a calibration delay with the latest Vive HMD,
looking at a line while moving will show two lines,
then at rest point the image becomes sharp again

seems a specific problem

u7angel 12/08/2016 - 21:47

@ggml, yeah i saw that too

mediadog 01/09/2016 - 00:03

Righteous! Works great on my Sager laptop with 2x GTX870Ms in SLI. I do see the double image on motion in the Vive HMD and not on the laptop display; I think that may be because my cards are below VR spec. @ggml and @u7angel what cards are you using? I'll try it on a desktop GTX970 and see what happens...

Thanks to all, really excellent contribution!

andresc4 05/09/2016 - 06:57

works amazing here
dk2+970+david leap nodes

andresc4 05/09/2016 - 07:04

is is possible to add any kind of 2d effect before the hmd ? like on the old dk2 wrap... ?

ggml 16/09/2016 - 18:36

@andresc4 you can translate a grid on z axis and connect it to hmd pose transform

any chance for a dx11 screenshot node for virtual patching purposes ?

ggml 17/09/2016 - 13:13

anyone managed to get the vive frontfacingcamera videotexture ?

catweasel 18/09/2016 - 18:08

The haptic pulse node seems a little odd, it only seems to work when the power is around 0.06 above that and you can hear it but not feel it, it's also quite weak, is that as high as it goes? I want a massage :)
Also the node goes red if the controller disconnects.

lari.fari 18/09/2016 - 23:14

hi all,

first of all great thanks to tonfilm and all others for bringing this to vvvv.

i am currently trying to move the controller's origin (or axis center) to another location in the controller, but no luck so far.

i edited the .obj files origin in the steam/steamapps/.../vr_controller_vive_1_5 which is used in the ViveController node, but that obviously only changes the rendered model.

i also looked at the json file in that folder but couldn't figure out if this is the right place.

if anybody could give me directions on this it would help me a lot.


guest 22/09/2016 - 10:33

Thanks tonfilm and supporters!

The Poser node is CPU intensive (8000 ticks in debug mode). I can't get a perfect 90fps with the OpenVRdemo..

When WaitForSync=0, Poser is 100 ticks, perfect 90 fps.
But I can see the double lines in motion...
The motion is perfect only with WaitForSync=1.

Any idea for a workaround or other ways to decrease the Poser CPU consemption?
What is the role of WaitForSync?

VVVV 34.2 x64
dx11 (b33.7)
HTC Vive / Direct Mode / SteamVR
NVidia 980Ti
Windows 8.1
i7-4790K 4.00Ghz
RAM 16Go

tonfilm 22/09/2016 - 14:37

you have to disable the sync of the renderer, every node that blocks the vvvv mainloop has to release its sync. so enable "Do Not Wait" on every DX11 Renderer (immediate on DX9 Renderer) and VideoTextures.

guest 25/09/2016 - 16:57

hi tonfilm,
Thanks for your answer, but I can't get good results with the OpenVRdemo at this time (it's an exageration: results are perfect, but after drawing a few lines in space, CPU is overcharged, and framerate too small...)
With this CPU budget, it's hard to develop more complex applications.

If I understand correctly (and for me it's very abstract), OpenVR use a fonction called WaitGetPoses()(the VVVV WaitForSync Poser Pin?).
This fonction seems to wait for the position of every tracked objects in the scene and it's necessary for a perfect fluidity and avoiding any judder effects.
But it has a very high CPU cost.
Seems to be a frequent OpenVR concern on Github.https://github.com/ValveSoftware/openvr/issues/64
An OpenVR user talk about rendering GetWaitPos on a specific thread to gain performance, and not to block the others CPU process.
A thing like that would be possible in VVVV?


microdee 25/09/2016 - 17:25

yo guest! I've already tried it with multiple vvvv instances, one was getting openvr data in sync, the other was rendering the scene independently. it was worse than being 45 fps synced. problem is that the presentation of the image for the vive need to be at tight exact times otherwise it will be horribly glitchy and flashing in the headset. so the problem with the vvvv implementation is that it's asking for the waiting process at node evaluation and not at right before end of the frame so you can't really have a precise idea when vvvv asks for the next available state of the vr system also if anything else is not calculating afterwards, which can make missing frames. that's the reason why it is capped at 45 fps when the patch runs at 120+ fps without the VR syncing.

+ on this topic: is there a method with vvvv plugininterfaces in which I can make sure my thing will be executed last before presentation. is already one of the Mainloop events can do that?

guest 25/09/2016 - 18:12

Hi microdee,

Thanks for your clear explanation!

So the (scary) question is:

There is no way to use Vive+VVVV without judder and/or low framerate, regardless of your hardware specs?

microdee 25/09/2016 - 21:07

currently if you want more than phong shaded boxes, it won't be a smooth experience in vvvv now but it can be improved in the future with 2 things: waiting done at right time, and as vux suggested making a proper renderer for the compositor (instead of resource pointer readback as done currently which also consumes a lot of overhead)

tonfilm 27/09/2016 - 17:46

hello guest and @microdee,

as you can read on the openvr github and steam threads about WaitGetPoses, there is no way around it. but calling it as soon or as late as possible in the frame is the next thing that will be added to the pack.

also microdee has developed a compositor node that has a DX11 texture input to avoid the resource pointer read back... i will try to merge that soon.

microdee 27/09/2016 - 19:46

@tonfilm: my compositor node is still using pointer readback it is only improving usability. vux pointed out that the fastest would be a clone of the preview node just without a forms window. when I was doing that node I didn't have much time to experiment with it unfortunately and currently I'm busy with fbx and commercial work.

tonfilm 28/09/2016 - 19:14

@microdee ok, do you know in theory how to avoid resource pointer read back, or should i contact @vux for more details?

mainloop events is in the making...

microdee 28/09/2016 - 19:39

yup contact vux. also try the syncing on different thread with WaitHandles for vvvv ;)

sebl 28/09/2016 - 20:18

@tonfilm maybe you can do the readback similar to here (https://github.com/elliotwoods/VVVV.Nodes.ReadBack) not sure this is the ideal way for reading back only 1 pointer, but at least it's threaded.

tonfilm 29/09/2016 - 19:24

@sebl that's something different... the texture data has not to go back to the CPU in that case, it's only about sending the pointer to OpenVR.

tonfilm 03/10/2016 - 05:43

@microdee and others, as of V3 the WaitGetPoses is now by default after the vvvv frame, so shortly before the next frame, which is recommended by valve. if Sync After Frame is off, the call is right before the vvvv frame. you can check what works better for your setup...

@catweasel please try haptic pulse again, i think i fixed a little bug and the node is now spreadable. it is common to trigger the pulse in multiple frames (MonoFlop or so), the power pin is the duration for one single pulse from 1 to 3999 microseconds, so max 4ms.

guest 08/10/2016 - 12:26


with SteamVr autoupdate everything goes wrong!
my DK2 rig was working perfectly with vvvv.openvr V1 with early september steamVR version.
with the new update i try every combination between SteamVR, SteamVR beta, vvvv.openvr V1/V2/V3 with no luck, no more vvvv Rendering in the headset
i've this compositor error message in vvvv:

Unsupported texture format. Make sure texture uses RGBA, is not compressed and has no mipmaps.

and SteamVr says:

(unresponsive) vvvv.exe

the vr_client_Steam log file says:

Sat Oct 08 2016 11:53:17.502 - error VRInitError_Init_LowPowerWatchdogNotSupported when initing driver oculus_legacy from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\oculus_legacy\bin\win32\driver_oculus_legacy.dll.
Sat Oct 08 2016 11:53:17.502 - Unable to init watchdog mode for driver oculus_legacy: VRInitError_Init_LowPowerWatchdogNotSupported
Sat Oct 08 2016 11:53:17.503 - error VRInitError_Init_LowPowerWatchdogNotSupported when initing driver null from C:\Program Files (x86)\Steam\steamapps\common\SteamVR\drivers\null\bin\win32\driver_null.dll.
Sat Oct 08 2016 11:53:17.503 - Unable to init watchdog mode for driver null: VRInitError_Init_LowPowerWatchdogNotSupported
Sat Oct 08 2016 11:53:17.503 - No drivers were capable of being watchdogs. Failing init.

sounds like a SteamVr issue more than a vvvv one!
any ideas


microdee 08/10/2016 - 14:49

@guest: use R8G8B8A8_UNorm (you can try sRGB variant too) texture format. only dx11

tonfilm 10/10/2016 - 03:33

the new V3 also has a color space enumeration. not all RGB formats run with all color spaces. before V3 the default format was 16-bit float, but i changed that because of performance reasons to an 8-bit format. seems the new steamVR update does not like that particular one...

lassemunk 10/10/2016 - 12:54

Hi everyone,

I'm new to vvvv,so maybe this question is very obvious, for that I am sorry.

I am trying to get my Rift DK2 to work, It works with the SteamVR calibration etc. - so far so good.

I am trying to use the example patches in the


However, when I open the demo patch, I have several 'red' (unloaded) objects.

I read the Using Adddons page, and I have gotten the impression that placing the openVR folder inside packs should be suffienct for letting vvvv see the content in all subdirectories.

Is there a setting which let me direct vvvv to the sub directories of the OpenVR 'nodes' folder?

thanks a lot! :)

tonfilm 11/10/2016 - 17:10

@lassemunk did you also install the DX11 pack from:


this needs to be besides the VVVV.OpenVR pack.

or double check whether you are starting the correct vvvv.exe, sometimes another vvvv instance is registered as the default for .v4p files. you can change this setting with the setup.exe besides vvvv.exe.

also regarding the DK2, it requires 'direct mode' to be working but most laptops with two graphics cards can't do that...

lassemunk 11/10/2016 - 18:36

Hi Tonfilm,

Thanks a lot for your answer, I think my problem was with me installing the Oculus SDK and SteamVR wrong. Anyway - after uninstalling everything and installing again it works with the newest version of oculus sdk (1.8), steamVR etc.

I should have deleted my question, but got carried away in the new good energy eager :)

Have a good evening!

mrboni 26/10/2016 - 22:57

Is it possible to disable the blue ring / grid? (I think it's called the chaperone)

everyoneishappy 27/10/2016 - 08:36

I think you can set chaperone mode and color in the steamVR settings with your remote

quaddro 27/10/2016 - 11:39

is it right that the connection to steamvr only works if the oculus patch is in focus? so if i minimize (alt+3) it, vvvv.exe "is not responding".
is there any workaround?

and furthermore, are there any more dependencies for the second girlpower patch "patch in vr"? i have a few red nodes with hard links. the title had me quiet interested, as i'm still wondering how to get my patching window into vr.

thanks in advance, huge contribution!

tonfilm 28/10/2016 - 00:04


for your fist question, there might be a solution but i have to check that... you can somewhere tell OpenVR that the application is a background application.

the patch in vr patch is only displaying the XML of a patch, you cannot interact with it really... i might remove that.

tonfilm 11/11/2016 - 22:56


OpenVR does something similar for you... i think it's currently not as good, but i read somewhere that there will be an update soon.

microdee 11/11/2016 - 23:38

yeah I think it's reprojection in openvr terms

andresc4 12/11/2016 - 01:34


I mean this
"The hardware requirements for ASW are modest. This functionality has been enabled on all current-generation AMD GPUs (RX 400 series) and previous- or current-generation Nvidia GPUs (GTX 900 or 1000 series)."

I have a 950 on a notebook and I would love to use OpenVR without my big desk pc

tonfilm 14/11/2016 - 18:27


the problem is that the specs are for desktop cards. unfortunately the mobile GTX cards have less then half of the computing performance than the desktop variants. so it's unlikely that any VR app will run smoothly on a 950M chip. my GTX 970M was barely able to drive the VR demos from valve... VR on laptops is currently no fun, also because most of them do not support direct mode, which is required for Oculus.

sunep 14/11/2016 - 18:40

@tonfilm according to nvidia, that should change with the latest 10 series GPUs, where they have dropped the mobile naming and claim that the mobile versions are within 10% of their desktop counterparts.

everyoneishappy 18/11/2016 - 07:39

I've a laptop with a 10 series card (GTX 1080) and the performance is great (with VR in general- I did have some of the performance issues in vvvv mentioned above but haven't had much of a chance to tweak things).

snipersu28 04/12/2016 - 19:57

Hey guys, how can I stream VR player on the screen with chromakey body? Like on that video:https://youtu.be/Ikz5uJ0KE3w . You see, that man is playing the game,and we also can see his body. I understand that he has something green or blue befind him, and other "VR operator" shooting him and stream it with his body? How can I do it?

screamer 06/12/2016 - 22:25

This could be a useful starting point:

dominikKoller 07/12/2016 - 20:25

Is there a solution to the post from
08/10/2016 - 11:26
Does using a 16bit texture format work?

tonfilm 07/12/2016 - 22:31

@dominikKoller yes, definitely check that.

dominikKoller 22/12/2016 - 17:14

Using a 16bit texture format didn't help..
Can't test anymore, I don't have the hardware here!

dominikKoller 22/12/2016 - 17:19

Feature request:

Inspired by Dat.Gui for WebVR:


The option to 'expose' IOBoxes to VR, to have an interface similar to the one in Dat.Gui VR!


(I'd actually love to do it myself if there's support!)

id144 18/01/2017 - 20:25

@dominikKoller with Intersect (EX9.Geometry Quad) node it is easy to get the XY coordinates of where the controller is aimed at (and create a pointer that starts at the controller and ends at the intersection point with quad). It's then easy to map interface texture onto the quad and feed the interface with XY and controller interactions. Could be a HTMLTexture (DX11) and I guess that allows you to create interactive interface and read its state.

tonfilm 19/01/2017 - 00:36

how about making the vvvv contribution anttweakbar vr compatible?

io 08/02/2017 - 19:35

Nodes are missing for the Patch in VR patch, is this supposed to be working now? Or what are you using to do some patching while wearing the vr set? I tried with the camera but it is too low res, maybe screenshooting?

EDIT: https://sourceforge.net/projects/screencapturer/files/ this one works at least so it is possible ot tweak the scene wearing the vrset.
I am really missing a zoom feature here for vvvv though...

tonfilm 09/02/2017 - 14:33

@io this patch is quite old and non functional. it was just there to display the patch. no interaction...

499reality 09/02/2017 - 16:14

I'm facing some lag in the vive headset view after installing the new version (18/01/17) at every movement, as if I'm still at 90 fps. I mean every movement duplicate the content for a short time. It creates a bad feeling and a real vr sickness. this was not the case in the previous version.
Maybe someone as some idea how to fix it?
Many thanks

tonfilm 09/02/2017 - 17:06

can you reproduce this behavior with the exact same patch and vvvv version with two different versions of the pack?

499reality 09/02/2017 - 17:35

HI tonfilm. Thanks for your reply
just made the try before to read your answer, downgraded to previous pack and relunch my patch and the issue is still there. but I did not have this behavior before ( i would obviously noticed this ). I tried to change the texture format to 16bit in the renderer but it made the "movement delay" effect worst than in 32bits.

elektromeier 09/02/2017 - 18:19

499 reality, i had the same trying the vrdemo patch in girlpower. by deleting the renderer which renders the scene in vvvv, the stutter disappeared.

499reality 09/02/2017 - 18:28

@elektromeier, many thanks for your help, just tried this and removed the renderer for preview purpose but nothing changed in the headset.
maybe the stutter was a bit faster..

mediadog 09/02/2017 - 19:00

@499reality I have always seen the same thing, but only when actually moving. If I just rotate my head everything is smooth.

I suspect that with just rotation the update is happening in the OpenVR software (it can just slide the texture while doing the next render), but a move means that whole new textures from vvvv are needed.

Are you sure you weren't seeing the smooth pan before and now seeing the rougher images during movement? If you just turn your head is it smooth?

I think movement double image does indicate there is a double-buffer problem in there somewhere though.

Also, what GPU are you using?

499reality 09/02/2017 - 19:16

i'm using nvidia gforce 1060 everything was quite perfect before.
you are right the head rotation is quite smooth and no stutter in this case, but when moving ( walking or moving the controllers) the things are going worst. it seems to be a position refresh issue, like a delay between the real position of my controller and the position received by the computer. as the effect appears bigger when moving faster.

mediadog 09/02/2017 - 19:38

@499reality Another reason I think it is a vvvv -> OpenVR buffer or frame rate issue is that when I move near the edge of the space and the "fence" pops up, the fence (being rendered by OpenVR) moves smoothly but the vvvv imagery does the double-image stutter.

mediadog 12/02/2017 - 23:20

At least with my setup, this is not only a problem with this plugin. I just tried "The Body VR", and if I set the rendering quality to high, the framerate drops, and I see the same exact double-imaging on movement. So this seems to happen when the rendering framerate drops below the Vive display rate even with Vive apps.

kalle 16/02/2017 - 18:45


since i discovered and disabled the Post Present Handoff on Compositor (OpenVR) my HTCvive runs fine with 90fps and no more ghosting. even with the headmounted Leapmotion :)

hhdev 24/04/2017 - 14:01

this pack is amazing, thanks for sharing! I've been using these nodes while prototyping my last project. i hooked up the vive with blender through osc using vvvv. for the final demo i turned towards unreal engine as the rendering features and accessibility were much more robust.


moving on to my next project i was wondering wether this pack supports the htc vive tracker by any chance?

tonfilm 25/04/2017 - 18:59

hallo @hhdev nice to hear that it helped you prototyping. the trackers should just appear in the list of tracked devices the same as the controllers. but i have never tested it personally and haven't heard form anyone who tried it. if you have them and it won't work it should be a quick fix. if you are located in berlin, as the video suggests, it would be helpful to get the tracker for an afternoon to test it...

hhdev 25/04/2017 - 21:46

hey tebjan, thanks for the reply.

i ordered one which is supposed to be delivered in early may. i'll let you know if they work out of the box. i was just curious if anyone else already gathered some experience with the trackers. in case they don't i'll get in touch with you (you are right, i'm currently doing my interaction masters degree in wei├čensee)

readme 26/04/2017 - 01:13

Tracker works out of the box as is.

tmp 09/06/2017 - 11:59

the directory paths in ViveLighthouse and ViveController nodes should be accessible as pin since not everyone chooses the default directory for installation :)

tmp 09/06/2017 - 15:18

deleting the poser node crashes vvvv all the time (with 35.7 RC)

tmp 09/06/2017 - 15:27

left and right touchpad visualization is reversed in ViveController node.

sorry for spam.. :)

dominikKoller 10/07/2017 - 16:46

Great great pack. Would be nice to install it over vpm!

ottomatic 19/07/2017 - 14:49

Is there minimum PC spec that is recommended? does it run on windows 10?


tonfilm 19/07/2017 - 15:20

hallo @ottomatic

there is rather a minimum graphics card that is recommended... any card better than NVidia GTX970 should work nicely. sure it runs on windows 10.

anonymous user login


~19min ago

StiX: @synth you sauin something about 420? if mangosh gets confirmed i am coming with him as we are in one ... package

~20h ago

synth: @evvvvil here only to do lasers, they don't let me near the screens after last time ...

~20h ago

evvvvil: hahaha yes, please sir, can I have some more sir? Hopefully me and you be battling for visual space soon, GTFOH with your lasers.

~20h ago

synth: BTW - Got 4 20w Kvant lasers here thinking of testing the ILDA nodes live :)

~20h ago

synth: @evvvvil Hell yeah! Couldn't get Vux drunk but your going to get it :D

~21h ago

evvvvil: @synth: hopefully I should be going to GEM FEST soon, not confirmed yet, but if so, beer is on you why not ;) (and me ok)

~22h ago

synth: BTW any vvvv guy coming to Georgia for GEM Festival shout out I am here for the entire thing alone. Some beer on me ;)

~22h ago

synth: @dominikKoller perfect! Count me in :)

~1d ago

dominikKoller: @synth I am! It's going to be donation/ based (or sponsored by someone) though :)

~1d ago

dominikKoller: @joreg I found it, my FF has flash disabled (by default), and those are old embeds that still use flash.