Kollision mit Objekten aus Filmsequenz - a la Rebel Assault
-
Hallo zusammen,
ihr erinnert euch besitmmt an die Level in Rebel Assault - dort wird einem eine Filmsequenz eingespielt, auf der zB ein Flug durch einen "Kristall"Canyon zu sehen ist. Man steuert da dann einen gezeichneten A-Wing durch, kann aber auch mit den Felsen kollidieren.
Wie haben die nun diese Kollisionen genau umgesetzt?
Klar, die Kollision hat nichts mit den zu sehenden Objekten zu tun, die gibts ja nur im Film, aber wie sonst? Merken die sich die Abspielzeit und definieren dann pro Szene bestimmte Kollisionspunkte? Viel aufwendige Arbeit finde... weiß jemand was?
-
Gibt mehrere Möglichkeiten...
Vermutlich müsste es gehen, wenn man sich das Video rausrendern lässt, und zu jedem Frame den z-Buffer abspeichert.Oder, wenn das Video sowieso schon in einem 3D Programm gemacht wird, macht man ne viel einfachere Kollisions-Geometrie, und speichert die mit ab. Plus die Kamera-Matrix zu jedem Frame.
-
hustbaer schrieb:
Vermutlich müsste es gehen, wenn man sich das Video rausrendern lässt, und zu jedem Frame den z-Buffer abspeichert.
Der z-Buffer bleibt doch gleich, der Film wird doch Tiefenmäßig an einer Stelle abgespielt?! Wie meinst Du das?
hustbaer schrieb:
wenn das Video sowieso schon in einem 3D Programm gemacht wird
Geht sowas zB in Blender? Oder welches 3D Programm meinst Du zB?
-
iop schrieb:
hustbaer schrieb:
Vermutlich müsste es gehen, wenn man sich das Video rausrendern lässt, und zu jedem Frame den z-Buffer abspeichert.
Der z-Buffer bleibt doch gleich, der Film wird doch Tiefenmäßig an einer Stelle abgespielt?! Wie meinst Du das?
beim rendern vom film gibt es einen zbuffer. nicht abspielen, sondern bei lucas arts auf der server farm
hustbaer schrieb:
wenn das Video sowieso schon in einem 3D Programm gemacht wird
Geht sowas zB in Blender? Oder welches 3D Programm meinst Du zB?
ich denke man hat einfach 3 praktikanten genommen und die haben dann an schwarzweiss bilder gemacht die angaben wo man bei einem bestimmten frame nicht sein darf.
das bekommt jeder hin und ist kostenguenstiger als jemanden etwas aufwendiges programmieren zu lassen dass man noch testen und bugfixen muss.
-
kann man mal das video sehen? Ich glaube ich finde nicht das richtige auf YouTube.
-
http://www.youtube.com/watch?v=PsmYbY_jHpI
die waende sind die hindernisse
-
Oben sprach ich von diesem Level http://www.youtube.com/watch?v=YJUWTROjNvY&feature=related aber im Endeffekt tut das nichts zur Sache...
Ok, vom Prinzip her kann ich mir jetzt vorstellen, wie man sowas macht, wenn das Video (also die Umgebung quasi) am Rechner in einem 3D Programm erstellt wurde.
Was wäre denn (und das interessiert mich eigentlich mehr), wenn ich ein "normales" Video hätte, also einfach per Kamera aufgenommen? Hier gibt es ja keinen z-Buffer.
Übrigens vielen Dank schon einmal bis hierhin
-
iop schrieb:
Ok, vom Prinzip her kann ich mir jetzt vorstellen, wie man sowas macht, wenn das Video (also die Umgebung quasi) am Rechner in einem 3D Programm erstellt wurde.
Wie du richtig erkannt hast, ist das kein Video, sondern eine Spielwelt, deren Aufbau irgendwo in einer Datei abgespeichert wurde. Und beim Bewegen durch die Spielwelt wird einfach überprüft ob du mit einer Wand-Koordinate kollidierst.
Das ist die Standartvorgehensweise bei jedem Computerspiel.iop schrieb:
Was wäre denn (und das interessiert mich eigentlich mehr), wenn ich ein "normales" Video hätte, also einfach per Kamera aufgenommen? Hier gibt es ja keinen z-Buffer.
Wie soll das denn funktionieren? Ein Video ist immer zweidimensional. Dort kann nie überprüft werden ob du mit einem Objekt kollidierst, weil man ja gar keine Entfernung bestimmen kann. Bei einem 2D-Spiel, in dem man sich nur in eine Richtung bewegen kann, mag so etwas funktionieren, da man hier nur die Hintergrundfarben überprüfen muss um zu gucken ob sich der Spieler irgendwo befindet wo er sich nicht aufhalten darf, aber da benutzt man Hintergrundbilder und keine Videos.
Außerdem existieren in einem Video überhaupt keine Informationen was sich außerhalb des Videos befindet. Du könntest die Kamera in einem Video nie bewegen, da du dazu ja von einem anderen Punkt aus auf das Geschehen des Videos sehen müsstest.
-
dann müssen die von rapso erwähnten praktikanten herhalten.
bloss für kollision reicht ja eine einfache bitmap (pro frame natürlich) mit zwei farben (schwarz=ok, weiss=kollision). zumindest wenn das schiff sich nur in der bildschirmebene bewegen kann, und in der z-richtung "fixiert" ist.
diese kollisions-bitmap kann man nun entweder auf dem z-buffer erzeugen, oder von hand malen.
der z-buffer hat natürlich noch den weiteren vorteil, dass objekte die sich auf nicht vorherbestimmten pfaden bewegen, in die szene einblenden kann. denkbar wären z.B. gegner, die von einer KI gesteuert werden.
-
hustbaer schrieb:
...(pro frame natürlich) ...
naja, man kann davon ausgehen das in den meisten frames die bitmap nur weiss ist, theoretisch kann man es also weglassen und nur in manchen frames extra "einbauen"
ich glaube das spiel hatte ne simple kompression wie in flv bzw flc dateien, dort ein extra frame mit den "hits" einzubauen sollte nicht aufwendig gewesen sein.
aber
Antoras schrieb:
iop schrieb:
Was wäre denn (und das interessiert mich eigentlich mehr), wenn ich ein "normales" Video hätte, also einfach per Kamera aufgenommen? Hier gibt es ja keinen z-Buffer.
Wie soll das denn funktionieren?
theoretisch koennte man , wenn der flug tunnelmaessig ist (wie bei rebelassault), ueber die vectoren der motion compensation in etwa schaetzen wie weit die objekte entfernt sind, wenn die geschwindigkeit konstant ist.
nicht 100% akkurat, aber es waere sehr wenig aufwand, eigentlich.
-
rapso:
Hast du dir mal die Motion-Compensation-Vektoren angesehen, die ein Encoder so ermittelt? Die stimmen oft so garnicht mit der tatsächlichen Bewegung von Objekten zusammen...
-
hustbaer schrieb:
rapso:
Hast du dir mal die Motion-Compensation-Vektoren angesehen, die ein Encoder so ermittelt? Die stimmen oft so garnicht mit der tatsächlichen Bewegung von Objekten zusammen...ich habe es oft genug implementiert, sie sind oft sehr passend, gerade bei solchen monotonen bewegungen. die vectoren sind auch oft anhand der vectoren der vorherigen frames bzw der nachbar bloecke "estimated", ich denke das waere noch die beste moeglichkeit. man muesste sich aber auch die einzelnen filme dahingehend anschauen, es kann sein dass bei fluegen die nahen objekte dermassen schnell sind, dass sie immer einen neu encodeten block haben.
das kommt dann auch auf die quelle an, CG movies haben vielleicht keinen blur und es ist so, mit blur hat man eventuel keine neuen bloecke.alles eine frage des ausprobierens.
