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.

Mi történt, át állsz a sötét oldalra?

Egyébként még sosem figyeltem meg, hogy mit művel egy üres ablak, de ha ahogy írod 612-612 között ugrál, akkor az nem is ugrálás.

Az természetes, hogy egy üres ogl-es ablaknál sose áll meg fixre az fps? (dx-esnél megállt 620 körül, itt 612-612 között ugrál másodpercenként többször (a fraps-es fps számláló csak úgy "ugrál" )
Sőt... néhány indításnál megáll 580-90 körül, fel se megy 600 fölé, azután meg vígan..

Bazz leesett, tárgytalan, tök jogos a torzulás, már csak az a kérdés, hogy amit én teszek ellene, az elegáns-e vagy sem.

Na kellene egy kis help, félig medig OGL igazábós Shader abban is OGSL.

Szóval BillBoard shaderrel szórakozok.

Átadoka shadernek többek között egy ModelView matrixot, meg a textúra koordinátákat.

Na most az alap elképzelés, hogy a billboard vertex pozícióját a textúra koordniátákból nyerem ki. Ehhez előbb a modelview matrixból képzek egy középpont vektort, és ehhez képest eltolom a négy vertexet. Ez rendben is van, frappánsan működik a billboard, igaz a kirajzolás iránya kicsit megzavart, y koordinátán kellett egy -1-es szorzás, de ez mellékes, viszont a kirajzolt billboard, nem négyzet, hanem téglatest, mégpedig a képaránnyal megegyező arányú. Ez így normális, ha a textúrakoordinátákkal számolok, és ezt le kell kezelni a shaderben, vagy valamit elcsesztem?

És ha már így koptattam a számat be is szúrom ide.



Ha kiiktatok mindent, csak a textúra koordinátát használom, akkor is csinálja, tehát nem a mátrixommal van a baj.

tudom a v_Position értékadása gáz, de átmeneti.

Idézet

---

Eldor :
A texturat mikor hozod letre es toltod be? Mert ha azelott, mielott megcsinalnad az ablakot, akkor a glGenTextures 0-t rak a textura azonositodba. A 0-as id meg hibat jelent ebben az esetben. Csak otlet, de ez nem derul ki a berakott kododbol.

---

Hehe, ez lett volna a másik kérdésem.

extension-ök kezelése is más úgy tudom linux alatt

Sztem elég a transzponálás

OGL-ben annyit kell tudni, hogy a transzformációnál, nem a vertexből képzett sormátrixot szorozzuk be a transzformáció mátrixával, hanem a transzformáció mátrixát szorozzuk be a vertexből képzett oszlopmátrixal. Természetesen ezért a transzformációk megadásának sorrendje is ellentétes.

A DX ugye balsodrású, az OGL meg jobbsodrású koordináta-rendszerrel dolgozik (vagymi)
Anno szépen megírtam a mátrixokat (perspective, lookat, stb.) dx alatt, de ugye így oglben meg nem azok vannak Az oglben a mátrixok, a dx-es mátrixok transzponáltjai, vagy egyéb trükközés is van?

szerk.:
Ja, meg mire kell ügyelni, ami platformfüggő? Nyilván az ablakozás, ogl "device" létrehozás, kezelés, ilyesmi, de ezen kívül van-e még valami, amire figyelni kell, ami más linuxon, windowson, meg egyéb helyeken? (ha mondjuk a telefontól eltekintünk, szóval nézzük csak a pc-t / esetleg pár értelmes konzolt, amin mondjuk nem "butított" ogl van)

Ezt nem hiszem el tényleg ez volt a baj! A program legelején töltettem be a textúrát még mielőtt létrehoztam volna az ablakot. Itt bénázok már ezzel napok óta, szétszedtem az egészet, erre egy control+x control+v megoldja az egész problémát Na erre majd ügyelni fogok a jövőben. Nagyon szépen köszönöm!!