DE112021003189T5 - Auf mobileinheit basierende vr-steuerung - Google Patents

Abstract

Die vorliegende Offenbarung betrifft ein Steuern von Virtual-Reality-Inhalt (VR-Inhalt), der auf einem am Kopf angebrachten VR-Display (VR-HMD) angezeigt wird. Es kann ein Datenaustausch zwischen einem Computersystem, einem VR-HMD und einer Mobileinheit eingerichtet werden. Auf der Mobileinheit kann eine Benutzereingabe empfangen werden, die dafür konfiguriert ist, VR-Inhalt zu steuern, der auf einem Display des VR-HMD angezeigt wird. Der auf dem HMD angezeigte VR-Inhalt kann dann basierend auf der Benutzereingabe gesteuert werden, die auf der Mobileinheit empfangen wird.

Description

• HINTERGRUND
• Die vorliegende Offenbarung betrifft allgemein das Gebiet der Virtual Reality und insbesondere das Steuern von Virtual-Reality-Systemen unter Verwendung von Mobileinheiten.
• Virtual-Reality-Systeme (VR-Systeme) simulieren virtuelle Umgebungen unter Verwendung von Computertechnologie. VR-Systeme stellen Benutzern Sensordaten (z.B. Audiodaten und visuelle Daten) bereit, so dass die Benutzer eine immersive Umgebung wahrnehmen. VR-Systeme umfassen typischerweise ein am Kopf angebrachtes Display (Head Mounted Display, HMD), welches ein Benutzer aufsetzen kann, um eine simulierte Umgebung zu visualisieren. Die simulierte Umgebung kann der echten Welt ähneln oder vollständig fiktional sein.
• KURZDARSTELLUNG
• Ausführungsformen der vorliegenden Offenbarung betreffen ein Verfahren, ein System und ein Computerprogrammprodukt zum Steuern von Virtual-Reality-Inhalt (VR-Inhalt), der auf einem am Kopf angebrachten VR-Display (HMD) angezeigt wird. Es kann ein Datenaustausch zwischen einem Computersystem, einem VR-HMD und einer Mobileinheit eingerichtet sein. Eine Benutzereingabe, die dafür konfiguriert ist, VR-Inhalt zu steuern, der auf einem Display des VR-HMD angezeigt wird, kann auf der Mobileinheit empfangen werden. Der auf dem VR-HMD angezeigte VR-Inhalt kann dann basierend auf der Benutzereingabe gesteuert werden, die auf der Mobileinheit empfangen wird.
• Es ist nicht beabsichtigt, dass die obige Kurzdarstellung jede veranschaulichte Ausführungsform oder jede Realisierung der vorliegenden Offenbarung beschreiben soll.
• Figurenliste
• Die in der vorliegenden Offenbarung enthaltenen Zeichnungen sind in die Beschreibung integriert und bilden einen Teil davon. Sie veranschaulichen Ausführungsformen der vorliegenden Offenbarung und dienen zusammen mit der Beschreibung dazu, die Prinzipien der Offenbarung zu erläutern. Die Zeichnungen veranschaulichen lediglich typische Ausführungsformen und beschränken die Offenbarung nicht.
• 1 zeigt eine VR-Umgebung, in welcher veranschaulichende Ausführungsformen der vorliegenden Offenbarung realisiert werden können.
• 2 zeigt ein Blockschaubild einer beispielhaften Datenverarbeitungsumgebung, in welcher veranschaulichende Ausführungsformen der vorliegenden Offenbarung realisiert werden können.
• 3 ist ein Ablaufplan, welcher einen Prozess zum Steuern einer Virtual Reality unter Verwendung einer Mobileinheit gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
• 4 ist eine bildliche Darstellung, welche verschiedene Steuerungen veranschaulicht, die verwendet werden können, um Virtual-Reality-Inhalt gemäß Ausführungsformen der vorliegenden Offenbarung zu steuern.
• 5 ist ein Schaubild, welches eine Cloud-Computing-Umgebung gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
• 6 ist ein Blockschaubild, welches Abstraktionsmodellschichten gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
• 7 ist ein übergeordnetes Blockschaubild, welches ein beispielhaftes Computersystem, das beim Realisieren eines oder mehrerer der hierin beschriebenen Verfahren, Tools und Module und aller zugehörigen Funktionen benutzt werden kann, gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
• Obwohl die hierin beschriebenen Ausführungsformen für verschiedene Modifikationen und alternative Formen offen sind, sind spezielle Einzelheiten davon beispielhaft in den Zeichnungen dargestellt worden und werden detailliert beschrieben. Es versteht sich jedoch, dass die bestimmten Ausführungsformen, die beschrieben werden, nicht als beschränkend anzusehen sind. Es sollen stattdessen alle Modifikationen, Äquivalente und Alternativen abgedeckt sein, die unter den Umfang der Offenbarung fallen.
• DETAILLIERTE BESCHREIBUNG
• Aspekte der vorliegenden Offenbarung betreffen allgemein das Gebiet der Virtual Reality und insbesondere das Steuern von Virtual-Reality-Systemen unter Verwendung von Mobileinheiten. Obwohl die vorliegende Offenbarung nicht notwendigerweise auf solche Anwendungen beschränkt ist, können verschiedene Aspekte der Offenbarung durch eine Erörterung verschiedener Beispiele unter Verwendung dieses Kontexts verstanden werden.
• Virtual-Reality-Systeme (VR-System) simulieren virtuelle Umgebungen unter Verwendung von Computertechnologie. VR-Systeme umfassen gewöhnlich ein am Kopf angebrachtes Display (HMD), welches einem Benutzer, der das HMD aufgesetzt hat, neben anderen Daten visuelle Sensordaten bereitstellt. Ein VR-System wie OCULUS RIFT^® oder HTC VIVE^® umfasst typischerweise Steuereinheiten, welche derart in den Händen eines Benutzers gehalten werden können, dass sie mit der VR-Umgebung interagieren können. Die Steuereinheiten können während der VR-Nutzung als die Hände des Benutzers dienen, wodurch ermöglicht wird, dass der Benutzer Objekte oder Ansichten innerhalb der VR-Umgebung manipuliert.
• Steuereinheiten, die zu VR-Systemen gehören, sind jedoch typischerweise teuer. Ferner können einige Steuereinheiten viele Steuertasten und/oder Steuertechniken umfassen, bei denen es für einen Benutzer schwierig sein kann, mit ihnen vertraut zu werden. Dies kann das VR-Erlebnis des Benutzers behindern. Außerdem vermehren spezielle VR-Steuereinheiten nur die Hardware, die zu einem VR-System gehört, welche bereits mehrere Sensoren (zum Verfolgen), ein HMD, ein Computersystem und notwendige Kabel und Anschlüsse zum Verbinden der zugehörigen Komponenten umfassen kann. Daher besteht ein Bedarf für eine Lösung, welche spezielle VR-Steuereinheiten ersetzen kann und welche intuitive Funktionalitäten zum Steuern von VR-Inhalt bereitstellt.
• Aspekte der vorliegenden Offenbarung betreffen Verfahren zum Steuern von Virtual-Reality-Inhalt (VR-Inhalt), der auf einem am Kopf angebrachten VR-Display (HMD) angezeigt wird. Es kann ein Datenaustausch zwischen einem Computersystem, einem VR-HMD und einer Mobileinheit eingerichtet sein. Eine Benutzereingabe, die dafür konfiguriert ist, VR-Inhalt zu steuern, der auf einem Display des VR-HMD angezeigt wird, kann auf der Mobileinheit empfangen werden. Der auf dem VR-HMD angezeigte VR-Inhalt kann dann basierend auf der Benutzereingabe gesteuert werden, die auf der Mobileinheit empfangen wird.
• Indem ermöglicht wird, dass Benutzer VR-Inhalt über Mobileinheiten steuern, können statt spezieller VR-Steuereinheiten, bei denen es für Benutzer schwierig sein kann, damit vertraut zu werden, intuitive Steuerungen, die auf einer Mobileinheit basieren und an die Benutzer bereits gewöhnt sind, benutzt werden, um den VR-Inhalt zu steuern. Ferner können Benutzer, anstatt zusätzliche Hardware erwerben zu müssen, einfach die Mobileinheiten, die sie regelmäßig benutzen, mit einem VR-System verbinden, um das VR-System zu steuern. Außerdem wird der Bereich der Steueroptionen auf Grundlage der Eingaben erweitert, die für die verbundene Mobileinheit verfügbar sind. Beispielsweise können Steuerungen wie In-Air-Steuerungen, Steuerungen auf Drehringbasis, Berührungssteuerungen und Bewegungssteuerungen benutzt werden, um VR-Inhalt zu steuern, anstatt auf die Steuermechanismen beschränkt zu sein, die für eine spezielle VR-Steuerung verfügbar sind.
• Nun Bezug nehmend auf die Figuren, ist 1 ein Schaubild, welches eine beispielhafte Virtual-Reality-Umgebung (VR-Umgebung) 100 gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht. Die Virtual-Reality-Umgebung 100 umfasst ein am Kopf angebrachtes VR-Display (HMD) 105, welches zum Datenaustausch mit einem Computersystem 110 verbunden ist. Ein VR-Benutzer 115 benutzt aktiv das VR-HMD 105 und steuert die VR-Nutzung (z.B. ein VR-Spiel) unter Verwendung eines Smartphones 120 (z.B. Steuereinheit 215-1 der 2) und einer Smartwatch 125 (z.B. Steuereinheit 215-2 der 2).
• Vor dem Benutzen des VR-HMD 105 kann der VR-Benutzer 115 die VR-Umgebung 100 einrichten. Anfangs kann der VR-Benutzer 115 benötigte VR-Software auf dem Computersystem 110 installieren und eine Datenaustauschverbindung zwischen dem Computersystem 110, dem VR-HMD 105, einem ersten Sensor 130 und einem zweiten Sensor 135 konfigurieren. Nach dem Starten der VR-Software auf dem Computersystem 110 kann der VR-Benutzer 115 zu einer Raumeinrichtung aufgefordert werden. Durch die Raumeinrichtung kann sichergestellt werden, dass das VR-HMD basierend auf Eigenschaften des VR-Benutzers 115 richtig kalibriert ist (z.B. eine richtige Größe und eine richtige Blickrichtung) und dass der VR-Benutzer 115 nicht mit in der Nähe befindlichen Objekten zusammenstößt. Die Raumeinrichtung kann ein Anzeigen der Position des Bodens, der Größe des Benutzers und der Richtung umfassen, in die der Benutzer 115 während der VR-Nutzung ausgerichtet sein wird.
• Die Raumeinrichtung kann ferner Definieren einer VR-Grenze 140 umfassen. Die VR-Grenze 140 kann definiert werden, um sicherzustellen, dass der VR-Benutzer 115 nicht mit stationären Objekten in dem Raum zusammenstößt. Dies kann absolviert werden, indem die VR-Grenze 140 dem VR-Benutzer 115 angezeigt wird, während er das VR-HMD 105 nutzt, so dass der VR-Benutzer 115 innerhalb der VR-Grenze 140 bleibt und nicht mit in der Nähe befindlichen Objekten (z.B. in der Nähe befindlichen Möbeln, einem Fernsehgerät oder einer Arbeitsplatte) zusammenstößt. In Ausführungsformen kann es sein, dass die VR-Grenze 140 nur angezeigt wird, während sich der Benutzer bewegt (z.B., um die Verwirrung auf ein Mindestmaß zu beschränken, wenn er in die VR-Umgebung eingetaucht ist).
• Nach dem Konfigurieren der VR-Umgebung 100 kann der VR-Benutzer 115 das VR-HMD 105 aufgesetzt haben und die VR-Nutzung (das VR-Spiel) beginnen. Die Sensoren 130 und 135 können so konfiguriert sein, dass sie den VR-Benutzer 115 verfolgen, wenn er in die VR eingetaucht ist. Beispielsweise können die Sensoren 130 und 135 das VR-HMD 105, das Smartphone 120 und die Smartwatch 125 verfolgen, um eine Aktualisierung der Position des VR-Benutzers 115 innerhalb der Virtual Reality zu ermöglichen. Ferner können die Sensoren 130 und 135 die Verfolgung des VR-HMD 105, des Smartphones 120 und der Smartwatch 125 nutzen, um die Position des VR-Benutzers in Bezug auf die VR-Grenze 140 zu bestimmen. Dies kann genutzt werden, um den VR-Benutzer 115 zu warnen, wenn er sich der VR-Grenze 140 nähert, um ein Zusammenstoßen mit in der Nähe befindlichen Objekten zu verhindern.
• In Ausführungsformen können die Steuerungen (z.B. Steuerungen auf Berührungsbasis, auf Drehringbasis, auf Bewegungsbasis und In-Air-Steuerungen) des Smartphones 120 und der Smartwatch 125 verwendet werden, um die VR-Nutzung zu steuern. Somit können das Smartphone 120 und die Smartwatch 125 so betrieben werden, dass sie Objekte oder Blickwinkel innerhalb eines VR-Spiels manipulieren. Beispiele für Steuerungen, die unter Verwendung des Smartphones 120 und der Smartwatch 125 absolviert werden können, umfassen Anvisieren (z.B. Bewegen einer Kameraansicht eines Benutzers aus der Perspektive des Benutzers), Verschieben (z.B. Neupositionieren einer Draufsicht auf eine Karte auf virtueller Basis, Bewegen einer Kameraansicht entlang einer horizontalen Ebene), Handlungsausführung (z.B. Bewirken einer Interaktion mit Objekten) Zoomen, Fortbewegung und andere. Ferner können das Smartphone 120 und die Smartwatch 125 die Hände des VR-Benutzer 125 (oder eine virtuelle Einheit) innerhalb eines virtuellen Spiels emulieren. Beispielsweise kann das Smartphone 120 benutzt werden, um die Bewegungen der rechten Hand des Benutzers zu steuern, und die Smartwatch 125 kann benutzt werden, um Bewegungen der linken Hand des Benutzers zu steuern.
• Es sei angemerkt, dass 1 die repräsentativen Hauptkomponenten einer beispielhaften VR-Umgebung 100 abbilden soll. In einigen Ausführungsformen können jedoch einzelne Komponenten eine größere oder geringere Komplexität aufweisen, als in 1 dargestellt, es können andere Komponenten als die in 1 dargestellten oder zusätzliche zu diesen vorhanden sein und die Anzahl, die Art und die Konfiguration solcher Komponenten können variieren. Somit kann die Konfiguration des Systems variieren und Aspekte der vorliegenden Offenbarung sind nicht auf eine bestimmte beschriebene Einrichtung beschränkt. Beispielsweise kann in Ausführungsformen die VR-Umgebung 100 nur das Smartphone 120 und nicht die Smartwatch 125 umfassen. Ausführungsformen können mehr oder weniger Sensoren umfassen. In Ausführungsformen können zusätzliche Display-Einheiten innerhalb der VR-Umgebung 100 vorhanden sein (z.B. kann ein Monitor VR-Inhalt spiegeln, der auf dem VR-HMD 105 angezeigt wird).
• Nun übergehend zu 2, ist dort ein Blockschaubild dargestellt, welches eine beispielhafte Datenverarbeitungsumgebung 200 veranschaulicht, in welcher veranschaulichende Ausführungsformen der vorliegenden Offenbarung realisiert werden können. Die Datenverarbeitungsumgebung 200 umfasst ein VR-HMD 205, eine erste Steuereinheit 215-1, eine zweite Steuereinheit 215-2 (zusammenfassend als Steuereinheiten 215 bezeichnet), mindestens ein Computersystem 235, einen Sensor 260 und ein Netzwerk 250.
• Die Steuereinheiten 215 und das Computersystem 235 umfassen einen oder mehrere Prozessoren 220-1, 220-2 (zusammenfassend als Prozessoren 220 bezeichnet) und 240 bzw. einen oder mehrere Speicher 225-1, 225-2 (zusammenfassend als Speicher 225 bezeichnet) und 245. Ferner können das VR-HMD 205 und der Sensor 260 jeweils einen oder mehrere Prozessoren und Speicher (nicht dargestellt) umfassen. Die Steuereinheiten 215 und das Computersystem 235 sind so konfiguriert, dass sie über interne oder externe Netzwerk-Schnittstellen 230-1, 230-2 (zusammenfassend als Netzwerk-Schnittstellen 230 bezeichnet) und 240 miteinander Daten austauschen. Die Netzwerk-Schnittstellen 210 und 240 sind in einigen Ausführungsformen Modems oder Netzwerk-Schnittstellenkarten. Ferner können das VR-HMD 205 und der Sensor 260 jeweils eine oder mehrere Netzwerk-Schnittstellen (nicht dargestellt) zum Ermöglichen eines Datenaustausches über das Netzwerk 250 umfassen. Die Steuereinheiten 215 und/oder das Computersystem 235 können mit einem Display ausgestattet sein. Außerdem können die Steuereinheiten 215 und/oder das Computersystem 235 optionale Eingabeeinheiten (z.B. eine Tastatur, eine Maus, einen Scanner, eine Videokamera usw.) und/oder eine beliebige kommerziell erhältliche oder individuelle Software (z.B. Browser-Software, Datenaustausch-Software, Server-Software, Software zum Verarbeiten natürlicher Sprache, Suchmaschinen- und/oder Web-Crawling-Software, VR-Software usw.) umfassen.
• In Ausführungsformen können die Steuereinheiten 215 Mobileinheiten sein, die benutzt werden, um die VR-Nutzung zu steuern. Beispielhafte Mobileinheiten umfassen Smartphones, Tablets und am Körper tragbare Einheiten. Das Computersystem 235 kann eine VR-bereite Maschine sein, die dafür konfiguriert ist, VR-Programme zu laden und auszuführen, eine VR-Graphikwiedergabe durchzuführen und eine VR-Spielverarbeitung durchzuführen. Somit kann VR-Inhalt unter Verwendung der Prozessorleistung des Computersystems 235 auf einem Display 210 des VR-HMD 205 angezeigt werden. Der Sensor 260 kann ein Positionierungssystem 265 umfassen, welches dafür konfiguriert ist, Komponenten innerhalb der Datenverarbeitungsumgebung zu lokalisieren. Beispielsweise kann das Positionierungssystem 265 dafür konfiguriert sein, die Steuereinheiten 215, das VR-HMD 205 und das Computersystem 235 unter Verwendung von Indoor-Positionierungssystemtechnologien (z.B. Positionierungssystemen auf Wi-Fi-Basis, Positionierungssystemen auf Bluetooth-Basis, Ankunftswinkel, Ankunftszeit, Empfangssignalstärke-Anzeige (Received Signal Strength Indication, RSSI) und anderen) zu lokalisieren. Durch Verfolgen von Einheiten, die zu der Datenverarbeitungsumgebung 200 gehören, können basierend auf den physischen Bewegungen von Einheiten entsprechende Positionsanpassungen innerhalb eines VR-Spiels simuliert werden.
• Die Steuereinheiten 215, das VR-HMD 205, der Sensor 260 (zusammenfassend als „Einheiten“ bezeichnet) und das Computersystem 235 können voneinander entfernt sein und über das Netzwerk 250 Daten austauschen. In einigen Ausführungsformen kann das Computersystem 235 ein zentraler Knoten sein, von welchem Einheiten eine Datenaustauschverbindung einrichten können, z.B. in einem Client-Server-Netzwerkmodell. Alternativ können das Computersystem 235 und Einheiten in einer beliebigen anderen geeigneten Netzwerkbeziehung konfiguriert sein (z.B. in einer Peer-to-Peer-Konfiguration (P2P-Konfiguration) oder unter Verwendung einer beliebigen anderen Netzwerktopologie).
• Das Netzwerk 250 kann unter Verwendung einer beliebigen Anzahl an geeigneten Datenaustauschmedien realisiert werden. Beispielsweise kann das Netzwerk 250 ein Weitverkehrs-Netzwerk (WAN), ein lokales Netzwerk (LAN), ein Internet oder ein Intranet sein. In bestimmten Ausführungsformen können die Einheiten und das Computersystem 235 lokal zueinander sein und über ein beliebiges geeignetes lokales Datenaustauschmedium Daten austauschen. Beispielsweise können die Einheiten und das Computersystem 235 unter Verwendung eines lokalen Netzwerks (LAN), einer oder mehrerer festverdrahteter Verbindungen, einer drahtlosen Verbindung (z.B. Bluetooth^®) oder eines Routers oder eines Intranet Daten austauschen. In einigen Ausführungsformen können die Einheiten und das Computersystem 235 unter Verwendung einer Kombination eines oder mehrerer Netzwerke und/oder einer oder mehrerer lokaler Verbindungen zum Datenaustausch verbunden sein. Beispielsweise kann das VR-HMD 205 mit dem Computersystem 235 festverdrahtet sein (z.B. über HDMI- und/oder USB-Verbindungen), während der Sensor 260 unter Verwendung einer drahtlosen Verbindung wie Bluetooth mit dem Computersystem 235 Daten austauschen kann.
• In einigen Ausführungsformen wird das Netzwerk 250 innerhalb einer Cloud-Computing-Umgebung oder unter Verwendung eines oder mehrerer Cloud-Computing-Dienste realisiert. Gemäß verschiedenen Ausführungsformen kann eine Cloud-Computing-Umgebung ein verteiltes Datenverarbeitungssystem auf Netzwerkbasis umfassen, welches einen oder mehrere Cloud-Computing-Dienste bereitstellt. Ferner kann eine Cloud-Computing-Umgebung viele Computer (z.B. hunderte oder tausende Computer oder mehr) umfassen, die innerhalb eines oder mehrerer Rechenzentren angeordnet sind und dafür konfiguriert sind, Ressourcen über das Netzwerk 250 gemeinsam zu nutzen.
• Die erste Steuereinheit 215-1, die zweite Steuereinheit 215-2 und das Computersystem 235 umfassen die VR-Anwendungen 227-1, 227-2 bzw. 247 (zusammenfassend als „VR-Anwendungen“ bezeichnet). Die VR-Anwendungen können dafür konfiguriert sein, verschiedene Funktionalitäten bereitzustellen, so dass unter Verwendung von Einheiten innerhalb des Systems ein VR-Spiel realisiert werden kann. Die VR-Anwendung 247 des Computersystems 235 kann dafür konfiguriert sein, VR-Spiele/Apps zu laden und auszuführen, Überwachung, Kopplung und Aktualisierungen (z.B. Firmware-Aktualisierungen) der Steuereinheiten 215-1 und 215-2, des VR-HMD 205 und des Sensors 260 durchzuführen, Regeln für den „Spielbereich“ (z.B. sitzend, stehend, Raummaßstab usw.) bereitzustellen, welchen ein Benutzer bei der VR-Nutzung in Anspruch nimmt, und Einstellungsänderungen (z.B. für Graphikeinstellungen wie Supersampling und Bewegungsglättung, Audioeinstellungen und Layout-Einstellungen) zu ermöglichen, die von einem Benutzer vorgenommen werden.
• Die VR-Anwendungen 227-1 und 227-2 können dafür konfiguriert sein, Funktionalitäten bereitzustellen, so dass die Steuereinheiten 215-1 und 215-2 VR-Spiele steuern können. Das heißt, die Steuereinheiten 215-1 und 215-2 können Benutzereingaben empfangen und die Benutzereingaben an das Computersystem 235 senden, so dass VR-Spiele (angezeigt auf dem VR-HMD 205) gesteuert werden können. In Ausführungsformen stellt die VR-Anwendung 247 Aktualisierungen der VR-Anwendungen 227-1 und 227-2 bereit, so dass Einheiten, welche die Steuereinheiten 215-1 und 215-2 emulieren, richtig konfiguriert sind, um die VR-Nutzung zu steuern (z.B. eine gegebene Eingabe zu einer gewünschten Ausgabe führt).
• Beispiele für Eingaben, die verwendet werden können, um die VR-Nutzung zu steuern, umfassen Interaktionen auf Berührungsbasis (z.B. interagiert ein Benutzer mit einem berührungsempfindlichen Bildschirm auf einer Mobileinheit), Interaktionen auf Kippbewegungsbasis (z.B. kippt ein Benutzer eine Einheit, was zu einer entsprechenden Steuerung führt), Interaktionen auf Trägheitsbasis (z.B. bewegt ein Benutzer eine Einheit, was zu einer entsprechenden Steuerung führt), Interaktionen auf Drehringbasis (z.B. interagiert ein Benutzer mit einem Drehringabschnitt einer Mobileinheit, vgl. Steuerungen auf Drehringbasis 460 der 4) und In-Air-Interaktionen (z.B. interagiert ein Benutzer in der Luft über eine Mobileinheit, was von Kameras oder Sensoren (der Mobileinheit oder einer separaten Einheit) aufgenommen und in eine entsprechende Ausgabe übersetzt werden kann). Beispiele für Ausgaben, basierend auf den empfangenen Eingaben erreicht werden können, umfassen Handlungsausführung (z.B. Interagieren mit einem Objekt innerhalb der VR, wie z.B. Aufheben eines Gegenstands), Anvisieren, Bewegen, Verschieben, Zoomen, Fortbewegung und andere innerhalb der Virtual Reality.
• Obwohl 2 eine Datenverarbeitungsumgebung 200 mit einem einzigen Computersystem 235 veranschaulicht, können geeignete Datenverarbeitungsumgebungen zum Realisieren von Ausführungsformen der vorliegenden Offenbarung eine beliebige Anzahl an Computersystemen umfassen. Die verschiedenen Modelle, Module, Systeme und Komponenten, die in 2 veranschaulicht sind, können, falls überhaupt, über eine Mehrzahl von Computersystemen und Einheiten vorhanden sein. Beispielsweise können solche Ausführungsformen zwei Computersysteme umfassen. Die zwei Computersysteme können unter Verwendung einer beliebigen geeigneten Datenaustauschverbindung (z.B. unter Verwendung eines WAN, eines LAN, einer drahtgebundenen Verbindung, eines Intranet oder des Internet) zum Datenaustausch verbunden sein.
• Es sei angemerkt, dass 2 die repräsentativen Hauptkomponenten einer beispielhaften Datenverarbeitungsumgebung 200 abbilden soll. In einigen Ausführungsformen können jedoch einzelne Komponenten eine größere oder geringere Komplexität aufweisen, als in 2 dargestellt, es können andere Komponenten als die in 2 dargestellten oder zusätzliche zu diesen vorhanden sein und die Anzahl, die Art und die Konfiguration solcher Komponenten können variieren. Somit kann die Konfiguration des Systems variieren und Aspekte der vorliegenden Offenbarung sind nicht auf eine bestimmte beschriebene Einrichtung beschränkt. Beispielsweise kann in einigen Ausführungsformen das Computersystem 235 mit dem VR-HMD 205 integriert sein.
• Nun Bezug nehmend auf 3, ist dort ein beispielhafter Prozess 300 zum Steuern von VR-Inhalt, der auf einem VR-HMD angezeigt wird, unter Verwendung einer Mobileinheit gemäß Ausführungsformen der vorliegenden Offenbarung dargestellt.
• Der Prozess 300 beginnt bei der Operation 305, wo ein Datenaustausch zwischen einem Computersystem, einem VR-HMD, (gegebenenfalls) einem Sensor und einer Mobileinheit eingerichtet wird. Es können beliebige Datenaustauschtechniken, die in Bezug auf das Netzwerk 250 der 2 beschrieben sind, verwendet werden, um die oben erwähnten Komponenten zu verbinden. In Ausführungsformen können eine oder mehrere festverdrahtete Verbindungen zwischen Einheiten innerhalb des Systems eingerichtet werden. Beispielsweise kann eine HDMI- und/oder eine USB-Verbindung dafür konfiguriert sein, das Computersystem mit dem VR-HMD zu verbinden (z.B. um eine schnelle Übertragung von Graphikdaten zu ermöglichen). In Ausführungsformen kann eine drahtlose Verbindung zwischen dem Computersystem, den Mobileinheiten und den Sensoren eingerichtet werden (welche z.B. eine Indoor-Positionierung sowie eine Datenübertragung ermöglicht).
• Anschließend wird bei der Operation 310 eine Raumeinrichtung durchgeführt. In Ausführungsformen kann die Raumeinrichtung eine Benutzerverfolgung (z.B. unter Verwendung einer Mobileinheit) umfassen, wobei eine Grenze einen Bereich definiert, wo die VR-Nutzung sicher ist. Diese Grenze kann dem Benutzer dann während der VR-Nutzung angezeigt werden, was dem Benutzer ermöglicht, sich frei innerhalb der Grenze zu bewegen, ohne mit in der Nähe befindlichen Objekten zusammenzustoßen. In einigen Ausführungsformen kann die Raumeinrichtung Kennzeichnen einer Still-Stehen- oder einer Sitzkonfiguration umfassen, in welcher angenommen wird, dass sich ein Benutzer nicht bewegt, wodurch die Notwendigkeit einer VR-Grenze umgangen wird. In diesen Ausführungsformen kann die Raumeinrichtung Kennzeichnen eines stationären Punkts und Bestimmen einer Höhe des VR-HMD und des Bodenniveaus (z.B. über IPS-Verfolgung) umfassen, so dass das virtuelle Spiel richtig angezeigt werden kann.
• Anschließend wird ein VR-Programm gestartet. Dies wird bei der Operation 315 veranschaulicht. Es kann ein beliebiges geeignetes VR-Programm gestartet werden, umfassend Videospiele, Karten- und Navigationsanwendungen, Kunstanwendungen, Wortverarbeitungsanwendungen und andere. Das Starten des VR-Programms kann bewirken, dass das VR-HMD beginnt, Daten anzuzeigen, wie von dem Computersystem verarbeitet.
• Das Verfolgen des VR-HMD und der Mobileinheit unter Verwendung des Sensors beginnt dann bei der Operation 320. Das Verfolgen kann ein Anwenden der IPS-Technologie zum Lokalisieren der Position des VR-HMD und der Mobileinheit in Echtzeit umfassen. Dies kann genutzt werden, um die Position des VR-HMD und der Mobileinheit innerhalb der Virtual Reality zu aktualisieren. Dies kann ferner genutzt werden, um die Position eines Benutzers in Bezug auf eine virtuelle Grenze zu verfolgen, um zu verhindern, dass der Benutzer mit Objekten zusammenstößt.
• Anschließend wird eine Benutzereingabe von einem Benutzer auf der Mobileinheit empfangen. Dies ist bei der Operation 325 dargestellt. Die Benutzereingabe kann von dem Computersystem empfangen und verwendet werden, um das VR-Spiel zu steuern, während der Benutzer in die VR eingetaucht ist. Beispiele für Eingaben, die verwendet werden können, um die VR-Nutzung zu steuern, umfassen Interaktionen auf Berührungsbasis, Interaktionen auf Bewegungsbasis, Interaktionen auf Drehringbasis und In-Air-Interaktionen.
• In Ausführungsformen kann das Display auf der Mobileinheit innerhalb der virtuellen Umgebung gespiegelt werden, um dem Benutzer zu helfen, Steueroptionen auszuwählen. Wenn beispielsweise eine GUI eines berührungsempfindlichen Bildschirms auf der Mobileinheit angezeigt wird, aber für den Benutzer nicht sichtbar ist (da der Benutzer ein VR-HMD aufgesetzt hat), kann die GUI des berührungsempfindlichen Bildschirms in die virtuelle Umgebung gespiegelt werden, so dass der Benutzer die verfügbaren Steueroptionen auf der GUI des berührungsempfindlichen Bildschirms innerhalb der Virtual Reality sehen kann. In einigen Ausführungsformen kann der Inhalt, der auf der Mobileinheit angezeigt würde, nur in der Virtual Reality angezeigt werden, da es nicht notwendig ist, ihn außerhalb der Virtual Reality zu betrachten.
• VR-Inhalt, der auf dem VR-HMD angezeigt wird, wird dann basierend auf der Benutzereingabe gesteuert. Dies ist bei der Operation 330 veranschaulicht. Beispiele für Steuerungen, die basierend auf den empfangenen Eingaben erreicht werden können, umfassen Handlungsausführung (z.B. Interagieren mit einem Objekt innerhalb der VR, wie z.B. Aufheben eines Gegenstands), Anvisieren, Bewegen, Verschieben, Zoomen und andere innerhalb der Virtual Reality.
• Die vorstehend erwähnten Operationen können in beliebiger Reihenfolge absolviert werden und sind nicht auf die beschriebenen beschränkt. Außerdem können einige, alle oder keine der vorstehend erwähnten Operationen absolviert werden, ohne vom Umfang der vorliegenden Offenbarung abzuweichen.
• Nun Bezug nehmend auf 4, ist dort eine bildliche Darstellung dargestellt, welche verschiedene Steuerungen 400 veranschaulicht, die gemäß Ausführungsformen der vorliegenden Offenbarung verwendet werden können, um VR-Inhalt zu steuern, der auf einem VR-HMD angezeigt wird. Die Steuerungen 400 umfassen Berührungssteuerungen 410, Bewegungssteuerungen 440, Steuerungen auf Drehringbasis 460 und In-Air-Steuerungen 470.
• Die Berührungssteuerungen 410 sind allgemein als Steuerungen definiert, welche basierend auf einer Berührungseingabe ausgelöst werden können, die auf einem berührungsempfindlichen Bildschirm empfangen wird. Es kann ein beliebiger geeigneter berührungsempfindlicher Bildschirm verwendet werden, umfassend resistive, Oberflächenschallwellen- und kapazitive berührungsempfindliche Bildschirme. Es können verschiedene Berührungssteuerungen realisiert werden und die dargestellten sollen nicht andere mögliche Berührungssteuerungen beschränken, die realisiert werden können. Die Berührungssteuerungen 410 umfassen neben anderen Arten Tippsteuerungen 415, Berührungs-Wählscheibensteuerungen 420, Ziehsteuerungen 425 und Zusammenzieh/Auseinanderzieh-Steuerungen 430.
• Die Tippsteuerungen 415 sind Steuerungen, welche in Reaktion auf ein Tippen auf einen berührungsempfindlichen Bildschirm ausgelöst werden, das von einem Benutzer empfangen wird. Die Tippsteuerungen 415 können verwendet werden, um mit Objekten innerhalb der Virtual Reality zu interagieren (z.B. kann ein Tippen auf einen Bildschirm zu einer entsprechenden Handlung führen, wie z.B. „Aufheben“ eines Gegenstands). Die Tippsteuerungen 415 können ferner verwendet werden, um innerhalb der Virtual Reality zu zoomen (z.B. kann ein Tippen oder ein Doppeltippen zu einem Zoom-Vorgang führen). Die Tippsteuerungen 415 können außerdem verwendet werden, um eine oder mehrere Ansichten innerhalb der Virtual Reality zu ändern. Als ein Beispiel kann basierend auf der Position auf dem berührungsempfindlichen Bildschirm, wo das Tippen registriert wird, die Ansicht innerhalb der VR geändert werden. In einigen Ausführungsformen können die Tippsteuerungen 415 verwendet werden, um die VR-Fortbewegung zu steuern. Beispielsweise können die Tippsteuerungen 415 verwendet werden, um eine flüssige Bewegung oder eine Teleportationsbewegung innerhalb der Virtual Reality zu erzeugen.
• Die Berührungs-Wählscheibensteuerungen 420 sind eine Art von Steuerungen, welche eine digitale Wählscheibe auf dem berührungsempfindlichen Bildschirm einer Einheit erzeugen. Die Position der Berührung des Benutzers entlang der digitalen Wählscheibe führt zu einer bestimmten Ausgabe. Beispielsweise kann die digitale Wählscheibe verschiedene Optionen umfassen, die entlang dem Umfang der Wählscheibe angeordnet sind. Als ein Beispiel kann es eine erste Steuerung C₁ bei 0 Grad auf der Wählscheibe, eine zweite Steuerung C₂ bei 90 Grad auf der Wählscheibe, eine dritte Steuerung C₃ bei 180 Grad auf der Wählscheibe und eine vierte Steuerung C₄ bei 270 Grad auf der Wählscheibe geben. Wenn in diesem Beispiel die Wählscheibe durch die Berührung des Benutzers bei 90 Grad kontaktiert wird, kann die zweite Steuerung C₂ ausgewählt werden. Somit können Berührungs-Wählscheibensteuerungen besonders nützlich sein, wenn versucht wird, aus einer Mehrzahl von Optionen auszuwählen (z.B. Elementen in einem Bestand, Steuerungen auf einem Steuerfeld usw.). In Ausführungsformen kann die Berührungswählscheibe innerhalb der Virtual Reality angezeigt werden, um bei der Benutzersteuerung zu helfen, da es hilfreich sein kann, die Berührungswählscheibe zu sehen.
• Die Ziehsteuerungen 425 umfassen Eingaben, welche basierend auf einer Ziehbewegung empfangen werden, die auf einem berührungsempfindlichen Bildschirm vorgenommen wird. In Ausführungsformen können die Ziehsteuerungen 425 verwendet werden, um Ansichten innerhalb der Virtual Reality zu steuern. Beispielsweise können Ziehsteuerungen zum Anvisieren und zum Verschieben verwendet werden. In Ausführungsformen können die Ziehsteuerungen 425 auch für die VR-Fortbewegung von Nutzen sein. Zum Beispiel können die Ziehsteuerungen 425 für eine „Zug“-Fortbewegung verwendet werden (z.B. führt ein Ziehen der Welt der Virtual Reality in Reaktion auf eine Ziehsteuerung zu einer Verschiebung des Benutzers innerhalb der Virtual Reality). In Ausführungsformen können die Ziehsteuerungen 425 zum Scrollen (z.B. auf einer virtuellen Scroll-Leiste) durch eine Liste verfügbarer Optionen verwendet werden. Die Ziehsteuerungen 425 können auch verwendet werden, um Objekte innerhalb der VR zu steuern/zu manipulieren. Die Ziehsteuerungen 425 können jedoch auch in einer beliebigen anderen geeigneten Art und Weise verwendet werden.
• Die Zusammenzieh/Auseinanderzieh-Steuerungen 430 umfassen Eingaben, welche basierend auf zwei Kontaktpunkten eines berührungsempfindlichen Bildschirms, die berührt und anschließend aufeinander zu oder auseinander bewegt werden, empfangen werden. Wie in den Zusammenzieh/Auseinanderzieh-Steuerungen 430 der 4 abgebildet, umfasst eine Zusammenziehsteuerung, dass zwei Kontaktpunkte auf dem berührungsempfindlichen Bildschirm näher zusammen bewegt werden, während eine Auseinanderziehsteuerung umfasst, dass zwei Kontaktpunkte voneinander weggezogen werden. Zusammenzieh/Auseinanderzieh-Steuerungen können zum Zoomen innerhalb der Virtual Reality verwendet werden (z.B. führt ein Zusammenziehen zu einem Herauszoomen, während ein Auseinanderziehen zu einem Heranzoomen führt). Jedoch können Zusammenzieh/Auseinanderzieh-Steuerungen auch in einer beliebigen anderen geeigneten Art und Weise verwendet werden. Beispielsweise kann eine Zusammenziehsteuerung für eine Vorwärts-Fortbewegung innerhalb der Virtual Reality verwendet werden, während eine Auseinanderziehsteuerung für eine Rückwärts-Fortbewegung innerhalb der Virtual Reality verwendet werden kann.
• Die Bewegungssteuerungen 440 beziehen sich allgemein auf Eingaben, welche in Reaktion auf bestimmte Bewegungen von Mobileinheiten erzeugt werden, die vorgenommen werden. Diese umfassen neben anderen Arten von Bewegungssteuerungen 440 Kippsteuerungen 445 und Trägheitssteuerungen 450. Die Kippsteuerungen 445 können in Reaktion auf ein Ändern eines Winkels einer Mobileinheit erzeugt werden (z.B. Kippen der Einheit nach oben, nach unten, nach links oder nach rechts). In Ausführungsformen kann ein Kippsensor wie z.B. ein Beschleunigungsmesser oder ein Gyroskop verwendet werden, um ein Kippen der Einheit zu erfassen. In Ausführungsformen können die Kippsteuerungen zum Anvisieren (z.B. Ändern eines Blickwinkels aus der Ich-Perspektive oder der Perspektive eines Dritten) innerhalb der Virtual Reality verwendet werden. Beispielsweise kann der Blick innerhalb der VR direkt die Orientierung der Mobileinheit spiegeln. In Ausführungsformen können Kippsteuerungen zum Lenken verwendet werden (z.B. in virtuellen Racing-, Flug- und Bootfahr-Spielen). In Ausführungsformen können Kippsteuerungen zum Realisieren einer Handlungsausführung verwendet werden. Beispielsweise kann ein Kippen der Mobileinheit zum Durchführen einer bestimmten Handlung (z.B. Sprinten) innerhalb der VR führen. Jedoch können die Kippsteuerungen 445 auch in einer beliebigen anderen geeigneten Weise verwendet werden.
• Die Trägheitssteuerungen 450 können in Reaktion auf eine vorgenommene Bewegung einer Einheit erzeugt werden. In Ausführungsformen kann die Bewegung der Einheit unter Verwendung eines Beschleunigungsmessers und/oder eines Gyroskops erfasst werden. Die Trägheitssteuerungen 450 können zum Ändern von Blickwinkeln (z.B. Anvisieren und Verschieben) auf Grundlage der Bewegung der Mobileinheit verwendet werden. Ferner können die Trägheitssteuerungen zur Handlungsausführung verwendet werden (z.B. führt eine bestimmte Bewegung zu einer bestimmten Handlung, wie z.B. „Springen“). In Ausführungsformen können die Trägheitssteuerungen verwendet werden, um eine Bewegung von Handlungen der linken und der rechten Hand eines VR-Benutzers zu steuern. Das heißt, die Bewegung der Mobileinheiten (z.B. gehalten in der linken und der rechten Hand) kann zu entsprechenden Bewegungen innerhalb der Virtual Reality führen.
• Die Steuerungen auf Drehringbasis 460 umfassen Steuerungen, welche eine Eingabe in Reaktion auf eine Interaktion mit einem Bereich erzeugen, der nicht auf dem berührungsempfindlichen Bildschirm einer Mobileinheit enthalten ist (z.B. einem Drehringabschnitt). Gewöhnliche Steuerungen auf Drehringbasis umfassen eine Interaktion mit einer „Home“-Taste (abgebildet in den Steuerungen auf Drehringbasis 460 der 4), eine Interaktion mit einer „Sperr“-Taste, eine Interaktion mit Lautstärkesteuerungen und andere. Obwohl die Steuerungen auf Drehringbasis 460 nicht auf dem Abschnitt des berührungsempfindlichen Bildschirms einer Mobileinheit enthalten sind, können sie dennoch Eingabesteuerungen auf Berührungsbasis umfassen. Beispielsweise umfassen „Home“-Tasten auf Smartphones typischerweise Berührungssensoren, so dass Berührungssteuerungen verwendet werden können. Unter Verwendung von Steuerungen auf Drehringbasis können verschiedene Steuerungen absolviert werden. Wenn beispielsweise der Drehringabschnitt einer Smart-Einheit eine „Home“-Taste mit einem Touchpad umfasst, können die oben beschriebenen Berührungssteuerungen 410 unter Verwendung der „Home“-Taste absolviert werden. Die Steuerungen auf Drehringbasis 460 können neben anderen Steuerungsoptionen zum Ändern von Blickwinkeln, zur Handlungsausführung und zur Fortbewegung verwendet werden.
• Die In-Air-Steuerungen 470 umfassen Steuerungen, welche in Reaktion auf eine bestimmte Geste (z.B. Hand- oder Körpergesten), die über dem Bildschirm einer Mobileinheit gemacht wird, eine Eingabe erzeugen. Die In-Air-Steuerungen 470 nutzen hochentwickelte Tiefenkameras (z.B. eine Frontkamera auf einer Mobileinheit) und Sensoren derart, dass Gesten, die in der Luft (über einer Mobileinheit) gemacht werden, eingefangen und in eine bestimmte Eingabe innerhalb der Virtual Reality übersetzt werden können. „In der Luft“ bezieht sich auf eine Eingabe, die berührungslos ist.
• Die In-Air-Steuerungen 470 können verwendet werden, um verschiedene VR-Aspekte zu steuern. In einigen Ausführungsformen können die In-Air-Steuerungen 470 zur Fortbewegung verwendet werden. Wenn zum Beispiel ein Benutzer mit seinem Finger über den Bildschirm zeigt, kann eine Vorwärtsbewegung absolviert werden. In einigen Ausführungsformen können die In-Air-Steuerungen 470 zur Handlungsausführung verwendet werden (z.B. kann eine bestimmte Geste „Faust“ zu einer bestimmten Handlung „Hocken“ führen). In einigen Ausführungsformen können die In-Air-Steuerungen 470 verwendet werden, um Blickwinkel zu steuern (z.B. kann ein Winken mit der Hand zu einem Verschieben in die Richtung des Winkens mit der Hand führen, ein zeigender Finger über der Mobileinheit kann zu einem Anvisieren in die Richtung des Fingers führen usw.).
• In einigen Ausführungsformen können die In-Air-Steuerungen 470 zur Konstruktion eines dreidimensionalen Objekts (3D-Objekts) verwendet werden. Beispielsweise kann, wenn ein Benutzer ein bestimmtes Objekt in der Luft über seiner Mobileinheit verfolgt (d.h. ein In-Air-Muster), dies dazu führen, dass ein entsprechendes 3D-Objekt innerhalb der Virtual Reality erzeugt wird (z.B. das Quadrat, das in den In-Air-Steuerungen 470 der 4 abgebildet ist). In Ausführungsformen kann das verfolgte Objekt innerhalb der Virtual Reality vergrößert werden.
• In Ausführungsformen beeinflusst die Tiefe und/oder die Geschwindigkeit, mit welcher die In-Air-Interaktion erfolgt, die Ausgabe auf dem VR-HMD. Beispielsweise kann eine schnelle Handgeste zu einem schnellen Verschieben führen, während eine langsame Handgeste zu einem langsamen Verschieben führen kann. In ähnlicher Weise kann eine Geste in der Nähe des Bildschirms zu einem Heranzoomen führen, während eine weit von dem Bildschirm entfernte Geste zu einem Herauszoomen führen kann.
• In Ausführungsformen können mehrere verschiedene Steuerungen 400 gleichzeitig verwendet werden, um Virtual-Reality-Inhalt zu steuern, der auf einem VR-HMD angezeigt wird. Es wird nun auf verschiedene Spielbeispiele Bezug genommen, welche verschiedene oben beschriebene Steuerungen umfassen. Gemäß einem ersten Beispiel, z.B. in einem Ego-Spiel, können Kippsteuerungen 445 verwendet werden, um Blickwinkel des VR-Spiels zu steuern, Ziehsteuerungen 425 können verwendet werden, um Objekte innerhalb eines VR-Spiels zu bewegen, und Steuerungen auf Drehringbasis 460 können verwendet werden, um die Fortbewegung eines Benutzers zu steuern. Ferner können gemäß diesem Beispiel Tippsteuerungen 415 verwendet werden, um Handlungen zu absolvieren. Beispielsweise kann ein „Doppeltippen“ zu einer ersten Handlung (z.B. Hocken) führen, während ein „Halten und Drücken“ zu einer zweiten Handlung (z.B. Ändern eines Elements) innerhalb der der Virtual Reality führen kann. Außerdem können Wählscheibensteuerungen 420 bei einer Konfrontation mit mehreren Optionen bei der Optionsauswahl helfen (z.B. „Tür öffnen“ oder „Weggehen“).
• Gemäß einem zweiten Beispiel, z.B. in einem 3D-Kartenprogramm (wie z.B. GOOGLE EARTH^®), können Ziehsteuerungen 425 zum Verschieben (z.B. Kamerabewegung entlang einer horizontalen Ebene) verwendet werden und Zusammenzieh/Auseinanderzieh-Steuerungen 430 können zum Heranzoomen und Herauszoomen verwendet werden. In einigen Ausführungsformen können jedoch In-Air-Steuerungen 470 zum Steuern des Verschiebens und des Zoomens verwendet werden. Beispielsweise kann durch ein Fingerziehen in der Luft das Verschieben gesteuert werden. Die Geschwindigkeit, mit welcher sich der Finger des Benutzers über dem Bildschirm bewegt, kann von einer Frontkamera erfasst und in eine entsprechende Verschiebungsgeschwindigkeit übersetzt werden. In Ausführungsformen kann durch die Strecke, um welche die Hand des Benutzers in der Luft über der Mobileinheit gemessen wird, die Zoomvergrößerung gesteuert werden. Wenn sich beispielsweise die Hand des Benutzers in der Nähe der Mobileinheit befindet, kann eine herangezoomte Konfiguration ausgeführt werden, während, wenn die Hand des Benutzers weit von der Mobileinheit entfernt ist, eine herausgezoomte Konfiguration ausgeführt werden kann.
• Gemäß einem dritten Beispiel, z.B. in einem Konstruktionsspiel (z.B. einem Hausbau- oder Städtebausimulator), können In-Air-Steuerungen 470 verwendet werden, um eine 3D-Struktur zu konstruieren (z.B. ein Hochhaus oder ein Haus). Beispielsweise kann eine In-Air-Verfolgung eines Objekts in eine vergrößerte Version eines Hauses oder eines Hochhauses übersetzt werden. In diesen Ausführungsformen können Berührungssteuerungen 410 verwendet werden, um Optionen (z.B. das Material oder den Stil des Gebäudes) auszuwählen, Bewegungssteuerungen 440 können verwendet werden, um Blickwinkel zu steuern, und Drehringsteuerungen 460 können verwendet werden, um eine Fortbewegung zu erzeugen (so dass der Benutzer z.B. das konstruierte Gebäude erkunden kann).
• In einigen Ausführungsformen können verschiedene Steuerungen 400 mehrerer Einheiten in einem VR-Spiel realisiert werden. Als ein Beispiel, z.B. in einem FPS-Spiel, können Bewegungssteuerungen 440 einer ersten Einheit (z.B. einer Smartwatch) verwendet werden, um ein Anvisieren zu steuern, Berührungssteuerungen 410 der ersten Einheit können verwendet werden, um eine erste Gruppe von Handlungen (z.B. „Hocken“) zu steuern, In-Air-Steuerungen 470 einer zweiten Einheit (z.B. eines Smartphones) können verwendet werden, um eine zweite Gruppe von Handlungen (z.B. „Ändern eines Elements“ oder „Sprinten“) zu steuern, und Drehringsteuerungen 460 der zweiten Einheit können verwendet werden, um die Fortbewegung zu steuern.
• Obwohl auf spezielle Steuerungskonfigurationen Bezug genommen wird, kann jede geeignete Steuerungskonfiguration realisiert werden, die nicht vom Umfang der vorliegenden Offenbarung abweicht. Die oben beschriebenen Steuerungen sind lediglich beispielhaft und sollen nicht beschränkend sein.
• Es versteht sich, dass das Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud-Computing umfasst. Vielmehr können Ausführungsformen der vorliegenden Offenbarung in Verbindung mit jeder beliebigen Art von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung realisiert werden.
• Cloud-Computing ist ein Dienstbereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Hauptspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand oder minimaler Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften, mindestens drei Dienstmodelle und mindestens vier Einsatzmodelle umfassen.
• Bei den Eigenschaften handelt es sich um die Folgenden:
• On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter des Dienstes erforderlich ist.
• Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
• Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer im Allgemeinen keine Kontrolle oder Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
• Rapid Elasticity: Funktionen können für ein schnelles Scale-out schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
• Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Nutzung von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.
• Bei den Dienstmodellen handelt es sich um die Folgenden:
• Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende E-Mail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet oder steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher oder sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.
• Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte oder erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet oder steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme oder Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen der Application Hosting Environment.
• Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, das Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet oder steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
• Bei den Einsatzmodellen handelt es sich um die Folgenden:
• Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
• Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder fremden Räumen befinden.
• Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
• Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (Private, Community oder Public), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Bursting für den Lastenausgleich zwischen Clouds).
• Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Zentrum des Cloud-Computing steht eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten umfasst.
• Nun Bezug nehmend auf 5, ist dort die veranschaulichende Cloud-Computing-Umgebung 510 abgebildet. Wie dargestellt, umfasst die Cloud-Computing-Umgebung 510 einen oder mehrere Cloud-Computing-Knoten 500, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie zum Beispiel der elektronische Assistent (PDA, Personal Digital Assistant) oder das Mobiltelefon 500A (z.B. die Steuereinheiten 215), der Desktop-Computer 500B (z.B. das Computersystem 110 und/oder 225), der Laptop-Computer 500C (z.B. das Computersystem 110 und/oder 225) und/oder das Automobil-Computer-System 500N Daten austauschen können. Die Knoten 500 können miteinander Daten austauschen. Sie können physisch oder virtuell in ein oder mehrere Netzwerke wie Private, Community, Public oder Hybrid Clouds, wie vorstehend beschrieben, oder in eine Kombination daraus gruppiert werden (nicht dargestellt). Dies ermöglicht es der Cloud-Computing-Umgebung 510, Infrastructure, Platforms und/oder Software as a Service anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es versteht sich, dass die Arten der in 5 dargestellten Datenverarbeitungseinheiten 500A bis N lediglich veranschaulichend sein sollen und dass die Datenverarbeitungsknoten 500 und die Cloud-Computing-Umgebung 510 über eine beliebige Art Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.
• Nun Bezug nehmend auf 6, ist dort ein Satz von funktionalen Abstraktionsschichten dargestellt, die durch die Cloud-Computing-Umgebung 510 (5) bereitgestellt werden. Es versteht sich, dass die in 6 dargestellten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Ausführungsformen der Offenbarung nicht darauf beschränkt sind. Wie nachstehend abgebildet, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt.
• Die Hardware- und Software-Schicht 600 umfasst Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: Mainframe-Computer 602; auf der RISC-Architektur (Reduced Instruction Set Computer) beruhende Server 604; Server 606; Blade-Server 608; Speichereinheiten 610 und Netzwerke sowie Netzwerkkomponenten 612. In einigen Ausführungsformen umfassen Software-Komponenten eine Netzwerk-Anwendungsserver-Software 614 und eine Datenbank-Software 616.
• Die Virtualisierungsschicht 620 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 622, virtueller Speicher 624, virtuelle Netzwerke 626, darunter virtuelle private Netzwerke, virtuelle Anwendungen und Betriebssysteme 628 und virtuelle Clients 630.
• In einem Beispiel kann die Verwaltungsschicht 640 die nachfolgend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 642 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen und anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Messen und Preisfindung 644 stellt die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungs-Software-Lizenzen umfassen. Sicherheit stellt die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 646 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Dienstumfangsverwaltung 648 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen derart bereit, dass die benötigten Dienstumfänge erreicht werden. Die Dienstumfangsverwaltung 648 kann eine geeignete Verarbeitungsleistung und Speicher zum Verarbeiten statischer Sensordaten zuordnen. Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) 650 stellt die Vorab-Anordnung und die Beschaffung von Cloud-Computing-Ressourcen, für die ein zukünftiges Erfordernis vorausgesehen wird, gemäß einer SLA bereit.
• Eine Arbeitslastschicht 660 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 662; Software-Entwicklung und Lebenszyklusverwaltung 664; Indoor-Positionierung 666; Datenanalytikverarbeitung 668; Transaktionsverarbeitung 670; und Virtual-Reality-Verwaltung 672.
• Nun Bezug nehmend auf 7, ist dort ein übergeordnetes Blockschaubild eines beispielhaften Computersystems 701 (z.B. Computersystem 110, Steuereinheiten 215, Computersystem 235) dargestellt, welches beim Realisieren eines oder mehrerer der hierin beschriebenen Verfahren, Tools und Module und aller zugehörigen Funktionen (z.B. unter Verwendung eines oder mehrerer Prozessorschaltungen oder Computerprozessoren des Computers) gemäß Ausführungsformen der vorliegenden Offenbarung benutzt werden kann. In einigen Ausführungsformen können die Hauptkomponenten des Computersystems 701 eine oder mehrere CPUs 702, ein Speicher-Teilsystem 704, eine Anschlussschnittstelle 712, eine Speicherschnittstelle 714, eine I/O-Einheiten-Schnittstelle (Eingabe/Ausgabe-Einheiten-Schnittstelle) 716 und eine Netzwerk-Schnittstelle 718 umfassen, von denen alle über einen Speicherbus 703, einen I/O-Bus 708 und eine I/O-Bus-Schnittstelleneinheit 710 direkt oder indirekt zum Datenaustausch zwischen Komponenten verbunden sein können.
• Das Computersystem 701 kann eine oder mehrere universelle programmierbare Zentraleinheiten (CPUs) 702A, 702B, 702C und 702D enthalten, die hierin allgemein als die CPU 702 bezeichnet werden. In einigen Ausführungsformen kann das Computersystem 701 mehrere Prozessoren enthalten, die für ein relativ großes System typisch sind; in anderen Ausführungsformen jedoch kann das Computersystem 701 alternativ ein Einzel-CPU-System sein. Jede CPU 702 kann Anweisungen ausführen, die in dem Speicher-Teilsystem 704 gespeichert sind, und kann eine oder mehrere Ebenen eines integrierten Cache umfassen.
• Der Systemspeicher 704 kann computersystemlesbare Medien in der Form eines flüchtigen Speichers umfassen, z.B. Direktzugriffsspeicher (RAM) 722 oder Cache-Speicher 724. Das Computersystem 701 kann ferner andere entfernbare/nicht-entfernbare, flüchtige/nicht-flüchtige Computersystem-Speichermedien umfassen. Lediglich beispielhaft kann ein Speichersystem 726 zum Auslesen aus einem und Schreiben auf ein nichtentfernbares, nicht-flüchtiges Medium bereitgestellt werden, wie z.B. eine „Festplatte“. Wenngleich nicht dargestellt, kann ein Magnetplattenlaufwerk zum Auslesen aus einer und Schreiben auf eine entfernbare, nicht-flüchtige Magnetplatte (z.B. eine „Diskette“) oder ein optisches Plattenlaufwerk zum Auslesen aus einer und Schreiben auf eine entfernbare, nicht-flüchtige optische Platte wie eine CD-ROM, eine DVD-ROM oder andere optische Medien bereitgestellt werden. Außerdem kann der Speicher 704 einen Flash-Speicher umfassen, z.B. einen Flash-Speicher-Stick oder ein Flash-Laufwerk. Speichereinheiten können durch eine oder mehrere Datenmedien-Schnittstellen mit dem Speicherbus 703 verbunden sein. Der Speicher 704 kann mindestens ein Programmprodukt umfassen, welches einen Satz von Programmmodulen (z.B. mindestens eines) aufweisen kann, die dafür konfiguriert sind, die Funktionen verschiedener Ausführungsformen auszuführen.
• In dem Speicher 704 können ein oder mehrere Programme/Hilfsprogramme 728 gespeichert sein, welche jeweils mindestens einen Satz von Programmmodulen 730 aufweisen. Die Programme/Hilfsprogramme 728 können einen Hypervisor (auch als Monitor für virtuelle Maschinen bezeichnet), ein oder mehrere Betriebssysteme, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten umfassen. Jedes der Betriebssysteme, des einen oder der mehreren Anwendungsprogramme, der anderen Programmmodule und Programmdaten oder eine Kombination davon kann eine Realisierung einer Netzwerkumgebung umfassen. Die Programme 728 und/oder die Programmmodule 730 führen im Allgemeinen die Funktionen oder die Methoden verschiedener Ausführungsformen aus.
• Obwohl der Speicherbus 703 in 7 als eine Einzelbusstruktur dargestellt ist, welche einen direkten Datenaustauschweg zwischen den CPUs 702, dem Speicher-Teilsystem 704 und der I/O-Busschnittstelle 710 bereitstellt, kann der Speicherbus 703 in einigen Ausführungsformen mehrere verschiedene Busse oder Datenaustauschwege umfassen, welche in beliebigen von verschiedenen Formen eingerichtet sein können, z.B. Punkt-zu-Punkt-Verbindungen in hierarchischen, Stern- oder Netzkonfigurationen, mehrere hierarchische Busse, parallele und redundante Wege oder eine beliebige andere geeignete Art von Konfiguration. Außerdem kann, obwohl die I/O-Busschnittstelle 710 und der I/O-Bus 708 als jeweils einzelne Einheiten dargestellt sind, das Computersystem 701 in einigen Ausführungsformen mehrere I/O-Busschnittstellen-Einheiten 710, mehrere I/O-Busse 708 oder beides enthalten. Ferner können, obwohl mehrere I/O-Schnittstelleneinheiten dargestellt sind, welche den I/O-Bus 708 von verschiedenen Datenaustauschwegen trennen, die zu den verschiedenen I/O-Einheiten verlaufen, in anderen Ausführungsformen einige oder alle der I/O-Einheiten direkt mit einem oder mehreren System-I/O-Bussen verbunden sein.
• In einigen Ausführungsformen kann das Computersystem 701 ein Mehr-Benutzer-Mainframe-Computersystem, ein Ein-Benutzer-System oder ein Server-Computer oder eine ähnliche Einheit sein, welche wenige oder keine direkten Benutzerschnittstellen aufweist, aber Anforderungen von anderen Computersystemen (Clients) empfängt. Ferner kann in einigen Ausführungsformen das Computersystem 701 als ein Desktop-Computer, ein tragbarer Computer, ein Laptop- oder Notebook-Computer, ein Tablet-Computer, ein Taschencomputer, ein Telefon, ein Smartphone, Netzwerk-Switches oder -Router oder eine beliebige andere geeignete Art von elektronischer Einheit realisiert sein.
• Es sei angemerkt, dass 7 die repräsentativen Hauptkomponenten eines beispielhaften Computersystems 701 abbilden soll. In einigen Ausführungsformen können jedoch einzelne Komponenten eine größere oder geringere Komplexität aufweisen als in 7 dargestellt, andere Komponenten als oder zusätzliche Komponenten zu den in 7 dargestellten können vorhanden sein und die Anzahl, die Art und die Konfiguration solcher Komponenten kann variieren.
• Wie hierin detaillierter beschrieben, ist abzusehen, dass einige oder alle der Operationen einiger der Ausführungsformen der hierin beschriebenen Verfahren in alternativen Reihenfolgen ausgeführt werden können oder möglicherweise gar nicht ausgeführt werden; ferner können mehrere Operationen gleichzeitig oder als ein innerer Teil eines größeren Prozesses erfolgen.
• Bei der vorliegenden Offenbarung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder -medien) mit computerlesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Offenbarung auszuführen.
• Bei dem computerlesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem computerlesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste speziellerer Beispiele des computerlesbaren Speichermediums gehören die Folgenden: eine auswechselbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein auswechselbarer Compact-Disk-Nur-Lese-Speicher (CD-ROM), eine Digital Versatile Disc (DVD), ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein computerlesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
• Hierin beschriebene, computerlesbare Programmanweisungen können von einem computerlesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenleiter, drahtlose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server umfassen. Eine Netzwerk-Adapterkarte oder Netzwerk-Schnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt computerlesbare Programmanweisungen aus dem Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung in einem computerlesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
• Bei computerlesbaren Programmanweisungen zum Ausführen von Operationen der vorliegenden Offenbarung kann es sich um Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ oder Ähnliches und herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gate-Arrays (FPGAs, Field Programmable Gate Arrays) oder programmierbare Logik-Arrays (PLAs, Programmable Logic Arrays) die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der computerlesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Offenbarung durchzuführen.
• Aspekte der vorliegenden Offenbarung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Offenbarung beschrieben. Es versteht sich, dass jeder Block der Ablaufpläne und/oder der Blockschaubilder und Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaubildern mittels computerlesbarer Programmanweisungen realisiert werden können.
• Diese computerlesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen Mittel zur Umsetzung der in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Handlungen erzeugen. Diese computerlesbaren Programmanweisungen können auch auf einem computerlesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das computerlesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt umfasst, darunter Anweisungen, welche Aspekte der in dem Block oder den Blöcken des Ablaufplans und/oder der Blockschaubilder festgelegten Funktion/Handlung umsetzen.
• Die computerlesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Operationsschritten auf dem Computer, der anderen programmierbaren Vorrichtung oder der anderen Einheit zu verursachen, um einen auf einem Computer realisierten Prozess zu erzeugen, so dass die auf dem Computer, der anderen programmierbaren Vorrichtung oder der anderen Einheit ausgeführten Anweisungen die in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Handlungen umsetzen.
• Die Ablaufpläne und die Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Realisierung der festgelegten logischen Funktion(en) umfassen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren dargestellt stattfinden. Zwei nacheinander dargestellte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
• Die hierin verwendete Terminologie dient nur der Beschreibung bestimmter Ausführungsformen und soll die verschiedenen Ausführungsformen nicht beschränken. Wie hierin verwendet, sollen die Singularformen „ein“, „eine“ und „der“, „die“, „das“ ebenso die Pluralformen umfassen, sofern dies nicht durch den Kontext eindeutig anders angezeigt ist. Es versteht sich ferner, dass mit den Begriffen „umfasst“ und/oder „umfassen“, wenn sie in dieser Beschreibung verwendet werden, das Vorliegen angegebener Eigenschaften, ganzer Zahlen, Schritte, Operationen, Elemente und/oder Komponenten beschrieben ist, jedoch nicht das Vorliegen oder das Hinzufügen ein oder mehrerer anderer Eigenschaften, ganzer Zahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen derselben ausgeschlossen wird. In der vorstehenden detaillierten Beschreibung beispielhafter Ausführungsformen der verschiedenen Ausführungsformen wurde auf die begleitenden Zeichnungen Bezug genommen (wo gleiche Zahlen gleiche Elemente repräsentieren), welche einen Teil davon bilden und in welchen veranschaulichend spezielle beispielhafte Ausführungsformen dargestellt sind, in welchen die verschiedenen Ausführungsformen ausgeführt werden können. Diese Ausführungsformen wurden detailliert genug beschrieben, um dem Fachmann zu ermöglichen, die Ausführungsformen auszuführen, es können aber andere Ausführungsformen verwendet werden und logische, mechanische, elektrische und andere Änderungen vorgenommen werden, ohne vom Umfang der verschiedenen Ausführungsformen abzuweichen. In der vorstehenden Beschreibung wurden zahlreiche spezielle Einzelheiten ausgeführt, um für ein gründliches Verständnis der verschiedenen Ausführungsformen zu sorgen. Die verschiedenen Ausführungsformen können jedoch auch ohne diese speziellen Einzelheiten ausgeführt werden. In anderen Fällen sind gut bekannte Schaltungen, Strukturen und Techniken nicht detailliert dargestellt worden, um die Ausführungsformen nicht unklar werden zu lassen.
• Wenn das Wort „Ausführungsform“ in dieser Beschreibung verschiedenfach auftritt, bezieht sich dies nicht notwendigerweise auf dieselbe Ausführungsform, kann es aber. Alle hierin veranschaulichten oder beschriebenen Daten und Datenstrukturen sind lediglich Beispiele und in anderen Ausführungsformen können andere Datenmengen, Datentypen, Felder, Anzahlen und Typen von Feldern, Feldbezeichnungen, Anzahlen und Typen von Reihen, Aufzeichnungen, Einträge oder Organisationen von Daten verwendet werden. Außerdem können jegliche Daten mit Logik kombiniert werden, so dass keine separate Datenstruktur notwendig sein muss. Die vorstehende detaillierte Beschreibung ist deswegen nicht als beschränkend anzusehen.
• Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Offenbarung dienen der Veranschaulichung, sollen aber nicht erschöpfend oder auf die offenbarten Ausführungsformen beschränkt sein. Dem Fachmann werden viele Modifikationen und Variationen ersichtlich sein, ohne vom Umfang der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde so gewählt, dass die Prinzipien der Ausführungsformen, die praktische Anwendung oder die technische Verbesserung gegenüber marktüblichen Technologien bestmöglich erläutert werden oder anderen Fachleuten ermöglicht wird, die hierin offenbarten Ausführungsformen zu verstehen.
• Obwohl die vorliegende Offenbarung in Form spezieller Ausführungsformen beschrieben worden ist, ist vorauszusehen, dass dem Fachmann Änderungen und Modifikationen daran ersichtlich werden. Deswegen sollen die folgenden Patentansprüche so ausgelegt werden, dass sie all solche Änderungen und Modifikationen als unter den wahren Umfang der Offenbarung fallend abdecken.

Claims (20)

1. Verfahren, umfassend: Einrichten eines Datenaustauschs zwischen einem Computersystem, einem am Kopf angebrachten Virtual-Reality-Display (VR-HMD) und einer Mobileinheit; Empfangen einer Benutzereingabe auf der Mobileinheit, die dafür konfiguriert ist, VR-Inhalt zu steuern, der auf einem Display des VR-HMD als Ausgabe von dem Computersystem angezeigt wird; und Steuern des VR-Inhalts, der auf dem VR-HMD angezeigt wird, basierend auf der Benutzereingabe, die auf der Mobileinheit empfangen wird.
2. Verfahren nach Anspruch 1, wobei die Benutzereingabe eine In-Air-Steuerung ist.
3. Verfahren nach Anspruch 2, wobei eine bestimmte Geste, die über der Mobileinheit gemacht wird, zu einer bestimmten Handlungsausführung innerhalb des VR-Inhalts führt.
4. Verfahren nach Anspruch 1, ferner umfassend: Empfangen einer In-Air-Steuerung von einem Benutzer der Mobileinheit; Steuern eines Blickwinkels des VR-Inhalts basierend auf der In-Air-Steuerung.
5. Verfahren nach Anspruch 1, ferner umfassend: Empfangen einer Steuerung auf Drehringbasis von einem Benutzer der Mobileinheit; Steuern einer Fortbewegung des Benutzers innerhalb des VR-Inhalts basierend auf der Steuerung auf Drehringbasis; Empfangen einer Berührungssteuerung von dem Benutzer der Mobileinheit; und Ausführen einer ersten Handlung innerhalb des VR-Inhalts in Reaktion auf das Empfangen der Berührungssteuerung.
6. Verfahren nach Anspruch 1, ferner umfassend: Empfangen einer In-Air-Steuerung von einem Benutzer der Mobileinheit; Ausführen einer ersten Handlung innerhalb des VR-Inhalts basierend auf der In-Air-Steuerung; Empfangen einer Bewegungssteuerung von dem Benutzer auf einer zweiten Mobileinheit; und Ändern eines Blickwinkels des VR-Inhalts basierend auf der Bewegungssteuerung.
7. Computerprogrammprodukt, aufweisend ein computerlesbares Speichermedium, welches damit verkörperte Programmanweisungen aufweist, wobei das computerlesbare Speichermedium nicht per se ein flüchtiges Signal ist, wobei die Programmanweisungen von einem Prozessor ausführbar sind, um zu bewirken, dass der Prozessor ein Verfahren durchführt, umfassend: Einrichten eines Datenaustauschs zwischen einem Computersystem, einem am Kopf angebrachten Virtual-Reality-Display (VR-HMD) und einer Mobileinheit; Empfangen einer Benutzereingabe auf der Mobileinheit, die dafür konfiguriert ist, VR-Inhalt zu steuern, der auf einem Display des VR-HMD als Ausgabe von dem Computersystem angezeigt wird; und Steuern des VR-Inhalts, der auf dem VR-HMD angezeigt wird, basierend auf der Benutzereingabe, die auf der Mobileinheit empfangen wird.
8. Computerprogrammprodukt nach Anspruch 7, wobei die Benutzereingabe eine In-Air-Steuerung ist.
9. Computerprogrammprodukt nach Anspruch 8, wobei eine bestimmte Geste, die über der Mobileinheit gemacht wird, zu einer bestimmten Handlungsausführung innerhalb des VR-Inhalts führt.
10. Computerprogrammprodukt nach Anspruch 7, wobei das von dem Prozessor durchgeführte Verfahren ferner umfasst: Einfangen eines In-Air-Steuerungs-Verfolgungsmusters von einem Benutzer der Mobileinheit unter Verwendung einer Frontkamera der Mobileinheit; und Konstruieren eines dreidimensionalen virtuellen Objekts innerhalb des VR-Inhalts basierend auf dem In-Air-Steuerungs-Verfolgungsmuster.
11. Computerprogrammprodukt nach Anspruch 7, wobei das von dem Prozessor durchgeführte Verfahren ferner umfasst: Empfangen einer Berührungssteuerung von einem Benutzer der Mobileinheit; Steuern einer Fortbewegung des Benutzers innerhalb des VR-Inhalts basierend auf der Berührungssteuerung; Empfangen einer Bewegungssteuerung von einem Benutzer einer zweiten Mobileinheit; und Ändern eines Blickwinkels innerhalb des VR-Inhalts basierend auf der Bewegungssteuerung.
12. Computerprogrammprodukt nach Anspruch 7, wobei das von dem Prozessor durchgeführte Verfahren ferner umfasst: Empfangen einer In-Air-Steuerung von einem Benutzer der Mobileinheit; Ausführen einer ersten Handlung innerhalb des VR-Inhalts basierend auf der In-Air-Steuerung; Empfangen einer Steuerung auf Drehringbasis von einem Benutzer auf einer zweiten Mobileinheit; und Ändern eines Blickwinkels des VR-Inhalts basierend auf der Steuerung auf Drehringbasis.
13. System, aufweisend: ein am Kopf angebrachtes Virtual-Reality-Display (VR-HMD); eine Mobileinheit; und ein Computersystem, welches zum Datenaustausch mit dem VR-HMD und der Mobileinheit verbunden ist, wobei das Computersystem mindestens eine Speicherkomponente und mindestens einen Prozessor umfasst, wobei der Prozessor dafür konfiguriert ist, ein Verfahren durchzuführen, umfassend: Empfangen einer Benutzereingabe von der Mobileinheit, die dafür konfiguriert ist, VR-Inhalt zu steuern, der auf einem Display des VR-HMD angezeigt wird; und Steuern des VR-Inhalts, der auf dem VR-HMD angezeigt wird, basierend auf der Benutzereingabe, die von der Mobileinheit empfangen wird.
14. System nach Anspruch 13, wobei die Benutzereingabe eine In-Air-Steuerung ist.
15. System nach Anspruch 14, wobei eine bestimmte Geste, die über der Mobileinheit gemacht wird, zu einer bestimmten Handlungsausführung innerhalb des VR-Inhalts führt.
16. System nach Anspruch 13, wobei das von dem Prozessor durchgeführte Verfahren ferner umfasst: Einfangen eines In-Air-Steuerungs-Verfolgungsmusters von einem Benutzer der Mobileinheit unter Verwendung einer Frontkamera der Mobileinheit; Konstruieren eines dreidimensionalen virtuellen Objekts innerhalb des VR-Inhalts basierend auf dem In-Air-Steuerungs-Verfolgungsmuster; Einfangen einer In-Air-Handgeste von dem Benutzer der Mobileinheit unter Verwendung der Frontkamera der Mobileinheit; und Verschieben einer Kameraansicht innerhalb des VR-Inhalts basierend auf der In-Air-Handgeste.
17. System nach Anspruch 13, wobei das von dem Prozessor durchgeführte Verfahren ferner umfasst: Empfangen einer Berührungssteuerung von einem Benutzer der Mobileinheit; Steuern einer Fortbewegung des Benutzers innerhalb des VR-Inhalts basierend auf der Berührungssteuerung; Empfangen einer Bewegungssteuerung von einem Benutzer einer zweiten Mobileinheit; und Ändern eines Blickwinkels innerhalb des VR-Inhalts basierend auf der Bewegungssteuerung.
18. System nach Anspruch 13, wobei das von dem Prozessor durchgeführte Verfahren ferner umfasst: Empfangen einer In-Air-Steuerung von einem Benutzer der Mobileinheit; Ausführen einer ersten Handlung innerhalb des VR-Inhalts basierend auf der In-Air-Steuerung; Empfangen einer Steuerung auf Drehringbasis von einem Benutzer auf einer zweiten Mobileinheit; und Ändern eines Blickwinkels des VR-Inhalts basierend auf der Steuerung auf Drehringbasis.
19. System nach Anspruch 13, wobei das von dem Prozessor durchgeführte Verfahren ferner umfasst: Einfangen einer ersten Geste von einem Benutzer der Mobileinheit unter Verwendung einer Frontkamera der Mobileinheit; Steuern einer Fortbewegung innerhalb des VR-Inhalts basierend auf der ersten Geste von dem Benutzer; Einfangen einer zweiten Geste von dem Benutzer der Mobileinheit unter Verwendung der Frontkamera der Mobileinheit; und Ändern einer Kameraansicht innerhalb des VR-Inhalts basierend auf der zweiten Geste.
20. System nach Anspruch 13, ferner umfassend mindestens einen Sensor, wobei das von dem Prozessor durchgeführte Verfahren ferner umfasst: Verfolgen der Mobileinheit unter Verwendung eines Indoor-Positionierungssystems unter Verwendung des mindestens einen Sensors; und Aktualisieren einer Position der Mobileinheit innerhalb des VR-Inhalts basierend auf der Verfolgung.

Images