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.

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

Kérdezd Gerit ^^

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!

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:

ami helyett lehetne nyilván az is, hogy

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ó

Ez meg szintén nem jó:

Lehet h itt linkelt be valaki egy oldalt ahol össze voltak hasonlitva a GPU-k aszerint hogy melyik hogyan párhuzamositja a shadereit. Minnyá elöszedem.

szerk.:

http://www.geeks3d.com/20120309/opengl-4-2-atomic-counter-demo-rendering-order-of-fragments/

"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...

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

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?

---

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)

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.

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.

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é.

ifet nem raknek shaderbe

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.

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.

Hát, majdnem ugyan az nálam

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:

Én nem a "finalcolort" nézem, hanem fény dot normalt (ill. shadowt). Próbáld ki hátha^^

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

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...)

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...)

Jól hangzik.

@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.

@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...)

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?

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.

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.