ultraschall
-
na dann könnt ihr ja jetzt das System bauen gehen
ich halts zwar anders für einfacher
aber ich wünsch euch trotzdem viel Spass...
-
Sgt. Nukem schrieb:
Naja, EyeToyTM & Co. kommen ja auch ohne aus.
Da ist es aber egal, wie groß die Entfernung zur Webcam ist (bei Eyetoy zumindest). Die Entfernungen können bei zu nah oder zu weit weg nur nicht mehr so genau festgestellt werden, weil das Bild entweder unscharf oder zu klein ist. Außerdem erkennt Eyetoy soweit meine (recht kleine) Spielerfahrung richtig ist nur Bewegungen, und nicht, wenn man einfach nur vor dem Bildschirm sitzt. Wie weit der Spieler weg ist, das ist bei Eyetoy jedenfalls egal (auf jeden Fall beim ersten Teil...)
geloescht
-
War auch nicht ganz ernst gemeint.
Hat wer dieses Sound-Ortungs-Teil auf der GC2005 gesehen?
-
Apropos "Scharf stellen": Könnte das nicht eine Mgölichkeit sein? Die Kamera muss ja scharf stellen, geschieht das nicht automatisch? Könnte man dann nicht auch die Einstellung irgendwie abfragen? Oder ist das zu ungenau? Meine Idee war, dass die Kamera immer aufs Gesicht scharf stellt...
geloescht
-
würde mich wundern wenn normale Webcams eine Schnittstelle hätten, über die man die Schärfeeinstellung abfragen kann
ausserdem was will man mit 8 bildern pro sekunde
in einem schnellen Spiel kann man das vergessen
30 oder so solltens schon sein
-
Ich weiß nicht, ob man wirklich merken würde, ob es 8 oder 30 Bilder pro Sekunde hat, wenn man zwischen den verschiedenen Kopfpositionen interpoliert. Aber es wird wohl ein Problem sein, dass das Berechnen der Bilder zu viel Prozessorzeit frisst. Ich kenne mich nicht aus, aber wenn man sich keine Clownsnase
aufsetzen will wird die Erkennung des Gesichts doch etwas zeitraubend, oder?
geloescht
-
ähm, das mit der Interpolation dürfte etwas schwierig werden. Du kannst nicht zwischen zwei Werten interpolieren, von denen es einen noch nicht gibt. Du kannst höchstens aus den vorherigen Bewegungen extrapolieren, oder einen gewissen Lag in Kauf nehmen. Wenn nur der Öffnungswinkel des Frustum korrigiert wird, dürfte die Veränderung so subtil sein, das ein (geglätteter) Lag nicht auffällt.
-
na dann is ja jetzt alles klar
-
Aber wenn man sich bewegt, also den Kopf, dann hat man den Monitor nicht mehr im Blickfeld. Lösung: Den Monitor an den Kopf tackern
-
oh, du hast recht. Ich meinte Extrapolieren, nicht Interpolieren. Trotzdem denke ich, dass es nicht auffällt. Es sei denn man erwartet, dass ruckartige Bewegungen sofort zu einem Ergebnis führen.
geloescht
-
Extrapolieren ist auch ungeeignet. Das funktioniert genau bis zum 3. Frame. Stells dir einfach mal "bildlich" vor, dann weist du wieso *zufaulzumerklärenbin*.
-
Ahhh, klar. Im vierten Frame kann das ja nicht gehen. Soso.
Bye, TGGC (Demo or Die)
-
Doch, nur dann hat man wieder einen Lag drinnen. Den muss man in kauf nehmen, sonst hat man wieder aprupte Sprünge drinnen.
Ich versuch mich mal an ASCII:
^ Abstand zum Bildschirm | | | x | \ | \ | \ x Hier müssten wir sein | x | . | . | . | + Dank Extrapolation sind wir aber hier.... | ----------------------------------------- > Frames (Zeit)Wenn man glätten will, bleibt wohl nix über als den Lag von 1 Frame in Kauf zu nehmen.
Falls das jetz falsch ist, klär mich bitte auf, lieber TGGC. Ich bin immer geneigt deinen Weisheiten zu lauschen ...
-
Da deine Achsen nicht beschriftet sind, kann ich deinem Diagramm nicht viel entnehmen.
Bye, TGGC (Demo or Die)
-
Ich dachte ich müsste sie nicht beschriften, da das Problem ein allgemeines ist.
Habs jetzt jednfalls beschriftet. Also?
-
Es geht sehr wohl. Allerdings müssen wir dann tatsächlich noch einmal interpolieren.
Folgendermaßen: Wir haben zwei Punkte, extrapolieren den dritten (in der Zukunft), fahren dort hin. Soweit so gut. Jetzt erhalten wir den neuen Punkt, der natürlich nciht mit dem übereinstimmt, an dem sich unser Programm befindet. Jetzt extrapolieren wir den neuen Punkt (zwischen den vorigen zwei) und fahren da hin. Usw. Vielleicht kann ich es mit nem Diagramm verdeutlichen:p . ^ . . | *. - . |* / . * - .* | \ - * . . | *. . | . . | . 0------------------------------> t* sind die realen Punkte, - / \ die Verbindungen dazwischen, . die inter-/extrapolierten Werte. TGGC, wie du siehst habe ich die Achsen beschriftet
Hmm... sieht nach einem ziemlichen Geeier aus, aber so ungefähr passt es. Vielleicht sollte man sich aber trotzdem mit einem Lag begnügen. Um zu sehen, was jetzt besser ist bräuchte man ein Testprogramm.
geloescht
-
kennt sich den jemand hier damit aus wie man eine Webcam Schnittstelle benutzt?
-
OK, aber ich kann mir vorstellen, das das Überschwingen schwerer wiegt, als ein Lag von einem Frame.
-
ChockoCookie schrieb:
Ich dachte ich müsste sie nicht beschriften, da das Problem ein allgemeines ist.
Habs jetzt jednfalls beschriftet. Also?Ok. Die Zeichnung ist falsch. Man kann nicht zum + extrapoliert haben, wenn man eigentlich noch beim zweiten x ist. Dort stimmen nämlich die t nicht überein. Da t aber der Parameter und bekannt ist, kann der "falsche" Punkt nicht in der Zeitdimension abweichen.
Bye, TGGC (Demo or Die)
-
TGGC schrieb:
Ok. Die Zeichnung ist falsch. Man kann nicht zum + extrapoliert haben, wenn man eigentlich noch beim zweiten x ist. Dort stimmen nämlich die t nicht überein. Da t aber der Parameter und bekannt ist, kann der "falsche" Punkt nicht in der Zeitdimension abweichen.
Huh? Das + und das x liegen doch direkt übereinander? Oder hast Du gedacht, das sei die Legende?
