|
|
Geri ha van videód az engine -röl szívesen megnézném. Az látszik hogy a szűk keresztmetszet a processzor. Senkinek sem sikerült megoldani hogy olyan gyorsan generálódjon le a pálya hogy a töltés ne látszódjon. Ezért én olyan pálya generáláson gondolkoztam aminél csak az töltődik le ami látszik pl a föld alatti barlangok nem. Gondolkozom azon érdemes lenne cuda -t segítségül hívni a generálásban persze akkor ati kártyával lassabban működne. Szerintem komoly jövő áll a voxeles játékok előtt főleg azért is mert nem kell iszonyatos mennyiségű grafikai elemet hozzáadni a játékhoz hogy élvezhető legyen.
Ezt a hozzászólást nab módosította (2012.05.30 14:16 GMT+1 óra, ---)
|
|
|
nekem működik a voxeles grafikus enginem gyakorlatban is, azt kell hogy mondjam, hogy kicsit még korai ez a technológia, kell még neki MINIMUM 3-4 év, hogy az első értelmesebb voxel alapú játékok elkezdjenek szállingózni. És itt most voxel alatt a renderelési technológiát értem, és nem azt, hogy féltéglákból áll a játék.
|
|
|
Ez a unityis jópofa
|
|
|
Idézet nab :
Minecraft -oz hasonló játékot, milyen engine -el lenne érdemes csinálni? Tele van az internet millió 1 enginel, de nézegetem amint "voxeleket" szeretnék megvalósítani rengeteg probléma adódik, pl udk -ra elég nehéz ráerőszakolni hogy egyszerű cubeokat generáljon, voltak már próbálkozások ogre ben, de ott sem sikerült eddig senkinek használható kódot írnia. Voxel engine meg jelenleg még nem létezik. Próbálkozott már valaki hasonlóval?
Vannak azért voxeles cuccok, esetleg: Polyvox
Egyébként az MC elég speciális genre, bár mostanában mmo félék is kijöttek kockákból összerakott világokkal (láttam valahol, név nem jut eszembe). Én arra tippelnék, hogy saját megvalósítás a legtöbb. Ogre-ben is van ilyen tényleg. Ott visszakonvertálja a kockákat mesh-re.
A nagy részét úgyis neked kell megírni szerintem, a kirajzolást már akármelyik engine végezheti, csak tudjon sok kockát/háromszöget rajzolni.
Egyébként rákerestem a 'Minecraft like engine'-el,és úgy néz ki meg lehet oldani Unity-vel is:
vid
|
|
|
|
Minecraft -oz hasonló játékot, milyen engine -el lenne érdemes csinálni? Tele van az internet millió 1 enginel, de nézegetem amint "voxeleket" szeretnék megvalósítani rengeteg probléma adódik, pl udk -ra elég nehéz ráerőszakolni hogy egyszerű cubeokat generáljon, voltak már próbálkozások ogre ben, de ott sem sikerült eddig senkinek használható kódot írnia. Voxel engine meg jelenleg még nem létezik. Próbálkozott már valaki hasonlóval?
|
|
|
Idézet syam :
Más téma:
Az atof /sscanf nagyon durván lassú. Ha sztring->lebegőpontos szám konverziót csináltok írjatok sajátot!
igen. az én saját atofom kb 15-20x gyorsabb, mint a beépített.
|
|
|
Csak úgy mellékesen
A lényeg inkább:
Ha különböző shadingeket akarok (normal mapping, sima diffuse, stb. ), akkor ugye érdemes eltárolni egy material ID-t. De azzal hogy választom ki, hogy melyik pixel/fragment shader fusson le? Esetleg stencilezés?
|
|
|
Más téma:
Az atof /sscanf nagyon durván lassú. Ha sztring->lebegőpontos szám konverziót csináltok írjatok sajátot!
alias aalberik
|
|
|
discard, if temahoz....
discard: ahogy syam irta, TBD gpu-kon a discard halal, tenyleg csak akkor erdemes hasznalni, ha muszaj. Asztalinal kicsit bonyolultabb a dolog, architekturatol fuggoen nyereseg tud lenni, ha kelloen koherens. Erdemes amugy minel elorebb rakni a kodban, mert altalaban a shader ugyan lefut a discard utan, de a texturamuveletek mar nem.
if: na ez mar egy bonyolult tema, itt is igaz, hogy a koherenciatol fugg, mennyire lassit/gyorsit az if, erosen javasolt megnezni/profilozni a generalt shaderkodot. Pragmakkal kenyszeritheto a fordito, hogy mit csinaljon egy if-bol, ez neha nagy gyorsitas tud lenni. Egyszerubb, kisebb if-eknel erdemes ugy hagyni, ahogy a fordito akarta, vagy lerpelni ala version, vagy egyszeruen a trinary operatort hasznalni (a=b<c ? d : 0). Utobbi esetben, illetve sima if-eknel erdemes vigyazni, hogy ha lehet, ne legyen hirtelen vagas, "vegtelenfrekvencias" valtas, mert az aliasingot general. (pld a "saturate(dot(l,n))" nem fog, de a discard(alpha-0.5) igen)
|
|
|
Hú, megint rám jött...
1:
A worldspace pozíciót így számolom vissza pixel shaderben:
Kód: float3 wposition = eyePosition + normalize(EyeRay) * depthText;
ami helyett lehetne nyilván az is, hogy
Kód: float3 wposition;
wposition.xy = // akármi, nem tudom hirtelen :)
wposition.z = depthText;
wposition = mul(wposition, invView);
wposition /= w;
Gondolom az előbbivel még így is jobban jövök ki (annak ellenére, hogy a normalizálás nem egy olcsó művelet). De azért várnék egy kis megerősítést. (a depth viewspace)
2:
lent már beírtam ugyan, de szerintem elveszett, hogy: mi a normális point light attenuation képlet? Most ez van, de az nem jó
Kód: float3 lightVector = position - wposition;
float dist = length(lightVector);
float attenuation = saturate(1.0f - dist / radius);
Ez meg szintén nem jó:
Kód: float attenuation = saturate(1.0f / (constant + linear*dist + quad*dist*dist));
|
|
|
|
"Teljesen azt hittem, hogy pixelenként fut le, és minden egyes pixellel lehet spórolni így"
jo lenne , igaz akkor mar processzornak hivnak
|
|
|
Idézet sirpalee :
Pretender, a gpun a shader egységek kötegekbe vannak csomagolva, és egy adott tile rész egy köteg futtat le. Ha ebből az egyiknél discardolsz az semmit sem ér, mert meg kell várnia a többit. Ha az egész csomag, összes szálánál ez meg tudod tenni, az viszont már jó dolog. Ha csak pár pixelre jó, akkor a plusz vizsgálat miatt rosszabbul is jöhetsz ki akár.
Ki kell próbálni és kiderül.
(pl nv gpuknál a shader procik hogy vannak csoportosítva, nagyon változik, tipikusan 8 és 192 között mozognak, az újabb gamer kártyákon több van, mint a kepler; ezért is rosszak gpgpura)
Ja értem. Akkor már értelmet nyert a bf3-mas paperben olvasott "tile-based deferred shading". Nem is értettem, hogy mi értelme van, de akkor már vágom  Teljesen azt hittem, hogy pixelenként fut le, és minden egyes pixellel lehet spórolni így (ha mást nem, egy alphablendet)
Jut is eszembe... point light attenuation-re mi a legnormálisabb képlet? Eddig ez volt, de ez így nem az igazi...
Kód: float3 lightVector = position - wposition;
float dist = length(lightVector);
float attenuation = saturate(1.0f - dist / radius);
volt egy olyan is, hogy 1 / (constant + linear*dist + quad*dist*dist), de az se volt túl jó. Sőt, azzal rosszabb volt
|
|
|
Idézet versio :
syam: 50 pontfeny nem sok egy kicsit? jatekba eleg 1 
ha meg mar durvulni akar az ember akkor cubemapos Gi-t csinal
Részecskerendszerhez ennyi még lehet, hogy kevés is :3
alias aalberik
|
|
|
syam: 50 pontfeny nem sok egy kicsit? jatekba eleg 1 
ha meg mar durvulni akar az ember akkor cubemapos Gi-t csinal
|
|
|
Idézet Asylum :
Márminthogy annyira életszerüek mint te? 
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
|
|
|
Pretender, a gpun a shader egységek kötegekbe vannak csomagolva, és egy adott tile rész egy köteg futtat le. Ha ebből az egyiknél discardolsz az semmit sem ér, mert meg kell várnia a többit. Ha az egész csomag, összes szálánál ez meg tudod tenni, az viszont már jó dolog. Ha csak pár pixelre jó, akkor a plusz vizsgálat miatt rosszabbul is jöhetsz ki akár.
Ki kell próbálni és kiderül.
(pl nv gpuknál a shader procik hogy vannak csoportosítva, nagyon változik, tipikusan 8 és 192 között mozognak, az újabb gamer kártyákon több van, mint a kepler; ezért is rosszak gpgpura)
raytraceisten és übermedic
|
|
|
A discard hiánya nálam felezi fpst deferred shadingnél (kb. 50 pontfény - csak az attenuation alapján dobok el).
Az immediate renderelőknél, mint amilyen az asztali gpuk, a discard gyorsít.
A deferred típusú renderelőknél (az összes imgtec gpu - az ájfónokban is ez van), ott brutálul lassít a discard.
alias aalberik
|
|
|
abban igaza van ddbwo-nak hogy annyira nincs ertelme optimalizalni az engineket, mert ugysem lesz annyi grafikus aki telerajzolja
kvarcjatekokon, gondolok itten az ipadra,iphonera es androidra csak sima color shadereket kell nyomni faek egyszeruseggel, ugysem tamogatjak a deferred shadinget
aztan irni kell a jatekot,
windows kornyezetbe meg az ifek sem veszesek a shaderekben , de ott is felesleges tulbonyolitani
|
|
|
Idézet ddbwo :
Az én shadereim teljesen életszerű környezetben működnek.
Márminthogy annyira életszerüek mint te?
|
|
|
float3 diffusecolor=lerp(DiffuseColor2,DiffuseColor1,fNormalDotLight);
szerintem a lerp nagyon jol helyettesiti az if-et
|
|
|
Az én shadereim teljesen életszerű környezetben működnek. Akár a Half-Life 2, Prey, Crysis vagy az Oblivion.
Tehát nem éppen szimpla modelviewer szinten nézegetem. Attól még mert nem vásároltak nekem diplomát, megcsinálom a teszteket és az alapján értékelek.
---
@Pretender:
Az egy dolog, a discard az alpha tesztnek felel meg. oldalas shadereknél látszik a különbség sebességben. És az én kártyámon biztosan lefut a shader többi része discard után.
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
|
|
|
Teszteltem okostóbi, lásd a kódot lentebb. Ha nem volt kikommentezve a discard, akkor a fragmentet nem színezte fehérre...  (bár ez most HLSL, de kizárt, hogy lenne bármi köze is hozzá)
|
|
|
Idézet ddbwo :
Ha az én kártyám boldogan elvan a feltételvizsgálattal, akkor mindenkié.
Amig anyut kápráztatod csak el a nagyszerü sédereiddel addig biztos. Amint viszont valami real-life projektben van egy ilyen máris nem olyan boldog a kártya. Pláne nem egy ipad vagy android..
|
|
|
Idézet Pretender :
- A discard után NEM fut le a fragment shader többi része
Dede.. Tesztelheted is... Nem csak poénból mondom.
Ha az én kártyám boldogan elvan a feltételvizsgálattal, akkor mindenkié.
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
|
|
|
|
hmm, akkor lehet nem érdemes vele szórakozni, főleg, ha alapvetően felsőnézetes játékról van szó.
@ddbwo: nagyot tévedsz, több helyen is.
- A discard után NEM fut le a fragment shader többi része
- A shaderben az if nem túl nyerő ötlet, mert nem "valódi" feltételvizsgálat... ami az ifen belül van, az is lefut, és utólag értékeli ki. (lehet, hogy azóta változott, amióta ezt én tanultam, javítsatok ki, ha tévedek...)
|
|
|
A discard után minden végig fut !!!
Érdemesebb if ekre tagolni és a legalsó helyre egy defaultot tenni. Ami discard is lehet akár.
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
|
|
|
texturaba is tilenkent ir, a cachekbol, viszont ha garantalni tudod hogy nagyobb foltokat ki tudsz hagyni akkor elkepzelheto hogy van ertelme, bar 10%-ert nem erdemes szenvedni
|
|
|
textúrába nem pixelenként ír? ha meg igen, és discardolva van, akkor arra le sem fut a shader többi része + rá sem blendeli, mert azt mondtuk neki, hogy hagyja a 'csába, nem?
|
|
|
szerintem hulyeseg ez a discard, mivel a gpu tilekkel szamol , es attol meg hogy a tilen egy pixel discradolva van attol meg meg kell varni a tile tobbi pixelet is
|
|
|
Ha lemész asm szintre akkor látni fogod, h a discard az a KILnek felel meg, ami vár egy paramétert. Ha az negatív akkor megy a fragmentre a halál.
Hasonlítsd össze melyik éri meg jobban:
színre feketét vizsgálni
vagy dot(normal, light) -ra azt, hogy negatív.
alias aalberik
|
|
|
Hát, majdnem ugyan az nálam
Kód: float4 finalColor = float4(diffuse * color, 1.0f);
ahol a diffuse a dot(normal, light) * att * intensity
Ahol ilyen világos "folt" van, azokra a pixelekre nyomja a discardot

esetleg dot nélkül egy sima összehasonlítás float3-mal? (finalcolor.xyz == float3(0,0,0))
szerk.:
jut is eszembe, point lightnál:
Kód: if (attenuation == 0.0f)
discard;
Ezt a hozzászólást Pretender módosította (2012.05.06 14:13 GMT+1 óra, ---)
|
|
|
Én nem a "finalcolort" nézem, hanem fény dot normalt (ill. shadowt). Próbáld ki hátha^^
alias aalberik
|
|
|
Hmm... deferred shadingnél ugye számít az is, hogy hány pixelt kell blendelni egymásra, mert az nem feltétlen olcsó egy művelet... Erre van ugye az a megoldás, hogy ha a color 0, akkor discardoljuk a fragmentet. Betettem egy kis tesztet, hogy a feltételt ellenőrizzem, hogy egyáltalán belefut-e
Kód: if (dot(finalColor.xyz, 1.0f) == 0)
{
discard;
Output = float4(1.0f, 1.0f, 1.0f, 1.0f);
return;
}
Szépen látszott is, hogy melyik részt discardolja (amíg a "discard" ki volt kommentezve természetesen), gondoltam ettől gyorsabb lesz. Azonban kb. 3 fps-t vesztettem. Vajon érdemes benthagyni, mert több fény esetén megtérül, vagy hülyeség az egész, és a dot producttal többet vesztek, mint amennyit azon a ~10-20%-nyi pixel írásán blendelésén nyernék?
|
|
|
És hogy egy szemléletesebb is legyen: under water. Csak víztükörrel, így érzékletesebb. Plusz tompított homály effekt.
(katt a képre...)
Ezt a hozzászólást ddbwo módosította (2012.05.01 22:16 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
|
|
|
Régebben említették, hogy ha tudok nagyítót meg stb-t OpenGL-ben, miért nem mutogatom. Nagyító helyett most ez is megteszi.
(katt a képre...)
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
|
|
|
|
@fpeti:
Az volt az első változat, csak az költséges és kicsi.
Most lényegében úgy néz ki jól a map, hogy a player körül van a rendes rácsozás, méterről méterre, kiljebb meg egyre lazább a cucc. A mapnak megvan az igazi méterenkénti bontása is. (ahol kell neki)
Közelről helyre áll a rend, mert multitextúra és detail textúra van. Az utat shaderrel bf2-sre minimum meg tudom csinálni.
lényegében ezek mind benne vannak:
- colormap farcry-os talaj színezős féle
- detailmap homok, fű, strand, szikla minta, stb
- overlay textúra (elvileg bármi lehet, bumpos, gloss, tényleg bármi)
Minden rétegnek a szokásos alfamap
És akkor a terepnek a bontás. A fehér rács "követi" a playert, így mindig ott részletes a terep, ahol kell.
A térkép bármely koordinátájára beszúrható colormap, ha kell. De pl a nagy mezőkön csak a fő térképre van elnagyolt colormap, plusz a közeli detail textúra.
Újabb alkalom egy képre..
Persze lehetne szigetenként a shadert lod hálózásra állítani, csak akkor mi lenne a kontinenssel?
Hmm. meg kéne csinálni a bálnavadászatot is, hátha valaki az északi sark felé tévedne...
---
A FarCry nekem is meg lett véve eredetiben, multis accountom is van rá, csak kicsit laza a net.
Ezt a hozzászólást ddbwo módosította (2012.04.26 23:21 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
|
|
|
@ddbwo:
Csak érdekességképpen: a 2004-es Far cry 2048x2048 használt nemtom pontosan, de 2x2 vagy 4x4 km-re.
Addig nincs gond a durva felosztással, amíg nem akarsz bele kis utakat,ösvényeket rajzolni. A textúrájába is lehet, de akkor meg az lesz nagyon nagy. Persze nem tudom, mi a cél: csak távolról nézzük a szigeteket, (Holdról?  ), akkor nem lesz baj.
Ha részletes terraint szeretnél, ez a 256x256 max 256x256 méterre lesz elég. Én elég szimplán oldom meg, négyzetekre osztottam a heightmap-et, a közeliek mennek maximumon, távolodva meg kihagyok egyre több részletet: (1x1 cella helyett 2x2, 4x4 cellát rajzolok ki, mintha egy lenne)
kép
Ahogy néztem, az első Far cry is így csinálja (direkt ezért megvettem bótba 900huf-ért  )
Kicsit 'detail-popping', de működik. A rossz benne csak az, hogy ezeket a különböző felbontású részeket össze kell 'ötleni' - kis 3szöglistát rajzolni a különböző felbontású patch-ek között, különben T-junction féle problémák lesznek (terrain stitching-nek hívják).
|
|
|
Ezen már látszik... 256*256, 50*50 km. Szinte a Holdról nézzűk. A közepe gyakorlatilag fehér már, mert ott sűrű a cucc...
(katt a képre...)
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
|
|
|
Nem, de a belseje tipikusan nincs is kidolgozva, a kulseje viszont baromi reszletes.
Szal valami olyasmi kene ami reszleges visibilitynel kurvagyors, de a teljesnel nem rosszabb mint a static batching (vagy nem lenyegesen).
Errol a pvs-rol tudsz linkelni konkret megvalositasokat? Mert wikipedia alapjan nem egeszen tiszta, es a memoria szinten kurvanagy issue.
|
|
|
Annyira nyitott a modell, hogy a belseje is látszik mindenhonnan?
alias aalberik
|
|
|
Az a baj, hogy sokszor az egesz modell latszik, szal valamifele batching mindenkeppen kell.
|
|
|
Attól függ milyen modell. Ha van benne sok takart felület akkor pl egy octree és hozzávenni pvs-t.
alias aalberik
|
|
|
Nem az volt a kerdes hogy mit csinaltassak meg a userrel, hanem hogy a problemat hogyan lehet jol kezelni.
|
|
|
a statikus modellek nem jok , nem hiaba hasznalnak subdivet displacemappal a professzionalis gfx iparban, annal jobb nincs
|
|
|
Lenne egy kerdesem hatha tud valaki vmi okosat.
Hogyan lehet irtozatosan nagy (tobb gigabyte, tobb tizmillionyi poligon) statikus modelleket ertelmesen terparticionalni, hogy mondjuk egy kozepkategorias gepen is 30 fps folott menjen?
Jelenleg static batchinget hasznalok, ami igazabol elfogadhatoan megy (egy eleg regi kartyan 2-3 fps), egy viszonylag ujabb quadron mar 15-20 al is. A jelenet kb. 15 millio poligon.
|
|
|
Oké, ez eddig egy uniform grid, hol van ebben a LOD?
Olyan képet mutass, ahol van azért, és látszik is.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
|
|
|
Legújabb project:
Smashed Potatoes
Legutóbb frissített project:
Treasure Measure
Friss kép a galériából:
|