játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5440
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:    2185
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] [27]
FZoli - Szerkesztő | 4892 hsz       Online status #210096   2016.08.19 13:04 GMT+1 óra  
hát, szerintem sokkal egyszerűbb, mint aminek látszik, az én tippem valami ilyesmi:

- Az látszik, hogy csak bizonyos modelek shaderei bírnak a funkcióval. Ezek többnyire a folyosókat keretező kőalapokra húzott oszlopok, diadalívek
- látszik, hogy a karaktertől való távolság az egyik szempont a clipnek, az is lehet, hogy a kamerának csak minimális köze van hozzá, csak a karakter távolságában vág, esetleg minimális offset a kamera felé (nehéz megmondani)
- maga a clip fodrossága szerintem simán egy elmosott noiseból jön, szerintem ott semmi extra nincs, még azt is megkockáztatom h a model uv-ját használva rá van nyomva egy textúra ami vezérli a clip szabálytalanságát.
   
syam - Törzstag | 1491 hsz       Online status #210092   2016.08.18 16:58 GMT+1 óra  
Olyan mintha a felület normálvektorát figyelné. Ha a kamera előre vektora és a normálvektor közötti szög kisebb egy határnál akkor discard. Emlékeztet egy erősen mutálódott Fresnel-hatásra.
alias aalberik
   
HadaHector - Tag | 71 hsz       Online status #210091   2016.08.18 16:42 GMT+1 óra  
Wow ilyet még nem láttam, tök jó gyors nincs alfa. Egyértelműen pixel shader, és szerintem a Z depth meg egy fura torzítós textúra segítségével el lehet érni a hatást. (olyan textúra ami ilyen "heightmap" szerűen dolgozik megadja a kúpot, csak kicsit zajos)

   
Elodin - Tag | 170 hsz       Online status #210090   2016.08.18 14:50 GMT+1 óra  
Van bárkinek ötlete arra, hogy hogy működhet a pixelek eldobása a divinity original sin-ben a játékos és a kamera között?

Próbálok rájönni, de akárhogy nézem, ötletem sincs, hogy honnan jöhetne ez a mintázat a dobott terület szélén.

   
Asylum - Törzstag | 5440 hsz       Online status #209759   2016.06.21 13:46 GMT+1 óra  
A discard megbassza az early z-testet is meg a blokkosítást is.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Elodin - Tag | 170 hsz       Online status #209758   2016.06.21 11:45 GMT+1 óra  
A határon lévő háromszögek vágása helyett nem célszerűbb shaderből dobni a pixeleket a decal renderelésekor, ha a textúrakoordinátájuk nem 0 és 1 közé esik?

Statikok a decal-ok, nem mozognak, és a geometria sem, amire hatniuk kell, de játék közben állítódnak elő (vér ), erősen úgy érzem spórolni kéne számításokkal a geometria előállításakor.

   
Asylum - Törzstag | 5440 hsz       Online status #209757   2016.06.21 10:38 GMT+1 óra  
Az első része jó, de nem mented le; visszatrafózod world spacebe és kirajzolod őket, mint decal. A texcoord pedig (decalProj * pos).xy
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Elodin - Tag | 170 hsz       Online status #209756   2016.06.21 10:29 GMT+1 óra  
Tehát sorra veszem a háromszögeket, nézem a szöget a normáluk és a projektor box orientációja között, egy bizonyos felett szimplán dobom őket.

Ha nem dobom, akkor áttranszformálom a projector space-be - itt is 3d-sek lesznek, mindhárom tengely mentén 0-1-re kell vágni őket, és textúra koordinátának pedig az első két koordinátájukat lementem?

   
Asylum - Törzstag | 5440 hsz       Online status #209755   2016.06.21 09:54 GMT+1 óra  
A projector box-ra gondolj úgy mintha egy pisztolyból lőnéd ki a golyókat, amik aztán nyomot hagynak a falon. Ha merőleges (sőt, backfacing), akkor semmit nem kell csinálni. A merőleges vetítés bydef [0, 1]-be trafózza a pontokat, tehát címezhetsz vele textúrát.

Ez egyébként kajak ugyanaz, mint a shadow mapping.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Elodin - Tag | 170 hsz       Online status #209754   2016.06.21 09:48 GMT+1 óra  
Én is erre gondoltam, de ez még mindig 3d-s, nem?
A textúrakoordináták meg szintén nem tiszták.

Mondjuk az elvben sincs meg, hogy minek kéne történnie, ha a felület merőleges a decal orientációjával.

   
Asylum - Törzstag | 5440 hsz       Online status #209753   2016.06.21 09:45 GMT+1 óra  
A "projector space" a decal-okat vetítő ortho mátrix (mint affin transzformáció) tere. Arról beszél, hogy a háromszögeket áttranszformálja ide (decalProj * pos), ekkor kap egy egységkockát amiben könnyű vágni. Onnan aztán a megvágott hszögeket vissza world spacebe (decalProjInv * pos).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Elodin - Tag | 170 hsz       Online status #209752   2016.06.21 09:36 GMT+1 óra  
A geometria kivágást / uv előállítást te érted vmennyire?
Totál nem vágom, hogy az imént linkelt alkotás mit ért "projector space" alatt. Hogy lesz a 3d-s kockából (kamerafüggetlen) 2d-s négyzet? Nem nagyon látom, hogy milyen transzformáció az, amivel előállíthatnám, és hogy a fenébe nem tud lenni egy olyan háromszög, ami a 3d->2d transzformáció következtében teljes egészében ugyanazt a textúrakoordinátát kapná mindenképp.

Gondolom van vmi magic, ami nem ugrik be, mert amúgy ez ebben a formában elég lehetetlennek tűnik nekem :/

   
Instalok - Tag | 530 hsz       Online status #209751   2016.06.20 19:44 GMT+1 óra  
Nem feltétlen drágább, nem azt mondtam. Csak drágább screenspace számolni mindent, mint geometriát renderelni. Nem az a sok, hogy kirenderelj 100 háromszöget, sokkal rosszabb minden pixelre visszaszámolni a pozíciót és normalt. Általában költségesebb screenspace számolni a dolgokat, mint a geometriából "simán megkapni". Cserébe ugye ehhez az kell, hogy statikus legyen az objektum és a decal is, hogy ki tudd számolni. Egyébként annyira nem vészes szerintem a geometriából való kivágás sem. De majd látod, h melyiket használod.

   
Elodin - Tag | 170 hsz       Online status #209750   2016.06.20 19:25 GMT+1 óra  
A hagyományosnak egyszeri nagy költsége van, amikor ki kell számolni a geometriát. A screen space meg mindig ugyanannyiba kerül, csak kérdés, hogy mennyivel drágább az, mint simán az objektumot renderelni?
Mindenesetre nem látom még mindig, hogy miért lenne drágább forward rendering esetén, mint egyébként.

   
Instalok - Tag | 530 hsz       Online status #209749   2016.06.20 19:04 GMT+1 óra  
Ja igen, persze, ugyan úgy, mint a többi solid objectet. Gondolom a normalt pedig azért depthből számolta, mert írta a normal buffert. És ugyebár egyszerre olvasni és írni nem szerencsés.

A normalt meg ugye csak azért rendereli ki, mert kell a megvilágításhoz deferred shading esetén. Ha viszont azt csinálod, hogy geometriát generálsz, akkor nincs szükség normal kiszámolására, hiszen adott.

Statikus objektumok és forward esetén valószínűleg a geometria-vagdosós módszert választanám, csak az ugye érzékeny a háromszögszámra - persze ez talán nem nagy gond. Nem kell hozzá se depth buffer, se normal számolás, mert minden adott amikor a decal objektumot rendereled.

Igazából működhet forwarddal is, csak kérdéses, hogy mennyire éri meg. Valószínűleg ez a deferred shading egy "gyereke", mert ez remekül passzol a pipeline-ba.

   
Elodin - Tag | 170 hsz       Online status #209748   2016.06.20 18:01 GMT+1 óra  
Ha minden solidot kirendereltem már, akkor a depth data gyaklag elérhető forward renderingel is.
Kérdés a normal - az számítható depth-ből (ha jól emlékszem még a cikkben is úgy csinálta), vagy megoldható úgy is, hogy renderelek normal-t, ha nagyon muszáj.

"ahány fény hat rá, annyiszor kell újrarenderelni"
Miért? Simán renderelhetem úgy, mint bármelyik solid-ot szerintem, csak a többi után, nyílván saját shaderrel.

   
Instalok - Tag | 530 hsz       Online status #209747   2016.06.20 16:57 GMT+1 óra  
Az a baj, h ennek a technikának az a lényege, hogy a meglévő textúrákból (GBuffer) olvasod ki a neked kellő értékeket (depth + normal). Ha csak simán forwarddal csinálod, akkor két lehetőséged van: vagy kézzel generálsz háromszögeket ahol a decal "metszi" a geometriát, és azt rendereled, vagy a teljes geometriát, és valamiféle projektív textúrázást használsz.

Ha nincs deferred shading, akkor nincs gbuffered, magyarul nem screen space decals lesz, hanem simán decals.

szerk.:
Vagy nem.
Végülis talán működhet, csak ugye ahány fény hat rá, annyiszor kell újrarenderelni, míg a deferred ugye ezt elkerüli. Talán azért van ez a technika, mert szépen passzol a deferred shading pipeline-ba. Megvan a GBuffer, a decalok pedig módosítják.

Ezt a hozzászólást Instalok módosította (2016.06.20 17:05 GMT+1 óra, 371 nap)

   
Elodin - Tag | 170 hsz       Online status #209746   2016.06.20 16:33 GMT+1 óra  
Deferred Screen Space Decals -okat próbálom megérteni ez alapján.

Azt írja, hogy csak deffered renderingel működik a cucc.
Az nem működőképes, hogy solid objektumok renderelése után renderelem őket forward rendinggel? Nem sikerült rájönnöm még, hogy mi okozná így a problémát.

   
Elodin - Tag | 170 hsz       Online status #209683   2016.05.27 09:34 GMT+1 óra  
Első körben úgy néz ki, hogy működik a trükk - még majd mások felülvizsgálják, de nekem jónak tűnik. Előző frame ao-jából olvasok előző frame world->clip mátrixából számolt index alapján, forward rendering, nincs z pre-pass, és tudom ott számításba venni az ao-t ahol kell Anélkül, hogy többször renderelnék.

Amúgy mipmap-okkal mennyit lehet spórolni, és mennyire megy a minőség rovására? Azt első körben kiírtottam, mert pillanatnyilag egyszerűbbnek tűnt hibakeresés szempontjából, de most gondolkozom, hogy lehet vissza kéne hozni.

Asylum:
A linkelt paper demo projectje is on the fly számol. (Meg én is, mert azt használom). Kérdés, hogy ez mennyire pontos :/

   
Asylum - Törzstag | 5440 hsz       Online status #209682   2016.05.27 08:57 GMT+1 óra  
A PBR demómban le van implementálva a SAO. Nem kell hozzá külön normal buffer, mert on the fly kiszámolja.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209680   2016.05.26 17:42 GMT+1 óra  
Sajnos szerintem nem úszod meg a depth+normal passt, ami nem mellesleg egyébként sem árt. Utána meg simán PP passban rátolod a megfelelő időben. Ilyen ez, ha valaki screen-space effekteket akar forward renderinggel.

   
Elodin - Tag | 170 hsz       Online status #209677   2016.05.26 13:28 GMT+1 óra  
Blur egész jól eltünteti talán :/

Nagyon sötét. Képem most nincs sajnos. Viszont így, hogy előttük számítom az AO textúrát, ez végülis működik.

Holnap még megpróbálom az előző frame AO textúrája előző frame projection mátrixával számolt indexelés kombót, aztán ha nem jön össze, akkor valószínűleg megpróbálom jövőhéten megdumálni az illetékessel, hogy mégiscsak kell az a Z pre-pass.

   
syam - Törzstag | 1491 hsz       Online status #209676   2016.05.26 00:04 GMT+1 óra  
Engem eléggé zavart hogy mindig van egy fals él SSAO-ban - kicsit rajzfilmes érzetet adott.

Ha mindenáron forwardot akarsz tolni akkor bizony sokszor kell ugyanazt renderelni. Talán az alfa csatorna okos használatával tudsz spórolni rendert.

Az átlátszó dolgok még mindig átkozottak
AO után kell és saját árnyalás, köd stb számítás rájuk.
Mennyire volt "nagyon" az a sötítés? Van róla esetleg kép? Sugárral és lecsengéssel is lehet játszani még SAO esetében.
alias aalberik
   
Elodin - Tag | 170 hsz       Online status #209675   2016.05.25 23:58 GMT+1 óra  
Felmerült már, hogy normált is renderelnünk kéne valami multiple rendertarget magic-el, de még függőben van a dolog. Annyira nem néz ki rondán az SSAO textúra így se szerintem.

A köddel volt leginkább gond - annak az ambient lighting után kéne számolódnia :/ Meg még volt néhány effekt a shaderekben, amiknek szintén.

HDR a pipeline különben.

Amúgy az átlátszó dolgokat hogy kezelik? Nekünk a füvek, bokrok nagyon besötétítettek - ezt úgy oldottam meg, hogy az egyes asseteknél beállítható egy flag, ha az be van nyomva, akkor egy későbbi pass-ban renderelem őket, miután elkészült az SSAO textúra.

   
syam - Törzstag | 1491 hsz       Online status #209674   2016.05.25 23:37 GMT+1 óra  
Idézet
Elodin :
SAO-t próbálok beépíteni forward rendering-es engine-be úgy, hogy nincs z pre-passunk, és nem is szeretnénk
...



A kedvenc SSAO variánsom
Normál buffer nélkül viszont nem annyira jó szóval forward esetén az artifactok eléggé elrontják.
Ha multipass fényrender történik akkor oda lehet elrejteni.

Mi volt a probléma az SAO PP renderével? Pl. nagy könyv szerint csak indirekt fénynél kellene használni AO-t én mindenhol szeretem, mert elég drága ahhoz hogy elvesszen végül a képen.
Példa

Ha pedig HDR a pipeline abba szépen beleolvad a nagyon erős AO is a széles színtartomány miatt.
alias aalberik
   
Elodin - Tag | 170 hsz       Online status #209673   2016.05.25 21:07 GMT+1 óra  
Scalable Ambient Obscurance.

Gyaklag egy ssao algoritmus.

Depth-ből generálom a textúrát. De pont ez a gond -csak akkor tudom, ha minden renderelődött, de már hamarabb kéne használni.

   
Instalok - Tag | 530 hsz       Online status #209672   2016.05.25 20:17 GMT+1 óra  
Az SAO az mit takar? Nekem a Sword Art Online jut róla eszembe. SSAO-t ismerek, mint Screen-Space Ambient Occlusion.

Ha erre gondoltál, akkor honnan van AO?

   
Elodin - Tag | 170 hsz       Online status #209671   2016.05.25 18:54 GMT+1 óra  
SAO-t próbálok beépíteni forward rendering-es engine-be úgy, hogy nincs z pre-passunk, és nem is szeretnénk

Elsőre csak simán utólag használtam az ao textúrát kb. mint egy posteffectet, az nem annyira jött be.

Most megpróbáltuk az egy frame-el előtti ao textúrát használni a shaderekben, ezzel meg az a gond, hogy ha mozog a kamera (főleg ha változó sebességgel), iszonyat látszik, hogy "lemarad" a sötétség

Következő ötlet, hogy az egy frame-el előtti AO textúrából olvasunk, de úgy, hogy az egy frammel ezelőtti screen koordináta alapján - tehát a kamera mozgását ezzel megpróbáljuk korrigálni :/ Erre már nem ma jutott időm teljesen, de vannak kétségeim.

Bármi egyéb ötlet?

   
Matzi - Szerkesztő | 2519 hsz       Online status #209662   2016.05.25 14:55 GMT+1 óra  
Nem static megjelolés kell az objektumokra. Alapból amúgy is célszeru szétszedni oket kulonbozo vektorokba, az egyik szempont lehet a statikusság. Így pusztán az hogy hol van, elárulja, hogy statikus e vagy sem.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 530 hsz       Online status #209660   2016.05.25 14:27 GMT+1 óra  
Na igen, mondjuk egyelőre kimaradt a "static" megjelölés az objektumokról. Pedig akkor lehetne úgy is csinálni, ahogy mondtad. Sőt, mi több, ha egy static objektumot transzformál az ember, akkor magára vessen, és az adott transzformáció után azonnal updatelődnének az adatok (world mátrix, world aabb). Ehhez viszont az kell, hogy az objektumok meg legyenek jelölve statikusnak. Persze meg lehet fordítani is, és azokat jelölném meg, amik nem statikusak (például hozzá van adva egy Rigidbody komponens, de bármilyen egyéb komponens beállíthatná, hogy az objektum mostantól dinamikus).

Lehet megpróbálom így, és akkor megszűnik az event küldözgetés. Persze a dirty flag még így is lehet, hogy marad, pont a dinamikus objektumok miatt.

   
Matzi - Szerkesztő | 2519 hsz       Online status #209657   2016.05.25 13:59 GMT+1 óra  
Átlagos hasznalatban nem ezek az arányok. Tipikusan van egy nagy halmaz statikus geometria, ami szinte sosem változik, azokat egyben lehet skippelni, vagy gyujtheted a kivételes eseteket valami pointer vektorba. A dinamikus dolgok meg tipikusan nagy százalékban megváltoznak. Annyit lehet még vele trukkozni, hogy a határesetet képzo elemeket pakolod egyik kategóriából a másikba. Pl fizikával ellátott ládák meg objektumok esetén szokták nézni, hogy ha egy ideje nem mozgott, akkor elaltatják, ha megmozdul, akkor meg felkel. És mivel a felkeltés és elaltatás ritka esemény, így nem baj, ha drága. A framenkénti update legyen hatékony.

Ha jól csinálod, akkor egy nagy részét a dolgoknak nem kell egyáltalán updatelni, még a dirty flaget sem kell nézni, míg a tobbit meg újraszámolhatod mindentol fuggetlenul, akkor is gyors lesz. IMHO.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 530 hsz       Online status #209656   2016.05.25 13:35 GMT+1 óra  
Szóval hagyjam az egészet, és iteráljak végig az egész jeleneten nem foglalkozva azzal, hogy transzformáltam-e az objektumot? Ez nekem elég overkillnek tűnik. Ha például van 100.000 objektum, amiből 10-et transzformáltam, de mindegyiknek újraszámolom a world mátrixát (és az AABB-t például) az csak ne legyen már gyorsabb, mintha 10-re tenném. Vagy mégis?

   
Matzi - Szerkesztő | 2519 hsz       Online status #209654   2016.05.25 12:33 GMT+1 óra  
Ahhoz a cachednek is mutable-nek kell lennie. Ami alapból nem túl szerencsés. Arról nem is beszelve, hogy mennyire nem biztonságos ha tobb szálon csinálod.

Mellesleg egy modern hardveren jelentos teljesítményromlást tudsz elérni, ha ilyen eventkuldos, meg dirty flages mókákkal játszol, ahelyett, hogy csak siman újraszámolnád a mátroxot. Amíg a cacheben van az egész az újraszámolás nagyon gyors, viszont ha a dirty flagekkel meg event pointerekkel felhígítod az objektumodat, akkor tobb lesz a cache miss, és a végeredmény lassabb lesz. Próbáld ki egy benchmarkkal.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5440 hsz       Online status #209653   2016.05.25 10:21 GMT+1 óra  
Kód:
mutable bool dirty;
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209652   2016.05.25 09:50 GMT+1 óra  
Igen, nekem is ez jutott eszembe először, csak ilyenkor bukta a const függvény. Ha viszont nincs nem-konstans "referenciám" az adott objektumra, akkor le se tudom kérni a world mátrixát? Persze, csinálhatok egy const függvényt is, de az meg vagy nem fog updatelni (és az előző world mátrixot adja vissza), vagy mindig újraszámol. Minden esetre a probléma nem ez. Az, hogy most két függvényt egybegyúrok-e, az eredeti kérdéshez képest egy teljesen elhanyagolható apróság.

   
Asylum - Törzstag | 5440 hsz       Online status #209651   2016.05.25 08:36 GMT+1 óra  
Ilyen nincs h "meg kell hivni az updatet".

Kód:
void SetPosition(vec3 v) {
    pos = v;
    dirty = true;
}

Matrix GetViewMatrix() {
   if( dirty ) {
        dirty = false;
        return (cached = Recalc());
    }

    return cached;
}
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209646   2016.05.24 19:33 GMT+1 óra  
Azt hiszem ez picit hosszú lesz, de remélem valakinek van hozzá szép ötlete.

Adott egy update sorrend:
Kód:
scripts.PrePhysics();
PhysicsCalculation();
scripts.PostPhysics();

CalcBoneMatrices();
CalcWorldMatrices();
CalcBounds();
CalcCameraMatrices();

Tehát a user scripten keresztül 2 helyen tud kommunikálni az Engine-el. Az első arra jó, hogy a fizikai objektumok tulajdonságait módosítsuk (add force, stb.), a második pedig azért jó, hogy ezekről választ kapjunk (például le lehet így kérni, hogy mennyit mozdult el a karakter ténylegesen, és, hogy ezáltal melyik animációt kell lejátszani).

Ez mindaddig nagyon szép és jó, amíg mondjuk a scriptnek nincs szüksége valamilyen számoláshoz például a camera view mátrixára.

Ha nézzük a Unity esetét, ott adott a transform.localToWorldMatrix, vagy mondjuk a kamera esetén a camera.worldToCameraMatrix. Ezek up-to-date információkat adnak, azaz, ha egy scriptben módosítom a pozíciót, akkor jó értéket fog visszaadni.
Kód:
Matrix4x4 ltw;
ltw = transform.localToWorldMatrix; // up-to-date
transform.position = new Vector3(10, 0, 0);
ltw = transform.localToWorldMatrix; // up-to-date

Ebből arra következtetek, hogy a híváskor számolja, esetleg valamilyen dirty flaggel, hogy ha többször hívjuk egymás után úgy, hogy nem módosult, akkor ne számolja újra.

Egyelőre én is hasonlóan csináltam meg. Adott egy publikus Update() függvény az ilyen komponenseknek (Transform, Camera, QuadTreeElement <- Bounds), amin keresztül lehet kérni, hogy frissítse az adatokat.

Csakhogy a problémám ott kezdődik, hogy mivel a user nincs rákényszerítve, hogy ezt megtegye, így az Engine-nek is meg kell hívnia az Update-eket. Mivel nem akarok végigiterálni állandóan az egész jeleneten, ezért egy event-systemen keresztül jelez a komponens, hogy "heló, változott a transformom!" - ekkor az adott komponenst eltárolom egy megfelelő konténerben, így csak a ténylegesen változott adatokon iterálok, és hívom meg az Update()-et.

Maga a beregisztrálás úgy néz ki, hogy adott egy függvény, valami ilyesmi:
Kód:
void SetDirtyFlag()
{
    if (!dirty)
    {
        dirty = true;
        FireEvent(this);
    }
}

Maga az Update pedig annyit csinál, hogy megnézi, hogy a dirty az igaz-e. Ha nem, akkor azonnal visszatér, ha igen, akkor frissít, majd hamisra állítja. Látszik a probléma, hogy ha a user meghívja az Update()-et, majd ismét módosítja a transzformációt, akkor az event kétszer hívódik meg:
Kód:
transform.SetPosition(...); // dirty? -> no, dirty := true, fire event
transform.Update(); // dirty? -> yes, update, dirty := false
transform.SetPosition(...); // dirty? -> no, dirty := true, fire event

És mivel az eventhandler nem nézi, hogy ez az elem már benne van-e a konténerben (mert az legjobb esetben is O(n*logn) lenne), így az kétszer kerül bele. Alap esetben ez nem gond, mert max. a meghívott Update() függvény nem csinál semmit. Csakhogy ott van például a QuadTreeElement, amin keresztül le lehet kérni a befoglalóját a komponensnek. Amikor az említett konténeren iterálok végig, meghívom az adott Update() függvényt (hogy biztosan up-to-date world-space AABB-m legyen) majd szólok a QuadTree-nek, hogy "hé, ez az objektum változott, csekkold csak le!". Igenám, csak, ha a listában többször benne van egy elem, akkor többször fogom megkérni a QuadTree-t, hogy vizsgálja meg ugyan azt az objektumot, ami meg nyilvánvalóan fölösleges.

Lehetne egy újabb dirty-t bevezetni, amit csak egy friend class tud módosítani, de a friend class eleve nem szép design. Ha meg publikus elérhetőségűvé teszem a másik dirty-t is, akkor azt bárki módosíthatja.

Esetleg hagyjam ezt az egész problémát a francba, és magára vessen az, aki a scripten belül manuálisan kéri az Update()-et, majd újra módosítja a komponenst?

   
Asylum - Törzstag | 5440 hsz       Online status #209622   2016.05.19 10:50 GMT+1 óra  
Nem a sebesség a lényeg, hanem hogy lényegesen kevesebb memó és MSAA-t is használhatsz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 530 hsz       Online status #209620   2016.05.18 16:39 GMT+1 óra  
A mai nap tanulsága: A deferred shading gyorsabb, mint a light prepass, amíg elfér az ember 3 + 1 render targetben (a +1 a depth, de az ígyis-úgyis kell valamilyen formában).

Kicsit meglepődtem, mert a geometriám nagyon egyszerű: 2 kocka, 2 gömb és 1 plane. Ráadásul a light prepass butább is kicsit jelen esetben, mert csak monochrome speculart tud (és egyelőre) fix specular power értékkel. Így nem kell MRT support (a first pass elfér RGB10A2-ben), a lighting pedig megy egy RGBA16F textúrába. A második geometria pass is szintén RGBA16F-be megy, de az ugyan az, mint a deferred shadingnél.

Átnézem majd még, de ilyen kicsi jelenetre azt vártam, hogy a light prepass gyorsabb lesz. Cserébe ugyebár nincs korlátozva material szempontjából.

   
Instalok - Tag | 530 hsz       Online status #209232   2016.03.28 11:36 GMT+1 óra  
Command alapú renderelés mellett döntöttem, azaz maga a renderer egy command listába tölti fel az utasításokat, pl.
Kód:
cmdList.AddCommand<GCmdSetEffect>(eff);
cmdList.AddCommand<GCmdDrawIndexed>(vb, lay, ib);

majd, miután megvan az összes command:
Kód:
cmdList.ExecuteCommands(*graphicsDevice);

Ez a megoldás azért tetszik, mert, ha később úgy döntök, hogy "stateless" módra váltok, akkor csak módosítanom kell a commandokat, meg azoknak a megvalósítását, és kész.

A probléma a rajzoláshoz szükséges resource-oknál kezdődik. A uniformok értékének beállításához az adott shadernek/effektnek aktívnak kell lennie. Azonban az nem lesz aktív, amikor kiadom a uniform értékadás utasítást:
Kód:
eff->SetUniform(eff->GetUniform("uni1"), 1.0f);

Uniform buffer, vagy ehhez hasonló nem elérhető (OGL 2.0 például), illetve az a megoldás sem tetszik annyira, hogy ahelyett, hogy az effekt objektumon keresztül állítanám be a uniformokat, ezeknek is külön commandot csinálok. Természetesen egy járható út, de nem tetszik annyira.

Esetleg valamilyen Uniform buffert kellene kézzel implementálni? És akkor egyetlen commandot kellene létrehoznom, amely az adott uniform buffert érvényesíti.

   
Instalok - Tag | 530 hsz       Online status #206113   2015.01.08 21:39 GMT+1 óra  
Következő nagyobb része az ütközésdetektálás lesz. Egyszer már ezt megcsináltam, viszont nem biztos, hogy ez a legjobb ötlet. Felmerült bennem már akkor is néhány kérdés.

Például nem tudtam azt kontrollálni, hogy mi az a magasság, amin még ütközés nélkül át tud menni (de követve a magasságot), ahogy azt sem, hogy mi az a meredekség, amin már nem tud felmenni. Az egész úgy működött csak jól, ha azokon a helyeken, ahol ténylegesen ütközést akartam, a talajjal merőleges ütközési felületeket csináltam, minden más esetben pedig fel tudott "mászni" rajta.

A másik ami eszembe jutott az a frissítések sorrendje. Az egész rendszert úgy képzelem el, hogy vannak a Collision komponensek és a Rigidbody komponens. Utóbbival tudjuk úgy mozgatni az objektumokat, hogy azok figyelembe vegyék a fizikát, azaz ütközzenek a Collision meshekkel. Azonban mi történik, ha egymás felé halad 2 rigidbody? Alap esetben mondjuk félúton kellene ütközniük, de mivel az egyiket mindig hamarabb frissítem, így nem ott fognak.

Van ezekre valami jó ötlet?

szerk.:
Pont ilyenre gondoltam.

Ezt a hozzászólást Instalok módosította (2015.01.09 08:47 GMT+1 óra, 900 nap)

   
Instalok - Tag | 530 hsz       Online status #206054   2015.01.05 20:44 GMT+1 óra  
Engine-en Egyelőre konkrét projekt nincs, van egy-kettő "papíron", ha olyan szinten áll majd az engine, akkor ezek közül választok egyet, és keresek hozzá embert.

Néha belekattintgatok a Unity-be, hogy ők hogy oldották meg, és, ha megtetszik egy ötlet, akkor megpróbálom esetleg hasonlóan megcsinálni. Nyilván sose lesz olyan szinten, mint nekik, de én egyedül vagyok, és nincs rá több évem.

   
Elodin - Tag | 170 hsz       Online status #206035   2015.01.05 14:12 GMT+1 óra  
Amúgy min dolgozol pontosan, ha nincs titkosítva 15 évig ?

   
Instalok - Tag | 530 hsz       Online status #206032   2015.01.05 13:00 GMT+1 óra  
Igen, azt is lehet, de lehet, hogy maradok egy flagnél, ami megmondja, hogy akarunk-e automatikus szinkronizálást, ha igen, akkor %-osan nézve ugyan onnan indítom el az animációt. Innentől pedig a grafikus dolga megoldani azt, hogy például 50%-nál legyen a láb váltás a futás és a gyaloglás animációjában is.

Ha jól értettem, a Unity doksiban is valami ilyesmit írnak.
Idézet
In order for the blended motion to make sense, the motions that are blended must be of similar nature and timing.

Idézet
Examples of similar motions could be various walk and run animations. In order for the blend to work well, the movements in the clips must take place at the same points in normalized time. For example, walking and running animations can be aligned so that the moments of contact of foot to the floor take place at the same points in normalized time (e.g. the left foot hits at 0.0 and the right foot at 0.5). Since normalized time is used, it doesn’t matter if the clips are of different length.

A "normalized time" kifejezésben nem vagyok biztos, hogy hogy érti (igen, azt tudom, hogy 0.0 és 1.0 között van a kérdés inkább az, hogy mihez képest normalized), de logikusan belegondolva csak annyi lehet, mint a "%-os" idő az animációban.

Végül is lehet, hogy a következőt próbálom majd ki:
- mindegyik state megmondja magáról, hogy neki a jelenlegi animáció milyen hosszú
- SimpleState esetén ez az AnimClip length
- BlendTree esetén pedig
Kód:
weight * state1->length + (1.0 - weight) * state2->length

- ennek a hossznak a függvényében pedig beállítom az animáció sebességét, hogy ténylegesen ennyi időt vegyen igénybe (nyilván ez a BlendTree-nél lényeges)
- így a sub-statek a BlendTreeben "normalized time" szerint ugyan ott lesznek, azaz a futás és a séta animáció is az adott pillanatban x%-on fog állni.

   
Asylum - Törzstag | 5440 hsz       Online status #206031   2015.01.05 11:42 GMT+1 óra  
Ezt a szinkronizációt sztem a legegyszerűbben kézzel lehet megoldani. Minden animációhoz megadod, hogy a többi animációt honnan a legcélszerűbb kezdeni. A Doom 3 kódjából lehet meríteni inspirációt.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Elodin - Tag | 170 hsz       Online status #206027   2015.01.05 00:07 GMT+1 óra  
Legyen állítható, és ez a default
Vmilyen szinten úgyis a user dolga lesz egymáshoz illő animációkat gyártani, vagy leglább összeilleszteni vhogy őket.

   
Instalok - Tag | 530 hsz       Online status #206026   2015.01.04 23:03 GMT+1 óra  
Igen, valami ilyesmit tapasztaltam én is a Unity oldaláról. Lejátszási ideje viszont csak az AnimClipeknek van. Valahogy úgy lehetne megoldani talán, hogy mindegyik State megmondja magáról, hogy mennyi ideig fut - SimpleState esetén egyszerű, csak az AnimClip ideje, BlendTree esetén meg a sub-statek idejeinek valamilyen súlyozása.

Viszont kérdéses, hogy lehet-e általánosítani ezt az x%-os időben való elindulást: séta-futás-oldalazás váltáshoz jó lenne, kérdéses, hogy mire használnak még BlendTreeket.

   
Elodin - Tag | 170 hsz       Online status #206023   2015.01.04 20:57 GMT+1 óra  
Vmi olyasmi tűnik logikusnak, hogy mindkét animáció sebességét módosítod, hogy egyszeri lejátszásuk (súly1 * t1 + súly2*t2) időt vegyen igénybe.

Menet közben meg úgy indítanék, hogy ha a séta animáció az idő x%-ánál tart, akkor a futás onnan indulna szintén - persze ennek is csak akkor van értelme, ha alapból szinkronba van a séta és a futás, de más különben nem nagyon lehet mit csinálni.

De én is csak user oldalról láttam még ilyet, csak találgatok

   
Instalok - Tag | 530 hsz       Online status #206021   2015.01.04 19:52 GMT+1 óra  
Animációkezelésen dolgozok jelenleg, és egy kicsit elakadtam. A Unity-ben található rendszer eléggé megtetszett, így valami hasonlóval próbálkoztam én is. Egy meshhez tartozik egy Animator. Az Animator tartalmaz Layereket. A Layer tartalmaz State-eket, amiből 2 fajta van: SimpleState, BlendTree. A SimpleState egyetlen AnimClip-et tárol, és azt tudja lejátszani. A BlendTree pedig State-eket tárol, és azok között a 2 aktuálisat blendeli össze. Valami ilyesmi a felépítés, például:
Kód:
animator
{
    layer "baseLayer"
    {
        simple_state "idle"
        {
            loop = true
            speed = 1.5
            anim_clip "idle"
        }
        blend_state "walkBack"
        {
            simple_state "walkBackLeft"
            {
                loop = true
                anim_clip "walkBackLeft"
            }
            simple_state "walkBack"
            {
                loop = true
                anim_clip "walkBack"
            }
            simple_state "walkBackRight"
            {
                loop = true
                anim_clip "walkBackRight"
            }
        }
        blend_state "locomotion"
        {
            blend_state "walk"
            {
                simple_state "walkLeft"
                {
                    loop = true
                    anim_clip "walkLeft"
                }
                simple_state "walk"
                {
                    loop = true
                    anim_clip "walk"
                }
                simple_state "walkRight"
                {
                    loop = true
                    anim_clip "walkRight"
                }
            }
            blend_state "run"
            {
                simple_state "runLeft"
                {
                    loop = true
                    anim_clip "runLeft"
                }
                simple_state "run"
                {
                    loop = true
                    anim_clip "run"
                }
                simple_state "runRight"
                {
                    loop = true
                    anim_clip "runRight"
                }
            }
        }
    }
}

Alapvetően nincs gond, felépítettem a rendszert, egészen egyben van már, azonban a BlendTree-nél elakadtam picit. Főleg a következő probléma jutott eszembe:
Van egy séta előre animáció, ami mondjuk 3mp, meg van egy futás előre, ami 1,5mp. Amikor a kettő között 0.5 súllyal blendelek (azaz fele ez, fele az), akkor nem mehet teljes sebességgel mindkét state (legyen az SimpleState vagy BlendTree), mert 1,5mp-nél a futás már befejeződik, de a séta még csak akkor vált a másik lábra.

Szóval a kérdés igazából a szinkronizálás. Az is kérdéses, hogy amíg az egyik súlya 0.0 a másiké 1.0 (azaz csak egyetlen sub-state lejátszása van folyamatban), akkor ennek megváltozásakor honnan induljon a másik animáció. Például séta animáció éppen a jobb lábnál tart, amikor elkezdünk blendelni a futásba, ami a bal lábbal indít.


   
DieToBorn - Tag | 32 hsz       Online status #204986   2014.10.08 19:45 GMT+1 óra  
Sziasztok!

Időközbe ragaszkodtam ahhoz amit mondtatok, át írtam nagy részt az egészet és úgy működik most már ahogy kell neki Viszont olyan problémám van most hogy be van töltve 7 bitmap és be lassul tőle a progi.. PNG autókat töltök be 6db-ot meg a háttér is PNG . Kérdésem az lenne hogy tudtok valamit erre a problémára?

szerk:

traffic osztály:
http://pastebin.com/zThnW3eH

Paint:
http://pastebin.com/msQiPW64

A következő képpen van deklarálva:
Kód:
        private TRAFFIC traffic_car1,
                        traffic_car2,
                        traffic_car3,
                        traffic_car4,
                        traffic_car5,
                        traffic_car6;


Load-ba pedig így hozom létre:

Kód:
            traffic_car1 = new TRAFFIC();
            traffic_car1.color = a;
            traffic_car1.imagex = 40;
            traffic_car1.speed = 9;

            traffic_car2 = new TRAFFIC();
            traffic_car2.color = b;
            traffic_car2.imagex = 105;
            traffic_car2.speed = 11;

            traffic_car3 = new TRAFFIC();
            traffic_car3.color = c;
            traffic_car3.imagex = 160;
            traffic_car3.speed = 13;

            traffic_car4 = new TRAFFIC();
            traffic_car4.color = d;
            traffic_car4.imagex = 220;
            traffic_car4.imagey = 370;
            traffic_car4.speed = 9;

            traffic_car5 = new TRAFFIC();
            traffic_car5.color = ee;
            traffic_car5.imagex = 285;
            traffic_car5.imagey = 370;
            traffic_car5.speed = 12;

            traffic_car6 = new TRAFFIC();
            traffic_car6.color = f;
            traffic_car6.imagex = 345;
            traffic_car6.imagey = 370;
            traffic_car6.speed = 14;



Szerk.: Elnézést a dupla postért! Idő közbe rájöttem hogy a paintbe nem szerencsés állandón létrehozni imagelist-et meg betölteni a forrás fájlokat... Kezdek rá érezni a dolgokra

Ezt a hozzászólást DieToBorn módosította (2014.10.08 20:32 GMT+1 óra, 992 nap)

   
Frissebbek | Korábbi postok
[1] > 2 < [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [27]