I get that not many folks are into VR now, and that derivative can’t justify a lot of developer work if there is not much demand for it from users. So I am wondering about options. The Oculusrift TOP in my current project is the biggest villain in my current project and is knocking my frame rate from 60 to _35 fps right now. Is there anyway an individual like me can see inside this component and perhaps experiment to customize it myself to see if there is any way to improve it and optimize it perhaps with some fast POPS or maybe modified GLSL?
It is stretched on both CPU and GPU cook time in my current project, as you can see from the pix. Yes I know my geometry is a bit heavy, but it’s all pretty much vector graphics with lines and points and should not really be much of a load compared to pbr rendering etc..
Ben, Markus, Greg, Vincent and all - any way I can speed up this TOP by myself or with a good programmer? If it’s all C++ I would definitely need outside help…. but I am willing to try…
I will try every trick in Ben’s TDSW optimization talk….
Any way to get inside this if it is built in touch designer?
There isn’t any SOP/POP or heavy GLSL related work in that node to change or optimize. It’s complexity involves interfacing with the VR device and dealing with it’s swapchain. There really isn’t a pathway right now to create a Custom OP that can interface with the VR, since we don’t have a Vulkan workflow in the C++ TOP yet. You could do it with CUDA→DirectX I suppose, but that’s a few extra copy operations and would be tricky.
One thing that’s important with VR is to have your FPS set to the FPS of your VR headset, and make sure you are running in Perform Mode with VSync turned off in the Window COMP
Thanks for responding Malcolm. Sorry I know nothing about swapchains or CUDA-Direct X programming and have forgotten most of my C stuff from way back. Too bad POPS can’t help this. I know the warnings go away when I run at 72 fps for Quest 3 but in practice it actually works pretty well at 60 fps and I have not seen much visual difference even with light networks that run fine at full 72 or 60 fps. I have not tried turning off Vsync in the Window COMP but will do so.
Is some of this oculusrift TOP built in touch designer like other operators? Or is it all C++ stuff way over my head? Do you think there is room for any improvement in the near future? Or do I just have to suck it up and wait until more users request it?
All of the operations in TD are built using C++ at the core. One thing to check is, does your project run at 72FPS when its doing everything except the Oculus Rift TOP isn’t active? If the project isn’t running at full speed due to it hitting the GPU/CPU limits, then the high cook times on the Oculus Rift TOP are expected
OK thanks Malcolm. I understand they are mainly C++, which is beyond my current skill level alas.
Yes after a day of optimizing I got it to run at full 72 fps and even 90 fps without the Oculus Rift TOP. It is pretty clear from Probe, performance monitor and every test Ben Voight showed in his TSWG 3 hr talk on optimizing (all of which I implemented to debug this) that the Oculus Rift TOP was THE big problem. It’s not a total stopper as I can do some non real time rendering later without it for my VR pieces but I use it all the time to develop the pieces. Once I have something nice in VR I like, I go on to render higher res stuff with Realtime flag off for MovieFileOut.
But honestly, I am sure others would also benefit from a more efficient node. Everything in TD looks so great in true stereoscopy in VR! I can’t believe more people are not enjoying 3D stereo….
Ok not sure if this will help without the kinect and audio files etc but this is one I optimized that runs at 73 fps with Quest3 on the head and if you turn off OculusRift cooking hits 90 fps on my i9 RX 4080.
PS if you change timeline frame rate to 90, load in 2025.31760 (this file was after I went to 60 fps so just change it back to 90 to see test and affect of HOG chop = CPU limited in this file…
PPS you have to be wearing the headset (mine is Meta Quest3) and watching VR to see the frame rate I am talking about.
This is what Perplexity AI says and it matches my experience that it will run happily at many frame rates with 72 not reporting any warning in touch. I would like to get 72 fps but cannot always achieve it with very complex heavy TD scenes. Which is why I am hoping the oculusrift TOP can be updated and improved and maybe renamed to metaquest TOP while you are at it since oculus and rift are both deprecated names.
Here is the finished piece on YouTube for reference - please set for 2160 (4k) which I recorded at 60 fps yesterday after downgrading everything to simple vector graphics and points to get it to run ok on Quest3: https://www.youtube.com/watch?v=9MgEo2qv2DY
If you have a VR headset please try to watch with it. If not, you can do look-around 2D on a pc or mac. But you usually have to stop and specifically set to 4K to watch. A few days after upload, YouTube sometimes will properly show it as 8K. It takes them a long time to process. An hour or two after upload it will only show as HD res….
Did another test this morning and if I turn on Render Timing pop up in headset on oculusrift TOP it does say Compositor Frame Rate is 72.0 Hz (even if I run TD program at 60 fps). Compositor GPU time varies 7.4-7.6ms . Latency timing TW to mid photon in 33.5 ms if that helps. Setting TD to 72 fps on timeline did not seem to change anything.
I tried that and did not seem to make perceivable difference in headset. But when recording and tweaking content I usually run with network visible for adjustments and turn off all viewers I don’t need and use Window comp for separate window. That has worked for me fine for years….
How do I check framerate or modify my settings etc for VRpiece in perform mode for VR?
Sorry I think I’m still unclear on the issue. Are you saying the project runs at 72FPS, but you think the headset is stuck at 72Hz refresh rate and are looking for how to increase it to 90Hz or 120Hz?
Sorry Malcolm. Not exactly. I don’t think it is feasible to run my complex projects at 90 or 120 Hz as my current one cannot even make 60 fps. With simple networks on my i9 RTX 4080 I have achieved 90 fps. The oculus rift top is the biggest hog in my current project- consuming ~ 17 ms CPU cook time and 9-10 GPU cook time at the quest3 resolution of 20264 x 2272 at 60 Hz. The other blocks in my network consume 0.143 ms for control chops, 1.2 ms CPU and 2-3ms GPU for my kinect & videos, audio analysis, playback 1ms CPU and .1 ms GPU, and my heavy VR geometry ~ 2ms CPU and 4-5 ms GPU.
So, my main point is the oculus rift TOP is the heaviest of the bunch by far and I was simply requesting this be looked at for possible performance improvements. The Quest3 itself is watchable from project frame rates of 36 fps (at this point right now) to 90 or more as I have seen in small simple networks.
I am not asking you to do anything but consider improving efficiency of oculus render TOP in future, if possible. It is very heavy on cook time as I have seen with over 50+ VR projects. Thank you for your consideration. I am sorry to hear it is not feasible for users to get inside and customize it at their own risk. But thanks for your time - sorry to bother you.
Hey, certainly not a bother. The reason I’m asking these questions is because VR display is done differently than other outputs, so the cook time when looking at a v-synced network editor really doesn’t tell you much. This is because the Oculus/Meta driver may be stalling the thread to align the presentation/cook phase with the refresh phase of the output device.
The only time you can measure performance of a VR system is in Perform Mode with v-sync disabled, with the timeline FPS set to match the device’s refresh rate. This ensures that there aren’t multiple places trying to sync (the window vsync vs the VR vsync vs the timeline). In that mode, put a FPS counter up on the display and that is the true measure of your performance.
The cook time of the Oculus nodes isn’t necessarily ‘the work they are doing’, but is rather them waiting for other work to be completed on the GPU. If the GPU is overloaded, then the stall will be likely recorded in that node. It’s possible there is a bug in that node, but it really doesn’t do much work. I just does an image copy to the device’s swapchain so the image can be displayed. There isn’t anything to ‘optimize’ really.
In your case you can observing this because the Oculus TOP doesn’t do any more work for a heavy file vs a lighter file. So a longer cook time when the file is heavier is because the GPU is causing the Oculus TOP to stall. It’s not because the Oculus TOP itself is slow.
Ok thanks Malcolm I think I get most of that. So it is all down to optimizing everything else in my network then, right? And I should build a little UI so I always run in perform mode and trigger stuff there instead of tweaking stuff in my network while watching on a second monitor with window comp or in my headset itself - correct? Can you remind me how to put up an FPS counter in perform mode? I can’t remember how to do that. Thanks.
If you are playing back video you can just overlay a Text TOP ontop of the video. If you are looking at a 3D scene then place the FPS counter on a rectangle floating in the scene somewhere. You can also parent the geo to your camera so it sticks with you.
Ok thanks for the tip Malcolm. I did that and it is identical in Perform mode - 36-37 fps in VR in the headset. No different than running with my network while watching VR with same perform chop. Here’s a geo for any other newbies - put a perform chop at root level for the text top inside.
Ok thanks for checking that. It’s a better workflow to use going forward. Will help with false positives.
So for this case the next question is what happens if you reduce the GPU load. Such as reducing the resolution or anti-alias level of the Render TOPs. Does that affect the performance?
