Skip to content
Snippets Groups Projects

WIP: Feature/#294 untangle hmd open vr

Closed WIP: Feature/#294 untangle hmd open vr
feature/#294_Untangle_HMD_OpenVR into develop
2 unresolved threads
Closed Jan Delember requested to merge feature/#294_Untangle_HMD_OpenVR into develop
2 unresolved threads

This is not necessarily finished, and may be just a proposal going forward (depending on the scope of the issue). Tell me what you think.

The phx::HMD was essentially split into its OpenVR functionality (phx::OpenVRUnit) and the head representation (phx::Head), which can also be used in a CAVE or a Non-OpenVR HMD implementation (the head representation doesn't actually do a lot, and I don't know how much sense this makes, as, e.g., its transformation would probably be accessed via a head entity). Similar things could/should be done with controllers, etc., although this also has to be revamped when we "solve" input.

phx::OpenVRUnit could also be generalized into an HMDUnit that is derived from, but I don't see us implementing Non-OpenVR-based HMD support any time soon.

@jwendt @mbellgardt

Edited by Jan Delember

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
library/phx/display_system.cpp
61 61 return window_.get();
62 62 }
63 63
64 phx::HMD* DisplaySystem::CreateHMD() {
65 if (hmd_ == nullptr) {
66 hmd_ = std::make_unique<HMD>();
64 phx::OpenVRUnit* DisplaySystem::CreateOpenVRUnit() {
65 if (openvr_system_ == nullptr) {
66 openvr_system_ = std::make_unique<OpenVRUnit>();
  • Jan Delember marked as a Work In Progress

    marked as a Work In Progress

    By Sebastian Freitag on 2018-01-11T12:46:38 (imported from GitLab)

    • Jan Delember
      Jan Delember @delember
      Author

      I think the main problem that has to be addressed with the OpenVRUinit is the fact that it is such an almighty class that captures all the functionality of OpenVR. In my view it would be a good first step to split the functionality into several classes. At least the following functionality should be independent in my view:

      • Viewports (getting dimensions, pushing images)
      • Tracking (Head and controllers)
      • Accessing the controller models

      Then we might need a new way to make this information accessible in the places where it is needed.

      As discussed in the meeting, we could also go down the route of creating a system that handles all the OpenVR specific functionality and essentially enables the OpenVR HMD by being present. One would need to come up with ways to communicate with the other systems in a generalized fashion, so the other systems can do their job without worrying about HMDs. One example is the abstraction of rendering targets. The rendering system does not need to care about how the render targets are being used, if it has all the parameters necessary to render to them. This should not be too difficult to detangle.

      By Martin Bellgardt on 2018-01-12T13:04:48 (imported from GitLab)

  • Jan Delember closed

    closed

    By Sebastian Freitag on 2018-01-22T15:45:49 (imported from GitLab)

    • Please register or sign in to reply