szerk.:
Ez még az előzőre, ez az SSS
De az király, ha van screen-space belőle. Akkor nem is tudom, hogy mi kellene még, a többire meg szerintem jó a "sima" irradiance / lighting.
De a lighting egy dolog, például egy SSS (zseléanyag ) shadert hogy csinálnál vele? Úgy értem, hogy ott fontos, hogy milyen fény honnan és mikor és hogyan éri, tehát a "sima" irradiance nem jó hozzá, nem?
De, de akkor 3 geometry pass kell, hogy ezt elérd. Az nem elég, hogy egyszer depth + normal + specular, aztán lighting aztán még1 "forward" pass textúrákkal, mert akkor a 2. passban (lighting) nem tudod, hogy milyen shadinget alkalmazz / objektum.
Gondolkoztam ezen a deferred shading / lighting dolgon. Ha teljesen különböző shadingeket akarunk deferred lightinggal (pl. normal mapping, SSS, ilyen-olyan amolyan shading), akkor valahogy a lighting számolás lépésben meg kell mondanunk, hogy melyik pixelre milyen shader fusson le.
Tehát kicsit visszakanyarodtam a deferred shadinghez, és valami ilyesmin gondolkoztam:
Kód:
Pass 1: G-buffer
- render depth
- render normals.rgb, render specular power in alpha
- render diffuse texture.rgb (render specular multiplier in alpha, or)
(- render specular with color)
- set stencil value based on shading type (diffuse without normal mapping, normal mapping, SSS shading, etc.)
Pass 2: Lighting
- for each shading type
- set stencil test equals to the pre-defined value (based on shading type)
- apply the current shader
- shade pixels based on G-buffer
Pass 3: Combine
- combine G-buffer's diffuse color and Lighting texture
(- apply gamma correction)
Az eleje a szokásos G-buffer, azzal a különbséggel, hogy ismerjük, hogy az adott objektumot milyen shaderrel akarjuk majd rendereltetni, tehát azon alapulva kiírunk egy stencil értéket.
A lighting passban beállítjuk a megfelelő shadert, a stencil tesztet az adott értékre állítjuk, ami így megadja azokat a pixeleket, amikre az adott shadernek le kell futnia, majd számolunk egyet.
A vége innentől szintén ugyan az.
Gondolkoztam még azon, hogy a stencil helyett alpha testet kellene valahogy használni, mert a point light stencil test optmializálás sokat dob a dolgon.
Van itt egy arc, aki leimplementálta, van benne kipróbálható exe is. Nem nagyon néztem még meg, csak kipróbáltam, de terveztem egyszer megcsinálni. Sokat dob(hat) a látványon, csak kérdéses, hogy megéri-e.
GI-t amúgy csak raytracinggel lehet csinálni, vagy van valami kevésbé szép, de használható módszer? Illetve ez a specular dolog elég szépen nézett ki. Ez is csak raytracing?
A hierarchiával lehet spórolni, de az oldalak iránya nem sokat jelent. Sőt, a normálok miatt akkor még valamiféle átlagolást is kéne ejteni, szóval ront a helyzeten ha lapos oldalú kockákként képezed le őket. A hierarchikusan felépített fában viszont gyorsabb a keresés, mert egész térrészeket dobhatsz el. Persze ez nem jelenti azt, hogy feltétlenül gyorsabb a poligonális objektumokra vett sugárkövetésnél, mert ugye függ a méretezéstől. Pl poligonok száma, objektumok száma, térfelosztás, vagy éppen a voxelhierarchia felépítése. Meg pl amíg poligonális modellekre jól kitalált animációs módszerek vannak, addig voxelesre még csak alig.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
Egy voxel-alapú 3D térben vajon nem gyorsabb a raytracing/raycasting, mint egyébként? Tehát ha az objektumok a térben kizárólag a három tengelyre merőleges lapokból állnak, vagy esetleg pont ugyanakkora kockákból (pl. Minecraft) van felépítve a jelenet, akkor vannak olyan optimalizációk, amik ilyen esetben tudnak hatni a sebességre?
Szerintem jónak tűnik.
(Ugyebár a XOR azonos bitek esetén 0-ra, eltérőeknél 1-re áll be, tehát az egyenlőségvizsgálat előtti rész tulajdonképpen a subnet biteken való eltérés "értékét" adja vissza. )
Ezt a hozzászólást __z módosította (2013.05.06 14:05 GMT+1 óra, ---)
IdézetAsylum :
Mennyire common az, hogy a klasszikus megvilágitási egyenlettöl eltérve nem az árnyékos részt szorzod be egy kisebb 1 értékkel, hanem ahol nincs árnyék ott beszorzod a képet egy nagyobb 1 értékkel?
Szeretek kísérletezgetni, meg nem is olvastam először utána, úgyhogy mindkét megközelítést próbáltam tunningolni. Ez miatt meg nem is igazán tudom pontosan mi a common. Én használom.
Ezen a két képen biztosra a második van, meg utána még kettőn. Aztán néhányon fordítva. Meg összevissza.
Kimérten mindkettő ugyanúgy néz ki, csak kicsit máshogy kell őket belőni. Teljesítményben lehet eltérés megoldástól függően. A legutóbbi videóra a második kicsit gyorsabbnak tűnt.
Gondolom attól is függ, hogy hogyan van kialakítva, meg alkalmazva...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
IdézetMatzi :
HDR nélkül nem nagyon van értelme, azzal együtt használva akár működhet is a dolog. Persze ahhoz biztos rendesen be kell lőni az értékeket újra. Egész más intervallumokat kell hozzá beállítani.
Hol láttál te ilyet?
Az osszes ceges program igy csinalja es olyan artifactos mint a seggem (es ram adjak h javitsam ki ) Azert kerdem mert nem akarom ugy elkuldeni oket a picsaba hogy utana se jartam. Ja HDR-rol assetudjak mi (meg gamma korrekcio sincs).
en nem ajanlom , pont most szivtam vele 3 napig , az onarnyek artifactos lesz, nalam a problema az Oren Nayar diffusenal jott elo, mert tovabb shadeli az objectet , nem vag le 90 foknal
HDR nélkül nem nagyon van értelme, azzal együtt használva akár működhet is a dolog. Persze ahhoz biztos rendesen be kell lőni az értékeket újra. Egész más intervallumokat kell hozzá beállítani.
Hol láttál te ilyet?
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
Mennyire common az, hogy a klasszikus megvilágitási egyenlettöl eltérve nem az árnyékos részt szorzod be egy kisebb 1 értékkel, hanem ahol nincs árnyék ott beszorzod a képet egy nagyobb 1 értékkel?
Az én véleményem az, hogy ez egy kibaszottnagy baromság, viszont jól fakeli az indirect lightot (pl. egy szobában vagy). Van ennek valami mélyebb magyarázata, vagy szimplán perverzió/hozzá nem értés?
Ügyes real-time syntax tree építéssel szerintem jó karakterenként is olvasni. Szerintem azért csinálhatták úgy, mert akkor a darabolás bonyolultabb, viszont eltárolni / ellenőrizni egyszerűbb. Zárójelek, utólagos kiértékelések, akármik. Legalábbis én így "hirtelen" nem találok hibát a karakterenkénti olvasásban, ha tényleg nem lassabb (bár én anno az x parsernél azt vettem észre, h karakterenként kiolvasni lassabb, mint bizonyos szeparátor karakterenként - ami itt mondjuk csak egyszerűen a whitespace volt).
Saját kis programnyelvemhez írok fordítót. Körbenéztem a neten, és azt láttam, hogy kivétel nélkül mindenki a lexing->parsing metódust használja ilyenkor. Én viszont kísérleteztem egy egymenetes fordítóval, ami tulajdonképpen karakterenként megy végig a forráskódon, és így állít össze belőle syntax tree-t. Elvileg minden szintaktikai hibalehetőséget le tudok kezelni vele, és nem tűnik lassúnak sem.
Itt jön be a kérdésem: miért ragaszkodik mindenki a fent említett lexeres módszerhez? A lexer ugye elég bonyolult regular expressionok segítségével bontja darabokra a forráskódot, aztán ezen még át kell menni a parserrel, hogy a kód ellenőrizve legyen és syntax tree-vé alakuljon. A regex-ek tudtommal nem a gyorsaságukról híresek, legalábbis ha egy "kurzor" segítségével karakterenként végigmegyek egy szövegen és így darabolgatom, elméletileg nincs olyan regex ami ezen a módszeren sebességben túltesz. Illetve általában jó pár regexnek végig kell mennie a forráson, ami azt jelenti, hogy többször is végigfutnak elég bonyolult ellenőrzések
Ráadásul ezeket a regexeket meg is kéne írni valakinek (nekem), amit jobb szeretnék kihagyni, ha lehet Szóval, mi a brutális hülyeség az én módszeremben, ami miatt mindenki más lexerrel szenved?
IdézetVultureHunter :
A baricentrikus koordinátákra gondoltam, de ott háromszögre alkalmazzák, működhet itt is szerintetek?
Matematikailag egy négyzet két háromszögre is bontható.
A lineáris interpolációval az a gond, hogy négy vertexből gyakran nem jön ki a plane egy síkra, így megtörik a tényleges felület, a számolt meg kicsit máshol lesz mint a vizuális. Persze ez nem mindenhol feltűnő.
---
u.i:
Ja már hogy a "nem koplanáris" azt jelenti... Jóvan.
Ezt a hozzászólást ddbwo módosította (2012.11.08 21:10 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
A következő kérdésem lenne: egy terep vertexei közül kiválasztom az avatar talppontjához legközelebb eső legkisebb indexű vertexet, majd ezek index szerinti közvetlen (legközelebbi) szomszédjait - az így kapott 4 vertex meghatároz egy területet (nem feltétlenül koplanáris...), hogy tudom meghatározni a magasság értékek alapján súlyozva, egy a területen belüli pont magasságát? A baricentrikus koordinátákra gondoltam, de ott háromszögre alkalmazzák, működhet itt is szerintetek?
Más:
Működik a becsomagolás, kicsomagolás, nézőke valamelyik filera, minden csudijó, azonban most kicsit elgondolkoztam.
Ha mondjuk a packemben van egy alma nevű file, aminek a mérete mondjuk 100 byte. Mi történik, ha egy szintén alma nevű filet akarok bemásolni oda? A totalcmd okosan megkérdezi, hogy felülírom-e, ha nem, akkor skippeli, tehát csak a felülírással kell foglalkozni.
Na már most 3 lehetőség van:
- az új alma mérete is 100, ekkor csak az adott részre kell ugrani a packben, és szimplán a "helyére" írni az újat.
- az új alma mérete < 100, ekkor még szintén megtehetjük, hogy a helyére írjuk, de marad egy kis "fölösleg", amit valahogy el kell tüntetni.
- az új alma mérete > 100, ami ugye azt jelenti, hogy ha odaírnánk, akkor "belelógna" a következő adatba, így kell egy kis plusz helyet csinálni neki.
Azaz ha az új file mérete != régi file mérete, valamit ügyeskedni kell. Az nekem elég durva megoldásnak tűnik, hogy fogom az utána lévő részeket, és memcpyvel átmásolom kicsit odébb. Főleg, hogy - ha jól tudom - azért van egy kis korlátja a memcpynek, azaz egy 2gb-s pack esetén nem lesz túl vicces dolog ilyet csinálni.
Tehát ami a legjobb lenne, hogy ha lenne egy olyan eljárás, ami a file egy adott részét törli. De úgy, hogy az utána lévő részek a "helyére" kerüljenek. Ekkor simán a file végébe írnám az új adatot.
Nafene, pedig megnéztem vagy 10x köszi hát, próbálgatom, majd jelentkezek, ha nem megy
szerk.:
Most volt egy 10-20 percem, nézegettem, marha jól ki van találva ez a TotalCmd. Adtak egy interfacet, amit meg kell valósítani, érthetően leírták a wikis oldalon, hogy mi mit csinál, és nekünk mit kell csinálni.
Röviden:
Amikor meg akarjuk nyitni majd a packfilet, lefut az OpenArchive: Itt semmi mást nem kell tennünk, csak vissza kell dobni egy handlert a fileról (pl. CreateFile). Ezután egy loopban lefut a ReadHeader: itt a mi kis headerjeinket olvassuk be, ahol legalább a fájlnevet, létrehozási dátumot, méretet meg kell határozunk (ez tök jó, ezek úgy is el voltak tárolva). Ha nincs több file, akkor E_END_ARCHIVE. A legvégén CloseArchive, ahol meg természetesen lezárjuk a handlert.
A tömörítés rész sem bonyolult, igazából csak a megfelelő függvényekbe be kell helyettesítenünk a mi kis kódolásunkat / dekódolásunkat. Remélem ismét lesz egy kis időm foglalkozni vele hamarosan, majd jelentkezek
Ezt a hozzászólást Pretender módosította (2012.08.02 17:00 GMT+1 óra, ---)
IdézetPretender :
Lehet, h hülye vagyok, de pl. azt se találtam meg, hogy hol van a totalcmdnek valami libje, hogy le tudjam fordítani a saját kis pluginemet
@zeller: Például mert a *.tar-t meg tudja nyitni bármelyik kispista is, aki nem ért hozzá.
@HG: ha rájönnék, hogy hogy kell, mindenképpen szólnék
@M4: ezeket már én is nézegettem, egybe leírást viszont nem nagyon találtam
szerk.:
Lehet, h hülye vagyok, de pl. azt se találtam meg, hogy hol van a totalcmdnek valami libje, hogy le tudjam fordítani a saját kis pluginemet
Ezt a hozzászólást Pretender módosította (2012.08.02 08:00 GMT+1 óra, ---)
Esetleg foglalkozott már valaki totalcmd plugin írásával? Csináltam egy saját pack fájlt, egyelőre egy adott folder összes fileját tudom csak egyszerre becsomagolni. Ez később folyamatos content hozzáadása esetén nem túl kényelmes, így gondoltam valami Total Commander alá épülő pluginra, amivel úgy tudnék pakolni / kivenni a saját fileomból, mintha csak egy zip lenne.
Zarojelben jegyzem meg hogy az entity system is oop. A hasznalt patternek a teljesseg igenye nelkul:
composite, strategy, decorator, visitor, chain of responsibility, flyweight. Nem feltetlenul mind egyszerre.
Az oop != heterogen kollekciok epitgetesevel.
IdézetclarDrum :
Erről tud valaki bővebben valamit és hogy megérné-e ezen az úton haladni??
Komponens rendszert akkor éri meg építeni, ha nagyon sok, nagyon változatos tulajdonságú entitás szerepelhet a játékban. Ebből ugye alap esetben (OOP) az következne, hogy az osztályhierarchia jó nagy, jó sok osztállyal és kapcsolattal. Ez mondjuk még felépíthető, de komoly gondok léphetnek fel, ha valamikor a fejlesztés során pl kitalál a designer egy új entitást (vagy módosít egy meglévőt) ami sehogy sem illeszkedik a hierarchiába. Komponens rendszer esetén hozzáadsz/elveszel 1-2 új komponenst és kész. Viszont az elején több munka van vele, szóval meg kell gondolni, hogy megéri-e.
) Azert kerdem mert nem akarom ugy elkuldeni oket a picsaba hogy utana se jartam. Ja HDR-rol assetudjak mi (meg gamma korrekcio sincs).
