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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2192
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
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]
Geri - Törzstag | 2192 hsz       Online status #208445   2015.10.12 16:08 GMT+1 óra  
minnél közelebbi leszármazási vonalat vizsgálunk, annál jobban hasonlítanak, és minnél távolabbit vizsgálunk, annál kevésbé.

egy emlős gerinces, és egy nem emlős gerinces is máshogy néz ki, de valamennyire azért hasonlítanak.

egy gerinces, és egy gerinctelen állat is máshogy néz ki.

és pl egy oxigént lélegző, egy széndioxidot lélegző, és egy nitrogént lélegző életforma már teljesen máshogy néz ki.

egy másik bolygó élőlényeit pedig igencsak nehezen fogjuk tudni észrevenni, főleg, ha nem is szén-alapúak. a te példád is az én gondolatmenetemet igazolja.

   
FZoli - Szerkesztő | 4892 hsz       Online status #208444   2015.10.12 14:36 GMT+1 óra  
nah ezzel viszont nem értek egyet. Attól még, hogy ugyanaz az api, még nagyon messze vagyunk a kinézettől.

Ennyi erővel a raszterizált megjelenítők is meghatározzák a kinézetét a játékoknak, de így még sem kategorizálunk. Mintha azt mondanád, hogy minden földi életforma azonos, csak mert szénalapú.
   
Geri - Törzstag | 2192 hsz       Online status #208443   2015.10.12 14:11 GMT+1 óra  
fzoli: a 3d gyorsítás a játékok kinézetét egyértelműen meghatározza, mert ugyanazon apik alatt futnak, amik alapvetően ugyanúgy renderelnek. ~1996 előtt, tehát a 3d éra előtt sokkal nagyobb volt a grafikai diverzitás.

   
FZoli - Szerkesztő | 4892 hsz       Online status #208442   2015.10.12 13:42 GMT+1 óra  
Azért az én megfogalmazásomban is ott van, hogy hasznos, meg hogy csak picit öli ki Tényleg jobb vele dolgozni, viszont ma annyira minden rápörögtt a PBR-re, szinte csak post effektekben térnek el, pedig azért egy Sourceot egy Doom III enginetől mennyire meg tudtál különböztetni pl. hiába a festett hatású textúrák és a kontúros ábrázolás a Wowban, vagy a fotoreál textúrák BF3-ban, meg a teljesen más tonemapping ha a fényezési modell csattra ugyanaz, akkor ott motoszkál az érzés, mint amikor látsz egy játékot és "tudod" róla, hogy nna, ez Unity. Hiába más a model stíllusa vagy a textúra, süt róla, felismered. De persze lehetek egyedül a véleményemmel
   
Asylum - Törzstag | 5462 hsz       Online status #208439   2015.10.12 12:54 GMT+1 óra  
Nem öli ki, ez olyan mintha azt mondanád, hogy "ami fotorealisztikus az nem egyedi". Maga a PBR önmagában nem fotorealisztikus, ugyanúgy lehet használni az algoritmust egy WoW-ban mint egy BF3-ban. A munkafolyamatot könnyíti inkább, mert amit megcsinálsz egy nappali pályához az egy esti pályán is jól fog kinézni.

Nem vagyok földönkívüli
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
FZoli - Szerkesztő | 4892 hsz       Online status #208436   2015.10.12 08:27 GMT+1 óra  
Csak most tévedtem id,e szép munka, szépen összegyűjtötted és elég jól végig is veszi a cikk, grat! Anno mikor én beleástam magam, több nap volt az irodalmazás, és hegyekben álltak a jobb roszsak könyvjelzők... különösen amikor opptimalizálni szerettem volna... azátn rá is hagytam az U5-el, meg aztán kicsit félre is tettem, emrt iszonyatosan hasznos, csak meg van az a hátránya, hogy picit kiöli az egyediséget a kinézetből.
   
Viperion - Tag | 540 hsz       Online status #208435   2015.10.12 01:32 GMT+1 óra  
Asylum az a matek ott emberfeletti.
Soha nem értettem és nem is fogom.
Szerintem azok akik értik is azok földönkívüliek. Asylum te is az vagy.

   
Asylum - Törzstag | 5462 hsz       Online status #208423   2015.10.07 13:02 GMT+1 óra  
Nem tudok sűrűbben cikket írni mert baromi sok meló : / (ez is két hónap volt)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
zeller - Törzstag | 480 hsz       Online status #208420   2015.10.06 17:32 GMT+1 óra  
Jo cikk. Az elejebe tehettel volna tobb abrat a kepletekhez. Regen volt mar...

   
Asylum - Törzstag | 5462 hsz       Online status #208378   2015.09.28 20:44 GMT+1 óra  
Köszi, csak annyit szeretnék kérni, hogy a blogbejegyzésre (amit ide beraktam) mutasson a link, mert ott számolja a statisztikát
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2524 hsz       Online status #208375   2015.09.28 18:41 GMT+1 óra  
Done.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Lord_Crusare - Törzstag | 1305 hsz       Online status #208369   2015.09.28 11:56 GMT+1 óra  
Fú, köszi, ez baromi hasznos!

   
Asylum - Törzstag | 5462 hsz       Online status #208367   2015.09.28 10:11 GMT+1 óra  
Physically based rendering cikk:

http://darthasylum.blog.hu/2015/09/28/physically_based_rendering

Ha most visszaemlékszem arra, hogy annak idején milyen cikkek voltak itt az oldalon a Phong modellről, akkor ezt a technológiát egy újabb mérföldkőnek kell tekintem, sőt ez kellene hogy az új generáció standardja legyen innentől kezdve (a látszólagos nehézsége ellenére).

Lenne szíves valaki befrissíteni a blogszemlét? Szerintem ez megér annyit
Thx
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #207097   2015.03.17 13:35 GMT+1 óra  
Következőre már az lesz írok egy sajátot aztán tudom mi hol van honnét hova megy a sin meg a cos. Tegnap már átnéztem kézzel hogyan lehet forgatni 1-1 tengelyen. Kicsit tovább fog tartani, de 2D-be is írtam saját Vector2 osztályt és minden működött vele.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Asylum - Törzstag | 5462 hsz       Online status #207093   2015.03.16 22:24 GMT+1 óra  
Idézet

Lényegében rossz a forward.



Mert rossz oldalról szorzod...

Szvsz a jf ott kezdődik hogy saját matlibet írsz és nem hagyatkozol ilyen nem egyértelmű szarokra (glm ugyanilyen fos).

Ezt a hozzászólást Asylum módosította (2015.03.17 13:55 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #207087   2015.03.16 13:47 GMT+1 óra  
Nah igen ez a yaw, pitch, roll kamera kell nekem. De beírtam Asylum a kodod és hát nem igazán szuperál. Vmit még mindig elcseszek. Ja és OpenTK-t használlok, de ugyanaz mint a gl kb. Itt a kód:

Kód:
Matrix4 perspective = Matrix4.CreatePerspectiveFieldOfView(1.0f, Width / Height, 0.01f, 2000f);
GL.MatrixMode(MatrixMode.Projection);
GL.LoadIdentity();
GL.MultMatrix(ref perspective);

Matrix4 view = Matrix4.Identity;
view = Matrix4.Mult(view, camera.MatrixFromYawPitchRoll(camera.Yaw, camera.Pitch, camera.Roll));
camera.Forward = Vector3.Transform(new Vector3(0,0,-1), view);
camera.Position += camera.Forward / 10f;
view = Matrix4.Mult(view, Matrix4.CreateTranslation(camera.Position.X, camera.Position.Y, camera.Position.Z));

GL.MultMatrix(ref view);
GL.MatrixMode(MatrixMode.Modelview);
GL.LoadIdentity();


Azt csinálja hogy folyamat megy a Z tengelyen, de akármerre yaw-olok meg rollozok,.. mindig a Z tengelyen megy ugyanabba az irányba a kamera. Lényegében rossz a forward.
Instalok a te módszeredet még nem igazán próbáltam.

ui. a forgatós kodot innét vettem: http://www.opentk.com/node/3758 (ezt csak bemásoltam ránézésre nem igazán akartam megérteni )
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Asylum - Törzstag | 5462 hsz       Online status #207078   2015.03.15 22:27 GMT+1 óra  
Rossz oldalról közelíted meg...ha jól értem spectator kamerát akarsz (bár egy repülős játékhoz miért pont azt?), persze arra is lehet használni a lookat-ot csak nincs értelme. Milyen matlibet használsz?

Kód:
mat4 view = rotate(yaw, pitch, roll);
vec3 forward = view * vec3(0, 0, -1);

eyepos += forward * speed;
view = translate(eyepos) * view;
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 563 hsz       Online status #207073   2015.03.15 19:11 GMT+1 óra  
Csinálhatsz egy olyat, hogy készítesz egy orientation matrixot, amiben eltárolod a forgatást. Majd, ha megvan, hogy a középponttól mennyire szeretnéd látni a modellt, akkor eltranszformálod azt a vektort ezzel az orientation matrix-szal, valami ilyesmi:
Kód:
orientation.yawPitchRoll(rotate);
eyePosition = position + Vector3::transform(eyeOffset, orientation);

Majd ezzel már tudod használni a lookAt függvényt.

   
Bukta - Tag | 308 hsz       Online status #207072   2015.03.15 18:32 GMT+1 óra  
Okés köszönet, de az a forgatás akkor is kell a repcsi irányításához :/ . Van a kamera pos, meg van a target, és a targetet a kamera körül kéne mozgatni. De akárhogy csinálom mindig az origo körül mozgatja.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Instalok - Tag | 563 hsz       Online status #207069   2015.03.15 17:33 GMT+1 óra  
Van külön mátrix erre, amit te számolsz, az a world mátrix A view mátrixra nézd meg a lookAt nevűt. Ennek van 3 pozíciója: hogy honnan nézel, mit nézel, és mi a world up.

   
Bukta - Tag | 308 hsz       Online status #207068   2015.03.15 17:17 GMT+1 óra  
view = identity;
view = scale*rotate*translate;
Így és azem ez a jo sorrend. de csak forgatom. scale nem játszik.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Asylum - Törzstag | 5462 hsz       Online status #207067   2015.03.15 16:15 GMT+1 óra  
Hogyan számolod ki a view mátrixot?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #207065   2015.03.15 15:58 GMT+1 óra  
Üdv

Jó régen forumoztam már itt, ugyhogy elejtek egy kérdést 3D-s repülős játékot akarok készíteni. Viszont már az elején elakadtam :/ megcsináltam a sík pályát -később domborzatot is- de a kamera mozgatás nem megy. Azt akarom h ha nyomom az előre gombot akkor a kamera menjen előre (arra amerre néz). Viszont akkor tudni kéne az irányvektort. Volt pár 5letem, de nem jöttek be. Nektek biztos nem nagy varázslat ezt megoldani .

Előre is kösz!
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Instalok - Tag | 563 hsz       Online status #207003   2015.03.12 11:35 GMT+1 óra  
Idézet
Asylum :
ui.: még jó hogy elolvastam, én is rájöttem egy kurvanagy marhaságra az engineben


Szívesen!

   
Asylum - Törzstag | 5462 hsz       Online status #207002   2015.03.12 10:10 GMT+1 óra  
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Dark_Secrets_of_shader_Dev-Mojo.pdf

ui.: még jó hogy elolvastam, én is rájöttem egy kurvanagy marhaságra az engineben

Ezt a hozzászólást Asylum módosította (2015.03.12 10:32 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 563 hsz       Online status #206990   2015.03.11 19:14 GMT+1 óra  
Igazából csak a lentebb említett problémáim vannak. Egyébként nem tudom elképzelni, hogy nagyon lassítana az, hogy éppen a vec3-nak melyik konstruktorát használom, illetve, hogy változóból kap-e értéket. A többit a szerény GLSL tudásomnak megfelelően írtam meg.

   
syam - Törzstag | 1491 hsz       Online status #206989   2015.03.11 18:21 GMT+1 óra  
Mi pontosan az a "mikre"?
alias aalberik
   
Instalok - Tag | 563 hsz       Online status #206988   2015.03.11 18:11 GMT+1 óra  
Van valahol valami tips & tricks gyűjtemény, hogy mikre érdemes ilyenkor figyelni?

   
syam - Törzstag | 1491 hsz       Online status #206987   2015.03.11 17:55 GMT+1 óra  
A shader compiler gyártónként változik vagyis egyik jobban optimalizál, mint a másik vagy egyáltalán nem.
Ha shadert generálsz akkor mindenképp érdemes saját kódoptimalizálót szerezni/írni, hogy ne bízd magad a véletlenre.
alias aalberik
   
Instalok - Tag | 563 hsz       Online status #206986   2015.03.11 17:27 GMT+1 óra  
Nem, generálok node-okból, mint az UE4 Material editorja. Tudom, hogy vannak többféle konstruktorai, csak az a kérdéses, hogy ezek között (illetve aközött, hogy beírod a konstans értéket, vagy változóból olvassa ki) van-e sebességbeli különbség.

   
Asylum - Törzstag | 5462 hsz       Online status #206985   2015.03.11 17:14 GMT+1 óra  
Vektor konstruktor lehet egyelemű is:

Kód:
vec2 a = vec2(0.5);


Automatikus generálás alatt pedig mit értesz konkrétan? Fordítást egy másik nyelvről?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 563 hsz       Online status #206983   2015.03.11 16:04 GMT+1 óra  
Van valami performance drawback-je a változók használatának (GLSL version 110)?
Kód:
vec2 a = vec2(0.5, 0.5);

vs
Kód:
float a = 0.5;
vec2 b = vec2(a, a);

Nyilván ép ésszel nem írnék le olyat, mint a második, de most shader auto-generáláson dolgozok, és ha az ilyesmi nem lenne gond, az nagy könnyítés lenne.

Illetve ehhez hasonlóan az alábbi is felmerült:
Kód:
vec2 a = vec2(1.0, 2.0);
vec3 b = vec3(a, 3.0);

vs
Kód:
vec2 a = vec2(1.0, 2.0);
vec3 b = vec3(a.x, a.y, 3.0);

   
Asylum - Törzstag | 5462 hsz       Online status #206933   2015.03.06 18:34 GMT+1 óra  
http://m.cdn.blog.hu/da/darthasylum/tutorials/C++/ch40_deferred.html
http://m.cdn.blog.hu/da/darthasylum/tutorials/C++/ch52_compute.html

A png egy vicces állat, mert úgy tudom külön be lehet állítva neki gamma érték (de feltételezheted, hogy 2.2). Ha srgb textúrába töltöd be, akkor a textúra olvasás automatikusan degammázza (pow(x, 2.2)). A gamma korrekciót viszont én mindig egy külön shaderrel oldom meg (pow(color.rgb, 1.0 / 2.2)). Van srgb framebuffer is de az nekem mindig furán működik... Nézd meg a forward+ kódot.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 563 hsz       Online status #206920   2015.03.06 08:58 GMT+1 óra  
Most akkor hogy van ez a gamma korrektálás?

Van egy input png textúrám, ezt dekódolom RGBA-ba, ezt töltöm fel a GPU-ra (GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE)

Vannak FBO-k. Nevezetesen (deferred shading) egy GBufferem és Lighting bufferem, a következő textúrákkal:
GBuffer: GL_RGBA8, GL_RGBA8
Lighting: GL_RGBA16F

A geometriát renderelem a gbufferbe, az abban eltárolt adatokat használom fel a lighting buffer előállításához, majd azokat az információkat renderelem a back bufferbe (egyelőre, később az is egy FBO lesz, hogy lehessen ügyesen postprocesselni). A backbufferem gondolom RGBA8.

Most akkor mikor melyik irányba kell mit csinálni? Esetleg SRGB textúra? Próbáltam felfogni, hogy mi hogy van, de ahogy kipróbáltam, úgy elég furcsa eredményt kaptam.

   
Instalok - Tag | 563 hsz       Online status #206593   2015.02.12 06:17 GMT+1 óra  
A 100 szerintem jóval 60 fölött van. De ezek szerint ez természetes jelenség, jól van.

   
Asylum - Törzstag | 5462 hsz       Online status #206588   2015.02.11 21:22 GMT+1 óra  
Mert a játék nem 60 fps felett megy hanem valszeg jóval alatta
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
proof88 - Törzstag | 530 hsz       Online status #206587   2015.02.11 20:13 GMT+1 óra  
valszeg véletlenül pont annyi fps-ed van azokban a játékokban, hogy vsync nélkül sincs feltűnő tearing.
   
Instalok - Tag | 563 hsz       Online status #206585   2015.02.11 18:21 GMT+1 óra  
Most lettem csak arra figyelmes, hogy (csak és kizárólag) fullscreen módban, ha mozgok a kamerával, hullámzik a kép. A vsync nyilván megoldja a problémát, de hogy lehet az, hogy a játékoknál, amivel játszom, nem tapasztalom ezt a jelenséget? Az update-ek 60x hívódnak meg másodpercenként, a rajzolás viszont egyelőre nincs korlátozva.

   
Asylum - Törzstag | 5462 hsz       Online status #206568   2015.02.10 14:25 GMT+1 óra  
Nem, simát is lehet (image-ként).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #206567   2015.02.10 13:56 GMT+1 óra  
Ha jól tudom compute shadernek csak immutable texturet lehet bekötni.
alias aalberik
   
Instalok - Tag | 563 hsz       Online status #206566   2015.02.10 09:16 GMT+1 óra  
Nem jól fogalmaztam. Nyilván nem úgy értettem, hogy 1-nek, hanem, hogy olyan hívásoknak. Viszont a glTexImage2D OGL 2.0 óta van, míg a másik úgy látom, hogy egy új dolog, OGL 4.2.

   
Asylum - Törzstag | 5462 hsz       Online status #206565   2015.02.10 09:03 GMT+1 óra  
Nem azt írja...azt írja, hogy ez az egy hívás megfelel egy glTexImage2D ciklusnak (azaz a storage egy menetben tölti fel az összes mip szintet). DE utána többször már nem módosítható a formátum.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 563 hsz       Online status #206562   2015.02.09 15:43 GMT+1 óra  
Annyit olvastam róla, h immutable, de nem tudtam, hogy emiatt gyorsabb is lehet. Köszi!

szerk.:
Mondjuk a doksi szerint a glTexStorage2D GL_TEXTURE_2D paraméterrel való hívása megfelel a
Kód:
glTexImage2D(target, i, internalformat, width, height, 0, format, type, NULL);

hívásnak.
Idézet
The behavior of glTexStorage2D depends on the target parameter. When target is GL_TEXTURE_2D, GL_PROXY_TEXTURE_2D, GL_TEXTURE_RECTANGLE, GL_PROXY_TEXTURE_RECTANGLE or GL_PROXY_TEXTURE_CUBE_MAP, calling glTexStorage2D is equivalent, assuming no errors are generated, to executing the following pseudo-code:

   
Asylum - Törzstag | 5462 hsz       Online status #206552   2015.02.09 14:03 GMT+1 óra  
A storage egy módosíthatatlan textúrát csinál (immutable), ez rajzoláskor optimálisabb, mert a driver nem végez rajta ellenőrzéseket.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 563 hsz       Online status #206548   2015.02.09 11:35 GMT+1 óra  
Van valami értelme glTexStorage2D-t használni glTexImage2D helyett? Mikor melyiket?

   
Levente - Tag | 24 hsz       Online status #206407   2015.01.26 21:08 GMT+1 óra  
Sikerült megoldani. x64 es glew volt a lib-be. És ezzel szenvedtem 3 napig.
De végre működik, köszi a segítséget.

   
Levente - Tag | 24 hsz       Online status #206405   2015.01.26 20:31 GMT+1 óra  
szerintem megtalálja, mert ha megcserélem és a freeglut-ot includolom először akkor a glew jelez, hogy a őt kéne először includolni

   
Instalok - Tag | 563 hsz       Online status #206402   2015.01.26 20:25 GMT+1 óra  
Pedig ez a fordítási linkelési hiba arról árulkodik, hogy valami linkelés nem jó. Esetleg rossz libet fordítasz hozzá, vagy meg sem találja?

   
Levente - Tag | 24 hsz       Online status #206399   2015.01.26 19:48 GMT+1 óra  
Igen arról az oldalról csináltam meg, a linkelések is megvannak, de még mindig ugyan az. A glew-l van valami mert a freeglut-ot, os rész futtatom csak az lefut rendesen létre is hozza az ablakot, de ha glew-os rész hozzá csapom akkor nem megy.

   
Instalok - Tag | 563 hsz       Online status #206396   2015.01.26 16:55 GMT+1 óra  
Nem kellene a libet belefordítani? Úgy tudom, hogy attól, hogy van egy dll-ed, attól még egy libbel össze kell fordítani. No persze ez egy kicsi lib ilyenkor, mert alapvetően csak függvénypointerek vannak benne.

Gondolj csak bele, a fordító nem tudhatja, hogy mik vannak a dll-ben, amíg meg nem mondod. Van ilyenkor egy statikus libed, ami megmondja, hogy milyen függvényeid vannak milyen szignatúrával, és ezt oldja fel dinamikusan (dll-ből)

Itt le is van írva, hogy hozzá kell fordítanod.
Idézet
Remember to link your project with glew32.lib, glu32.lib, and opengl32.lib

   
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]