Zadravim
mam RH 9 po aplikovani dostupnych updatu.
Pri pokusu o kompilaci mi to hazi ...
$bash -x compile opengl_05_1.c
++ basename opengl_05_1.c .c
+ OBJ=opengl_05_1
+ gcc -L/usr/X11R6/lib -lglut -lGL -lGLU -lm -lX11 -lXmu -o opengl_05_1 opengl_05_1.c
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libglut.so: undefined reference to `glXBindChannelToWindowSGIX'
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libglut.so: undefined reference to `XGetExtensionVersion'
.
.
.
.
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libglut.so: undefined reference to `XSelectExtensionEvent'
collect2: ld returned 1 exit status
Co s tim ?
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
$ ldd /usr/lib/libglut.so.3.7
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
Petr Klima
O ViewportMatrix jsem se v článku nepřesně vyjádřil. Z hlediska programátora OpenGL aplikace totiž nejde o "klasickou" matici 4x4 prvky, se kterou by šlo takto přímo manipulovat. Ale Viewport samozřejmě ovlivňovat můžeme (i když se už jedná o 2D souřadnice, protože poslední transformací, která se aplikuje i na z-ovou souřadnici je převod na normalizované souřadnice zařízení).
Jinak transformace zadaná v ProjectionMatrix se provádí ještě před dělením z-ovou souřadnicí, tedy PŘED převodem na normalizované souřadnice zařízení a ViewPort transformace se aplikují AŽ na normalizované souřadnice (výstupem těchto transformací jsou přímo souřadnice v okně).
Takže ProjectionMatrix a "ViewPortMatrix" jsou odlišné pojmy.
Máte pravdu, že tento termín opravdu není v OpenGL specifikaci. Já jsem ho zde použil z toho důvodu, že při vysvětlování funkce grafické pipeline je dobré všechny transformace chápat jako lineární transformace zadané maticí 4x4 (i když v některých částech pipeline už nejsou homogenní souřadnice použity). Takto to používají někteří autoři knih o počítačové grafice (např. F.S.Hill) i já při výkladu studentům.
Ale uvědomuji si, že jsem ten termín použil v článku bez dalšího vysvětlení, což je samozřejmě matoucí.
Dobry den,
moc pekny clanek, jenom bych chtel doplnit, ze souradnicim [x,y,z,w] se rika homogenni souradnice. A dosti pouzivanou funkci je take glPushMatrix() a glPopMatrix(), ktere se pouzivaji, kdyz chcete manipulovat jenom s nekterymi body. Tomu prikladu by neskodilo, kdyby se dane operace projevovali na nejakem objektu vykreslovanem v render kontextu, ale jinak perfektni.
Neplanujete tuto serii clanku vydat v nejakem pdf? Byl by to skvely studijni material pro studenty.
Také přeji pěkný den,
v příštích dílech si práci s maticemi (resp. transformacemi) ukážeme na příkladech, kde se také použije zásobník matic (tedy funkce glPushMatrix() a glPopMatrix()), takže na ty funkce jsem opravdu nezapoměl. Nějaké složitější věci s maticemi budou probrány až při vykreslování 3D scén s několika objekty.
Vydání ve formě .pdf prozatím neplánuji, ale zkusím se domluvit s redakcí Roota, zda je to uskutečnitelné. Pro "své" studenty na FIT mám připraveno několik přednášek o OpenGL, ukázkové příklady, originální dokumentaci k OpenGL a teď ještě dostanou odkazy na Root :-)
Pokud uvažujete 3D prostor, kde má bod souřadnice [x, y, z], tak aplikací matice 3x3 posun samozřejmě nevytvoříte. Právě proto (a kvůli perspektivě) se v počítačové grafice používají homogenní souřadnice, kde má každý bod souřadnice [x, y, z, 1] a matice jsou velikosti 4x4.
Posun stačí do této matice vhodně zadat prvky tak, aby se posun provedl (submatice 3x3, kterými se násobí souřadnice x, y, z je jednotková, v posledním sloupci matice je vektor [0, 0, 0, 1] a zbylé tři prvky představují vektor [dx, dy, dz]).
A prave proto posun NENI linearni transformace, jenze tato veta: "Mezi lineární transformace patří posun, otáčení, změna měřítka a zkosení." z Vaseho clanku tvrdi opak.
Homogenni souradnice toto resi pridanim dalsiho koordinatu, coz je vlastne rozsireni na ctyrrozmerny prostor, tam se provede nejaka transformace (avsak zase to neni posun) a vhodnou reprezentaci ctyrrozmernych koordinatu v trojrozmernem prostoru se novy vektor jevi posunuty.
Avsak toto funguje spravne pouze v pripade, kdy (jak jste rekl) je ctvrty koordinat roven 1. Pokud by nebyl (napr. zadanim jine hodnoty pouzitim funkci gl*4*), vektor uz nebude posunuty spravne.
Tady možná záleží na úhlu pohledu. V každém případě se na lineární transformaci můžeme dívat jako na funkci/zobrazení "f" definovanou nad dvěma vektorovými prostory f:V->W, kde platí f(x+y)=f(x)+f(y) a f(ax)=af(x) [a je skalár].
Pokud jsou V a W konečné (v našem případě ano), pak lze lineární transformaci V->W zapsat pomocí matice A, která se používá ve významu f(x)=Ax (platí tuším pouze pro Euklidovské prostory).
Takže jde pouze o to říct, nad jakými prostory budeme transformace definovat: nad [x,y,z] nebo pro specifické vektory [x,y,z,1], x,y,z jsou z R.
Asi trochu predbiham. Kdyz jsem konecne uz vykreslil par objektu v prostoru, tak jsem narazil na problem s jejich pruhlednosti. (Tu jsem urcoval alfa kanalem pri nastavovani barvy.) Nektere objekty nejsou skrz jine videt. Zjistil jsem ze to zalezi na poradi v jakem byly vykresleny. Jak to vypada je na techto obrazcich.
Pri vypnutem DEPTH_TEST:
http://www.sweb.cz/jkufner.web/root.cz/2003-07-31/depth_test_off.png
Pri zapnutem DEPTH_TEST:
http://www.sweb.cz/jkufner.web/root.cz/2003-07-31/depth_test_on.png
Jak je videt, tak pri vypnutem DEPTH_TEST je pruhlednost celkem v poradku, ale pro zmenu je videt za roh (pokud to za rohem necham vyreslit az po rohu). Takze tudy cesta nevede.
Kompletni zdrojak je na:
http://www.sweb.cz/jkufner.web/root.cz/2003-07-31/3D.tar.bz2
(DEPTH_TEST se prepina klav. 'd' a zbytek je pod 'h')
Takze co musim udelat, aby se to vykreslilo jak ma?
Dobrý den,
s průhledností (resp. obecně blendingem) je to trošku ošidné, protože z principu fungování grafického akcelerátoru vyplývá, že u průhledných objektů opravdu záleží na pořadí vykreslování jednotlivých primitiv.
Tento problém se obecně řeší několika způsoby:
1. pokud vykreslujete POUZE neprůhledné objekty, lze bez dalších komplikací použít Z-buffer (resp. depth buffer). Ten si alokujete při startu aplikace a povolíte příkazem glEnable(GL_DEPTH_TEST). Objekty se mohou vykreslovat v libovolném pořadí, protože se automaticky provádí Z-test na každý vygenerovaný fragment.
2. pokud vykreslujete POUZE průhledné objekty (což se v reálu asi nikdy nestane), tak použití Z-bufferu nepomůže, protože by se některé potenciálně viditelné části nemusely vykreslit (neprojdou Z-testem). Proto je potřeba objekty ručně setřídit podle Z-ové souřadnice a vykreslovat je v pořadí nejvzdálenější - nejbližší. Třídění samozřejmě zdržuje, což byl jeden z důvodů zavedení Z-bufferu.
3. pokud vykreslujete průhledné i neprůhledné objekty, musí se použít kombinovaná technika: nejdříve se v libovolném pořadí vykreslí všechny neprůhledné objekty se zapnutým Z-bufferem. Potom se zakáže zápis do Z-bufferu, ale test Z-ové hloubky se ponechá zapnutý. A následně se vykreslí _setříděné_ průhledné objekty.
Možnosti 2 a 3 mají nevýhodu v tom, že pokud se některé objekty protínají, budou jejich části vykreleny špatně. V tom případě se buď dá použít polygon offset a objekty vykreslit 2x nebo se musí objekty rozdělit v místě protnutí, což je samozřejmě zase práce pro programátora.
V dalších dílech si tyto techniky probereme podrobněji.