Az objektumot szeretném forgatni, első körben "kurzor billentyűkkel"

Na akkor most egy tömör mondatban ird le, hogy mit is akarsz csinálni?
Valamilyen kamerát vagy objektum forgatást? És mivel? Egérrel?

Kösz, ezt holnap megnézem, most már bosszant ez a workaround.

Az y tengely már a helyén marad.

Szóval előbb csak azért is, aztán beleolvasok a forrásba.


EDIT: Na jó belelestem, kísértetiesen hasonlít a képlet az enyémre, majd azért össze vetem.

dmg
http://www.az.cs.is.nagoya-u.ac.jp/class/comp-sys/programs/trackball.c

Na jó feladom.

Most már minden lehetséges variációt kipróbáltam, átvariáltam a Projection és ModelViewMatrix kezelésemet is, mert kicsit szar volt elvben, de lehet, még mindig az és az a gond.

Kezdjük az alapoknál.

Szóval van egy projectMatrix-om, amit az elején beállítok perspektívre, és békén hagyom.

Van egy ModelView Matrixom, amin végzem az eltolást, forgatást, skálázást.

Majd ezekből számolom ki a ProjectionViewmatrixot (projection * modelview), ez lesz aztán átadva a shadernek, amivel dolgozik.


Nem tudom ez jó-e eddig minden működött vele szépen, most amit variáltam rajta, hogy eddig a teljes projectionviewmatrix-ot forgattam toltam skáláztam.



na most, erre jön a katernió.

Ügye van 3 szögem x, y, z. Ezek megfelelő tengelyen való forgatásából gyártok 3 katerniót.

Így:



Aztán ezeket összeszorzom (a sorrendben nem vagyok biztos, valahol azt írták, hogy y*z*x, de mindenhogy szar.)

Ha összeszoroztam, akkor az eredményből kinyerem a forgási szöget, meg a tengelyt.
Így:


Aztán ezzel a szöggel, és tengellyel forgatom el a modelView matrixot. A 3 külön tengelyes elforgatás helyett.

Na az eredmny Bimbal Lock.



Aztán, gondoltam ez így nem kóser.

Csináltam egy egység matrixot, amit elforgattam a megkapott szöggel a megkapott tengelyen.
Majd ezt szoroztam hozzá a modelview matrix-hoz. Na ennek az eredménye ugyan az, mintha a katernió-ból csinálnék mátrixot. forgás közben a teszt kocka, mint valami papír doboz összecsuklik.




Ebből már rá tud valaki világítani, hog ymit csinálok rosszúl? mit felejtek ki a "képletből"


GOndoltam átverem, hagyom a katerniót, és a következőt eszeltem ki, ami így elméletben tök jónak tűnt.

Szóval elöbb forgatok X tengelyen ß fokkal. Aztán mielőtt forgatnék y tengelyen ¤ fokkal előbb magát az y tengelyt forgatom el -ß irányba, így elméletben visszaforgatom az í tengelyt a helyes irányba nem? lehet a megvalósítás sántít és nem az elmélet, de ez sem működik, most ellenőrzöm, hogy miért is, de akkor is csak workaround.

HELP!

Hát azt én sem tudom miért kell belekeverni a kamerát. Csak amit találtam leírst, az ezt mondogatja.

-Namost ahogy lén csinálnám (felteszem nem jól)

Van egy rx, ry, rz forgási szögem, amiket balra, jobbra, fel, le tudok növelni (pontosabban csak x és y szögeket, z marad 0 fok.

Na ezekbőla forgási szögekből számolok egy-egy kvaterniót.

Ezeket összeszorzom.

Majd az eredményből, kinyerem a forgási szöget, és a tengelyt.

Amivel aztán egy glRotate(alfa, qx, qy, qz)-el elforgatom a testet.

De ez így szemmel láthatóan nem jó. Persze most hogy leírom, kezdem kapizsgálni hogy hol van a bibi. Na majd este folyt.köv.

Nahát ezexerint kínaiul is tudok. Nofene

Most mi is a feladat? Objektumot forgatni? Akkor mért kell belekeverni a kamerát?

- a forgatási sebességböl (egérrot * speed) kiszámolod a yaw, pitch, roll -t
- mindegyikböl csinálsz egy kvaterniot
- ezeket összeszorzod
- és megszorzod a jelenlegi orientációval

Asy, az a baj, hogy a te kódod nekem tök kínai a sok DX-es szintaktikátol.

Na, annyi már talán világos, hogy a katernióm az jól működik, csak rosszúl alkalmazom.

Azt mondja a cucc, hogy fogni kell a 3 tngely forgási szögét, ebből csinálni egy átmeneti katerniót, ez meg is van. Ezt a katerniót kell összeszorozni a kamera kvaterniójával, na talán itt a bibi. a kamera kvaternióját honnan nyerem ki?

Csak így vázlatpontokban, kvaternióval most akkor hogy is kell forgatni egy testet, mert lehet hgoy én értem félre?



EDIT:

Na végszóra találtam egy ilyet, ami nekem rémlik.

Szóval hogy egy egység mátrixon előbb elvégezzük a forgatásokat, aztán szorozzuk hozzá az így kapott mátrixot a modelview-hoz. Szóval valami rémlik, hogy ilyennel szórakoztam régebben, de már nem emlékszem kristály tisztán. Most már nem próbálom ki, elzsibbadtam, majd holnap.

Idézet

---

DMG :
Nem akarsz rá Tutorialt írni?

---

Meg lesznek majd valamikor emlitve (de mivel a dummyban van 50 féle példa ezért nem olyan sürgös nekem ).

dupla (mobilról)

Meg a glm-et lenne erdemes megnezni, azt kifejezetten az opengl-hez irtak/irjak.

Kösz!

Megnézem amint hazaértem.

java-hoz kerestem Quaternion osztályt de nem találtam eddig semmi használhatót.


EDIT:

Alap esetben én x,y,z Euler szögekből (ez a becsületes nevük?) számolom a kvaterniót, most találtam egy doksit, ami a tegnapival szemben teljesen más sorrendben végzi az egyenletet, és azt írja, hogy meg sem szabad változtatni, hát megnézem, hátha csak ennyi a baja. Aztán megnézem az a mathlib forrást is, igaz első ránézésre nem láttam benne a megoldást, de elszokott a szemem a C++-os forrásoktól szóval még vetek rá egy pillantást maly otthon is.

Én simán lenyúltam függvényeket hozzá - azt hiszem innen:
http://tfc.duke.free.fr/

Nem akarsz rá Tutorialt írni?

A kavterniókat szerintem senki sem érti, csak használják öket

Hát nekem ez most nem megy. Csináltam kavernió-t de az eredmény első próbálkozásra gimbal lock lett második próbálkozásra, hát... kicsit furcsa. Most tökre nem arra forog amerre mondom neki, meg még előjelet is vált valahol.

Na jó majd holnap szarakodom vele, aztán segítségért kiáltok ha végkép feladom, kösz az eddigieket!

Köszönöm!

Kvaternió-t nézegetem. Hogy utálom az ilnye körmönfont módon ábrázold képleteket, mire kihámozom belőle, hogy mi micsoda, addigra már golyózik tőle a szemem.

Ha gimbal lock akkor kvaternió. Amikor pedig renderelni akarsz akkor a kvaternió, pozíció párosból tudsz mátrixot gyártani.

Idézet

---

DMG :
Megnézem, de még nem találkoztam eddig vele.

Hát az alap probléma, mondjuk egy test, amit érintéssel tudsz forgatni (vagy egértrel, ha PC-s oldalon maradunk) Na most vertikális iránybe elforgatod 180 fokkal, akkor ahorizontális irányba forgatásnál pont az ellenkező iránybe fog forogni, mint ahogy te szeretnéd, hogy forogjon. Ez jelentkezik mondjuk akkor is, ha egy adott pályán egy golyót gurítok ilyen transzformáció segítségével, nem tudom, mennyire érthető a probléma.

EDIT:

Közben rátaláltam a megfelelő kulcsszavakra google-ben, azt hiszem már tudom milyen irányba kell elinduljak, azért még hátgha tud valaki valami hasznos félmondatot.

---

Ezt a problémát hívják gimbal locknak és például egy megoldás rá ha kvaterniókkal forgatsz (viszont nehezebb értelmezni mint a mátrixokat).

Az XNA honlapján valamelyik (talán többen) sampleben van egy arcballcamera; abban a Free beállítás felel meg a gimbal lock-mentességnek (ha jól emlékszem még).

Söt a dummyban levö repcsis sample-ben a repcsi forgatása is gimbal lock mentes (és kvaterniós).

Sztem ezeket csekkold.

Most már a nevét is tudom, szóval a "Gimbal Lock" hatást akarnám elkerülni.

Syam: úgy nagyából világos, de most valahogy nehezebb az agyam a szokottnál, szóval a minor matrixot melyik sor/oszlop eldobásával nyerem ebben az esetben? Bocs a tök alap kérdésért, szégyellem is magam.

Amúgy találtam egy ilyen linket, ami pont ezzel foglalkozni, most olvasgatom.

http://www.gamedev.net/page/resources/_/reference/programming/math-and-physics/quaternions/quaternion-powers-r1095

Szóval csak a pozíciót akarod mozgatni forgatással, de a test orientációját nem?
Ha igen, akkor 2 lehetőséged van:
- lemented a test minor mátrixát, eforgatod és visszaírod a végeredménybe a minor mátrixot
- csinálsz egy pontot a test mátrixának eltolásából azt beszorzod a kívánt mátrixszal és visszaírod a test mátrixának eltolás részébe.

Megnézem, de még nem találkoztam eddig vele.

Hát az alap probléma, mondjuk egy test, amit érintéssel tudsz forgatni (vagy egértrel, ha PC-s oldalon maradunk) Na most vertikális iránybe elforgatod 180 fokkal, akkor ahorizontális irányba forgatásnál pont az ellenkező iránybe fog forogni, mint ahogy te szeretnéd, hogy forogjon. Ez jelentkezik mondjuk akkor is, ha egy adott pályán egy golyót gurítok ilyen transzformáció segítségével, nem tudom, mennyire érthető a probléma.

EDIT:

Közben rátaláltam a megfelelő kulcsszavakra google-ben, azt hiszem már tudom milyen irányba kell elinduljak, azért még hátgha tud valaki valami hasznos félmondatot.

RotationAxisAngle, dx-ben van ilyen, tuti van oglben is aztán az y meg az x tengelyt adod meg tengelynek, oszt' kész.
Amúgy mire jó ez, hogy amazon a koordináta-rendszeren forgatod?

megint nem látom a fától az erdőt, szóval gondoltam bedobom ide, hátha valaki fél mondattal helyre igazít.

Szóval Forgatnék egy testet X,Y tengelyen, de lehetőleg úgy hogy a tengelyek eközben ne forduljanak el. Szóval nem az objektum koordináta rendszerében szeretném forgatni, hanema világ koordináta rendszerében.

Szóval ezt hogy.

Most úgy néz ki alapból a dolgo, hogy elforgatom az x tengelyen, aztán az y tengelyen, ami már a forgatott y tengely körül fog forgatni, ami nekem nem jó

Ja tényleg az utolsó nulla paraméteremen valahogy átsiklottam

Úgy rajzolsz, hogy (void*)(indices + 300).

De ha nincs kiszámolva a vertex index range, akkor a sima gldrawelementset használd.

const GLvoid *indices

De akkor hogyan rajzolok mondjuk a 300. indextől? Mert a start ezek szerint nem azt jelöli, hogy hanyadik indextől indul a rajzolás.

A start és end azt mondja meg, h a kirajzolandó mesh index listájában mi a min. és max. vertex index érték.
Ez pedig nem korlátoz semmit csak a gpunak segít optimalizálni.

Pont úgy, ahogy egyet

void glDrawRangeElements
(GLenum mode
, GLuint start
, GLuint end
, GLsizei count
, GLenum type
, const GLvoid *indices
);

Két napon keresztül kerestem a lehetséges hibákat a konverteremben, mire rájöttem, hogy semmi baja, csak félreértettem a fenti metódus paramétereit
Eddig azt hittem, hogy a start és az end az index tömbön belüli pozíciókat jelölik, míg a count a rajzolás során felhasznált vertexek számát (tehát pl egy GL_TRIANGLE kockánál 24-et). Most hogy újra elolvastam a specifikációt, azt már tudom, hogy a count az a kirajzolt vertexek száma (kockánál 36). Viszont hogy ha a start és az end a minimum és maximum értéket jelölik az index tömbben, hogy lehet egy EBO-ba több mesh indexeit feltölteni?

"glBegin helyett VBO"-> Jól csináltad Csoki bácsi, kemény vagy!

Újabb szegénységi bizonyítvány.

Biztonság kedvéért lett leírva a gluLookAt() magyarázata, hátha mégis azt látja könnyebbnek valaki.

Még nem teszteltem sebességben, de sztem mindegy hogy 0-hoz ad hozzá, vagy egy már meglévő számhoz adja hozzá a többit, mert mindenképpen vannak változások ugyanazokban az értékekben. Nagyjából ugyanannyit kellhet számolni, ha belegondolok a térgeometriába. De ez úgy is részlet kérdés...
Abban az esetben számíthat, ha először mindent ténylegesen is nullára állít és nem csak a felül írásnál számol nulláról a behelyettesítések helyett és a push-pop sem emelteti át a meglévő adatokat arra a helyre, ahol számol vele. Mondjuk ezt nem tudom hogy megy odabent pontosan.

Én kezdőként a glulookat-et használtam, aztán megcsináltam a poposat, aztán megint azt használom tesztekhez. Persze az first person forgáshoz kell bónusz metódus így is, amit könnyebb a glulookat-tel használni. És lehet rá camera objektumot is alapozni. És a playstation-ös "target"követés is simább vele.

---
A Begin - End nél ott van az "// akár". Javasolhatnék VBO-t is ahhoz a kérdéshez, hogy "miért nem mozognak külön az objektumok".

jahh igen, azt a részt én már ignoráltam.

Nade az NVidianak még eladható az ötlet.

Ez a glBegin-glEnd se valami performanciás dolog. Ha szándékosan lassítani kell a renderelést, akkor ddwbo kolléga módszerei jók lehetnek, de egyébként mobilon már nincs is glBegin-glEnd gondolom nem véletlenül.

Abban az esetben ki lehet kerülni, ha, ahogy a kolelga mondja, minden objektum rajzolása elött kvázi a nulláról beállítjuk az egész jelenet nézetét. Persze ez előbb utóbb kaotikus lesz, felesleges szorzás műveletekkel jár, és a többi.

Kezdőnek push / pop párossal a legegyszerűbb ezt megoldani.

A glulookat pedig jellemzően egy glmultmatrix + gltranslate ergo a push / popot így sem lehet kikerülni.

Nem kell bemutatni a LookAt() metódust, köszi!

Viszont tök felesleges és pazarló minden objektum rajzolása előtt beállítani, Bőven elég egyszer a render elején, utána meg ott a mátrix verem.

Ez így igaz, nullázza. Viszont a glu erre ad megoldást, ha van glu. Illetve 2D rendszerben könnyű a koordinátákat eltolni.

glLoadIdentity();

gluLookAt( cam.pos_x, cam.pos_y, cam.pos_z, cam.view_x, cam.view_y, cam.view_z, 0.0, 1.0, 0.0 );

// float-ban megadva

stb..stb
---
ahol az első három a kamera pozíciója, a második három ahova néz a kamera, a harmadik három a kamera normálja. ami alap esetben stabil 0.0, 1.0, 0.0 lenne, hogy előre nézzen a kamera, inkább az oldal hajláshoz jó módosíthatóra berakni.

Ezzel a megoldással az a baj, hogy szétcseszi az eredeti nézeti transzformációkat, kvázi a kamera beállítást., szóval nem igazán rugalmas.

Szóval a mátrix verem használata az ami inkább használható.

Idézet

---

levi1224 :
Hali!
Lenne egy problémám. A baj az hogy létrehozok kettő objektumot 2D-ben. Én az egyiket szeretném mozgatni, de mindegyiket mozgatja glTranslatef(); függvénnyel. Mit csinálok rosszul?
Mi a megoldás?

---

Egy másik lehetséges megoldás. Teljesen különálló és alap szinten megérthető objektumhoz:

glLoadIdentity(); // új tárgy jön.. ez nullázza a változtatásokat

glTranslatef( cucc1.x, cucc1.y, cucc1.z );

glBegin(); // akár
...
glEnd();

glLoadIdentity(); // új tárgy jön.. ez nullázza a változtatásokat

glTranslatef( cucc2.x, cucc2.y, cucc2.z );

glBegin(); // akár
...
glEnd();

Idézet

---

levi1224 :
Hali!
Lenne egy problémám. A baj az hogy létrehozok kettő objektumot 2D-ben. Én az egyiket szeretném mozgatni, de mindegyiket mozgatja glTranslatef(); függvénnyel. Mit csinálok rosszul?
Mi a megoldás?

---

Egy lehetséges megoldás a pop és push, hogy megmaradjon az állapota az adott objektumnak. Feltéve, hogy arrays-el rajzolsz:

Hali!
Lenne egy problémám. A baj az hogy létrehozok kettő objektumot 2D-ben. Én az egyiket szeretném mozgatni, de mindegyiket mozgatja glTranslatef(); függvénnyel. Mit csinálok rosszul?
Mi a megoldás?

Jó, hát sejtettem, hogy nem feltétlen azt kell használni, csak mondtam, hogy ha pl. debug objecteket akarok kirajzolni, akkor az tök egyszerű.

glBegin() glEnd() rajzolást gyorsan felejtsd is el.

Amúgy tényleg tök egyszerű, meg nem kell semmit redundánsan tárolnod vele, mint mondjuk egy DrawArray() vagy DrawElement()-el de a lehető leglassabb módszer.

Mind1, most valószínűleg amúgy más baja van a cuccnak... már' a gépnek...
Ami eddigi pozitívum számomra az openglben, az az, hogy marha egyszerűen lehet primitíveket kirajzolni. Lehet, hogy directxben is, de itt glBegin, glEnd között 3 glVertex3f, és már ott is volt egy háromszög

Lassan át kell állni OpenCL/CUDA-ra, addig meg elszórakozni mindegy úgyis.

Ja hoppá, az 610-612 akart lenni
Nem álltam át, csak gondoltam belenézek, hogy hogy is van ez a cucc. Annyira azért nem tetszik... De minden bizonnyal használható, és működik is, de nekem így első körben nem jött be.

Lehet, hogy időnként elfárad és lejjeb veszi a frissítést. Egyébként nem szokott, biztos driver függő is a dolog, vagy valami progi zavar be a háttérben. A sötét oldallal vigyázni kell, mert könnyen fény derülhet a zsiványságra.