játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5444
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:    2188
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] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]
__z - Tag | 69 hsz       Online status #201966   2014.03.12 10:54 GMT+1 óra  
Idézet
syam :
Én itt nem látok vbot csak vertex arrayt.


A lényeg, hogy működik...

   
syam - Törzstag | 1491 hsz       Online status #201965   2014.03.12 10:43 GMT+1 óra  
Idézet
__z :
Itt a konkrét kód (Android/Java):
Kód:
FloatBuffer vertices = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer(),
            texCoords = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer();
float[] array = new float[12];
int[] transform = new int[2];         
float width, height;

gl.glVertexPointer(2, GL10.GL_FLOAT, 0, vertices.clear());           
gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, texCoords.clear());

void drawArrays(GL10 gl) {
  gl.glDrawArrays(GL10.GL_TRIANGLES, 0, vertices.position() / 2);
  texCoords.clear();
  vertices.clear();
}       

void draw(float x, float y, int textureX, int textureY, int textureWidth, int textureHeight) {     
  if (vertices.remaining() == 0) drawArrays(gl);
  array[10] = array[2] = array[0] = x;
  array[9] = array[5] = array[1] = y;           
  array[8] = array[6] = array[4] = x + Math.abs(transform[0]) * textureWidth;
  array[11] = array[7] = array[3] = y + Math.abs(transform[1]) * textureHeight; 
  vertices.put(array);             
  array[10] = array[2] = array[0] = (transform[0] > 0 ? textureX : textureX + textureWidth) / width;
  array[9] = array[5] = array[1] = (transform[1] > 0 ? textureY : textureY + textureHeight) / height;           
  array[8] = array[6] = array[4] = (transform[0] < 0 ? textureX : textureX + textureWidth) / width;
  array[11] = array[7] = array[3] = (transform[1] < 0 ? textureY : textureY + textureHeight) / height;
  texCoords.put(array);                 
}
// a transform tömböt tükrözéshez és nagyításhoz használom




Én itt nem látok vbot csak vertex arrayt.
alias aalberik
   
Seeting - Törzstag | 2306 hsz       Online status #201964   2014.03.12 08:07 GMT+1 óra  
Idézet
syam :
VBO frissítése nem ajánlott dolog. Ha mégis muszáj, mert pl. uniformként nem kezelhető az adat, akkor buffersubdata esetleg dupla bufferelve. A mappelés annyira nem válik be.



Hát pedig ez a dynamic batchelés lényege. Minden frameben frissíteni. Csak az a kérdés, hogy milyen módszerrel invalidáljuk a régi adatot. A duble bufferinget is el lehet érni többféleképpen. Egyébként miért nem szereted a mapbuffer-t?
   
__z - Tag | 69 hsz       Online status #201963   2014.03.12 06:44 GMT+1 óra  
Itt a konkrét kód (Android/Java):
Kód:
FloatBuffer vertices = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer(),
            texCoords = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer();
float[] array = new float[12];
int[] transform = new int[2];         
float width, height;

gl.glVertexPointer(2, GL10.GL_FLOAT, 0, vertices.clear());           
gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, texCoords.clear());

void drawArrays(GL10 gl) {
  gl.glDrawArrays(GL10.GL_TRIANGLES, 0, vertices.position() / 2);
  texCoords.clear();
  vertices.clear();
}       

void draw(float x, float y, int textureX, int textureY, int textureWidth, int textureHeight) {     
  if (vertices.remaining() == 0) drawArrays(gl);
  array[10] = array[2] = array[0] = x;
  array[9] = array[5] = array[1] = y;           
  array[8] = array[6] = array[4] = x + Math.abs(transform[0]) * textureWidth;
  array[11] = array[7] = array[3] = y + Math.abs(transform[1]) * textureHeight; 
  vertices.put(array);             
  array[10] = array[2] = array[0] = (transform[0] > 0 ? textureX : textureX + textureWidth) / width;
  array[9] = array[5] = array[1] = (transform[1] > 0 ? textureY : textureY + textureHeight) / height;           
  array[8] = array[6] = array[4] = (transform[0] < 0 ? textureX : textureX + textureWidth) / width;
  array[11] = array[7] = array[3] = (transform[1] < 0 ? textureY : textureY + textureHeight) / height;
  texCoords.put(array);                 
}
// a transform tömböt tükrözéshez és nagyításhoz használom

   
syam - Törzstag | 1491 hsz       Online status #201961   2014.03.12 01:57 GMT+1 óra  
Mármint dinamikusan töltöd fel / updateled minden frameben a vbo tartalmát?
alias aalberik
   
__z - Tag | 69 hsz       Online status #201960   2014.03.12 00:38 GMT+1 óra  
Idézet
syam :
A vbo "akármekkora" lehet sebességet nem befolyásol. Ha mobilplatform is bejátszik, akkor arra kell figyelni, h 64k vertexnél ne legyen több.


Az ilyesmikre voltam kíváncsi, de most csak kb. ~12k vertex-nyit foglalok (49152 byte), ami már biztosan elég, és ezek szerint sok vizet nem zavar a "fölöslegesen" lefoglalt hely.
Egyébként nem tudom, milyen alternatívák vannak, de én egyszerű float-ként olvasom be a bufferekbe a texcoord és vertex pozíciókat, így feltételezem, ezek frame-enként "közlekednek" a két ram között, ezért gondoltam, hogy számíthat a méretük...

   
syam - Törzstag | 1491 hsz       Online status #201959   2014.03.11 23:10 GMT+1 óra  
A vbo "akármekkora" lehet sebességet nem befolyásol. Ha mobilplatform is bejátszik, akkor arra kell figyelni, h 64k vertexnél ne legyen több.

Kb. csak arra kell figyelni, hogy interleaved legyen az adat és minél kisebb méretű legyen a vertex attrib össz mérete.

VBO frissítése nem ajánlott dolog. Ha mégis muszáj, mert pl. uniformként nem kezelhető az adat, akkor buffersubdata esetleg dupla bufferelve. A mappelés annyira nem válik be.
alias aalberik
   
Seeting - Törzstag | 2306 hsz       Online status #201958   2014.03.11 22:08 GMT+1 óra  
Egyébként te hogy frissited a vbo-k tartalmát? Mert jelenleg pont én is ilyesmit implementálok. És ez egyáltalán nem triviális dolog.
   
Seeting - Törzstag | 2306 hsz       Online status #201957   2014.03.11 22:05 GMT+1 óra  
Minél nagyobb a vbo, nyilván annál többet foglal a vram-on, és ha kevés négyszöget rajzolsz ki, akkor ráadásul feleslegesen is.
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201950   2014.03.11 12:57 GMT+1 óra  
Amit írtam, az igazából független attól, hogy mit rajzolsz ki - ezer db négyzet = kétezer db tri (feltéve, hogy nincs ismétlődés), meg egy kétezer polys modell is kétezer tri

Szóval nem, nem látom, hogy lenne bármilyen hátulütője a dolognak.
Dare to imagine!
http://www.insaneidea.hu
   
__z - Tag | 69 hsz       Online status #201949   2014.03.11 08:41 GMT+1 óra  
MaNiAc :
Még mindig csak 2D-s sprite-okat rajzolgatok.
A kérdés arra vonatkozott, hogy foglalhatok akkorát, amibe mondjuk 1000+ "négyzet" belefér, úgyis csak a használt rész számít (a glDrawArrays-nál ugyebár meg kell adni ezt), vagy lehetnek ennek hátulütői?

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201939   2014.03.10 22:29 GMT+1 óra  
Ha 1x akkora kell a modellnek, amit megjelenitesz, akkor akkora kell neki, ebbol ne csinalj problemat Ha mar millios nagysagrendrol van szo, akkor meg ugyis lesz valamifele vagas, ami alapjan megjelenitesz vagy nem jelenitesz meg egy objektumot (pl. egy epulet modelljet felvagod reszekre es csak azokat a reszeket jelenited meg, amik a latoterben vannak, stb)
Dare to imagine!
http://www.insaneidea.hu
   
__z - Tag | 69 hsz       Online status #201891   2014.03.09 07:55 GMT+1 óra  
Implementáltam a dolgot, még az a kérdés merült fel bennem, hogy mekkora vertex és texCoord buffereket érdemes foglalni? Vagy másként megfogalmazva: ha túl nagy méretet foglalok (persze itt csak kilobyte-os nagyságrendre kell gondolni), annak lehet negatív hatása? (Most 4kb-ot foglalok, és ha kevés lenne, meghívódik a glDrawArrays és a bufferek visszaállítása.)

   
Seeting - Törzstag | 2306 hsz       Online status #201835   2014.03.07 05:56 GMT+1 óra  
Ja igen, főleg ha VAO-t használsz. De ha nem, akkor jobb az összevont buffer, mert az csak 1 db glBind().
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201830   2014.03.06 19:40 GMT+1 óra  
Idézet
Seeting :
Desktop GL esetében is ajánlott, a drawcall-ok számának redukalasa. Persze pc-n egy 2D-s játék eseteben nem fogod érzékelni a változást.

Összevonás alatt arra gondoltam, hogy két külön array van vs. egy db array + stride. Ez drawcall szempontból tök mindegy szerintem.
Dare to imagine!
http://www.insaneidea.hu
   
Seeting - Törzstag | 2306 hsz       Online status #201820   2014.03.06 13:11 GMT+1 óra  
Desktop GL esetében is ajánlott, a drawcall-ok számának redukalasa. Persze pc-n egy 2D-s játék eseteben nem fogod érzékelni a változást.
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201818   2014.03.06 09:36 GMT+1 óra  
Szerintem az összevonás preferencia kérdése - bár nem tudom, ES-nél van-e erre valami speciális dolog... (Desktop GL-lel dolgozok). Én csináltam már így is, úgy is.

A másik meg igen, triangles... Régen nagyon nyomatták a tristrip-et is, néhány esetben biztos jó is, de sokszor elég szopás, mivel egy random 3d progiból (pl. Blender) kiexportált modellben sima trik lesznek, indexelve.
Dare to imagine!
http://www.insaneidea.hu
   
syam - Törzstag | 1491 hsz       Online status #201817   2014.03.06 09:34 GMT+1 óra  
Amit lehet batchelj. A mobilok nagyon kényesek a drawcall számra.
Célszerű külön kezelni uvt és pozíciót.
Indexelt háromszögeket érdemes használni, mert akkor egymással össze nem kapcsolt háromszögeket tudsz renderelni (strip esetén degenerált háromszög kellene), de ugyanakkor használod is a vertex cachet.

Én billboard pontokat és vonalakat batchelek (ill. szöveget) - tipikusan az az eset, amiből sok van viszont egyszerre kevés a geometria.
alias aalberik
   
__z - Tag | 69 hsz       Online status #201814   2014.03.06 09:02 GMT+1 óra  
Még két kérdés:
- a texCoord és vertex tömböket össze lehet (illetve érdemes) vonni egybe?
- mi a legcélszerűbb primitiv (gondolom GL_TRIANGLES) ?

   
Pretender - Törzstag | 2498 hsz       Online status #201813   2014.03.06 08:29 GMT+1 óra  
Szövegekre mindenképpen érdemes egybegyúrni. Sőt, a sprite-ok rajzolásához is. Általában Sprite Batch-nek nevezik ezt az egészet, és egy dinamikus VBO-ba frissítgetik az értékeket.
Szóval ilyesfajta sprite renderelésnél szerintem mindenképpen gyorsulást hozna, elkerülve a draw callok overhead-ét.

   
__z - Tag | 69 hsz       Online status #201812   2014.03.06 05:39 GMT+1 óra  
OpenGL ES (1.1) kérdés: Egy 2D-s játéknál, ha a "négyzetenkénti" rajzolás (gl.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4); ) helyett összegyűjteném a textúra és vertex koordinátákat egy über tömbbe, és csak egyszer hívnám a glDrawArrays-t, az eredményezhet-e érdemi gyorsulást, illetve lehetnek-e egyéb előnyei/hátulütői (rajzolási sorrend, stb.) ?
(Most főként a szövegek kiírásánál jön elő lassulás, ahol a betűket is a fent leírt módon, "egyesével" rajzolom.)
(Szerk: Persze a felvetett megoldás feltételezi, hogy egyetlen nagy textúra atlaszból rajzolok, és nem váltogatom a textúrákat közben.)

   
Geri - Törzstag | 2188 hsz       Online status #201534   2014.02.23 14:46 GMT+1 óra  
én a régi enginemben kettesével töltöttem őket, az újban még nem írtam meg a textúrabetöltéshez szűkséges threadolást.

   
Pretender - Törzstag | 2498 hsz       Online status #201533   2014.02.23 14:39 GMT+1 óra  
Igazából azért a 2048x2048 nem egy túl kicsi textúra, nagyjából 1mp-es betöltési idő talán oké lehet. Persze, ha minden egyes ilyen textúrabetöltésre új threadet indítok, ...

   
Geri - Törzstag | 2188 hsz       Online status #201531   2014.02.23 13:52 GMT+1 óra  
xanat: használj threadokat, azért van a sok cpu mag.

   
__z - Tag | 69 hsz       Online status #201530   2014.02.23 12:35 GMT+1 óra  
Pretender :
Nem tudom, mennyit határoz, de egy próbát megér szerintem, ha a png-ken leveszed a tömörítést 1-3 közé (ha a nulla jelenti a tömörítetlent)...

   
Pretender - Törzstag | 2498 hsz       Online status #201523   2014.02.23 09:02 GMT+1 óra  
Na még egy, ha már a textúráknál vagyunk
Az mennyire természetes, hogy 9 db 2048x2048-as png képet kb. 8-9 mp-ig tart betölteni? Lodepng nevű statikusan befordítható cuccot használom a betöltéshez.

   
Pretender - Törzstag | 2498 hsz       Online status #201522   2014.02.23 07:21 GMT+1 óra  
Ja-ja, ez is jó ötlet. Így viszont szerencsére elkerülöm ennek a problémának az általános megoldását, mert nem fog előjönni.
Minden esetre abban a progiban valahogy trükköztek, mert ezeket a contenteket használva oldották meg. Persze az is igaz, hogy az egy cél-program.

   
__z - Tag | 69 hsz       Online status #201521   2014.02.23 06:07 GMT+1 óra  
Pretender :
Ami nekem eszembe jutott:

Itt az A-B, C-D, E-F részt mindig kirajzolod (persze az utóbbi kettő pozíciója változik), és B-C, D-E rész rajzolásánál trükközöl (vágod, nyújtod, stb.).

   
Pretender - Törzstag | 2498 hsz       Online status #201517   2014.02.22 19:51 GMT+1 óra  
Igazából a contentek adott voltak, egy másik programból vettem kölcsön tesztelés céljára, és ezáltal rögtön elő is jött ez a "probléma". Bár én sem érzem teljesen valósnak, mert ahogy Te is mondtad, más content-használattal kikerülhető.

Arra is gondoltam, hogy 2 részből állna a csík: egy a vastagabb és egy vékonyabb. Ez azért lenne jó, mert ha nem tele van, akkor is jó lenne, ha "csapott végű" maradna, ami pedig az üres + tele csík rajzolgatással nem érzem, hogy megoldható lenne.

   
Lord_Crusare - Törzstag | 1288 hsz       Online status #201516   2014.02.22 19:42 GMT+1 óra  
Ezt elég furcsán valósítod meg. Miért nem készítesz egy üres és egy tele állapotot a csíkból, és a "tele" verzióból csak annyit rajzolsz rá az üresre, amennyire szükség van? A nem-téglalap alakú csíkokat általában így szokták megoldani.

   
Pretender - Törzstag | 2498 hsz       Online status #201515   2014.02.22 19:35 GMT+1 óra  
Adott két alpha csatornával rendelkező kép. Adott továbbá egy program, ami helyesen ábrázolja a két képet. Gyorsan összedobtam egy sprite-kirajzolót. A zöld csík után a szürke keretet rajzolom: srcblend: srcalpha, destblend, invsrcalpha.
A képen látszik, hogy a program jól csinálja, csak nem értem, hogy hogyan. Ugyanis ahol a keret csíkja elvékonyodik, alul nem "lóg ki" a zöld csík. Tudom, kicsit kesze-kuszára sikerült, de itt egy kép. A kérdés röviden annyi, hogy a felül lévő tesztből, hogy csináljak olyat, hogy úgy nézzen ki, mint az alsó (a feliratokat és a kisebb dobozt leszámítva)? Hogy "vágják" meg a zöldet úgy, hogy takarásban legyen?



Olyan jutott eszembe, hogy a z irányában egy kicst eltolom "előrefelé" a szürke keretet. Bekapcsolom az alpha testet és a depth bufferezést. Ahol az alpha < x, ott a zöld csík fog látszani, egyébként meg kitakarja a szürke.

   
Pretender - Törzstag | 2498 hsz       Online status #201467   2014.02.20 21:33 GMT+1 óra  
Ó, elég ratyi így ez az fbo-rendszer. Kicsit át akartam alakítani a rendereremet, amihez kell egy depth prepass. Gondoltam én naív módon, hogy készítek egy fbot depth attachmenttel, majd a kövi fbohoz szintén depth attachment, de a depth write és clear kikapcsolásával. Hát persze, hogy nem. Valószínűleg az lenne a megoldás, hogy ugyan azt a depth renderbuffert csatoljam mindkettőhöz. De ez így miezmár? Oda a struktúra...

szerk.:
Oké, végül is teljesen jogos, hogy miért így működik. Meg nem is volt nagy kihívás megcsinálni. Csak hát na...

Ezt a hozzászólást Pretender módosította (2014.02.20 22:16 GMT+1 óra, ---)

   
ddbwo - Tag | 1625 hsz       Online status #201254   2014.02.16 11:16 GMT+1 óra  
Szerintem nem túl nagy kitérő. Később már mindegy mit hogy hívnak., vagy hogy magának elnevezi-e ugyanazt. Legalább találkozik a szereplőkkel mindenféle pepecselés nélkül.

Utána minden új dolog csak apróság és gyorsabban beépül. Mindennek a megértése a leghosszabb idő, a formaiság szinte lényegtelen.
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 - Törzstag | 2498 hsz       Online status #201253   2014.02.16 11:06 GMT+1 óra  
Ja értem. Szerintem azért elavult dolgokat már nem érdemes tanulni, ha már egyszer tanulja az ember, de való igaz, ez egyszerűbb kicsit. Mármint cpu oldalon.

   
ddbwo - Tag | 1625 hsz       Online status #201252   2014.02.16 10:52 GMT+1 óra  
Az alap alatt a standardot értem. Így elég annyit tenni, hogy meglegyen a shader fordítás, a többit a GLSL ismeri. Ami így néz ki:

Vertex Shader:
Kód:
void main()
{
    gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}


Fragment Shader:
Kód:
void main()
{
    gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0);
}
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 - Törzstag | 2498 hsz       Online status #201251   2014.02.16 10:30 GMT+1 óra  
Ennél alapabb shader nem létezik (mármint ami csinál is valami láthatót) Én csak arra akartam utalni, hogy nem kell 5 millió soros cg kódot nézni kezdetnek, hanem fel kell fogni, hogy mi mit csinál. És ez arra pont jó, lehet vele játszadozni. Persze egy minimális háttértudás azért nem árt.

   
ddbwo - Tag | 1625 hsz       Online status #201249   2014.02.16 09:57 GMT+1 óra  
A Pretendernél látott kód pont nem az alap, érdemes az igazi alappal kezdeni, mert ha azt megérted, a többit kisujjból átírod.
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
   
Elodin - Tag | 173 hsz       Online status #201247   2014.02.16 08:23 GMT+1 óra  
http://ogldev.atspace.co.uk/index.html

Lépésről lépésre a végén talán összeáll vmi kép.
Vagy nézd meg a Szirmay féle bme-s előadásvideokat. Vagy járj be hozzá előadásokra Ott aztán nem kímélnek a gyakorlatban elő nem jövő alapokkal sem. Jól megértheted, hogy hogy működnek olyan dolgok a videokariba, amihez úgyse lesz semmi közöd nagy valószínűséggel

Vagy keress vmi könyvet, vagy vmi. Azért ilyen hamar feladni nem érdemes

   
Pretender - Törzstag | 2498 hsz       Online status #201244   2014.02.16 07:31 GMT+1 óra  
Pedig nem egy bonyolult dolog, csak egyszerre túl sok mindent akarsz megérteni. Én például soha nem akartam tudni, hogy fizikailag hol tárolódik a frame buffer tartalma.

Érteni kell hozzá az alap matematikai struktúrákat (mátrixok, vektorok, ...) és a hozzá tartozó műveleteket. Továbbá fel kell fogni azt, amit lentebb írtam. Mire használod a vertex shadert és a fragment shadert.

A legegyszerűbb shadert egyébként úgy tudod előállítani, hogy nem csinál kb. semmit. Értsd ezt úgy, hogy a kirajzolást screenspace koordinátákkal adod meg (azaz [-1, 1], [-1, 1] intervallumon), ekkor a vertex shadernek csak annyi a dolga, hogy a bejövő pozíciót beállítsa outputként.
Valami ilyesmi:
Kód:
#version 110
attribute   vec2    inPosition;
void main()
{
    gl_Position = vec4(inPosition.x, inPosition.y, 0.0, 1.0);
}


A fragment shaderben meg például átszínezed a pixeleket zöldre
Kód:
#version 110
void main()
{
    gl_FragData[0] = vec4(0.0, 1.0, 0.0, 1.0);
}


Persze ez csak a shader-oldali kód. Ezt OpenGL-ben be kell tölteni, linkelni, használni.

   
Viperion - Tag | 540 hsz       Online status #201243   2014.02.16 03:30 GMT+1 óra  
"egyáltalán minek neked shader?"
Azért,hogy ne csak a proci szenvedjen a feladatokkal.
Meg azért,hogy tudjak írni sajátot.

De mindegy már mert lemondtam róla.
Maradok csak a c# nál.

   
Geri - Törzstag | 2188 hsz       Online status #201242   2014.02.16 01:23 GMT+1 óra  
egyáltalán minek neked shader?

   
Viperion - Tag | 540 hsz       Online status #201241   2014.02.16 00:15 GMT+1 óra  
Túl nehéz.
Nem értem a logikáját teljesen nem látom át ezt az egészet.
Azt hiszem,hogy maradok csak simán a c# nél. Aztán ha fognak kelleni shaderek akkor majd veszek + ott van még ez is Shader Forge elég jónak tűnik.


   
ddbwo - Tag | 1625 hsz       Online status #201237   2014.02.15 22:30 GMT+1 óra  
Idézet
Geri :
viperion: az a baj, hpgy a közepán próbálod megfogni a dolgot. először is talán sima opengl 1.0 kellene neked, meg sima C, amiben játszadozhatsz.



Kezd egy ponggal!
++
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
   
Geri - Törzstag | 2188 hsz       Online status #201233   2014.02.15 22:00 GMT+1 óra  
viperion: az a baj, hpgy a közepán próbálod megfogni a dolgot. először is talán sima opengl 1.0 kellene neked, meg sima C, amiben játszadozhatsz.

   
Viperion - Tag | 540 hsz       Online status #201231   2014.02.15 21:44 GMT+1 óra  
Ez nem igaz,hogy mennyit kell tanulni ahhoz,hogy valamit elérhessen az ember.
Néztem cg kódokat csak egy sima háromszöget állítanak zöldre aztán mégis igen hosszú volt a kód. :-(
Pedig csak annyit szeretnék,hogy jó legyek c# vagy c++ ban meg egy shadernyelv.

   
Pretender - Törzstag | 2498 hsz       Online status #201230   2014.02.15 21:23 GMT+1 óra  
Egyébként nem teljesen értem, hogy miért annyira fontos neked, hogy fizikailag hol van a frame buffer tárolva...
Elég lenne annyit tudnod, hogy a vertex shadert a vertexek manipulálására (általában transzformálására) illetve egyéb adatok vertexenkénti kiszámolására használod. A fragment shadert pedig a pixel színének meghatározásához, azt figyelembe véve, hogy a vertex shader outputját felhasználhatod inputként (szintén figyelve arra, hogy ezek az adatok interpolálva vannak, tehát csak ésszel).

   
Geri - Törzstag | 2188 hsz       Online status #201229   2014.02.15 21:16 GMT+1 óra  
Idézet
Viperion :
Mi kerül a frame buffer memóriába


a frame buffer

Idézet
Viperion :
és mi a textura memória?


lényegtelen.
a lényeg, hogy a frame buffer memória az vagy logikailag, vagy fizikailag különálló at the moment.

Idézet
Viperion :
Ezekbe mi kerül és hol vannak ezek a pc ben?


változó. manapság az igp-ket mrá a procikba teszik, szóval minden a rendszermemóriában van. dedikált kártyák esetén a VBO-k, textúrák, és a frame buffer a videómemóriában van, ami a videókártyádon van. de a dedikált grafikus kártyák valószínűleg ki fognak halni pár hardvergeneráción belül.

Idézet
Viperion :
Ha megváltoztatom a texturakoordinátáját akkor automatikusan magától változnak a pixelek színei is?


what?

Idézet
Viperion :
Azt írod,hogy a fragment shader azt vár amit a vertex shader kiböfög.
De ez így nem jó mert a fragment shader az pixelt vár nem pedig vertexet.


ezt melyik mesekönyvben olvastad?

   
Pretender - Törzstag | 2498 hsz       Online status #201228   2014.02.15 21:16 GMT+1 óra  
Szerintem utána kéne nézned az alapoknak, mielőtt hullámzó effektet akarsz csinálni
A vertex és a fragment shader között helyezkedik el az a réteg, ami a vertex shader által adott információkat a "pixelekhez rendeli" (interpolációval). Ezeket az értékeket kapja meg a fragment shader, ami az adott pixel (pl.) színét határozza meg. Ez persze így nagyon elnagyolt, egy csomó közbenső lépés van / lehet (például geometry shader)

A textúrakoordináta megmondja, hogy az adott textúrából honnan kell olvasni. Semmi nem csinál "automatikusan" semmit...

Rövid összefoglaló a wikin, hogy mi történik rajzoláskor. Ez meg talán jobban lefedi a pipeline-t.

   
Viperion - Tag | 540 hsz       Online status #201226   2014.02.15 21:00 GMT+1 óra  
És ezek micsodák?
Mi kerül a frame buffer memóriába és mi a textura memória?
Ezekbe mi kerül és hol vannak ezek a pc ben?

Hát ezt nem értem.
Azt írod,hogy a fragment shader azt vár amit a vertex shader kiböfög.
De ez így nem jó mert a fragment shader az pixelt vár nem pedig vertexet.
A vertex shader az vertexet böfög ki

Ha megváltoztatom a texturakoordinátáját akkor automatikusan magától változnak a pixelek színei is?

Ezt a hozzászólást Viperion módosította (2014.02.15 21:10 GMT+1 óra, ---)

   
Pretender - Törzstag | 2498 hsz       Online status #201225   2014.02.15 20:57 GMT+1 óra  
Pixel = fragment. A fragment shader lefut minden pixelre. Ennyi. A vertex shader pedig ki nem található módon minden vertexre. Amit az kiböfög magából, azt megkapja inputként a fragment shader. Abban pedig az a feladatod, hogy az adott pixelhez tartozó értékeket meghatározd. Például a színét. Oda pedig azt írsz, amit akarsz.
A lenti videóban meg csak annyit csinál, hogy bizonyos szabály szerint a textúra koordinátáit módosítja, ezzel az adott pixelhez mindig más és más textúrabeli-értéket rendel hozzá. Ezért tűnik úgy, hogy "hullámzik" a kép. De ezt már a többiek is mondták, ennél egyszerűbben meg nem lehet leírni.

   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] > 8 < [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]