játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5441
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2186
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] > 5 < [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]
MaNiAc - Szerkesztő | 1735 hsz       Online status #206361   2015.01.23 09:21 GMT+1 óra  
Nehe cikkeivel az a gond, hogy már nagyon elavultak, ezért nem mertem linkelni őket. Pont, ahogy az enyémek is azok sajna

Akkor már inkább ez:

http://www.opengl-tutorial.org/

Btw tavaly írtam ezt egy barátomnak, aki akkor kezdte az OpenGL-t - szerintem ennek nagy része még mindig helytálló infó:

http://www.insaneidea.hu/?p=1357
Dare to imagine!
http://www.insaneidea.hu
   
Asylum - Törzstag | 5441 hsz       Online status #206345   2015.01.22 10:31 GMT+1 óra  
http://nehe.gamedev.net/

De nekem is van pár opengl cikkem, de azok kicsit advancedebbek.

http://darthasylum.blog.hu/
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Levente - Tag | 24 hsz       Online status #206343   2015.01.21 23:31 GMT+1 óra  
Köszi. Pont ilyesmi tutorialt keresgéltem.

   
Elodin - Tag | 172 hsz       Online status #206342   2015.01.21 22:30 GMT+1 óra  
Én ezt a tutorialsorozatot találtam a legértelmesebbnek:
http://ogldev.atspace.co.uk/

Freeglut ablakkezeléshez és az operációs rendszerrel való egyéb kommunikációkhoz kell, mint input handling.

Könyv esetleg:
http://it-ebooks.info/book/2138/

A könyvnek csak az elejét olvastam. Elég korrektnek tűnt, kb. mindent részletesen ír le, de szerintem lehet érdemesebb először tutorialokat csinálgatni, hogy legyen egy gyakorlati szemléleted az egészről, és utána olvasni az elméletet - szerintem úgy több megy majd át.

   
Levente - Tag | 24 hsz       Online status #206341   2015.01.21 21:40 GMT+1 óra  
Sziasztok!

Kezdőként már másfél éve ismerkedek C++ nyelvvel és most elkezdtem nézegetni az OpenGL-t is, de nem találtam egybefüggő anyagokat, hogy mivel kezdjem. Gondolok itt arra, hogy valahol GLU - al valahol freeGlut- al ,stb. mutatják be és nem nagyon értem, hogy ezek külön függvénytárak és mind másra jó vagy hogy van ez? És melyikkel kellene kezdenem valami egyszerű megalkotására?

   
Geri - Törzstag | 2186 hsz       Online status #206262   2015.01.14 14:56 GMT+1 óra  
proof - ilyesmire hagyatkozni hiba. nem is biztos, hogy a textúrát letömöríti akkor, amikor feltöltöd. nem is biztos, hogy letömöríti.

jó ötlet a GL_COMPRESSED_RGB-t használni, mert ha van textúratömörítés támogatás, akkor az működni fog - de megkérdezni, hogy mit kompresszált össze belőle nem determinisztikus dolog, pusztán az érdekesség kedvéért lehet megnézni, de erre hagyatkozni hiba.

   
Asylum - Törzstag | 5441 hsz       Online status #206259   2015.01.14 09:25 GMT+1 óra  
Internal formatnak lehetőleg mindig explicit formátumot adj meg (GL_RGBA8, GL_COMPRESSED_RGBA_S3TC_DXT1_EXT, stb.). Nem szabad a driverre bízni SEMMIT.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
proof88 - Törzstag | 528 hsz       Online status #206257   2015.01.13 22:47 GMT+1 óra  
ATi megint alkotott az OGL driverben.
Ha eddig GL_COMPRESSED_RGB-t vagy GL_COMPRESSED_RGBA-t adtam meg internal formatnak a glTexture2D()-nél, akkor elvártam hogy a driver válasszon egy módot magától és tömörítsen annak megfelelően. Utána lekérdeztem a választott módot a glGetTexLevelParameter(GL_TEXTURE_INTERNAL_FORMAT)-tal. Eddig minden gépen király volt.
Most viszont a legfrissebb driverrel már meghalt a tesztem, ugyanis mit kaptam vissza választott módként? Hát GL_COMPRESSED_RGB-re GL_COMPRESSED_RGB-t, GL_COMPRESSED_RGBA-ra meg GL_COMPRESSED_RGBA-t.

Márpedig ilyen esetben neki kell választania, mert:
If the internalFormat parameter is one of the generic compressed formats, GL_COMPRESSED_RED, GL_COMPRESSED_RG, GL_COMPRESSED_RGB, or GL_COMPRESSED_RGBA, the GL will replace the internal format with the symbolic constant for a specific internal format and compress the texture before storage.
Valszeg választott is, csak mondjuk szeretném tudni hogy mit is választott. Na nem mintha annyira érdekelne, de azért elmondhatná.
   
Hamu - Tag | 18 hsz       Online status #204878   2014.09.24 20:04 GMT+1 óra  
Köszi a tippeket!

   
Asylum - Törzstag | 5441 hsz       Online status #204873   2014.09.24 13:29 GMT+1 óra  
polygonoffsettel nem érdemes hülyéskedni, mert az eredmény rosszabb lehet mint eredetileg...a kockákat helyezd el úgy, hogy legyen köztük 0.5-1 mm távolság, a near/far-t pedig optimalizáld ki ahogy syam mondta.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #204866   2014.09.24 00:36 GMT+1 óra  
Ha nagy a tér, akkor több részre szokták osztani depth alapján a részek között pedig hívnak depth cleart és így értelmes tartományban lehet tartani a near-far tartományt.
alias aalberik
   
Hamu - Tag | 18 hsz       Online status #204865   2014.09.24 00:27 GMT+1 óra  
Syam

Köszi a tippet.
A problémát az okozza, hogy gyakran nagy teret lehet (muszáj) belátni.
Ráadásul az elemek dinamikusak is (több állapotuk lehet és LOD is lesz).

Ezt a hozzászólást Hamu módosította (2014.09.24 00:32 GMT+1 óra, 1058 nap)

   
syam - Törzstag | 1491 hsz       Online status #204864   2014.09.23 22:56 GMT+1 óra  
Ötletek:
polygon offset használata, kamera near-far optimalizálása
alias aalberik
   
Hamu - Tag | 18 hsz       Online status #204863   2014.09.23 22:50 GMT+1 óra  
3D programozóktól kérdezném:

Szeretnék moduláris elemekből építkezni, ahol minden modul fix "cube" helyet tölt ki (a "kiszorításuk" voxeles, amúgy 3D modellek), de például egy random méretezhető ablaknál vannak a sarok elemek és az élek. Ezek találkozásnál, hogy lehet elkerülni, hogy ne legyen látható semilyen zizgő él, pláne, hogy a találkozó elemek "közös" átfedő vertexei ugyanabban a koordinátában vannak. Van erre valami módszer vagy ez is olyan 20 éves probléma, mint az alpha shortolás?

   
Asylum - Törzstag | 5441 hsz       Online status #204850   2014.09.22 15:03 GMT+1 óra  
Idézet

példásul a specular kiszámolását minden pixelre



Mert shadinggel azt hogy uszod meg, kiveve ha nem szamolod ki?

Idézet

subsurface scattering



Nagyon realis cel...de a Crytek is megoldotta. Sot, pont azert nem hasznalnak forward+ t mert az egy csomo hasonlo dolgot nem tud (pl. area light).

http://www.crytek.com/download/2014_03_25_CRYENGINE_GDC_Schultz.pdf
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #204847   2014.09.22 10:42 GMT+1 óra  
Ha jól értem, az csak annyi, hogy a GBuffer normal + shininess + depth értékeket ad. Ezután jön a lighting pass, ahol kiszámoljuk a szokásos értékeket (normal dot light vec, stb.), és ezeket tároljuk el a textúrában. Majd egy újabb geometry pass, ahol a mesheket a material tulajdonságaikkal rendereljük, felhasználva a lighting passban kapott textúrákat.

A problémám ezzel a következő: egyrészt nem spórol meg bizonyos dolgokat - példásul a specular kiszámolását minden pixelre -, illetve mi van akkor, ha nem elég a lighting passból kapott információ? Nem tudom pontosan, hogy mi kell hozzá, de pl. subsurface scattering?

Lehet, hogy jobban megérné egy komplexebb forward shadinget megcsinálni.

szerk.:
Korábban említettem a SM 2.0 targetet. Most nézem, hogy már a 3.0 sem egy nagyon vészes dolog.
Nvidia:
SM 2.0: Geforce 6-ostól
SM 3.0: Geforce 8-astól

AMD/ATI:
SM 2.0: Radeon R300-tól
SM 3.0: Radeon R600-tól

Ezt a hozzászólást Instalok módosította (2014.09.22 11:08 GMT+1 óra, 1060 nap)

   
Asylum - Törzstag | 5441 hsz       Online status #204846   2014.09.22 09:19 GMT+1 óra  
Úgy, hogy deferred lightingot használsz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #204845   2014.09.22 07:42 GMT+1 óra  
Úgy hiszem, hogy kelleni fog, ott vannak például a falevelek. Nem lenne jó, ha a levél egy egyébként nem látszódó része miatt eldobná a mögötte lévő pixeleket a depth test. Akkor marad a discard. Köszi!

szerk.:
Apropó, deferred shadingnél hogy érdemes a material ID-t megvalósítani? Gondolkoztam valami olyasmin is, hogy GBuffer passban fel kellene töltenem egy stencil buffert is - feltéve, ha tudok MRT mellett -, a shadingnek megfelelően, majd a megvilágítás kiszámolásakor annyi lépés, ahány ilyen group van. A stencil testet beállítom, hogy csak az adott értékű pixelekkel foglalkozzon, majd arra számolja ki a megvilágítást.

Ezt a hozzászólást Instalok módosította (2014.09.22 08:15 GMT+1 óra, 1060 nap)

   
syam - Törzstag | 1491 hsz       Online status #204843   2014.09.21 22:33 GMT+1 óra  
A discard arra kell, hogy ne írj a depth bufferbe és ezt máshogy nem tudod megtenni.
Ki kell derítened, hogy szükséged van-e arra, h ne írj a depthbe vagy elég ha csak a colorba nem írsz.
alias aalberik
   
Instalok - Tag | 532 hsz       Online status #204842   2014.09.21 20:23 GMT+1 óra  
Nekem is olyasmi a cél. Újra deferred shadingnél kötök ki, és igazából a gbuffernél akarok spórolni, hogy ne legyen kötelező se normal mapet, se specular mapet megadni, stb. Viszont a nagy része ugyan az, így nekem is über-shader-szerű dolog lesz.

Discard helyett mit lehet, illetve érdemes használni?

   
syam - Törzstag | 1491 hsz       Online status #204841   2014.09.21 20:13 GMT+1 óra  
A discard viszonylag drága (mobilon különösen) pláne ha bonyolult feltételhez kötött. Mindenképp külön shader kell neki.
Azt nem fogod megúszni, hogy amennyi variáció annyiféle shadered lesz. Egyedül a forráskódot érdemes kontrollálható szintre hozni. Én pl define-olok orrvérzésig és kvázi übershadereket írok. De ez ízlés dolga.
alias aalberik
   
Instalok - Tag | 532 hsz       Online status #204840   2014.09.21 20:06 GMT+1 óra  
Aha, ebben van valami. Nekem jelenleg az összes shading külön-külön shader, tehát külön program is. Jelen esetben hogy érdemes megoldani az alpha testet? Annak is egy külön shader, ami ugyan azt csinálja egyébként, csak az elején discardol, ha az alpha a határérték alatt van?

Elképzelhető, hogy eddig teljesen rosszul használtam a shadereket, és van ennél hatékonyabb módszer is. Betöltöm a két shader source-t, compile-olom, majd linkelem a programhoz. Ez alkot egy shadert. Mivel különböző megvilágítási modelleket szeretnék használni, így mindegyikre írok külön shadert - igazából #ifdefelek -, mivel SM 2.0 a target, a shaderen belüli elágazásnak nincs túl sok értelme.

   
syam - Törzstag | 1491 hsz       Online status #204839   2014.09.21 19:48 GMT+1 óra  
Alpha test nincs shaderek mellett - shaderben kell megoldanod míg a blendelés tényleg nem befolyásolja a shadert.

Minél kevesebb state állítás annál jobb. Ez igaz glEnable/Disable és glUseProgram hívásokra is szóval lehet sakkozni
alias aalberik
   
Instalok - Tag | 532 hsz       Online status #204838   2014.09.21 14:56 GMT+1 óra  
Alpha test state állítani nagyon vészes? Van néhány shaderem - például diffuse, diffuse + specular, normal, stb. -, és ezek mindegyikének egy alpha testes illetve egy alpha blendes változata is - ezek nyilván shader szinten nem különböznek, csak state szinten.

Mi szerint érdemes csoportosítani? Ugye nagyjából a következő két lehetőség van:
- shader szerint: adott shaderrel először az opaque meshek, majd alpha test enable, alpha testes meshek. Utána shader váltás, alpha test disable, stb.
- state szerint: először az összes opaque mesh, majd az alpha testesek.

Mindkét esetben az alpha blendeseket mindenképpen külön passban renderelem (deferred shading). A második verziónál kevesebb a state váltás (igazából csak az alpha test state változik), viszont újra és újra be kell állítani a shadereket, így ez nekem költségesebbnek tűnik.

   
Geri - Törzstag | 2186 hsz       Online status #204763   2014.09.10 16:02 GMT+1 óra  
Idézet
Asylum :
de, win7-en működik a dx11 régebbi kártyával is



nem működik, dx11-hez dx9-es kártya a minimum.
dx9-el viszont akár directx5-ös kártyát is használhatsz.

   
Geri - Törzstag | 2186 hsz       Online status #204762   2014.09.10 16:00 GMT+1 óra  
na meg xp-n eleve nincs dx11, vistan is csak szervicepackkal...

   
Asylum - Törzstag | 5441 hsz       Online status #204761   2014.09.10 15:47 GMT+1 óra  
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476082%28v=vs.85%29.aspx

Itt kell beadni feature levelnek a 9.x-et és akkor megy. Ha nem adják be akkor nyilván nem fog.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #204760   2014.09.10 14:12 GMT+1 óra  
Az jó. Akkor a cryneinge-ből kihagyták. Egyik ismerősöm próbálkozott nemrégiben futtatni egy újabb játékot, amely nem indult el, azzal a hibaüzenettel, hogy DirectX 11 szükséges, és bizony az ő kártyája nem tudott csak 10-est. Azt hiszem egy kis google turkálás után meg lehetett hekkelni, hogy elinduljon, de ez azért nem a legszebb dolog. Persze ez valószínűleg független a DirectX-től, ha az megadja a lehetőséget, csak nem használják ki.

   
Asylum - Törzstag | 5441 hsz       Online status #204759   2014.09.10 13:52 GMT+1 óra  
de, win7-en működik a dx11 régebbi kártyával is
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #204757   2014.09.10 12:23 GMT+1 óra  
No már a visszafelé kompatibilitást nem úgy értettem. Van egy régebbi videókártyád, aminek nincsen csak DirectX 9 támogatása. DirectX 10-et (11-et) használó engine-t nem fogsz tudni futtatni rajta. Legalábbis amikkel eddig találkoztam, azok ilyet nem tudtak.

   
Asylum - Törzstag | 5441 hsz       Online status #204756   2014.09.10 11:48 GMT+1 óra  
DX11 visszafelé kompatiblis DX9-ig.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #204755   2014.09.10 11:46 GMT+1 óra  
A külön fordítgatás ráadásul grafikus APItól független dolog. A c/c++ kódot újra kell fordítani a különböző platformokra, akár más és más fordítókkal. Néhány #ifdefet beszúrni a kódba azért nem lehet akkora fájdalom. Ráadásul c++t kell használni, aztán lehet szépen interface mögé rejteni az egészet, így nem kell azzal foglalkoznod, hogy az implementáció milyen grafikus APIt használ. Persze nem mindig egyszerű megtalálni a közös nevezőt, még akár a legegyszerűbb dolgokban sem. Azonban ezt elég egyszer kitalálni. No de ez OpenGL topicban OFF.

OpenGL-ben egyébként csak a gyér (főleg Intel) driver-támogatást sajnálom, nagyon meg tudtam vele barátkozni. Jó pár dolog jobban tetszik benne, mint anno a DirectX 9-es verziójában. Azóta persze a DirectX 10 lehet, hogy jobban áll. Egyszer foglalkoztam vele, még a felépítése is teljesen más volt.

Azonban OpenGL előnye a backward compatibility, azaz simán írható olyan játék is, ami nagyon régi gépeken is fut. A DirectX ezzel szemben: ha a 9-es verziót használod, jó pár "mai" funkció nem érhető el, ha viszont a 10-es - vagy afeletti - verziót használod, akkor a visszafele kompatibilitást veszíted el. Oké, értem én, a legtöbb videókártya már tud legalább DirectX 10-et is kezelni, de hát no!

   
Asylum - Törzstag | 5441 hsz       Online status #204754   2014.09.10 11:38 GMT+1 óra  
Ami egyáltalán nem új dolog, hiszen a konzolról pc-re portolás mindigis ilyen vérhugyozással járt. +1 platform ezen nem ront sokat, ha valaki el akarja adni a szarját, akkor megcsinálja.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Geri - Törzstag | 2186 hsz       Online status #204752   2014.09.10 01:16 GMT+1 óra  
a platformfüggő api addig jó, amíg elszeparálható külön fájlokba, és amíg kb 10 sorból megvan (alsa, mmsystem32, gdi).

viszont hogyha arra kell felépíteni valamit, akkor már brutális következményei vannak nemcsak portolhatóság, hanem akár egy másik fordítókörnyezetre való átállás során is.

   
Seeting - Törzstag | 2306 hsz       Online status #204746   2014.09.09 16:57 GMT+1 óra  
Nekem jó tapasztalataim vannak apple termékekkel és az sdk-val kapcsolatban. A metalt még nem próbáltam mert leszoktam a bétákról, de a Unity úgyis támogatni fogja a háttérben egyébként.
   
Asylum - Törzstag | 5441 hsz       Online status #204745   2014.09.09 15:11 GMT+1 óra  
Pedig a platformfuggo apiknak (pl. Metal) megvan az az elonye, hogy nem pattog a driver bug ideoda az apple meg az ati kozott, hanem eleg az apple-t seggberugni. Persze, hogy ok hogy intezik el az egy mas dolog, en mindenestre ugy, hogy nem veszek apple termeket.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
zeller - Törzstag | 464 hsz       Online status #204740   2014.09.09 11:03 GMT+1 óra  
ez vegso soron sztem azt fogja eredmenyezni, hogy meg kevesebb kis engine lesz, ami meg lesz, az csak winre. es mindenki hasznaljon unity/udk/stb...

   
syam - Törzstag | 1491 hsz       Online status #204739   2014.09.09 10:16 GMT+1 óra  
Régen sok API volt, akkor jött az egységesítjük őket mozgalom.
Most ez kezd lecsengeni és újra jön(?) a sok, saját API mozgalom.
alias aalberik
   
zeller - Törzstag | 464 hsz       Online status #204738   2014.09.09 09:31 GMT+1 óra  
hat en rohadtul nem akarok platformfuggo apikat hasznalni...

   
Geri - Törzstag | 2186 hsz       Online status #204731   2014.09.08 21:36 GMT+1 óra  
ez egy remek ötlet. használjon cry enginet mindenki a tetriszéhez

   
Seeting - Törzstag | 2306 hsz       Online status #204729   2014.09.08 18:38 GMT+1 óra  
Az az alternatíva, hogy használj ipari engine-t, ne sajátot.
   
Asylum - Törzstag | 5441 hsz       Online status #204728   2014.09.08 15:36 GMT+1 óra  
DirectX, Metal (majd ha lesz OS X-re).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
zeller - Törzstag | 464 hsz       Online status #204727   2014.09.08 14:51 GMT+1 óra  
Mi az alternativaja?

   
Asylum - Törzstag | 5441 hsz       Online status #204725   2014.09.08 12:39 GMT+1 óra  
Persze ha fizetnek érte, akkor muszáj nekrofilkodni
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #204724   2014.09.08 10:54 GMT+1 óra  
Halott az OpenGL? Ja jó, most azonnal abba is hagyom, nem is használom soha többé!

   
Asylum - Törzstag | 5441 hsz       Online status #204723   2014.09.08 10:26 GMT+1 óra  
Idézet

még reálisan elkészíthető egy új, nyílt forráskódú grafikus API.



Itt hagytam abba. Az opengl nem nyílt forráskodú, hanem nyilt szabvány...óriási különbség. És egyébként meg egy újratervezés nem fogja megmenteni, már most halott.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Seeting - Törzstag | 2306 hsz       Online status #204710   2014.09.07 19:24 GMT+1 óra  
Asylum - Törzstag | 5441 hsz       Online status #204691   2014.09.04 12:10 GMT+1 óra  
Új zellercikk:

http://darthasylum.blog.hu/2014/09/01/opengl_compute_shaderek

(néha még frissülni fog a nurbs-ös rész)

Ezt a hozzászólást Asylum módosította (2014.09.04 15:31 GMT+1 óra, 1078 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #204688   2014.09.04 10:26 GMT+1 óra  
Jelen esetben a Unity Asset Store-ban néztem szét, van pár jópofa. Általában FBX-ben vannak, de azt lehet ide-oda importálni.

   
syam - Törzstag | 1491 hsz       Online status #204686   2014.09.04 09:58 GMT+1 óra  
Off:
Ekkor viszont már megkérdezném, hogy honnan szoktál szerezni ingyenes csontozott modelleket?
alias aalberik
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] > 5 < [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]