The "Why I Still Love My Oculus Rift CV1 in 2026" Thread
I've gotten slightly tired of repeating all the awesome stuff about the Oculus CV1 on Oculus Subreddit and in here - so why not try to collect all the great arguments for still using the Rift CV1 in a thread? 1. It's oled. Even with the oled mura (SPUD) Rift CV1 is still a lot darker than lcd hmds. It may not matter to all, and sure you can live just fine with lcd, but for those of us wanting to experience a really dark night in Skyrim, wanting to have true night vision in Saints and Sinners (and not constantly needing a flashlight) - and to enjoy all the very dark horror games - oled is still king. Although Rift CV1 and the original Vive aren't completely the same, they both use oled panels - and these results indicate differences in blackness comparing oled (Vive) and lcd (Index) hmds: "Black level in nits: Index: 0.153 Vive: under 0.02 with true blacks turned off via black smear compensation (default). Vive: 0 with true blacks turned on, black smear compensation disabled via running the headset in secondary display mode." https://www.reddit.com/r/ValveIndex/comments/c5sxu5/brightness_blackpoint_and_gamut_measurements_of/ In a few games, like Saints and Sinners - and Westworld Awekening - I found some very dark locations where I basically can see nothing using the Index (lcd), while I clearly can make out objects using Rift CV1. In those cases Rift CV1 provides true night vision, while lcd cannot show very poorly illuminated objects making everything vanish into a grey lcd-fog of pure nothingness 😉 That's probably why all the otherwise dark tunnels in Alyx are lit up with so many lamps, because you need light to create great blacks using lcd, and Alyx was made for lcd (Index). Also having oled or not in extremely dark games like Phantom Covert Ops is the difference of being able to see all the awesome tiny ripples and subtle reflections in the surface of the water or not. 2. Sound is second to none using the CV1, primarily the deep bass, thanks to the awesome Rift CV1 headphones. Even Index cannot provide the same bass as CV1 - at all. It's very easy to test. Try the song Embers in Pistol Whip and compare CV1 with whatever hmd you'd like. Even Index has close to no bass in that song, while the CV1 is simply perfect - the difference is close to day and night: Also the larger Oculus exclusive games took years to make, like Asgard's Wrath, Stormland, Defector and Medal of Honor: Above and Beyond. Although such games were launched when Rift-S and Quest 1-2 hmds were available, these games were primarily developed using Rift CV1 hmd. In short, if you do not use Rift CV1 for these games, you're not experiencing sound effects and music exactly like the devs intended. This may mean you're getting too much or too little bass, and that may affect immersion. Maybe casual gamers don't care about this and might even accept the extremely poor piped-audio quality of Rift-S and Quest hmds, but getting the optimal sound experience should matter to audiophiles and enthusiasts. 3. Rift CV1 Touch controllers are built like tanks. Using Oculus subreddit, the amount of photos showing broken Rift-S and Quest controllers are numerous, and there have been many statements about the poor quality of newer controllers, also including Valve Index controllers. The new Reverb G2 controllers do not get a lot of love too, but more due to design and weight distribution. Instead, old Touch are still considered the reference when it comes to quality, design and durability. Batteries may even last for months - while some never controllers (like for the Reverb G2) may eat up batteries like there's no tomorrow 😉 4. Tracking. Although having sensors is quite a hassle for those needing to set them up for each VR session, permanently placed sensors provide next to no inconvenience and provide a level of tracking probably only beaten by the base stations used for Vive and Index hmds. Having used the Valve Index for 19 months, I really do not notice much difference between CV1 and Index tracking, which is a testament to the awesome tracking provided by the CV1. Although CV1 isn't included here, Index tracking was scientifically measured to be extremely much better than what inside-out solutions provide: Results - tracking accuracy - lower scores are best (hint: Cosmos did not win ;)) https://forums.oculusvr.com/community/discussion/91998/mirror-mirror-on-the-wall-which-one-has-the-best-or-worst-tracking-of-them-all I would be very surprised if Rift CV1 is much worse than Index. Using Rift CV1 360 degrees tracking (needs at least 3 sensors) you can hold your hands on your back for as long as you'd like - you'll never lose tracking. And you can play in a totally dark room, you do not need any light for perfect tracking. Also kojack​ compared CV1 tracking here to both HP Reverb G2 and the Quest 2 - I hope he doesn't mind quoting him here: "Tracking seems fine on the (HP Reverb) G2, it just has way worse coverage. It's too easy to lose sight of the controllers below or near the headset. Hold your hands out in front and they seem ok. While moving around the WMR home scene, there's big panels to look up at and I kept the controllers at waist level. The laser pointers on the controllers made it obvious every time the position tracking dropped out when I tilted my head up a little. CV1 tracking is great, I prefer it to anything else. Q2 (Oculus Quest 2) tracking seems ok, but also has worse coverage than CV1. For example in Audica, if I try to throw the guns underarm from a resting position, they just release from my hands and float at my side, while on the CV1 they'd be thrown correctly." https://forums.oculusvr.com/community/discussion/91084/hp-reverb-g2-available-pre-orders-up-november-release-date-confirmed/p39 5. Using temporal antialiasing (TAA), which is used for DLSS, does not create a blurry image with the Rift CV1. Some may not be aware of this - and that's entirely plausible for those never having tried using an oled hmd. In games like for example MADiSON VR, Metro Awakening, Riven. Ark Park, Robinson the Journey, Asgard's Wrath and Stormland, enabling TAA or DLSS using a lcd hmd easily creates a very blurry image quality. Like having your eyes dropped with liquid butter - or something. Using TAA or DLSS with Rift CV1 you get super-sharp image quality, maybe due to the screen-door effect (SDE) fooling our brains to experience a holistic and sharp image by filling out the blanks (blanks = the black stripes between rows of lit pixels which essentially make up the SDE). Furthermore, compared to other kinds of antialiasing like MSAA, TAA or DLSS does not cost a lot of gpu performance. Having to replace TAA or DLSS with 4xMSAA (or worse) may provide ok-ish image quality by severely reducing frames per second (fps), especially when combined with high levels of super sampling (ss). 6. Some games profit from the SDE and reduced res of the Rift CV1. Although many are annoyed with the Rift CV1 due to the low res and especially the SDE, sometimes the SDE can be a friend. Using high res lcd hmds with tons of subpixels may provide clarity so far ahead of the Rift CV1 that there's really no comparison. Unfortunately such clarity may also reveal tons of flaws and shortcomings in many (older) VR games. Using high-res lcd hmds, low res textures may easily be spotted and may reduce immersion. The advantage of the Rift CV1 SDE may in many cases be like having scanlines in MAME games (MAME = Multiple Arcade Machine Emulator) - or just an interlaced image quality. Remember how some games looked on lcd monitors, when some of us switched from using CRT monitors (or TVs)? The difference in image quality using Rift CV1 or a newer high-res lcd hmd may easily be like: Image quality with scanlines (like CV1 SDE) Image quality with no scanlines (like modern high-res lcd hmds) There are many games where low-res textures look so much better thanks to the Rift CV1 SDE, while everything looks a lot more pixelated using high-res lcd hmds. Again a game like Phantom Covert Ops comes to mind - that game looks great using Rift CV1, but using Index you can easily see all the ugly low-res textures. Even a game like Arizona Sunshine looks so much better using Rift CV1 due to lack of jaggies and it's much harder to notice any low-res textures. One thing that amazed me in that game was the thorns on the cactus plants which looked very real using Rift CV1 ss 2.0, but using Index it's so easy to see the low-res 2D thorns on the plants which now looked incredibly fake and thereby broke the immersion. 7. Physical interpupillary distance (IPD) slider. With the Rift CV1 you do not just have one big panel like in Rift-S and Quest 2, but you have two separate oled panels. One for each eye that can be physically moved. This allows for simply perfect IPD adjustment (or close), covering IPDs from about 58 to 72 mm, probably only beaten by the original Vive hmds allowing for up to 73-74 mm. Rift S is more or less locked to 64 mm, while Quest 2 has three locked positions (58, 63 and 68 mm). 8. Comfort. This is a matter of individual preferences, but it's my impression that many still find the comfort of CV1 as second to none. Personally I do find CV1 comfort a lot better than the Valve Index, even though the Index is great. With the small weight of 470 grams and the way you wear the CV1 hmd, I rarely notice it's on my head when I'm using it. 9. Using high levels of super sampling, visual acuity may be a lot better than many persons seem to believe. Having tested the Rift CV1 with high levels of super sampling I found some quite surprising results. This is a comparison of how many meters you can go back from a text and still be able to read it - note that higher res provides increased ability to zoom out while still sharply seeing objects and textures: Rift CV1: Ss 1.0 = 4 meters Ss 2.0 = 6 meters Valve Index: Res 100 % = 4.5 meters Res 200 % = 6.5 meters Source: https://forums.oculusvr.com/community/discussion/91907/testhmd-fov-sde-res-super-sampling-the-rift-s-against-everything-else/p1 I consider these results quite amazing, and they prove that increasing levels of super sampling has a profound effect on Rift CV1 image quality. I've heard several CV1 users say that you don't benefit from more than ss levels 1.3 to maybe 1.5 using Rift CV1. That's why we need science and to test subjective experiences thoroughly. Properly testing the Rift CV1 there's even a noticeable difference comparing ss 2.0 and 2.5. Going from ss 2.0 to 2.5 will probably require a RTX 3080/3090 or better to get 90 fps in many games, and the difference between 2.0 and 2.5 is more subtle than going from 1.5 to 2.0. For many it may come as a great surprise that perceived sharpness and ability to read signs etc. (=visual acuity) may really not be much different using Rift CV1 ss 2.0 or Valve Index res 200% - even though persons subjectively may feel that the res is so much better using a lcd panel with tons of subpixels, like the Index. 10. Many games were made for oled hmds - thus using an oled hmd may be the only way to play these games "the way it's meant to be played". This is one issue I've become more and more aware of since I got the Index. Many games made for Rift CV1 simply don't feel "right" using other solutions than the Rift CV1. Chronos may be a nice example. Chronos plays nicely using the Valve Index, but even forcing res 200% I can still see some jaggies and pixel crawling. And the blacks, textures and colors are nice too, but seem to lack something here and there. Now, using the Rift CV1 ss 2.0 there's simply no doubt I get the vision the devs intended to provide. I no longer see jaggies, and blacks and colors look the way the should - and I no longer notice any textures I think would benefit from a slightly higher res. Same with Mage's Tale: using lcd many surfaces look fake, like made of melted plastic - gold surfaces look fake - but using Rift CV1 everything looks so much more real, even including the gold. In short, there are still many of reasons to love the old Rift CV1. Even if the competition is fierce these days, there are many games and apps where the old Rift CV1 stands tall and bows to no one. I've probably missed something - do let me know in a post below, if there're even more reasons to still love/like the Rift CV1! 🙂
85KViews27likes196CommentsUsing rift CV1 without the sensor
Hello, I'm developing a standalone app where the positional sensor isn't needed. The problem is, Oculus home won't run the exe when the sensor is not connected... is there any way to disable this requirement? We could connect sensors and hide them where the target machines are (somewhere below where the users will be sitting), but I'd rather just disable the need for a connected sensor. Any ideas?Solved11KViews0likes7CommentsIs it possible to disable all tracking?
Hi, I've spend couple days trying to find a way to disable all tracking from the HMD(so extend display mode?), but could not get a working method so far. By all tracking i mean both position and rotation, where position is simple, current SDK provide that toggle directly. I'm using Unity 5.4.0f1 as of today, and testing on both DK2 and CV1. So far I've tried every method I could find via google and forums, nothing seem to work including tricks like "zero out" rotations each frame. Using Unity's build-in camera system does not seem to allow any control of camera at all, and the OVR camera rig does not provide such function directly. I also tried the timewarp methods and it's not/no longer working. For now I'm going to take a deeper look at the camera rig and see if i could come up with something. Researched on this for days and saw all methods were for 0.6 and earlier, or everyone turned to argue about the "uncomfortable experience" by disabling the tracking, which is out of the scope in my situation. For those of whom interested in providing evidence of "uncomfortable experience", I want to achieve this because I'm using external tracking system, which provides better information than the HMD's. Having both the HMD and external tracking system makes the rotation "doubled". I'm not sure if i should post this in Oculus forum or Unity's, so maybe I'd to create a duplication over there later today if it remains unanswered.. Thank you and everyone in advance.8.6KViews0likes13CommentsWhy does my gameObject's mesh edges were flickering in Oculus?
Hello Guys, I am making a quite big world for my game in Unity for Oculus Rift. Initially when I tried my game with default settings it looked somewhat blurry and mesh edges were flickering like a hell (especially trees). So I changed RenderScale value to 2 from 1. It made huge difference in my game quality but FPS went below 60 and then I adjusted RenderScale value to 1.2 so now my game quality is okay and FPS is also okay. But the problem I'm facing now is the flickering in mesh edges. I even tried with 8x MSAA but still flickering exists. Does anyone know how to solve this. FYI : THOSE FLICKERING PROBLEM IS ONLY IN OCULUS SCREEN, PC MONITOR DOES NOT SHOW THAT MUCH FLICKERING Oculus Version : Oculus Rift CV1 Current Settings : Rendering Path -> Forward, AA -> 8x MSAA, VSync -> Disabled, Color Space -> Gamma, Stereo Rendering Method -> Single Pass. PC Specs : RAM -> 32GB, Processor -> Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz 4.00 GHz, Gfx -> NVIDIA GeForce GTX 1070 If you guys need additional Info, I will provide :smile:6.6KViews0likes9CommentsHow to get raw sensor data of Oculus with the SDK later than v1.3?
I've tried getting raw sensor data (raw acceleration, gyro, magnetometer) of my Oculus DK2 via ovrTrackingState::RawSensorData, which is wrote in the official document of SDK v0.4 to v0.8. But it seems that the section related to raw sensor data doesn't in the document of later version than 1.3. And there is no RawSensorData in ovrTrackingState. So can I get the raw sensor data of an Oculus DK2 or CV1 through the official SDK? Or can I get it from another way?5.1KViews0likes5CommentsUnity5 development and building a game error
Hi there.. when I build and package a game I have develop in unity5, it does create an exe file.. which is correct.. I have the oculus CV1.. in general setting of the oculus application I have tick the "unknown source" tab and I am trying to run my game.. On the oculus, it gives me an error called "unity.exe is taking a while to load...." is there any way to solve this.. please help.4.4KViews0likes17CommentsOculusSDK causing application crash on exit
Windows 10, Visual Studio 2010 C++ OculusSDK 1.8.0, firmware version 7.9 GeForce GTX 1070/PCIe/SSE2, OpenGL Version: 4.6.0 NVIDIA 398.11, GLSL Version: 4.60 NVIDIA It seems that something has changed just in the past few days (as of 2018-08-23) that's causing our application to crash on exit. We wrap the OculusSDK 1.8.0 in our own DLL that we load at run-time via LoadLibrary, depending on application configuration options. (The application supports various VR tracking and display environments; the Oculus Rift is one option.) As of today, the application crashes on exit, only if the OculusSDK has been opened, and only in the release build; the debug build does not crash. This happens whether or not we explicitly call FreeLibrary for our DLL at program exit. The OculusSDK logs these status messages in our console window: [ At startup, we open with ovr_Initialize (nullptr) ] 23/08 19:07:20.832 {INFO} [Kernel:Default] [CAPI] LibOVR module is located at C:\Program Files\Oculus\Support\oculus-runtime\LibOVRRT64_1.dll 23/08 19:07:20.835 {INFO} [Client] Connected to the server running version (prod = 1).1.29.0(build = 651191) feature version = 0. Client runs version (prod = 1).1.29.0(build = 0) feature version = 0 23/08 19:07:20.838 {DEBUG} [Kernel:Default] [HMDState] Using default profile default 23/08 19:07:20.838 {INFO} [Kernel:Default] IAD changed to 64.2mm 23/08 19:07:20.839 {DEBUG} [SharedMemory] Creating factory 23/08 19:07:22.178 {DEBUG} [D3D11_CliCompositorClient] CliD3D11CompositorClient::initialize 1 23/08 19:07:22.220 {DEBUG} [KMTSyncObject] Creating KMTHandle 0x0d2fc4d0 23/08 19:07:22.222 {DEBUG} [KMTSyncObject] Creating KMTHandle 0x0d2fc610 23/08 19:07:22.222 {DEBUG} [KMTSyncObject] KMTHandle::Create hDevice=0x80000380 23/08 19:07:22.222 {DEBUG} [KMTSyncObject] KMTHandle::Create hContexts[0] = 2147485504 23/08 19:07:22.222 {DEBUG} [KMTSyncObject] KMTHandle::Create hContexts[1] = 2147485824 23/08 19:07:22.286 {DEBUG} [D3D11_CliCompositorClient] CliD3D11CompositorClient::addGLRef 2 23/08 19:07:23.552 {INFO} [Kernel:Default] [HMDState] Detected the active window handle changed to 111af0ll 23/08 19:07:28.635 {WARNING} [Tracking:Filter] Prediction interval too high: 0.101367 s, clamping at 0.100000 s [ The application runs well, with a good frame rate. I can move and resize the on-screen mirror window. Everything renders well in the Rift and on-screen. The test scene averages well over 100 frames per second, so the initial high prediction interval seems to be a startup fluke. ] [ At exit, we close with ovr_Destroy (m_Session) and ovr_Shutdown() ] 23/08 19:07:31.115 {DEBUG} [D3D11_CliCompositorClient] CliD3D11CompositorClient::release 2 23/08 19:07:31.117 {DEBUG} [D3D11_CliCompositorClient] CliD3D11CompositorClient::release 1 23/08 19:07:31.117 {DEBUG} [D3D11_CliCompositorClient] Unblocking monitored fence 23/08 19:07:31.121 {INFO} [Kernel:System] Graceful shutdown: OnThreadDestroy 23/08 19:07:31.121 {INFO} [Kernel:System] Graceful shutdown: OnSystemDestroy 23/08 19:07:31.121 {DEBUG} [SharedMemory] Destroying factory 23/08 19:07:31.121 {DEBUG} [Kernel:Default] [Client] Disconnected 23/08 19:07:31.121 {INFO} [Kernel:System] Graceful shutdown: Stopping logger At program exit, it dies in the Windows function __tmainCRTStartup(void) (in crtexe.c): A problem caused the program to stop working correctly. All of our C++ wrapper class close and d'tor functions appear to return successfully. I have wrapped the entire body of our main function in try {} catch() {}, but it fails to catch this exception. I have put a 10-second sleep just before the program exit, but that merely delays the crash; it does not avoid it. The console messages and the crash are all new behavior that I did not see (or notice) just a few days ago. The crash is definitely a new behavior. This application has not changed during that time. Judging from those console messages, it seems that maybe some Oculus resource isn't shutting down properly -- and that maybe somebody has been struggling with that. The fact that it crashes in the release build, but not the debug build, suggests that maybe something has not been initialized properly (e.g., to zero). Maybe the debug build initializes it; or maybe the lower degree of optimization avoids some memory corruption. Maybe there's a dangling reference to SharedMemory. Maybe the logging itself is causing the crash. I did not request logging, and in fact tried to explicitly disable it with ovrInitParams init_params = { 0, 0, nullptr, 0, 0 }; ovr_Initialize (&init_params) but the logging messages still appear in the console window. The appearance of the logging messages correlates with the crash-at-exit behavior: they're both new. Please advise. Thanks. -- Ted Hall <twhall@umich.edu>Solved3.9KViews0likes5CommentsWashed out (double gamma correction) on OpenGL
No matter which swapchain format I specify, my OpenGL application always renders washed out. That implies that OpenGL always thinks it is rendering to a linear render target, while OpenXR always thinks I am submitting an sRGB render target. Changing the swapchain format that I ask OpenXR to create between sRGB and linear makes no difference, and neither does glEnable(GL_FRAMEBUFFER_SRGB).3.1KViews1like4CommentsAny downsides to using OpenVR vs native Oculus SDK?
I am helping develop a VR project. We currently have separate Vive and Rift implementations. Vive uses OpenVR and Rift uses Oculus SDK. Is there any downside to using OpenVR for the Rift as well? Is performance worse, do we loose the Oculus audio SDK? Also will this restrict us in the future as Oculus update their SDK? (We are developing in Unity 5)Solved3KViews0likes3Comments