Panorama-Video mit SDL

rapso

1. naja, wenn es für ein spiel ist, ist es normal dass es 100% braucht.
2. es gibt ja noch immer noch Sleep(10) damit weniger last erzeugt wird.
3. wenn du weißt, wie du das bild entzerrst, dann weißt du wohl auch wie du es auf z.b. 90° wieder verzerrst, wobei man das unabhängig von irgendeiner api machen kann, also bloss c++ und cpu

naja, und das mit den 180° finde ich beeindruckend für filme, ich kenne das bisher nur für photos.

rapso->greets();

LiquidAcid

Kann mir nicht vorstellen wie man mit Fisheye "fast 360 Grad" hinbekommen soll, für mich geht das allein theoretisch schon nicht, da die Cam ja irgendwo steht. Wärens wirklich 360 Grad dann würde die Cam ja auch immer auf dem Bild drauf sein, oder sehe ich das jetzt falsch? Da könnte ich mir höchstens vorstellen, dass die Cam nach beiden Seiten hin "offen" ist und jeweils 2 180 Grad Aufnahmen reinbekommt. Aber so...

geloescht

eine "fast-360°-fisheye-linse" wäre ja praktisch eine kugel, ich kann mir auch nicht vorstellen, wie das gehn soll. aber das ist gottseidank nicht mein problem.
zum 100%-prozessoerauslastungsproblem: da du in echtzeit das video verzerren musst (damit die panorama-ansicht auch schön 3d-ähnlich aussieht) wirst du sowieso praktisch immer 100% prozessorauslastung haben (kommt natürlich auch auf die auflösung und qualität an) Aber auch mit SDL kommt eine weitgehend plattformunabhängige warte-funktion, ich weiß grad nur den Namen nicht mehr Falls du also mal Zeit übrig haben solltest, kannst du sie einfach verwarten. Allerdings sollte man der Funktion immer ein paar Millisekunden weniger übergeben, als man braucht, da Multitaskingbetriebssysteme öfters die Angewohnheit haben, zu lange zu warten.
geloescht

Sgt. Nukem

LiquidAcid schrieb:

Kann mir nicht vorstellen wie man mit Fisheye "fast 360 Grad" hinbekommen soll, für mich geht das allein theoretisch schon nicht, da die Cam ja irgendwo steht.

Yo, aber 320 könnte man ja schaffen... und das sind doch schon "FAST" 360°

Oder er meint Neugrad.

durito

Hm, versteh ich das richtig?..

OpenGL -> Skybox -> Video auf Skybox ?

rapso

durito schrieb:

Hm, versteh ich das richtig?..

OpenGL -> Skybox -> Video auf Skybox ?

fast
-SkyBox + SkyCylinder

rapso->greets();

durito

yep, das dürfte ja dann nicht zu schwierig sein.

Solang keiner auf die Idee kommt nach oben zu schauen

MG80S

Woah, ein reges Treiben hier. Erstmal vielen Dank für Eure Aufmerksamkeit und Tipps. Und hier ein paar mehr Infos wegens dem regen Interesse.
Also, erstmal sorry, die 360° waren (natürlich) übertrieben. Aber man bekommt immerhin ein 2D-Abbild mit 360°x340° hin, immerhin....
Wer mal Bilder sehen will:

http://mitglied.lycos.de/mg80s
Da die pics.zip isses.

test1.jpg ist die Originalaufnahme, musste nur die oberen und unteren Ränder abschneiden, da mein Algorithmus noch recht unflexibel arbeitet....
test3.jpg ist das Gleiche mit ein paar Hilfsmarkierungen.
test3_entzerrt.jpg ist dann das entzerrte Bild, jedoch mit nem gaaanz schlechten Algorithmus. Wird (bzw. ist) schon verbessert, aber das war erstaml so zum Rumtesten, wies überhaupt aussehen kann.

Die Performance brauche ich, weil das ganze eigentlich als Plugin gedacht ist und somit der Alg nicht der einzige ist. Aber umsomehr ich darüber nachdenke, um so besser gefällt mir die "3D-Emulations-Idee". Das hat was und ist in diesem Fall wahrscheinlich auch das beste. Vielen Dank dafür.

Dann wünsch ich Euch ertsmal eine geruhsame Nacht (eher mir?)...M

rapso

emm 360°x340° wären da wohl schon zwei bilder ;), ist aber ne schöne cam die euch da die parabolidfotos/videos macht

rapso->greets();

MG80S

MG80S schrieb:

Aber man bekommt immerhin ein 2D-Abbild mit 360°x340° hin, immerhin....

Damit meinte ich auch, wenn man das Ding entzerrt, kann man "sozusagen" horizontal 360° sehen, vertikal 340°.

illuminator

So wie ich das seh müsstest du dein Bild als Textur auf die Innenseite einer (unten ein bisschen offenen) Kugel projezieren und die Kamera in die Mitte hinein stellen.
Man müsste sich halt über die Texturkoordinaten ein wenig Gedanken machen, je nachdem von welchen Bildformat man ausgeht ...

rapso

Quick&Dirty würde es so aussehen. wobei das natürlich besser geht. ich benutze hier nur das Nehe tutorial (also oGL) um das berechnete bitmap (256*256) in eine texture zu stecken und dann als quad darzustellen (geht fixer als DIB oder DD).

wobei das noch nicht performance optimiert ist, optimiert würde das sicherlich auch auf meinem gba laufen, die qualität des jpg ist scheisse und ich hab nirgens filtering an.. quick&dirty eben.
mit der linken maustaste kann man rotieren,
mit dem mausrad ne art FOV einstellen (FISCHAUGE*alarm* )

und wie gesagt, alles nur 2d operationen.

rapso->greets();

MG80S

Woah, krasse Sache! Vielleicht "Quick&Dirty", darür aber sehr zweckmäßig.
Jetzt also doch OpenGL? War eingentlich gerade dabei die 3D-Geschichte in 2D-Koordinaten umzurechnen? Oder hast Du das vorher auch gemacht?
Wenn ja: Ich hab da irgendwie noch nen Logik-Fehler drin:
Wenn ich von vorn auf einen Cylinder schauen, habe ich ja theoretisch in den Aussenbereichen meines "Blickwinkels" mehr Bildinformationen, da ich hier mehrere Pixel der Krümmung auf eine 2D-Ebene projeziere. Wie man ja an Deinem Prog auch sehr gut sieht, sind in den Aussenbereichen ja viel weniger Infos, was die Pixel ordentlich auseinanderzieht.
WHY?!?
Hängt das mit dem "menschlichen Auge" bzw. Linsen im Allgemeinen zusammen?
Habe dann aufgrund der Beobachtung versucht, eine Funktion der neuen Pixel auf alte (Originalbild) zu schreiben. Habe es per Tangens und x³ versucht um in den Aussenbereichen weniger Infos zu haben als innen, aber irgendwie stellt mich das noch nicht zufrieden.
Mal nebenbei: Hast Du mal die fps Deines Progrs gemessen? Für den Fall, dass ich mich z.B. immer drehe oder ähnliches. Würde mich mal interessieren (auch ohne perfekte Perfomance). Meine ist nämlich (noch) ziemlich grottig.

Tiefsten Respekt ... M

MG80S

Und nochmal @rapso:

Du suchst nicht ganz zufällig einen mäßig gut bezahlten, dafür aber sehr interessanten Nebenjob?

Die o.genannte Sache ist nämlich gerade im Aufbau.

Nunja, ich meld mich wieder, wenn ich auch mal n Ansatz fertig habe....... M

rapso

das programm hat zur zeit ca 50fps, wobei es zum einen langsammer werden würde wenn man für das bild lineare filterung einbauen würde, auf der anderen seite kann man einiges vorberechnen (was ich mir wegen Quick&Dirty ersparrt habe ) und das würde das programm wiederrum viel fixer machen.

wie ich schon gesagt habe, benutze ich openGL nur zur darstellung der textur in die ich das fertigberechnete bild reinstecke, das ist vom programmieraufwand am fixesten.

das mappen muss eigentlich auf eine sphere und nicht auf einen cylinder. normalerweise würdest du ja so projezeiren für euer parabolidbild

laenge = sqrt(x*x+y*y+z*z);
x'=x/laenge;
y'=y/laenge;

nun mußt du die projektion umkehren damit das photo auf den bildschirm 'reprojeziert' wird, dabei hast du natürlich das problem dass du kein z hast, das mußt du dir ausdenken (darüber wird dann die stärke des fischaugeneffekts gesteuert ).
es bietet sich an von -1.f bis +1.f für x und y zu gehen, dann kann man fürs erste ein z von ca 1.f wählen. (die schritweite ist natürlich 2.f/SizeX bzw 2.f/SizeY).

emm.. ja, hab ich was vergessen?

rapso->greets();

rapso

MG80S schrieb:

Und nochmal @rapso:

Du suchst nicht ganz zufällig einen mäßig gut bezahlten, dafür aber sehr interessanten Nebenjob?

just drop me a mail

rapso->greets();