Számítógépes grafika házi feladat tutorial - Laptörténet

Turai Botond: /* 2D rajzolás */

2021-03-22T21:43:56Z

2D rajzolás

← Régebbi változat		A lap 2021. március 22., 23:43-kori változata
100. sor:		100. sor:
	glVertex2f(center_x, center_y);		glVertex2f(center_x, center_y);

	for(int i = 0; i <= CIRCLE_RESOLUTION; i++) {		for(int i = 0; i < CIRCLE_RESOLUTION; i++) {
	float angle = float(i) / CIRCLE_RESOLUTION * 2.0f * M_PI;		float angle = float(i) / CIRCLE_RESOLUTION * 2.0f * M_PI;
	// Itt a kor paramtetrikus alakjat hasznaljuk: x = x0 + rcos(t), y = y0 + r sin(t)		// Itt a kor paramtetrikus alakjat hasznaljuk: x = x0 + rcos(t), y = y0 + r sin(t)
114. sor:		114. sor:
	glVertex2f(center_x, center_y);		glVertex2f(center_x, center_y);

	for(int i = 0; i <= CIRCLE_RESOLUTION; i++) {		for(int i = 0; i < CIRCLE_RESOLUTION; i++) {
	float angle = float(i) / CIRCLE_RESOLUTION * 2.0f * M_PI;		float angle = float(i) / CIRCLE_RESOLUTION * 2.0f * M_PI;
	glColor3f(0.0f, 0.5f + 0.5fcos(angle), 0.5f + 0.5fsin(angle));		glColor3f(0.0f, 0.5f + 0.5fcos(angle), 0.5f + 0.5fsin(angle));
137. sor:		137. sor:

	http://i.imgur.com/6yfh7q2.png		http://i.imgur.com/6yfh7q2.png


	=== Eseménykezelés ===		=== Eseménykezelés ===

Nagy Marcell: autoedit v2: fájlhivatkozások egységesítése, az új közvetlenül az adott fájlra mutat

2017-07-12T14:23:10Z

autoedit v2: fájlhivatkozások egységesítése, az új közvetlenül az adott fájlra mutat

← Régebbi változat		A lap 2017. július 12., 16:23-kori változata
2 319. sor:		2 319. sor:
	Az én implementációim: [[Média:Grafpp4_kamera.cpp‎\|Kamera]]		Az én implementációim: [[Média:Grafpp4_kamera.cpp‎\|Kamera]]

	[[~~Fájl~~:Graftutorial_kamera_anim.gif]]		[[File:Graftutorial_kamera_anim.gif]]

	== Utóhang ==		== Utóhang ==

Csala Tamás: apró javítások /* Sugárkövetés */

2015-11-06T23:03:19Z

apró javítások Sugárkövetés

← Régebbi változat		A lap 2015. november 7., 01:03-kori változata
596. sor:		596. sor:
	<br/> <syntaxhighlight lang="c">		<br/> <syntaxhighlight lang="c">
	Vector pos_on_plane = Vector(		Vector pos_on_plane = Vector(
	(x ~~+ 0.5f~~ - Screen::width/2) / (Screen::width/2),		(x - Screen::width/2) / (Screen::width/2),
	(y ~~+ 0.5f~~ - Screen::height/2) / (Screen::height/2),		(y - Screen::height/2) / (Screen::height/2),
	0		0
	);		);
651. sor:		651. sor:
	void capturePixel(float x, float y) {		void capturePixel(float x, float y) {
	Vector pos_on_plane = Vector(		Vector pos_on_plane = Vector(
	(x - Screen::width/2) / (Screen::width/2),		(x + 0.5f - Screen::width/2) / (Screen::width/2),
	(y - Screen::height/2) / (Screen::height/2),		(y + 0.5f - Screen::height/2) / (Screen::height/2),
	0		0
	);		);
1 095. sor:		1 095. sor:

	<br/> <syntaxhighlight lang="c">		<br/> <syntaxhighlight lang="c">
	x = max(0, ~~InputColor~~-0.004);		x = max(0, InputLuminance-0.004);
	~~OutputColor~~ = (x(6.2x+0.5))/(x(6.2x+1.7)+0.06);		OutputLuminance = (x(6.2x+0.5))/(x(6.2x+1.7)+0.06);
	</syntaxhighlight> <br/>		</syntaxhighlight> <br/>

Csala Tamás: /* A Sugárkövetés alapjai */

2014-11-16T00:39:02Z

A Sugárkövetés alapjai

← Régebbi változat		A lap 2014. november 16., 02:39-kori változata
590. sor:		590. sor:
	* Azt is tudnunk kell, hogy melyik iránynak felel meg a felfele ("What's up?"). Kódban pl nevezzük <code>up</code>-nak.		* Azt is tudnunk kell, hogy melyik iránynak felel meg a felfele ("What's up?"). Kódban pl nevezzük <code>up</code>-nak.
	* Tegyük fel, hogy téglalap (vagy sík) egységnyi távolságra van a kamerától. Ekkora annak a középpontja: <code>pos + fwd</code>.		* Tegyük fel, hogy téglalap (vagy sík) egységnyi távolságra van a kamerától. Ekkora annak a középpontja: <code>pos + fwd</code>.
	* Tudnunk kell még, hogy melyik irány van jobbra. Ezt az előre és a felfele pozícióból ki tudjuk számolni: <code>right = cross(fwd, up)</code>.		* Tudnunk kell még, hogy melyik irány van jobbra. Ezt az előre és a felfele pozícióból ki tudjuk számolni: <code>right = cross(fwd, up) // a cross-product a vektor szorzat angolul, a dot-product pedig a skalár szorzat. </code>
	* A felfele vektor amit megadtunk nem biztos, hogy merőleges az előre vektorra, pedig nekünk olyanra van szükségünk. Pl: ha rézsútosan előre és lefele nézünk, de az 'up' vektor az ég fele mutat. Ez valójában nem baj, mert a jobbra és előre vektor ismeretében már ki tudjuk számolni a pontos felfele vektort: <code>up = cross(right, fwd)</code>.		* A felfele vektor amit megadtunk nem biztos, hogy merőleges az előre vektorra, pedig nekünk olyanra van szükségünk. Pl: ha rézsútosan előre és lefele nézünk, de az 'up' vektor az ég fele mutat. Ez valójában nem baj, mert a jobbra és előre vektor ismeretében már ki tudjuk számolni a pontos felfele vektort: <code>up = cross(right, fwd)</code>.
	* Ha ezek megvannak, akkor ki kell tudnunk számolni, hogy egy (x, y) koordinátájú pixelnek a téglalap (ami most egy 2 egység oldalhosszúságú négyzet) melyik része felel meg. Ezt így tehetjük meg:		* Ha ezek megvannak, akkor ki kell tudnunk számolni, hogy egy (x, y) koordinátájú pixelnek a téglalap (ami most egy 2 egység oldalhosszúságú négyzet) melyik része felel meg. Ezt így tehetjük meg:

Csala Tamás: /* Egyszerű kamera */

2014-11-04T11:41:13Z

Egyszerű kamera

← Régebbi változat		A lap 2014. november 4., 13:41-kori változata
2 190. sor:		2 190. sor:
	Kétféle input érdekel minket, a billentyűlenyomások (W,A,S,D), és az egér mozgatása (úgy, hogy közbe az egyik egérgomb le van nyomva).		Kétféle input érdekel minket, a billentyűlenyomások (W,A,S,D), és az egér mozgatása (úgy, hogy közbe az egyik egérgomb le van nyomva).

	A billentyűlenyomásokat nem kezelhetjük egyszerűen az onKeyboard-ban, ez akkor generál eseményeket, amikor egy karaktert begépelnénk, ami pl megtörténik először a billentyű lenyomásakor, aztán jelentős ideig (kb. 0.3 - 0.5 sec) nem generálódik újabb esemény, majd után másodpercenként kb. 10-20 karakterbeütés-t generál. ~~És ez nekünk nagyon jó~~, helyette inkább tároljuk el, hogy az egyes billentyűk ~~mikor vannak~~ lenyomott állapotban.		A billentyűlenyomásokat nem kezelhetjük egyszerűen az onKeyboard-ban, ez akkor generál eseményeket, amikor egy karaktert begépelnénk, ami pl megtörténik először a billentyű lenyomásakor, aztán jelentős ideig (kb. 0.3 - 0.5 sec) nem generálódik újabb esemény, majd után másodpercenként kb. 10-20 karakterbeütés-t generál. Ez pl egy karakter irányításához teljesen használhatatlan, helyette inkább tároljuk el, hogy az egyes billentyűk lenyomott állapotban vannak-e.

	<br/> <syntaxhighlight lang="c">		<br/> <syntaxhighlight lang="c">

Csala Tamás: /* A kétirányú sugárkövetés */

2014-10-07T20:04:04Z

A kétirányú sugárkövetés

← Régebbi változat		A lap 2014. október 7., 22:04-kori változata
1 497. sor:		1 497. sor:
	Példaprogram: ''<Törölve, túl sokan másolták>''		Példaprogram: ''<Törölve, túl sokan másolták>''

	A korábbi jelenet~~, csak~~ kétirányú (bal oldalt) és ~~baloldalt~~ (jobb oldalt) ~~sugárkövetéssel~~, mindkét esetben 500 000 fotonnal		A korábbi jelenet kétirányú (bal oldalt) és csak globális (jobb oldalt) megvilágítással, mindkét esetben 500 000 fotonnal
	{\|		{\|
	\|-		\|-

Csala Tamás: /* A megvilágítás és a transzformációk */

2014-09-19T15:56:38Z

A megvilágítás és a transzformációk

← Régebbi változat		A lap 2014. szeptember 19., 17:56-kori változata
1 815. sor:		1 815. sor:
	http://i.imgur.com/iZJlFr9.gif		http://i.imgur.com/iZJlFr9.gif

	* A megvilágítást közvetlenül a setCamera() függvény után állítjuk be. Ekkora a glLightfv-ben megadott pozíció a világ koordináta-rendszerben lesz értelmezve, és a statikus objektumoknak "mindig ugyanaz az oldala lesz fényes". Ezt általában akkor szoktuk használni, ha a fényforrás a jelentben ~~statikus,~~ egy helyben marad.		* A megvilágítást közvetlenül a setCamera() függvény után állítjuk be. Ekkora a glLightfv-ben megadott pozíció a világ koordináta-rendszerben lesz értelmezve, és a statikus objektumoknak "mindig ugyanaz az oldala lesz fényes". Ezt általában akkor szoktuk használni, ha a fényforrás a jelentben egy helyben marad.

	http://i.imgur.com/cUPVzeT.gif		http://i.imgur.com/cUPVzeT.gif

Csala Tamás: /* A megvilágítás és a transzformációk */

2014-09-19T15:55:55Z

A megvilágítás és a transzformációk

← Régebbi változat		A lap 2014. szeptember 19., 17:55-kori változata
1 815. sor:		1 815. sor:
	http://i.imgur.com/iZJlFr9.gif		http://i.imgur.com/iZJlFr9.gif

	* A megvilágítást közvetlenül a setCamera() függvény után állítjuk be. Ekkora a glLightfv-ben megadott pozíció a világ koordináta-rendszerben lesz értelmezve, és a statikus objektumoknak "mindig ugyanaz oldala lesz fényes". Ezt általában akkor szoktuk használni, ha a fényforrás a jelentben egy helyben marad.		* A megvilágítást közvetlenül a setCamera() függvény után állítjuk be. Ekkora a glLightfv-ben megadott pozíció a világ koordináta-rendszerben lesz értelmezve, és a statikus objektumoknak "mindig ugyanaz az oldala lesz fényes". Ezt általában akkor szoktuk használni, ha a fényforrás a jelentben statikus, egy helyben marad.

	http://i.imgur.com/cUPVzeT.gif		http://i.imgur.com/cUPVzeT.gif

Csala Tamás: /* Kedvcsináló */

2014-09-10T22:09:33Z

Kedvcsináló

← Régebbi változat		A lap 2014. szeptember 11., 00:09-kori változata
1 563. sor:		1 563. sor:

	A általunk használt sugárkövetéssel a legnagyobb gond az, hogy nem használja a videókártyát. Hiába van a gépünkbe egy szuperszámítógép teljesítményű hardware, ha nem használjuk semmire. A mai videókártyák nem csak előre meghatározott műveletek tudnak végrehajtani, hanem már programozhatóak is. Az ezt kihasználó grafikus programok hihetetlen hatékonyak. Például az én grafika nagyházim egy 72 millió háromszögből álló jelenetet tudott valós időben (kb. 20 FPS-el) kirajzolni (fizikával együtt).		A általunk használt sugárkövetéssel a legnagyobb gond az, hogy nem használja a videókártyát. Hiába van a gépünkbe egy szuperszámítógép teljesítményű hardware, ha nem használjuk semmire. A mai videókártyák nem csak előre meghatározott műveletek tudnak végrehajtani, hanem már programozhatóak is. Az ezt kihasználó grafikus programok hihetetlen hatékonyak. Például az én grafika nagyházim egy 72 millió háromszögből álló jelenetet tudott valós időben (kb. 20 FPS-el) kirajzolni (fizikával együtt).


	<div style="text-align:center;margin:0px auto;">		<div style="text-align:center;margin:0px auto;">
	~~https~~://~~github~~.com/~~Tomius/LoD/raw/master/screenshot~~.png		http://i.imgur.com/zYUuZ0L.png
	</div>		</div>

Csala Tamás: /* Kedvcsináló */

2014-09-10T22:00:57Z

Kedvcsináló

← Régebbi változat		A lap 2014. szeptember 11., 00:00-kori változata
1 562. sor:		1 562. sor:
	Sugárkövetéssel nagyon látványos képeket tudunk elérni, ha vesszük a fáradtságot, hogy érdekes objektumokat helyezzünk el a világban. Főleg a másodrendű felületek tudnak nagyon szép képeket adni. Az árnyékszámításhoz gyakorlatilag ölünkbe hullott egy algoritmus, amihez pont ugyanazt kellett csinálni, mint amit rajzoláskor is csináltunk. A globális illuminációval ráadásul olyan hatásokat is implementálni tudtunk, amikkel a mai játékokba szinte sehol nem lehet találkozni. Akkor mi a gond a sugárkövetéssel, miért nem ezt használjuk mindenhol, miért kell akkor egyáltalán OpenGL? A probléma az vele, hogy lassú. Az általam mutatott programok mindössze 14 darab háromszögből álltak, messze elmaradva a mai játékok komplexitásától, és így is, a globális illuminációval kb. 5 másodperc volt, mire a kép előállt. Ez nem tűnik soknak, de optimális esetben egy játékhoz másodpercenként legalább 60szor kéne képet alkotnunk, a sugárkövető ettől messze elmarad. Ha a kódot két héten át optimalizáltam volna, akkor akár 0.1 másodperc is lehetne a renderelési idő. Igen ám, de ez csak a képalkotásra szánt idő! A játék logika, főleg ütközés detektálások, vagy ruha-, víz szimuláció stb. egyáltalán nincsenek ingyen, és még azoknak is bele kéne férnie az időbe. És ez még mindig csak 14 darab háromszög.		Sugárkövetéssel nagyon látványos képeket tudunk elérni, ha vesszük a fáradtságot, hogy érdekes objektumokat helyezzünk el a világban. Főleg a másodrendű felületek tudnak nagyon szép képeket adni. Az árnyékszámításhoz gyakorlatilag ölünkbe hullott egy algoritmus, amihez pont ugyanazt kellett csinálni, mint amit rajzoláskor is csináltunk. A globális illuminációval ráadásul olyan hatásokat is implementálni tudtunk, amikkel a mai játékokba szinte sehol nem lehet találkozni. Akkor mi a gond a sugárkövetéssel, miért nem ezt használjuk mindenhol, miért kell akkor egyáltalán OpenGL? A probléma az vele, hogy lassú. Az általam mutatott programok mindössze 14 darab háromszögből álltak, messze elmaradva a mai játékok komplexitásától, és így is, a globális illuminációval kb. 5 másodperc volt, mire a kép előállt. Ez nem tűnik soknak, de optimális esetben egy játékhoz másodpercenként legalább 60szor kéne képet alkotnunk, a sugárkövető ettől messze elmarad. Ha a kódot két héten át optimalizáltam volna, akkor akár 0.1 másodperc is lehetne a renderelési idő. Igen ám, de ez csak a képalkotásra szánt idő! A játék logika, főleg ütközés detektálások, vagy ruha-, víz szimuláció stb. egyáltalán nincsenek ingyen, és még azoknak is bele kéne férnie az időbe. És ez még mindig csak 14 darab háromszög.

	A általunk használt sugárkövetéssel a legnagyobb gond az, hogy nem használja a videókártyát. Hiába van a gépünkbe egy szuperszámítógép teljesítményű hardware, ha nem használjuk semmire. A mai videókártyák nem csak előre meghatározott műveletek tudnak végrehajtani, hanem már programozhatóak is. Az ezt kihasználó grafikus programok hihetetlen hatékonyak. Például az én grafika nagyházim egy 72 millió ~~háromszögból~~ álló jelenetet tudott valós időben (kb. 25 FPS-el) kirajzolni.		A általunk használt sugárkövetéssel a legnagyobb gond az, hogy nem használja a videókártyát. Hiába van a gépünkbe egy szuperszámítógép teljesítményű hardware, ha nem használjuk semmire. A mai videókártyák nem csak előre meghatározott műveletek tudnak végrehajtani, hanem már programozhatóak is. Az ezt kihasználó grafikus programok hihetetlen hatékonyak. Például az én grafika nagyházim egy 72 millió háromszögből álló jelenetet tudott valós időben (kb. 20 FPS-el) kirajzolni (fizikával együtt).

	<div style="text-align:center;margin:0px auto;">		<div style="text-align:center;margin:0px auto;">
	~~http~~://~~i.imgur~~.com/~~fGQv8Wp~~.png		https://github.com/Tomius/LoD/raw/master/screenshot.png
	</div>		</div>

	Csak emlékeztetőül, sugárkövetéssel 14 háromszög nem ment valós időben... A videókártya segítségével a 72 millió ~~háromszög~~ real-time kirajzolása még messze nem a maximum amit el lehet érni~~, a nagyházim kódja egyáltalán nincs is optimalizálva~~.		Csak emlékeztetőül, sugárkövetéssel 14 háromszög nem ment valós időben... A videókártya segítségével a 72 millió háromszögből álló jelenet real-time kirajzolása még messze nem a maximum amit el lehet érni.

	A videókártyát használhatnánk arra, hogy gyors raytracert írjunk. Ehhez viszont meg kellene tanulni, hogy hogyan kell a videókártyát programozni... Ehelyett mi a videókártya kezelését az OpenGLre bízzuk, és az inkrementális elvet használva fogunk rajzolni (ugyanúgy, mint a 2D OpenGL-es résznél, csak 3D-ben).		A videókártyát használhatnánk arra, hogy gyors raytracert írjunk. Ehhez viszont meg kellene tanulni, hogy hogyan kell a videókártyát programozni... Ehelyett mi a videókártya kezelését az OpenGLre bízzuk, és az inkrementális elvet használva fogunk rajzolni (ugyanúgy, mint a 2D OpenGL-es résznél, csak 3D-ben).