360°-Panorama-Engine

[blackdrake]

Hallo,

ich möchte gerne versuchen, mit Delphi eine Spielengine ähnlich dem alten Spiel "Zork Nemesis" bzw. "Zork Grand Inquisitor" zu schreiben. Für alle die die Spiele nicht kennen, handelt es sich hierbei um ein Point-n-Click Adventure mit Panorama-Bildern. Man kann also nach links und rechts scrollen und sich so im Raum bewegen. Anschließend kann man etwas anklicken und so kommt man dann zum nächsten Panorama-View.

Es ergeben sich grundsätzlich 3 Probleme

1. Erstellen der Panorama-Bilder
2. Finden des Algorithmus zur räumlichen Darstellung
3. Performance

Zu (1) dachte ich mir, dass ich ersteinmal auf 3D-Programme verzichte, sondern einfach mal Fotos von meinem Zimmer mache. Ich habe dazu ca. 7 Fotos gemacht und diese mit einer Software "Microsoft Composion Editor" professorisch zusammengesetzt.

Das Ausgabebild sollte nun Panorama-Fähig sein. Es fällt auf, dass Gegenstände, die zuvor Gerade waren (z.B. mein Schreibtisch) im 360°-Bild gekrümmt sind.

Zu (2): Ich habe lange versucht, durch Skizzen mit vorzustellen, wie man das Bildmaterial bearbeiten müsste, damit es wie ein echter Raum aussieht. Ich denke, dass sich das Bild wie eine Rolle um den Betrachter wölben soll, die "Rolle" also am Horizont liegt. Dabei soll die Seiten links und rechts einem "entgegenkommen" und der Punkt, auf den man schaut sollte am weitesten Entfernt sein. Ob diese Transformation aber so stimmt, weiß ich nicht.

Ich fand leider keine passenden Informationen im Netz und auch zu der Froschaugenperspektive habe ich nichts gefunden.

Übrigens: Ich möchte selbstverständlich nicht, dass das Foto verzerrt wird, sondern man sollte schon den Eindruck haben, dass es sich um einen quasi realistischen 3D-Raum handelt. (Natürlich mit geringfügigen Einschränkungen durch das 2D-Fotomaterial)

Zu (3): Dies wird ein erheblches Problem darstellen und wohl nur über DirectX lösbar sein. Problematisch wird sein, dass ich die Bildtransformation bei jedem Pixel, den ich links oder rechts scrolle, wiederholen muss. Es ist mir ein Rätsel wie man das damals zu Zeiten von Zork (1994) ohne DirectX und Co. hinbekommen hat, ohne dass etwas geruckelt hat.

Ich habe bisher nicht all zuviel mit DelphiX gearbeitet und kenne dort nur die Benutzung von Sprites. Leider ist dieses Problem ja nicht durch Sprites lösbar.

Lösungsansätze für die Panorma-Darstellungen wären

a) Transformation des 360-Bildes und Neu-Transformation beim Scrollen.
b) Arbeiten mit echtem 3D: Man erstellt eine Kugel oder einen Zylinder und lässt das Panorma-Bild in diesem Zylinder/Kugel rotieren, was den Eindruck von "sich drehen" bewirkt. (bzw. die Kamera rotiert)

Kennt jemand einen guten Algorithmus oder Vorgehensweise für so etwas bzw. kann mir bei dem mathematischen Transformationsansatz helfen?

(PS: Und ja, dieses Spiel, das ich plane soll ein "alter Schinken" werden, also auch ein Point-n-Click, sehr simpel gestrickt)

Grüße
blackdrake

[Alexander Kornrumpf]

Der Trick besteht eigentlich darin dass man die Bilder nur von dem Punkt aus sehen darf von dem aus sie aufgenommen wurden.

Also im Falle eines Zimmers z.B. machst du von der Mitte des Zimmers ein Foto von jeder Wand (in 3D Programmen leicher umzusetzen als in Realität) und die 6 Fotos setzt du dann wieder zu einem Raum zusammen. Ein Betrachter der nun ebenfalls in der Mitte des (virtuellen) Zimmers steht, kann sich beliebig drehen (umsehen) und wird den Effekt nicht bemerken. Sobald er sich aber bewegt fällt es auf.

Wenn ich mich nicht sehr schwer täusche waren Adventures damals eigentlich alle so dass man von Ort zu Ort teleportiert wurde um genau das zu vermeiden. Ich denke das was du mit scrollen meinst ist in wirklichkeit "umsehen". Myst/Riven wären noch klassische Vertreter.

P.S. Kann sein dass ich gerade auch Mist erzähle aber ich bin 99% sicher das mal implementiertgesehen zu haben und total erstaunt gewesen zu sein dass es klappt. Um ehrlich zu sein bin ich das immer noch.

[Stefan Zerbst]

Alexander hat Recht, der Betrachter darf sich nicht "verschieben", sondern nur drehen. Ansonsten passt die Darstellung des Bildes nicht mehr zu der Perspektive mit der es aufgenommen wurde und es sieht optisch einfach falsch aus.

Die Linien brauchst du auch nicht selber zu krümmen, das macht die Perspektive ganz allein für dich. Du musst tatsächlich alle Bilder vom selben Standpunkt aus aufnehmen und sie dann auch im virtuellen 3D so anordnen, dass sie zueinander passen. Der Betrachter darf sich dann halt nur auf der Stelle drehen, aber nicht bewegen.

Wenn du alle Bilder vorher mit einem anderen Tool zu einem Panorama verschmilzt, dann kannst du das im 3D nicht vernünftig darstellen weil dann die Perspektivie auf Teile des Bildes immer falsch ist.

Schau dir mal das folgende Video an: http://www.youtube.com/watch?v=x4TRNhPRQ2Q

Ist leider viel mit Unschärfe gearbeitet worden. Aber die Szene in der die Kamera das Geschoss verfolgt besteht auch nur aus Fotos der Gasse mit den Müllcontainern im Hintergrund. Diese Fotos der Gasse sind genauso "gemacht" wie ich das oben beschrieben habe. Alle Fotos vom selbern Standpunkt aus aufgenommen und dann im 3D (Adobe After Effects) im virtuellen 3D Raum mit Augenmaß so platziert, dass sie optisch passend aneinanderliegen. Dann ist die virtuelle Kamera (Adobe After Effects) entsprechend in einer Animation von einem festen Standpunkt aus rotiert. Im Endeffekt sieht das dann so aus, also ob die Kamera Während des Schußes vom Schützen der Kugel folgend geschwenkt worden wäre.

Und ich denke das ist der Effekt, den du erreichen möchtes. Es sieht aus wie eine flüssige Augenbewegung im Raum, ist aber nur eine Ansammlung von Fotos die geschickt im 3D verteilt sind.

Ciao,
Stefan

[blackdrake]

Hallo,

danke für euere Antworten.

Ja, das ist richtig. Es geht mir nur um das Drehen. Laufen kann man in dieser Spielserie nur durch Klicken. Dann kommt man zu einem neuen Panorama, das von einem anderen Standpunkt aus aufgenommen wurde.

Habe ich es richtig verstanden, dass ich also von 4 Wänden ein Foto (theoretisch) exakt von vorne machen soll und diese Fotos dann als "aufkleber" für einen Cube im 3D-Raum verwenden soll? Dies würde das Problem der perspektivischen Verzerrung beheben, allerdings bin ich dann auf "Räume" eingeschränkt. Wenn ein Raum eine andere Form hätte, gäbe es ein Problem. Und wie würde ich es dann machen, wenn ich z.B. im Wald oder auf der Straße stehe und ein scrollbares Panoramabild erstellen will?

Activision hat mit seiner "ZVision Surround" Engine es damals geschafft, ganz ohne 3D und DirectX, von einem reinen 2D-Bild ein scrollbares Panorma zu erstellen, ohne dass die Perspektive verzerrt war. Es war dort egal, ob man "4 Wände" oder gar keine Wände hatte, da das Panorama scheinbar auf eine Art Kugel oder Zylinder gepackt wurde.

Hier mal ein Screenshot von einer Tempelhalle:



Ich habe durch Zufall ein Tutorial gefunden, wie man die "Textures" aus dem Spiel dekomprimiert. Dort kann man sehen, welche Bilddaten das Spiel für die Panorama-Darstellung verwendet. Hier die selbe Tempelhalle als 2D-Quellmaterial (allerdings von einem anderen Standpunkt aus aufgenommen):

Original-Bildmaterial von Zork: Nemesis

Hier nocheinmal ein ganz anderes Bild, bei dem es sich definitiv nicht um einen Raum mit 4 Wänden handelt. Es spielt im Freien. Trotzdem wird der Tempel beim Drehen im Spiel nicht verzerrt.

Ein anderes Bild

(Ich hoffe es ist OK, dass ich das Bild anhänge, obwohl es eigentlich rechtlich geschützt ist. Man kann den Aufbau des Bildes allerdings schlecht beschreiben)

In Anlage #2 habe ich meinen Foto-Panorama versuch mit "Microsoft Composion Editor" beigelegt:

Zimmer mit MCE zum Panorama zusammengefügt

Nun ist die Frage, ob das Erzeugnis von MCE perspektivisch her brauchbar ist oder ob das Programm ungewollt irgendwelche falschen Verzerrungen eingebracht hat. Ich sehe sowohl beim Original als auch bei meinem Nachbau eine gewisse Krümmung im "Raum", aber ob die beiden Bilder in einer Engine kompatibel wären, weiß ich nicht.

Habt ihr eine Idee, wie man nun ein solches Bild (das nicht zwangsläufig in einem Raum mit 4 Wänden spielen muss) in einem Panorama scrollen kann? Oder eventuell eine Idee, wie Activision die Engine damals entwickelt hat, um das 2D-Bildmaterial aus Anlage #1 so darzustellen, dass man denkt, es sei ein 3D-Raum, in dem man sich dreht?

Grüße
blackdrake

[Krishty]

Die Fotos aus dem Spiel müssen auf die Innenseite eines Zylinders aufgetragen werden – das sieht man daran, dass sie zwar entlang der X-Achse gekrümmt sind (also musst du auch eine entlang der X-Achse gekrümmte Fläche benutzen), nicht aber entlang der Y-Achse.

Die Fotos deines Zimmers sind zusätzlich entlang der Y-Achse gekrümmt, du müsstest sie also auf die Innenseite einer Kugel auftragen.

Bilder, die man auf die Innenseite eines Würfels aufträgt, haben – genau wie der Würfel – keine Verzerrung sondern nur abrupte Sprünge in den Ecken und Kanten.

Ob du nun einen Raum darstellst oder ein Panorama, hat auf die Form keinen Einfluss, da du dich nie bewegst – und deshalb auch die Richtungen aller Texel statisch sind. Es geht einfach nur darum, dass in eine bestimmte Richtung der richtige Texel gewählt wird. (Ich benutze z.B. einen Texturwürfel, der auf die Innenseite eines Tetraeders aufgetragen wird – aber da die Texelkoordinaten wieder kubisch ausgerechnet werden, sieht man keinen Unterschied. Ich könnte es auch auf die Innenseite eines Labyrinths pappen und man würde es nicht merken.)

Gruß, Ky

[blackdrake]

Hallo. Vielen Dank für deine Antwort. Wow, trotz genaustem Hinsehen, fällt mir die Y-Achsenkrümmung in meinem MCE-Bild nicht auf. (Komisch, der Türrahmen etwas rechts im Bild sieht irgendwie ziemlich gerade aus?) Aber die doppelte Krümmung macht wohl in sofern sinn, dass man auch "4D"-Panoramas erzeugen könnte, die sowohl horizontal als auch vertikal scrollbar sind.

Ich denke, dass man das mit DelphiX mit einem 3D-Sphere, Textur und rotierender Kamera gut lösen kann. Diesbezüglich suche ich mal nach Beispielcodes. Sehe ich das richtig, dass ein Versuch, das ganze mit Bildtransformationen zu lösen, unnötig kompliziert ist?

Gruß
blackdrake

[Krishty]

Wow, trotz genaustem Hinsehen, fällt mir die Y-Achsenkrümmung in meinem MCE-Bild nicht auf. (Komisch, der Türrahmen etwas rechts im Bild sieht irgendwie ziemlich gerade aus?)

Du hast vollkommen Recht – ich habe vor allem auf die Stelle mit dem PC-Bildschirm und den Gardinen geguckt, da kommen kaum rechte Winkel vor. Mein Fehler. Zylinder müsste passen … aber achte darauf, dass du es nicht genau horizontal darstellst! Du hast die Kamera bei den Aufnahmen nicht horizontal gehalten, sondern nach unten gekippt – darum musst du auch entweder die Textur auf dem Zylinder nach unten verschieben oder stattdessen die Kamera nach oben hieven (die einfachere Lösung).

Sehe ich das richtig, dass ein Versuch, das ganze mit Bildtransformationen zu lösen, unnötig kompliziert ist?

Meiner Einschätzung nach reicht es, wenn du es so auf einen Zylinder pappst; die übliche 3D-Mathematik mit Projektion und allem erledigt dann den Rest. Bürgen kann ich dafür aber nicht … zylindrisch habe ich das selber noch nie implementiert.

[Chromanoid]

Zu (3): Dies wird ein erheblches Problem darstellen und wohl nur über DirectX lösbar sein. Problematisch wird sein, dass ich die Bildtransformation bei jedem Pixel, den ich links oder rechts scrolle, wiederholen muss. Es ist mir ein Rätsel wie man das damals zu Zeiten von Zork (1994) ohne DirectX und Co. hinbekommen hat, ohne dass etwas geruckelt hat.

Ich kann mir kaum vorstellen, dass du große Performance-Probleme bekommst. Das größte "Panorama-Adventure" Google Streetview ist übrigens mit Flash gemacht...

[blackdrake]

Ich kann mir kaum vorstellen, dass du große Performance-Probleme bekommst. Das größte "Panorama-Adventure" Google Streetview ist übrigens mit Flash gemacht...

Nun, wenn man es "richtig" macht, bekommt man keine Performance-Probleme. Aber ich denke, dass sowohl die DOS-Engine des Zork-Spiels als auch die Flash-Engine von Google recht aufwändig zu entwickeln sind. Wenn ich den mathematischen Aspekt der Zylinder-Transformation mit einer TPaintbox (und einem mathematischen Algorithmus zur Raumdarstellung) machen würde, wäre die Performance hinüber. Ich denke daher, dass es am einfachsten und sichersten ist, direkt eine vorhandene 3D-Engine nutzen, um einen Zylinder mit Textur zu rendern.

[Stefan Zerbst]

Hi,

ja das Mapping auf einen Zylinder oder eine Kugel oder auf einen Würfel (Stichwort Environmentmapping) ist auch eine Alternative. Ob vier Bilder für einen Raum ausreichen muss man ausprobieren, eventuell brauchst du auch mehr. Anstatt alles auf einen Zylinder zu mappen wäre ein nativerer Ansatz, dass du z.B. 8 oder mehr Fotos machst, und diese auf Rechtecken im Raum aufstellst. Das dürfte dem Zylinder optisch nicht viel nachstehen, ist aber vom Mapping her einfacher. Und als Start sowieso erstmal :)

Es ist im übrigen egal, ob es sich dabei um einen Raum mit vier WÄnden handelt oder um eine Landschaftsaufnahme.

Es gibt aber noch mehr zu berücksichtigen: Bemüh mal Google zu den Stichworten "Camera Calibration", "intrinsic and extrinsic camera parameter". Je nach Brennweite der Kamera hast du es zum Beispiel mit einer Verzerrung (Distortion) der Aufnahme zu tun. Normalerweise gerade Linien im Raum sind auf dem Foto dann ridial verzerrt, werden also gerade in den Randbereichen zu "gekrümmten" Kurven. Dazu sollte man die Projektion des 3D auch an die Brennweite der Kamera angleichen, die zu den intrisischen Parametern der Kamera gehört.

Je kleiner die Brennweite ist (Weitwinkel) desto größer wird im übrigen die Verzerrung auf den Bildern. Das kann den gewünschten Effekt im Programm nachher zusätzlich torpedieren.

Ciao,
Stefan

[joeydee]

Bei den älteren Pano-Engines war das tatsächlich nur eine Zylinderprojektion, damit musste man nur spaltenweise ein Bitmap umkopieren: die Bildschirmebene wurde von links nach rechts durchgegangen und für jede x-Position der Winkel berechnet, den der entsprechende Strahl mit der Blickrichtung bildet. Dann die entsprechende Spalte aus dem Quellbild in die aktuelle Spalte des Zielbildes kopiert, fertig.
Eine reine 2D-Dreiecks- und Winkelgeschichte mit damals nur 320(!) Winkelberechnungen je Frame, wenn man sich das von oben aufzeichnet wird's klar. Wenn man den Winkel richtig berechnet, ergibt sich der richtige Eindruck beim Scrollen. Die Spalten werden also nicht einfach 1:1 umkopiert.

Trotzdem rate ich zu einer Skybox, deren Maps aus einem Renderer kommen. Das ist am einfachsten zu lösen, und man hat 3-Achsen-Freiheit, kann also auch nach oben/unten schauen.

Vor knapp 8 Jahren (ups, wirklich schon sooo lange her?) hab ich mal ein Skyboxtutorial hier veröffentlicht:
http://old.zfx.info/Tutorials.php?ID=88
Da der Download nicht mehr geht, hier nochmal meine alte Datei:
http://enter.diehlsworld.de/ogl/skyboxa ... skybox.zip

Das Coding ist sicher grausig ;-) aber die Theorie dahinter stimmt noch immer.