# OpenVR problems with VTK 9.2

**URL:** <https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992>\
**Category:** VR/AR\
**Created:** [March 16, 2023, 2:44pm UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992 "2023-03-16T14:44:10Z")\
**Posts on this page:** 11\
**Page:** 2

<div class="post-metadata">

**Author:** ![codeling](https://discourse.vtk.org/user_avatar/discourse.vtk.org/codeling/32/3792_2.png) [@codeling](https://discourse.vtk.org/u/codeling)\
**Post date:** [November 6, 2023, 2:22pm UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/21 "2023-11-06T14:22:02Z")

</div>

Just tested, the last problems with wrong clipping seem to be fixed in VTK 9.3 (latest release candidate rc2)!

The above example program runs nicely, except for a few errors in the console:

```auto
vtkOpenGLFramebufferObj:356 ERR| vtkOpenGLFramebufferObject (000001419E3E3D40): failed at glDeleteFramebuffers 16 OpenGL errors detected

```

**Edit - Correction:** The near plane clipping problem is not yet fully fixed, but it has improved somewhat - the volume in the example code above is shown correct until the HMD gets close to the volume borders. When very close or in the volume, the clipping plane is quite far away from the eyes (nearly on the opposite side of the volume, but at least not in the wrong direction anymore).

---

<div class="post-metadata">

**Author:** ![LucasGandel](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lucasgandel/32/1831_2.png) [@LucasGandel](https://discourse.vtk.org/u/LucasGandel)\
**Post date:** [November 23, 2023, 12:32pm UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/22 "2023-11-23T12:32:33Z")

</div>

@codeling Thanks a lot for the feedback. I think this is the corresponding VTK issue : [https://gitlab.kitware.com/vtk/vtk/-/issues/19123](https://gitlab.kitware.com/vtk/vtk/-/issues/19123).  
There I proposed a fix, but did not open any MR as I thought something cleaner could be done. However, this might be better than the current bug for now if you want to open a MR for it, I’ll be happy to review.

---

<div class="post-metadata">

**Author:** ![codeling](https://discourse.vtk.org/user_avatar/discourse.vtk.org/codeling/32/3792_2.png) [@codeling](https://discourse.vtk.org/u/codeling)\
**Post date:** [January 17, 2024, 3:00pm UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/23 "2024-01-17T15:00:22Z")

</div>

Just tested with git master (specifically, ff92d0720f), and the near clipping plane issues that I described above are gone (probably due to [https://gitlab.kitware.com/vtk/vtk/-/merge\_requests/10783](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10783) having been merged?).

---

<div class="post-metadata">

**Author:** ![LucasGandel](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lucasgandel/32/1831_2.png) [@LucasGandel](https://discourse.vtk.org/u/LucasGandel)\
**Post date:** [January 17, 2024, 3:07pm UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/24 "2024-01-17T15:07:34Z")

</div>

I confirm the camera near plane clipping issue was fixed in [VTK!10783](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10783). It might also help with the `RemoveCuller` workaround, I would be curious to see if the “right eye” issue is also fixed by this MR.

---

<div class="post-metadata">

**Author:** ![codeling](https://discourse.vtk.org/user_avatar/discourse.vtk.org/codeling/32/3792_2.png) [@codeling](https://discourse.vtk.org/u/codeling)\
**Post date:** [January 18, 2024, 2:39pm UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/25 "2024-01-18T14:39:27Z")

</div>

> [@LucasGandel](#):
>
> It might also help with the `RemoveCuller` workaround, I would be curious to see if the “right eye” issue is also fixed by this MR.

Your intuition is right - the workaround is not required anymore!

---

<div class="post-metadata">

**Author:** ![LucasGandel](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lucasgandel/32/1831_2.png) [@LucasGandel](https://discourse.vtk.org/u/LucasGandel)\
**Post date:** [January 19, 2024, 7:29am UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/26 "2024-01-19T07:29:11Z")

</div>

This is an awesome news! Thank you so much for testing, this is very helpful!

---

<div class="post-metadata">

**Author:** ![codeling](https://discourse.vtk.org/user_avatar/discourse.vtk.org/codeling/32/3792_2.png) [@codeling](https://discourse.vtk.org/u/codeling)\
**Post date:** [April 19, 2024, 6:59am UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/27 "2024-04-19T06:59:36Z")

</div>

Does anybody know whether [the merge mentioned above](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10783) has any chance of making it into the next VTK release (probably 9.3.1, right?)? I tried to check in git but am not sure how to determine this… is there an easy way to determine the commit with which the request was merged? and what is the branch that will turn into version 9.3.1 - probably “release”?

---

<div class="post-metadata">

**Author:** ![mwestphal](https://discourse.vtk.org/user_avatar/discourse.vtk.org/mwestphal/32/19_2.png) [@mwestphal](https://discourse.vtk.org/u/mwestphal)\
**Post date:** [April 19, 2024, 7:04am UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/28 "2024-04-19T07:04:49Z")

</div>

Yes: [https://gitlab.kitware.com/vtk/vtk/-/merge\_requests/10854](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10854)

> and what is the branch that will turn into version 9.3.1 - probably “release”?

Yes, if a 9.3.1 is released.

---

<div class="post-metadata">

**Author:** ![codeling](https://discourse.vtk.org/user_avatar/discourse.vtk.org/codeling/32/3792_2.png) [@codeling](https://discourse.vtk.org/u/codeling)\
**Post date:** [October 22, 2024, 1:02pm UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/29 "2024-10-22T13:02:19Z")

</div>

Testing our application with VTK 9.3.1 and vtk master (decd60aaf1f975d9264a9fd05445d60eaee1d6c9), I still noticed culling issues; with 9.3.1, the right eye is still blank; under master, under some circumstances (for some viewing positions), some actors completely disappear - but only from the **left eye** this time.

The workaround [as proposed above](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/15), namely `renderer->RemoveCuller(renderer->GetCullers()->GetLastItem());`, makes things work in both cases!

Haven’t had chance to try and reproduce with a small example program, I doubt I’ll have time in the next weeks, but I’d thought I’d report it here anyway, maybe somebody else has an idea of how to “really” fix it instead of a workaround…?

---

<div class="post-metadata">

**Author:** ![LucasGandel](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lucasgandel/32/1831_2.png) [@LucasGandel](https://discourse.vtk.org/u/LucasGandel)\
**Post date:** [October 23, 2024, 6:53am UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/30 "2024-10-23T06:53:18Z")

</div>

Thanks @codeling for following up on this. From your previous posts I understood that the MR mentioned above is fixing the need for the RemoveCuller workaround. Now it’s not true anymore? It would be great to try the merge commit ([  
e6aeaedf](https://gitlab.kitware.com/vtk/vtk/-/commit/e6aeaedf6c6a801d3c2f25a26d8204e97a0b2c42)) of the MR to double-check and see if a regression was introduced in 9.3.1 and master after that.

---

<div class="post-metadata">

**Author:** ![codeling](https://discourse.vtk.org/user_avatar/discourse.vtk.org/codeling/32/3792_2.png) [@codeling](https://discourse.vtk.org/u/codeling)\
**Post date:** [October 23, 2024, 8:07am UTC](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992/31 "2024-10-23T08:07:00Z")

</div>

> [@LucasGandel](#):
>
> From your previous posts I understood that the MR mentioned above is fixing the need for the RemoveCuller workaround. Now it’s not true anymore?

Seems that way, yes. Though I don’t remember if back then I extensively tested our application with a VTK version with that MR applied; I just put the workaround in there (as we typically use release versions of VTK, and there wasn’t one yet with the MR applied), with a preprocessor check for more recent VTK versions; so now when I tested with vtk master where the preprocessor check disabled the workaround, it popped up.

> [@LucasGandel](#):
>
> It would be great to try the merge commit ([e6aeaedf](https://gitlab.kitware.com/vtk/vtk/-/commit/e6aeaedf6c6a801d3c2f25a26d8204e97a0b2c42)) of the MR to double-check and see if a regression was introduced in 9.3.1 and master after that.

If I find the time I’ll do that, thanks for the hint!

[Previous page](https://discourse.vtk.org/t/openvr-problems-with-vtk-9-2/10992.md?page=1)