|
|
Render state-re tippelek én is. Sphere-t is shader-rel rajzolod, ugye?
|
|
|
|
nálam nincs ilyen probléma 
de amikor volt ilyen v hasonló akkor nekiálltam átnézni a kódot hogy ugyan mi lehet..
nálam pl. ha kirajzolok egy skysphere-t akkor nem rajzolja ki a sprite okat...ez is érdekes...szerintem vagy renderstateket állitja át valami vagy valami más zavar be, még nem jöttem rá
szerk.: ja és érdekes módon csak csak a sprite ot nem rajzolja, a szöveget igen...odáig sikerült lebontani a problémát, hogy nem az effekt megjelenitésével van a gond (kikommentztem és ugyanaz), hanem a betöltésekor történik valami ami igy hat ki a sprite ra...ez baromi furcsa!
Ezt a hozzászólást Asylum módosította (2008.01.22 12:16 GMT+1 óra, ---)
|
|
|
|
Nem tudom, jó helyen járok-e a kérdésemmel...
Van egy jelentem, ebben egy kamera, egy fény, és két különböző effekt-tel ellátott test.
Ha a 2 testen más-más effektet alkalmazok, akkor az egyik "elromlik", eltűnik róla a textúra.
Ha mind a 2 testen ugyanaz az effekt van, minden jó.
Plusz érdekesség:
Ha egy ilyen effekt-es test mellé kiteszek egy D3DXCreateSphere-el készített gömböt, ráadásul anyagok nélkül, az effekt-es testen megzavarodnak az UV koordináták...
Ezekre tud valaki valamit?
|
|
|
|
hmm alakul..eza dazzling light mostmár többé kevésbé látszik csak még olyan száraz
|
|
|
|
Idézet
Asylum :
szal tehát fogom a framet, elsö rendereléskor még nincs miböl számolnom akkor mondjuk nem hajtom végre csak átpakolom a framet az afterimage texturába
aztán a következö frametöl kezdve az afterimage tex be ugy renderelek ahogy leirta vagyis
elözö ai * p + frame * c - 1/255
és ezt hozzáblendelem a framehez..de ez igy nálam azt eredményezte h szépen smoothosan átment kibaszott fehérbe a kép 
bright pass filterrel meg kibaszott kékbe (a háttér miatt)
Kód: half4 AfterimageFilter( float2 TexCoord : TEXCOORD0) : COLOR
{
half3 Output = {0,0,0};
Output += CurrentImageWeight * tex2D(BrightPassSampler,TexCoord).rgb-1.0f/255.0f;
Output += AfterimageWeight * tex2D(AfterimageTexSampler,TexCoord).rgb;
return half4(saturate(Output),1.0f);
}
Az ezzel előállított képet meg a tonemapping végén simán hozzáadom az eredményhez.
Reality is almost always wrong. - House
|
|
|
|
szal tehát fogom a framet, elsö rendereléskor még nincs miböl számolnom akkor mondjuk nem hajtom végre csak átpakolom a framet az afterimage texturába
aztán a következö frametöl kezdve az afterimage tex be ugy renderelek ahogy leirta vagyis
elözö ai * p + frame * c - 1/255
és ezt hozzáblendelem a framehez..de ez igy nálam azt eredményezte h szépen smoothosan átment kibaszott fehérbe a kép
bright pass filterrel meg kibaszott kékbe (a háttér miatt)
Ezt a hozzászólást Asylum módosította (2008.01.20 07:53 GMT+1 óra, ---)
|
|
|
|
Idézet
Asylum :
ezt az afterimage részt nem értem
Next afterimage = Previous frame afterimage * p + current frame image * c – 1/255
p: previous image weight
c: current image weight
ezt is iterációban csináljam mint a blur-t?és hányszor? és a súlyokat hogy találom ki? (irja itt hogy 0.9 és 0.25 de az honnan jött ki)
A súlyok hasraütéssel jönnek ki mint általában, addig kell őket állígatni amíg nem tetszik az eredmény. Egy menetes művelet az egész, frame-enként egyszer végrehajtod majd rákevered az eredményt a frame-re (+ elteszed a következő frame-hez). Egy dolgot viszont nem említ a dia: az afterimage forrása a bright pass filter eredménye tehát current frame image = bright pass filterezett HDR kép.
Szerk: Súlynak én 1-et és 0.55-öt használok a tesztekben.
Reality is almost always wrong. - House
|
|
|
|
hmmm,
ez : Next afterimage = Previous frame afterimage * p + current frame image * c egy sima mezei motion blur, ahol általában p+c=1 és én fullscreen blendezéssel használom
ez  ixel brightness = RGB * A , post process lighting, rgbben tárolod a modosítatlan textura szint alfában pedig a fényességet; így menet közben számos modon árnyalhatod uazt a felületet
alias aalberik
|
|
|
|
ezt az afterimage részt nem értem
Next afterimage = Previous frame afterimage * p + current frame image * c – 1/255
p: previous image weight
c: current image weight
ezt is iterációban csináljam mint a blur-t?és hányszor? és a súlyokat hogy találom ki? (irja itt hogy 0.9 és 0.25 de az honnan jött ki)
a másik meg Pixel brightness = RGB * A
ezzel szüri ki csak a fényes részeket, nade az alpha az általában 1.0f nem? (átlátszóság) vagy ott valami mást tárol?
|
|
|
|
Idézet
Asylum :
.....
van ez a Masaki Kawase nevü emberke és találtam egy ilyen hdr es demot töle...hát leestem az asztal alá..szal olyat játékban még soha nem láttam...és simán megy az én öskövületemen és eszméletlenül néz ki...
Szerencsére megosztotta a nagyvilággal a trükköket amiket abban a demóban használ (anno a demón én is borultam, nagyon durván néz ki), én is az ő trükkjeit nyúlom több-kevesebb sikerrel. 
GDC2003_DSTEAL.ppt és GDC2004_PIoHDRR_SHORT_EN.ppt fájlokra keress rá.
Reality is almost always wrong. - House
|
|
|
|
aham, pontosan; a legtisztább leírás a neten azok közül amiket eddig találtam:]
alias aalberik
|
|
|
|
|
|
Orphy:
én érdekes módon pont itt talátam a legjobb TBN számoló algoritmust - az egyetlent ami normális müködött eddig nekem
nem tudom megvan-e még az a cikk...
alias aalberik
|
|
|
|
Orphy:
Itt egy link, amiben komplett bumpmap példa van egy modellre (érdemes megnézni a gyíkot, elég pofásan néz ki  ), 22 mega.
- a bumpmap tangens számolás más, mint a standard-de-facto terathon.com-os, viszont ez figyelembe veszi, hogy nagy tangens eltérések esetén duplázni kell a vertexeket, és elég 3komponensű tangens, nem négy, mint amott.
http://ati.amd.com/developer/vertexblendD3D.html
|
|
|
|
Nem igazán találtam ennek megfelelő helyet, ezért ide rakom, hátha valakit érdekel:
spark hangrendszer
I, Robot
1. A robotnak nem szabad kárt okoznia emberi lényben.
2. A robot engedelmeskedni tartozik az emberi lények utasításainak.
3. A robot tartozik saját védelméről gondoskodni.
|
|
|
|
Köszi mindenkinek, átrágom... 
|
|
|
|
Átlátszósághoz meg szvsz öngyilkosság a realtime rendezés egy geometrián belül, viszon vannak rá módszerek (pl. nvidia sdk-ben több is), amikkel jobban jársz sebesség szempontjából.
|
|
|
|
Ezt a hozzászólást fpeti módosította (2008.01.15 09:15 GMT+1 óra, ---)
|
|
|
|
Idézet
Orphy :
Még egy kérdés, ami jól jönne:
Normalmapping-hez a BINORMAL és TANGENT értékeket tudja valaki, hogyan kell kiszámolni, ha a modell ezekkel nem rendelkezik? 
Azt hiszem, hogy ez a legismertebb tangens számolási mód a neten.
Ha megvan a tangens és a normál, akkor a bitangent már egyszerű, lévén:
B = N x T
x a vektoriális szárzás akar lenni.
|
|
|
|
|
|
Még egy kérdés, ami jól jönne:
Normalmapping-hez a BINORMAL és TANGENT értékeket tudja valaki, hogyan kell kiszámolni, ha a modell ezekkel nem rendelkezik?
|
|
|
|
Nekem az átlátszósággal kapcsolatban van kérdésem...
Addig rendben, hogy az átlátszóság miatt a kirajzolt objekt-eket a szemtől való távolság alapján rendezni kell. Ez azért egy nézeti vágás után nem egy kezelhetetlen mennyiség.
A kérdés az, hogy mi a helyzet magával a geometriával...
Elvileg a mesh face-eit is a szemtávolság alapján kellene kirajzolni (SRCALPHA, INVSRCALPHA), legalábbis a forgó, átlátszó kockámnál úgy tűnt, mintha a különböző oldalai nem mind ugyanolyan átlátszóak lennének...
Ha ez a helyzet, akkor van arra valami mód, hogy ezt meg lehessen kerülni?
Egy sokpoly-s modell esetében nem szívesen rendezgetném újra a vertexeket minden frame-ben...
Esetleg (ONE,ONE) paraméterekkel alpházni, de nekem valamiért az (SRCALPHA, INVSRCALPHA) eredménye természetesebbnek tűnik...
|
|
|
|
Irtam egy kicsit a díszítő tervmintáról és egy hasonló megoldásról
http://people.inf.elte.hu/asylum/programming/C++/qblog.html
ha hülyeségeket irok akkor javitsatok ki 
jaaa valami fontosat akartam mondani...hogy member függvényben nagyon nemjó windows üzeneteket küldözgetni ugyanis a teljes feldolgozás lefut és utána visszatér oda. Én a WM_CLOSE-nál jöttem rá erre az ember azt gondolná h berakja valahova az üzit aztán visszatér..hát nem
Ezt a hozzászólást Asylum módosította (2008.01.13 16:08 GMT+1 óra, ---)
|
|
|
|
na mind1 HDR és bloom
http://people.inf.elte.hu/asylum/programming/C++/qblog.html
a bloom jobban teccik csak az egész képet megdobja a HDR meg csak a fényes részeket.
van ez a Masaki Kawase nevü emberke és találtam egy ilyen hdr es demot töle...hát leestem az asztal alá..szal olyat játékban még soha nem láttam...és simán megy az én öskövületemen és eszméletlenül néz ki...
Ezt a hozzászólást Asylum módosította (2008.01.03 13:50 GMT+1 óra, ---)
|
|
|
|
Idézet
Asylum :
hehe a downsample sikerült de elég fura effekteket találtam bloom cimen
vagy csak én qrtam el eddig az xnas volt a legtürhetöbb
szerk: ja mert ez HDR hmm ez nemisroszz..hmmmm
csak nem ezt akartam
érdekes nem?
http://people.inf.elte.hu/asylum/alma.jpg
de valami ilyesmi a hdr xD sztem a háttér csak azért ilyen merthogy egyszinü (az exposure levelt is lejjebb kellett venni mert majdnem kiégette a szemem) floating point textura
Hát ez elég absztrakt, HDR-szerű, de azért nem teljesen olyan mint kellene, legalábbis ez alapján a kép alapján.
Reality is almost always wrong. - House
|
|
|
|
TheProGamer : 1K hála !!
|
|
|
|
hehe a downsample sikerült de elég fura effekteket találtam bloom cimen
vagy csak én qrtam el eddig az xnas volt a legtürhetöbb
szerk: ja mert ez HDR hmm ez nemisroszz..hmmmm
csak nem ezt akartam
érdekes nem?
http://people.inf.elte.hu/asylum/alma.jpg
de valami ilyesmi a hdr xD sztem a háttér csak azért ilyen merthogy egyszinü (az exposure levelt is lejjebb kellett venni mert majdnem kiégette a szemem) floating point textura
Ezt a hozzászólást Asylum módosította (2008.01.02 11:37 GMT+1 óra, ---)
|
|
|
|
Igen, köszi hogy szoltál, ma regisztráltam és már éppen készültem el menni, nemnagyon volt időm áttekinteni, igaz akkor kellett volna amikor van ideje az embernek bocsesz.
|
|
|
|
Idézet
fpeti :
Amúgy vcache cuccal kapcs:
D3DXOptimizeFaces() - ez se rossz (meg a legegyszerűbb), csak nincs a paraméterei közt a cache mérete, valszeg alutippel..de azt írják jobb, mint a semmi...
Egyébként tudja valaki, hogy kell a vga cacheméretét lekérdezni?
edit: megtaláltam..D3DDEVINFO_VCACHE..
Megfejeled egy D3DXOptimizeVertices-el és ugyanott vagy előrébb vagy mint a ID3DXMesh:: Optimize-al.
Reality is almost always wrong. - House
|
|
|
|
___________
A lelkesedés az, ami a tudásnak ízt ad...
|
|
|
|
Ezt a hozzászólást HexanV módosította (2008.01.02 12:39 GMT+1 óra, ---)
|
|
|
|
Asylum:
Nem egy SetViewPort() hiányzik (bár mintha nem lenne muszáj)?
Amúgy vcache cuccal kapcs:
D3DXOptimizeFaces() - ez se rossz (meg a legegyszerűbb), csak nincs a paraméterei közt a cache mérete, valszeg alutippel..de azt írják jobb, mint a semmi...
Egyébként tudja valaki, hogy kell a vga cacheméretét lekérdezni?
edit: megtaláltam..D3DDEVINFO_VCACHE..
Ezt a hozzászólást fpeti módosította (2008.01.01 19:37 GMT+1 óra, ---)
|
|
|
|
Naa megin van kérdésem bloomot csinálok, több lépésben, és ezért egy kicsinyitett texturába szeretnék renderelni.
naigen de a kicsi texturába is ugy renderel hogy a képernyö felsö negyede van csak benne  és ez nemjó  ha persze nem kicsinyitett texturába rajzolok akkor müxik szépen csakhát ugye lassabb...
szal hogylehet ezt megoldani?
|
|
|
|
Idézet
fpeti :
Idézet
TheProGamer :
Az a baj hogy ezt GPU-nként máshogy kell megcsinálni
Olvasgattam, azt mondják, hogy a Geforce3 szériától 24 elemű bufferrel nyugodtan lehet számoltatni, de ált. véve inkább kevesebb legyen a feltételezett cache size, mint több.. ha igaz.
......
'Független' cach-reorder progit csak az NvTriStrip-et találtam, pont Syam írt róla cikket... hehe.. lehet jó lesz.
Gef szériánál lehet 24-el számolni a 6xxx-ig biztosan de valószínűleg feljebb is. A probléma az hogy nem csak a Nvidia gyárt videókártyákat (pedig mennyivel egyszerűbb életünk lenne ) és a Radeon-oknál mintha már máshogy mennének a dolgok, az integrált Intel fosoknál meg fogadni merek hogy máshogy mennek.
Reality is almost always wrong. - House
|
|
|
|
Idézet
TheProGamer :
Az a baj hogy ezt GPU-nként máshogy kell megcsinálni
Olvasgattam, azt mondják, hogy a Geforce3 szériától 24 elemű bufferrel nyugodtan lehet számoltatni, de ált. véve inkább kevesebb legyen a feltételezett cache size, mint több.. ha igaz.
Idézet
TheProGamer :
külön konverterrel kell megpróbálni az X-et előállítani mondjuk 3ds-ből.
Apppám, de jó... írtam mondjuk 3ds betöltőt is pár hete, de abba meg animáció&skinning nincs..
Olvastam, hogy egy banális materiál-template sorrend felcserélés miatt nem tölti a Blender .x-eit.. Kár, hogy már dx8-as időkben is megvolt a probléma, és még mindíg megvan...  .. lehet python t is kéne tanulni...
'Független' cach-reorder progit csak az NvTriStrip-et találtam, pont Syam írt róla cikket... hehe.. lehet jó lesz.
|
|
|
|
Idézet
fpeti :
Nem tud valaki toolt vertexek gpu-vertex-cache-barát újrarendezésére?
DXMesh-ben is van, de az nem tölti a Blender .x exportját.. sajnos.. 
Az a baj hogy ezt GPU-nként máshogy kell megcsinálni szóval mindenképpen betöltésnél kell csinálni. A Blendernek meg xar az X exportere, nekem sem sikerült csak egyszer működésre bírnom, külön konverterrel kell megpróbálni az X-et előállítani mondjuk 3ds-ből.
Reality is almost always wrong. - House
|
|
|
|
Nem tud valaki toolt vertexek gpu-vertex-cache-barát újrarendezésére?
DXMesh-ben is van, de az nem tölti a Blender .x exportját.. sajnos..
|
|
|
|
áh nem arrol van szo h nem tudnám megirni mert egy ilyen alap fórum már van az ikonos tárhelyemen csak nincs idöm most bekalibrálni meg minden
|
|
|
|
Jól van Asylum, ám legyen 
Olyan UML diagramokat nyomhatsz fel jó sokat, hadd tanuljanak belőle a hozzám hasonló kezdők. Köszi
|
|
|
|
Hát gyerek, van most dolgom rendesen, de összedobok neked egy blogot kommentezéssel, képfeltöltéssel, ha van rá igény.
___________
A lelkesedés az, ami a tudásnak ízt ad...
|
|
|
|
Na remélem mindenkinek ugyanugy jelenik meg (sima html ugyh muszáj neki)
http://people.inf.elte.hu/asylum/programming/C++/qblog.html
kis felbontásu monitorokon sajnos a kódot nyomja összébb XD
jaa ezt a kódot az új StreamEditor csinálta már (sokkal jobb naon faja arrol is csinájak blogot? XD vagy irom azt is párhuzamosan az enginnel)
hubazmeg már 4 ora
|
|
|
|
ott lesz a blogban
mivel html ezért ilyen hozzászolásosat nemtok csinálni de azért mégse ezt a topicot tölsem már meg itt
|
|
|
|
off
szerintem nem vészes, ha ide irogatsz.
én pl mindet elolvasom, és előbb-utóbb még jól jöhet majd, ha egyszer én is ott tartok, és elakadok, de emlékszem rá, hogy volt valamikor egy Asylum aki erről értekezett....érted, szóval még hasznos lehet
csak még nem tudok érdemben hozzászólni, így többnyire csendben hallgatok
de a válaszok hiánya szerintem ne riasszon vissza 
...
on
szerk: most kitörölted? kösz! 
|
|
|
|
nyitok egy blogot a honlapomon
|
|
|
|
na diohéjban:
kicsit átirtam az 'eseménykezelést', nagyjábol olyan mint az xna ban: van egy 'fö' osztály ami mindent lekezel csak itt nem Game hanem Screen (volt egy ilyen screen management sample ami fölöslegessé is tette a Game osztályt)
a fö hurokban a program kap egy üzit, mondjuk WM_ACTIVATE
akkor a wparamtol függöen ugye a screenmanagerre meghivja az OnActivated() fv-t az meg az éppen aktiv screen-re
ez ilyen barkácsmegoldás dehát c++ ban nem lehet igazi eseménykezelést csinálni
ennek örömére az egérkurzor elrejtödik mikor a játékon van a fókusz és megjelnetödik ha elveszti
most tulajdonképpen egy csontváz maradt a cuccbol mintha kivettem volna a húst (meshek, anyagok stb.)
de igy legalább könnyebb debugolni
az meg külön jó, hogy a main.cpp mindössze ennyi:
Kód: int main(int argc, char* argv[])
{
QScreenManager* manager = new QScreenManager;
manager->Add(new GameScreen());
return QStart(manager);
}
Ezt a hozzászólást Asylum módosította (2007.12.27 16:08 GMT+1 óra, ---)
|
|
|
|
Visszatérve az input kezeléshez: WM_INPUT-al le lehet kezelni joystick-ot/kormányt vagy egyéb egzotikus játékoknál előforduló bemeneti eszközt? Annyi biztos hogy bill-re és egérre jó de másról konkrétumot nem találtam csak annyit hogy ezen a két dolgon kívül mást is le lehet kezelni.
Reality is almost always wrong. - House
|
|
|
|
Nekem még a ToDO listám is legalább 5 különböző helyen van -> mindig van nálam papír, hogy ha jön vmi ötlet felírjam. Ha mégsincs nálam papír (v toll), akkor a mobilomba írom. Otthon v megfelelő füzetbe írom, v cetlire, ez kb. 5-6 helyet jelent összesen (elvileg gépen is vezetek ToDo-t, de vmiért nem jött be annyira még a MS OneNote se, mert általában csak pár sort írok).
Tervezés: ha gépközelben vagyok, akkor én is megnézem, mások hogy csinálják, letöltök működő sample-öket... Ha viszont nem vagyok gépnél, akkor meg szoktam tervezni előre (van rá külön füzetem ), de azért ezek a tervek inkább csak amolyan átgondolások (jó lenne, ha Input-ot egységesen és könnyen lehetne kezelni -> ehhez mire van szükség?). Ezzel csak az a baj, hogy sokszor rájövök, hogy máshogy kéne, vagy hogy még van valami, amit nem vettem figyelembe -> ilyenkor már gépközelben vagyok, azaz innen már nem tervezek
|
|
|
|
Hu ez jólesett legalább nem érzem magam egyedül
Persze nem gondoltam hogy hudekönnyülesz mert itt párhuzamosan olvasgatom a könyveket is éshát igen komplex egy ilyen engine
De nem adom fel akkorse 
|
|
|
|
Idézet
TheProGamer :
Tervezni én sem szoktam csak max azt hogy milyen feature kellene még. Vannak is osztályaim amik 4-5-ször újra lettek írva általában azért mert később tanultam valami odavágó dolgot ami javított rajta de újra kellett miatta az egészet csinálni. Viszont mielőtt egy új elemnek nekiesek mindig körbenyomozok hogyan érdemes nekiállni, hogy csinálják mások. Van hogy heteket töltök el ezzel (közben minimum két másik dolgot kódolok).
Dettó én is igy csinálom.
|
|
|
|
Reality is almost always wrong. - House
|
|
Frissebbek 
