VIVE video freezing meanwhile TD rendering well on monitors

Using first gen HTC Vive headset and Build 2020.26630. Diving back into VR this week, after long hiatus, and the headset video would freeze when the openVR Out TOP was nested in a container, so I had to split panes to leave the top viewer visible on screen at all times. Today it only seems to load a single frame of the and remains frozen no matter what I do. (Weirdly, headset receives the frozen frame before TD splash screen even shows up.)

Also lots of crashes with no dump nor autosave…

Any ideas of fixes or test cases? Best software version parings? I’m a bit rusty on SteamVR voodoo.

Thanks,

_Will

Update: I was able to find a dumb-dumb-hack way to get things going for the sake of meeting my deadline, but it is not ideal. I had to use an OP Viewer TOP on an OpenVR CHOP and composite that under the content that supplies monitor display during perform mode… which is very silly, thus I am hoping someone has an idea why/how this became necessitated.

Is there some under-the-hood handshake/heartbeat between the OpenVR CHOPs/TOPs and the SteamVR software that is opaque to the typical TouchDesigner workflow/programmer which could be disrupted by OPs going into some resource saving mode when not viewed in edit mode?

Windows 10 Pro, 64bit, v 1903, build 18362.1016
TouchDesigner 64bit Commercial , build 2020.26630
SteamVR, v 1.14.16 (1600466902)

Also having a lot of tearing/judder/distortions as the POV rotates/translates around the scene. Any ideas?

We’ll try to take a look soon, thanks for the report.

Hey Will!

Are you using the TDVR system from the Palette. I just tested that system here and everything seems fine for me on the HTC Vive Gen1.

I remember specifically trying ViveSimple and ViveRender, and probably a few others from Palette. Always needed editor window to be within the same component as the active OpenVR OPs. The initial solution was to just copy the guts a Palette example into the main project component to keep things moving… I like mega-patch programming anyway :man_shrugging:

When it came time for Perform Mode I realized the problem persisted, hence my ending up with the OP Viewer trick.

One non-standard facet of the project was that I decoupled POV from tracking, for “VR on rails” experience. In tinkering toward the goal, I noticed that bypassing or locking various OpenVR CHOPs would freeze the VR display output.