Hallöchen,
mir schwirrt folgendes im Kopfe herum:
Man nehme Eine Kamerabewegung/-steuerung ähnlich der von AirRivals. Also ähnlich weil die auch nicht das optimale Beispiel ist: Ich denke an eine, bei der die Ausrichtung der Rotation schneller ist als die der Position oder umgekehrt.
Das führt zu so einem hübschen Effekt, der anmuten lässt, es sei eine Film-Kameraführung, bzw. wirkt die Kamera nicht so stark am Protagonist-Objekt fest gebaut.
Problem: Das Bild springt merkwürdig ruckelnd hin und her, (ich glaube) da die markanten Punkte für das Auge auf dem Bildschirm einmal durch die Rotation und ein anderes mal durch die Transformation bewegt werden und sie dies aber in unterschiedlicher Geschwindigkeit und Länge/Zeit tun.
In meinen Tests habe ich die Rotation mittels Quarternion gesmootht und die Position mittels Vektoraddition.
Probiert:
-eins linear das andere nicht linear smothen
-beides linear, beides nicht linear smoothen
-die Rotation mittels LookAt auf einen abstrakten Punkt der für die Kamerarichtung herhällt
Hab ich jetzt einfach was falsch gemacht? Oder gibt es da eine sinnvolle Herangehensweise? Mir fällt nix mehr ein.
schwammige Kamerabewegung ruckelt
schwammige Kamerabewegung ruckelt
"Es gibt 10 Arten von Menschen, die die Binär verstehen und die die es nicht tun."
"Hier gibts Code zum Auskommentieren. Wo ist der Praktikant? Hmpf, so müssen sich Lehrer beim Kontrollieren von Arbeiten fühlen..."
"Hier gibts Code zum Auskommentieren. Wo ist der Praktikant? Hmpf, so müssen sich Lehrer beim Kontrollieren von Arbeiten fühlen..."
-
Krishty
- Establishment
- Beiträge: 8244
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: schwammige Kamerabewegung ruckelt
Hast du vielleicht danach die Renormalisierung der Quaternions bzw. Reorthogonalisierung der Matrix vergessen? Die Rechenfehler potenzieren sich bei sowas recht schnell, wenn man es nicht tut …
Re: schwammige Kamerabewegung ruckelt
Öhm, ich denke das habe ich beachtet. Ich muss zugeben, dass ich mir alles über Abitur hinaus selber beibringe, weshalb ich mit Matrizen und Quaternions ca. 10 mal weniger sicher bin, als mit Vektoren... :oops:
Aus gegebenem Grund benutze ich die Buildinfunktionen von Unity, lese mich zwar nach wie vor ein, bau aber die "grundlegenden" Rechnungen mit Matrizen und Quaternions nie selber.
Folgende Vorgehensweise:
-ich sichere mir die aktuelle Position (Vektor) und Rotation (Quaternion)
-bewege mein Objekt per Vektoraddition
-berechne den LookAt-Vektor und daraus die Matrix der Kamera
-und lasse dann erst die Positionsveränderung smoothen (bewege das Objekt also prozentual zurück)
-und schließlich auch die Roation mittels Slerp
bei den letzten beiden Schritten lassen sich die Zahlen ja so gestalten, das es eine Anäherung an den gewünschten wert gibt (so eine Art Gummiseileffekt, da der Weg z.b. immer halbiert wird) oder im verhältnis zur Zeit linear, also Drehung und bewegung behalten ihre Geschwindigkeit, bis sie ihr Ziel erreicht haben.
Das das Ganze jetzt tatsächlich an meiner mathematischen Nichtdurchblickung liegen könnte, habe ich das ganze mal im 2D Raum getestet, da ich da mit Vektoren klar komme. Selbes resultat.
Ich werde mich jetzt an die Mathematik dahinter setzen und mal ein kleines Diagramm aufziehen, um mathematisch zu zeigen, was ich meine... gff schaff ich das nicht mehr (muss bald los und hab dann bis Mittwoch den Rechner nicht.) In dem Fall sollte das Mittwoch oben sein... auf, auf ;)
Aus gegebenem Grund benutze ich die Buildinfunktionen von Unity, lese mich zwar nach wie vor ein, bau aber die "grundlegenden" Rechnungen mit Matrizen und Quaternions nie selber.
Folgende Vorgehensweise:
-ich sichere mir die aktuelle Position (Vektor) und Rotation (Quaternion)
-bewege mein Objekt per Vektoraddition
-berechne den LookAt-Vektor und daraus die Matrix der Kamera
-und lasse dann erst die Positionsveränderung smoothen (bewege das Objekt also prozentual zurück)
-und schließlich auch die Roation mittels Slerp
bei den letzten beiden Schritten lassen sich die Zahlen ja so gestalten, das es eine Anäherung an den gewünschten wert gibt (so eine Art Gummiseileffekt, da der Weg z.b. immer halbiert wird) oder im verhältnis zur Zeit linear, also Drehung und bewegung behalten ihre Geschwindigkeit, bis sie ihr Ziel erreicht haben.
Das das Ganze jetzt tatsächlich an meiner mathematischen Nichtdurchblickung liegen könnte, habe ich das ganze mal im 2D Raum getestet, da ich da mit Vektoren klar komme. Selbes resultat.
Ich werde mich jetzt an die Mathematik dahinter setzen und mal ein kleines Diagramm aufziehen, um mathematisch zu zeigen, was ich meine... gff schaff ich das nicht mehr (muss bald los und hab dann bis Mittwoch den Rechner nicht.) In dem Fall sollte das Mittwoch oben sein... auf, auf ;)
"Es gibt 10 Arten von Menschen, die die Binär verstehen und die die es nicht tun."
"Hier gibts Code zum Auskommentieren. Wo ist der Praktikant? Hmpf, so müssen sich Lehrer beim Kontrollieren von Arbeiten fühlen..."
"Hier gibts Code zum Auskommentieren. Wo ist der Praktikant? Hmpf, so müssen sich Lehrer beim Kontrollieren von Arbeiten fühlen..."
Re: schwammige Kamerabewegung ruckelt
"da der Weg z.b. immer halbiert wird"
Das beschreibt dann eine Exponentialfunktion.... ich vermute du hast die geschwindigkeit der annäherung nicht als Funktion berechnet, sondern hast irgendsowas:
Position = Position*0.95 + SollPosition*0.05.
Setzt man jetzt die Faktoren 0.5 und 0.5 ein, kommt man auf deine "halbierung"
Ich würde jetzt aufs gerade Wohl unterstellen, dass du die Framezeiten nicht beachtest... du hast die 0.95 einfach so lange angepasst, (z.b. zu 0.99123) bis es bei der durchschnittlichen Framerate eine angenehme geschwindikeit hat... oder?
Dann ruckelt auch die Bewegung, ...wenn es schnelle und langsame Frames gibt. Die Schrittweite ist FPS-Abhängig.
Das beschreibt dann eine Exponentialfunktion.... ich vermute du hast die geschwindigkeit der annäherung nicht als Funktion berechnet, sondern hast irgendsowas:
Position = Position*0.95 + SollPosition*0.05.
Setzt man jetzt die Faktoren 0.5 und 0.5 ein, kommt man auf deine "halbierung"
Ich würde jetzt aufs gerade Wohl unterstellen, dass du die Framezeiten nicht beachtest... du hast die 0.95 einfach so lange angepasst, (z.b. zu 0.99123) bis es bei der durchschnittlichen Framerate eine angenehme geschwindikeit hat... oder?
Dann ruckelt auch die Bewegung, ...wenn es schnelle und langsame Frames gibt. Die Schrittweite ist FPS-Abhängig.
-
Schrompf
- Moderator
- Beiträge: 4856
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: schwammige Kamerabewegung ruckelt
Es "ruckt" auch bei jeder neuen Zielposition. Die mit so einer Formel berechnete Bewegung wird immer langsamer, je näher die Position an die Zielposition kommt. Wenn dann die Zielposition "erreicht" wurde und die nächste Zielposition angestrebt wird, wird an diesem Zeitpunkt die Bewegung abrupt wieder sehr viel schneller.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Re: schwammige Kamerabewegung ruckelt
Sorry, ich hab mich ja etwas überschlagen beim Posten, und musste dann auch gleich wieder los...
Hier also der etwas ruhigere Post:
Ich hab mich mal an Tests gesetzt: wer Lust hat sich die langen reihen anzusehen...
Die Zahlen der Geschwindigkeiten sind klar jetzt abstrakt, gelten aber als vergleichbare Richtlinien (und sind frameabhängig skaliert... pro Frame :D)
Bewegungsgeschw.: Transformation zum relativen Ausgangspunkt hinter dem Objekt
Drehgeschw.: Veränderung der Viewmatrix
Die Zahlen stehen für die potentiellen „Delta-Pixel-Veränderungen“, also der Projektionsveränderung in ganzen Pixeln des Objekts auf dem Bildschirm. Alle Tests sind mit 1600x900 und dem selben grafischen Gedöns gemessen worden.
Bewegungsgeschw.: 3
Drehgeschw.: 5
5
5
5
3
Da bei diesen Ergebnissen das Wackeln aber noch erträglich war, (habe eine Animation benutzt, um das Objekt auch immer gleich zu bewegen.) mal ein Freihandtest. Die Geschwindigkeiten liegen immernoch bei 5 und 3:
Und das kommt dem Problem schon näher. Da also die frage, ab wann ein Pixelsprung wie ein Sprung und nicht mehr wie ein Teil einer Bewegung aussieht. Also nächster Test: ein Objekt bewegt sich über den Bildschirm und die Geschwindigkeit wird langsam erhöht. Bei ca. 48 Pixeln à Sekunde ist das bei mir der Fall, dass es (eindeutig) wie ein Glitchen aussieht. (durchschnittliche Framerate 60 FPS). Sicherlich spielt hierbei die Framerate auch ne Rolle oder die Bildschirmgröße/Pixelgröße, aber bei doppelt so vielen Bildern wie das Auge verarbeiten kann, sollte das doch ok sein...
Fazit: Die Geschwindigkeitsänderungen sind das Problem (wie wir alle wissen bzw. Schrompf schon anmerkte.) Die potentiell „pseudo-random“-Bewegungen des Spielers gilt es zu smoothen. Aber eben dafür ist das Smoothen ja. Ich weiß jetzt genauer, ab wann das Problem auftritt. Aber eine Lösung hab ich noch nicht: Mehrere unterschiedliche Bewegungen der Bildschirmprojektion sorgen für doof...
Hier also der etwas ruhigere Post:
Gute Idee, aber nö. Auf ein ordentliches Skalar für alle Werte abhängig von der momentanen Framerate achte ich ganz ordnungsgemäß ;)DerAlbi hat geschrieben:Ich würde jetzt aufs gerade Wohl unterstellen, dass du die Framezeiten nicht beachtest...
Ja, so etwa meinte ich das. Ich glaube, dass das sogar so sehr zu häufig passiert, dass es eben sogar mehrmals pro Sekunde sichtbar wird (das Objekt, auf dem der Fokus liegt, hat quasi epileptische Anfälle...)Schrompf hat geschrieben:Wenn dann die Zielposition "erreicht" wurde und die nächste Zielposition angestrebt wird, wird an diesem Zeitpunkt die Bewegung abrupt wieder sehr viel schneller.
...also asynchrone Be-/Entschleunigung der Projektion auf dem Bildschirm.AyJayKay hat geschrieben:(ich glaube) da die markanten Punkte für das Auge auf dem Bildschirm einmal durch die Rotation und ein anderes mal durch die Transformation bewegt werden und sie dies aber in unterschiedlicher Geschwindigkeit und Länge/Zeit tun.
Ich hab mich mal an Tests gesetzt: wer Lust hat sich die langen reihen anzusehen...
Die Zahlen der Geschwindigkeiten sind klar jetzt abstrakt, gelten aber als vergleichbare Richtlinien (und sind frameabhängig skaliert... pro Frame :D)
Bewegungsgeschw.: Transformation zum relativen Ausgangspunkt hinter dem Objekt
Drehgeschw.: Veränderung der Viewmatrix
Die Zahlen stehen für die potentiellen „Delta-Pixel-Veränderungen“, also der Projektionsveränderung in ganzen Pixeln des Objekts auf dem Bildschirm. Alle Tests sind mit 1600x900 und dem selben grafischen Gedöns gemessen worden.
Bewegungsgeschw.: 3
Drehgeschw.: 5
5
3
Fazit: Die Geschwindigkeitsänderungen sind das Problem (wie wir alle wissen bzw. Schrompf schon anmerkte.) Die potentiell „pseudo-random“-Bewegungen des Spielers gilt es zu smoothen. Aber eben dafür ist das Smoothen ja. Ich weiß jetzt genauer, ab wann das Problem auftritt. Aber eine Lösung hab ich noch nicht: Mehrere unterschiedliche Bewegungen der Bildschirmprojektion sorgen für doof...
"Es gibt 10 Arten von Menschen, die die Binär verstehen und die die es nicht tun."
"Hier gibts Code zum Auskommentieren. Wo ist der Praktikant? Hmpf, so müssen sich Lehrer beim Kontrollieren von Arbeiten fühlen..."
"Hier gibts Code zum Auskommentieren. Wo ist der Praktikant? Hmpf, so müssen sich Lehrer beim Kontrollieren von Arbeiten fühlen..."
Re: schwammige Kamerabewegung ruckelt
Über Nacht sind mir noch zwei Dinge eingefallen:
Die Pixelzahlen da oben zeigen ja gar nicht so richtig mein Problem :D noch mal schnell nen Test; diesmal stehen die Zahlen für den Abstand des Objekts zum Bildschirmmittelpunkt.
Das sieht beim Überfliegen ganz ok aus, allerdings sind zwischendurch relativ harte Geschwindigkeitsveränderungen zu sehen (in Form von sprunghaft abweichenden Richtungen in der momentanen Entfernung).
Deshalb meine Idee: Wir simulieren doch mehr oder weniger die Realität. Die Augen bzw. für diese sichtbare Objekte verhalten sich meistens so, dass sie eine sichtbare Trägheit haben. (Kein Stein macht im Flug einen kurzen Aussetzer nach hinten. Natürlich macht das objekt das auch nicht, aber das Auge springt dementsprechend auch nicht kurz in Flugrichtung des Steins.) Ich versuch mal der Kamera eine Trägheit zu verpassen, so dass jede Geschwindigkeits- und Richtungsänderung von den vorherigen beinflusst wird.
Und voilà:
Man muss die werte zwar gut anpassen, wenn man keine Kamera auf einem Gummistock möchte :D aber leider ist das auch noch nicht die Lösung. Es sieht zwar lustiger und weicher aus aber die Wackler sind immernoch drin, vorallem wenn man versucht die Bewegung durch konstante Mausbewegung gleich zu behalten.
EDIT: Ich glaube wiedr, dass das Problem hauptsächlich bei der Überschneidung von weicher Bewegung und weicher Rotation liegt. Die Verschiebung der Projektion auf den Bildschirm sorgt für die Geschwindigkeitsänderungen, oder nicht?
Weitere Idee: Den Mausinput smoothen.
Die Pixelzahlen da oben zeigen ja gar nicht so richtig mein Problem :D noch mal schnell nen Test; diesmal stehen die Zahlen für den Abstand des Objekts zum Bildschirmmittelpunkt.
Deshalb meine Idee: Wir simulieren doch mehr oder weniger die Realität. Die Augen bzw. für diese sichtbare Objekte verhalten sich meistens so, dass sie eine sichtbare Trägheit haben. (Kein Stein macht im Flug einen kurzen Aussetzer nach hinten. Natürlich macht das objekt das auch nicht, aber das Auge springt dementsprechend auch nicht kurz in Flugrichtung des Steins.) Ich versuch mal der Kamera eine Trägheit zu verpassen, so dass jede Geschwindigkeits- und Richtungsänderung von den vorherigen beinflusst wird.
Und voilà:
EDIT: Ich glaube wiedr, dass das Problem hauptsächlich bei der Überschneidung von weicher Bewegung und weicher Rotation liegt. Die Verschiebung der Projektion auf den Bildschirm sorgt für die Geschwindigkeitsänderungen, oder nicht?
Weitere Idee: Den Mausinput smoothen.
"Es gibt 10 Arten von Menschen, die die Binär verstehen und die die es nicht tun."
"Hier gibts Code zum Auskommentieren. Wo ist der Praktikant? Hmpf, so müssen sich Lehrer beim Kontrollieren von Arbeiten fühlen..."
"Hier gibts Code zum Auskommentieren. Wo ist der Praktikant? Hmpf, so müssen sich Lehrer beim Kontrollieren von Arbeiten fühlen..."