játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5484
FZoli:    4893
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2526

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2196
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
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]
Instalok - Tag | 607 hsz       Online status #204318   2014.07.30 18:35 GMT+1 óra  
Nem tudom, hogy WebGL-ben van-e, de
Kód:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0-base value);

Ezzel korlátozd le a mipmapek számát a textúrának megfelelően, ha szükséges.

   
peti634 - Tag | 148 hsz       Online status #204317   2014.07.30 18:19 GMT+1 óra  
Mivel WebGL-be dolgozok, így kérném még annyiba segítségeteket hogy:
http://www.khronos.org/files/webgl/webgl-reference-card-1_0.pdf

Nem látok semmi hasonló beállítást, lehet marad 1 kép 1 textúrába elv?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Matzi - Szerkesztő | 2526 hsz       Online status #204314   2014.07.30 17:48 GMT+1 óra  
Sajnos a paddingnak is megvan a maga korlátja. Konkrétan ha eléri a legalsó mipmat szintet, akkor egyetlen pixel lesz a textúra, a benne található információ átlagával, és akkor azt fogja kitenni. Limitálni kell a maximális mipmap szinteket annyira, hogy még ne mossa össze őket.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
peti634 - Tag | 148 hsz       Online status #204313   2014.07.30 17:45 GMT+1 óra  
igen igen, közbe rájöttem, a texImage2D-nél levelt növelve, egyre kisebb képeket kell neki beadni, gondolom így kellene

De mi van akkor hogy ha egy 128x512-es textúrát akarok mipmapolni?
Az utolsó 1x4-es kép után mit adok be? 1x2, és 1x1 a levelet növelve?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
syam - Törzstag | 1491 hsz       Online status #204312   2014.07.30 17:36 GMT+1 óra  
Szerintem a mipmapelés mossa össze. Textura atlas - paddolni kell még mindig
alias aalberik
   
peti634 - Tag | 148 hsz       Online status #204311   2014.07.30 17:08 GMT+1 óra  
Valamit elrontanék?
A következő textúrát használom:


A kordinátáim a következőek:
x: 0.125 - 0.375
y: 0.25 - 0.75

Sok kis vertexet rajzolok ki, ezekre mind ezt a koordinátát használom, viszont a következő képet kapom:

A távolban a másik textúra színe látszódik már.

A MIN filterem Mipmap-ot használ, de bármilyen beállítás van, akkor is előjön ez a jelenség. Ha Nearest, vagy Linear akkor már persze jó, viszont nagyon csúnya így. Hogy tudom ezt kijavítani?

Mint látható egy Voxel típusú engine készülget, úgy hogy jó lenne ha sok textúrát tudnék használni egy kirajzolással.
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Asylum - Törzstag | 5484 hsz       Online status #204257   2014.07.26 18:03 GMT+1 óra  
textúra atlaszoknál az a szabály, hogy a résztextúrák 2 hatványak legyenek és csak a saját méretük többszörösénél kezdődhetnek. Pl. egy 32x32-es textúra kezdődhet 0, 32, 64, stb.-nél.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
peti634 - Tag | 148 hsz       Online status #204255   2014.07.26 17:47 GMT+1 óra  
A "jól" alatt gondolom azt érted hogy közvetlenül egymás mellet legyenek a textúrák.

Nagyobb textúráknál is gond lehet az hogy ha egy világosabb mellett egy sötétebb textúra van, vagy linear-nál csak a közvetlen (1 pixel) szomszédokat mossa össze?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 607 hsz       Online status #204254   2014.07.26 16:33 GMT+1 óra  
Ha jól packeled az atlaszt, akkor teljesen jó. Gondolj csak bele, mindegy, hogy 16*32x32, vagy 128x128, a méret ugyan annyi. Cserébe kevesebb a textúraváltás, ami viszont jó.

Mipmapeket gondolom használsz, ha linear filteringről volt szó. Elég kicsi textúráknál elő szokott fordulni. Esetleg megpróbálhatod egy fél pixelnyit odébbtolni a textúra-koordinátákat.

   
peti634 - Tag | 148 hsz       Online status #204253   2014.07.26 16:23 GMT+1 óra  
értem, erre gondoltam.
A felbontás csak példa, nagyobb képeket használok.
Továbbra is gondolkodok azon hogy használjak inkább Cube textúrákat?
8*6 mégis csak 48 textúra, a sima 8 helyett.
A textúra atlasz nem túl memória pazarló?
Sebességben mennyire rossz Cube-ot használni?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
syam - Törzstag | 1491 hsz       Online status #204243   2014.07.25 23:06 GMT+1 óra  
peti634:
textúra atlasz
ha viszont ilyen kicsi felbontású textúra kell érdemes meggondolni, hogy per-vertex nem lehet-e megoldani a kérdésed
alias aalberik
   
peti634 - Tag | 148 hsz       Online status #204241   2014.07.25 20:46 GMT+1 óra  
esetleg GL_LUMINANCE?
Szerintem ha olyat használsz ami csak komponenst tárolsz (R v G v B v A), és GL_BYTE a típusa, akkor ettől kevesebbet nem fogsz tudni használni, minden képpontnak legalább Byte méretűnek kell lennie, ha jól gondolom.

Nekem is lenne egy kérdésem:
Egy textúra részeit hogy tudom külön külön használni?
Ezalatt azt értem hogy mondjuk egy 16x16-os képet feltöltök, és a vertexre csak 8x8-at húzok rá, vagyis 0-0.5 értéket használok. Ezzel viszont az a gondom hogy ha LINEAR-re van állítva, akkor a szélén lévő pixeleknél beleveszi a másik kép képpontjait is. (ha ez a 8x8 rész fehér, a többi pedig fekete, elég feltűnő
Hogy lehet, vagy ti hogy oldjátok ezt meg?
Mivel általában 8 textúrát lehet feltölteni maximum egy renderelésre, de ha nekem többre van szükségem akkor mi a teendő? Esetleg használjak Cube textúrákat (8*6 kép)?

Mennyire lenne jó megoldás ha a 2 kép között hagynék 1 pixel rést, viszont távolról már több pixel is átlagolni fog, nem csak a közvetlen közelébe lévő pixeleket, nem?
ha már szép nem vagy, hülye ne légy
http://www.pokolstudio.hu
   
Instalok - Tag | 607 hsz       Online status #204234   2014.07.24 18:38 GMT+1 óra  
Ha egy fekete-fehér képet akarok textúrába renderelni (igazából a kiszámolt árnyékokról lenne szó, ezt akarom postproces lépésben a jelenethez hozzáadni), akkor milyen formátumot érdemes választani? Az RGBA8 elég pazarlónak tűnik, mivel fekete-fehér, és ráadásul csak 2 különböző érték lenne a textúrában. Láttam R8-at meg R3_G3_B2-t is, csak nem tudom, hogy ezek milyen szinten vannak támogatva.

Itt például azt írták, hogy a GL_R8 elég új dolog még.

   
Geri - Törzstag | 2196 hsz       Online status #203943   2014.06.30 18:48 GMT+1 óra  
mintha a d3d11-et, vagy a gl4et használná egyáltalán valaki

   
syam - Törzstag | 1491 hsz       Online status #203942   2014.06.30 18:33 GMT+1 óra  
Igen, végre értelmes újdonságok kerülnek bele. A D3D12 párjának szánják.

Egyelőre csak tippelik milyen extensionök kerülnek be a coreba.
alias aalberik
   
Elodin - Tag | 184 hsz       Online status #203941   2014.06.30 18:07 GMT+1 óra  
Hol?

   
Geri - Törzstag | 2196 hsz       Online status #203940   2014.06.30 17:46 GMT+1 óra  
micsoda hiánypótló ._.'

   
syam - Törzstag | 1491 hsz       Online status #203939   2014.06.30 16:36 GMT+1 óra  
Jön az OpenGL 5 !
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #203042   2014.05.24 07:24 GMT+1 óra  
Ennek az emberkének a tapasztalatai azt mondják, hogy az általában nvidia kártyán gyorsabb (wtf?). Bár, ezzel csökkenne a CPU-oldali terheltség (nem kell ténylegesen áttranszformálni a vertexeket, csak kiszámolni a pozíciókat), illetve nem kellene dinamikus VBO sem.

Bár a paper alapján nem teljesen értem, hogy mennyivel jobb, mint uniformként átadni, mert per instance kellene rajzolni, amivel nem tudom mennyire vagyok előrébb...

Harmadik megoldásként esetleg: statikus VBO, a vertexdata állna továbbá egy ID-ból is, és a mátrixokat / pozíciókat uniform array-ként passzolnám át a shadernek. Az az adott vertexnél megindexeli a tömböt az ID alapján. Persze ennek vannak korlátai, például, hogy egy teljes arrayt kell átpaszírozni a GPU-nak, illetve ez a mennyiség limitált (ha jól rémlik nagyjából 60 mátrix mehet át egyszerre).

Ezt a hozzászólást Pretender módosította (2014.05.24 07:32 GMT+1 óra, ---)

   
syam - Törzstag | 1491 hsz       Online status #203041   2014.05.24 01:24 GMT+1 óra  
Persze. Pseudo-instancing.
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #203040   2014.05.23 22:53 GMT+1 óra  
Köszi! Ja-ja, nem egy nagy munka. Statikus tömb (vertexek), dinamikus vbo, és vertexek pozíciójának tologatásánál van jobb módszer is?

   
syam - Törzstag | 1491 hsz       Online status #203039   2014.05.23 21:17 GMT+1 óra  
Csakis batch.
A point mérete maximalizálva van és pixelben van megadva.

A vertex shader használatának egyik mintapéldája billboardot rajzolni
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #203037   2014.05.23 17:53 GMT+1 óra  
Point sprite-ot hogy érdemes megoldani? GL_POINTS-al rajzolni, és a "beépített" point-sprite-ot használni, vagy kézzel batchelni a kis négyzeteket?

szerk.:
Ahogy így olvasgattam kicsit, néhányan panaszkodtak rá, hogy itt-ott máshogy működik. Hát, nem tudom, igazából nem egy túl nagy meló megcsinálni a batchelést.

Ezt a hozzászólást Pretender módosította (2014.05.23 18:19 GMT+1 óra, ---)

   
glezmen - Törzstag | 381 hsz       Online status #203023   2014.05.22 15:51 GMT+1 óra  
Idézet
Pretender :
A cikk fele arról szólt, hogy azért kell más megoldást használni (lowlevel szint, direktben a kártyát csesztetni, API nélkül), mert nem működik rendesen az Ogl4 + Intel páros.


igy van, de ez nem az OpenGL hibaja (vagyis nem "nem tud Intelen mukodni" hanem az Intele, mert nem kepes egy normalis OpenGL drivert csinalni a vackaihoz
gondolom ebbol mar egyenesen kovetkezett, hogy ha nem kepes o maga OpenGL drivert irni a kartyaihoz, akkor legalabb alacsony szintu hozzaferest biztositson, hogy a (nem DX-es) fejlesztok tudjanak kezdeni valamit a hardware-rel
   
Geri - Törzstag | 2196 hsz       Online status #203021   2014.05.22 13:26 GMT+1 óra  
szerintem úgyis a szoftveres renderelés a jövő, ahhoz meg nem kell api

   
Pretender - Törzstag | 2498 hsz       Online status #203020   2014.05.22 12:58 GMT+1 óra  
A cikk fele arról szólt, hogy azért kell más megoldást használni (lowlevel szint, direktben a kártyát csesztetni, API nélkül), mert nem működik rendesen az Ogl4 + Intel páros. Na és akkor mi legyen a megoldás? Hát hagyjuk ki az Ogl-t. Oké, nyilván ez csak egy része az egésznek, de simán benne van (legalábbis nekem). Értem én, hogy nem (feltétlen) ez a fő mondanivaló, de akkor is az OpenGL tűnik "hibásnak", mert azt akarják kihagyni, és helyette valami mást használni. Aminek persze lennének egyéb előnyei (sebesség?) is valószínűleg, de akkor is.

szerk.:
Idézet
Ha kiindulunk abból, hogy az Epic tapasztalt programozóinak nagyjából másfél évre van szükségük ahhoz, hogy tényleg gyorsra és stabilra összerakják a modern OpenGL-t a legújabb Intel hardverekhez, akkor felmerül a kérdés, hogy gyorsabb lenne-e hagyni az OpenGL-t, és szimplán direkten leprogramozni az IGP-kre egy-egy leképzőt.

Persze az is más dolog, hogy ezt a játékfejlesztő cégek tehetnék meg, az Intel drivereket viszont nem tudják átírni. A fene vigye el az Intelt!

   
glezmen - Törzstag | 381 hsz       Online status #203019   2014.05.22 10:59 GMT+1 óra  
Idézet
Pretender :
Azért érdekes, hogy a cikk szavaiból az jön le, hogy az OpenGL egy hulladék, mert "nem megy" Intel kártyákon... értem én, hogy sok Intel van, de ha a többi driverrel működik, akkor nem lehet, hogy fordítva kellene a problémát megközelíteni, és az Inteleseket csesztetni, h tanuljanak meg programozni és szabványt betartani?



nem tudom ezt hogy sikerult leszurni belole, szerintem nagyon masrol szol a cikk
ha mar mindenaron opengl-intel vonalra akarod szukiteni, akkor inkabb annyi a mondanivalo, hogy az intel szarik az opengl-re, ezert a fejlesztok szopnak
   
Pretender - Törzstag | 2498 hsz       Online status #203018   2014.05.22 10:37 GMT+1 óra  
Azért érdekes, hogy a cikk szavaiból az jön le, hogy az OpenGL egy hulladék, mert "nem megy" Intel kártyákon... értem én, hogy sok Intel van, de ha a többi driverrel működik, akkor nem lehet, hogy fordítva kellene a problémát megközelíteni, és az Inteleseket csesztetni, h tanuljanak meg programozni és szabványt betartani?

   
glezmen - Törzstag | 381 hsz       Online status #203017   2014.05.22 09:44 GMT+1 óra  
Geri - Törzstag | 2196 hsz       Online status #203015   2014.05.22 02:30 GMT+1 óra  
Idézet
Pretender :
Valami halvány emlékem mintha lenne arról, hogy háromszögenként renderelni a legoptimálisabb bizonyos driverek esetében, de simán lehet, hogy nem így van. Nagyon régről rémlik valami, és nagyon homályosan.



erről én írtam cikket még 2006-ban, és védtem erősen ezt az álláspontot. feltehetően ez ma is így van.

   
Pretender - Törzstag | 2498 hsz       Online status #202969   2014.05.17 16:18 GMT+1 óra  
Igen, mindig újra be kell állítani.

Ha nem adsz meg indexbuffert, akkor a vertex bufferbe való feltöltés sorrendjét veszi kirajzoláskor. Az meg, hogy milyen primitívnek tekinti, te adod meg rajzoláskor. (GL_TRIANGLES, stb.)

szerk.:
Viszont, ha háromszögenként renderelsz quadot, akkor van vertex ismétlődés. Miért nem jó az indexbuffer?

Valami halvány emlékem mintha lenne arról, hogy háromszögenként renderelni a legoptimálisabb bizonyos driverek esetében, de simán lehet, hogy nem így van. Nagyon régről rémlik valami, és nagyon homályosan.

   
Elodin - Tag | 184 hsz       Online status #202967   2014.05.17 14:54 GMT+1 óra  
Kösz!
Utólag belegondolva még ha csak egy stringből rész-stringet keresne is fölösleges hülyeség, nem volt vmi. értelmes kérdés


A másik még mindig áll: ha felváltva használok különböző shaderprogikat, akkor a uniformok értéke váltások után marad, vagy mindig újra kell tölteni? (Ha marad, akkor csak változáskor állítanám át, ha nem, akkor nyilván minden rajzolás előtt).

Még egy kérdés:

Quadokat hogy érdemes rajzolni? Biztos, hogy nincs vertex ismétlődés... ilyenkor is index buffer, vertexbuffer, vagy van vmi mód, hogy indexbuffer nélkül simán 0,1,2,3 sorrendben nézze a vertexeket?

Háromszögekben érdemes gondolkodni, vagy ha átállítok vmi opengl beállítást, akkor lehet négyszögként is értelmezni a vertexeket saját shader esetén is?

   
Geri - Törzstag | 2196 hsz       Online status #202965   2014.05.17 13:54 GMT+1 óra  
bármely opengl függvény basztatása legjobb esetben is kb 100x annyi órajel nagyságrendjét tekintve, mint kiolvasni egy egyszerű változót a memóriából.

   
Elodin - Tag | 184 hsz       Online status #202964   2014.05.17 13:36 GMT+1 óra  
A uniform változók értékét mindig be kell állítani, ha közben más shaderprogramot használtam, vagy az marad, ha egyszer már beállítottam?

A uniform location lekérése mennyire költséges? Érdemes egyszer lekérni, és megjegyezni, vagy mehet minden hívásnál?

   
Pretender - Törzstag | 2498 hsz       Online status #202590   2014.04.15 07:04 GMT+1 óra  
Mármint az ibo bindelés hiánya volt a hiba? Ha igen, az úgy elég kemény, mert általában furábban szokott ilyenkor kinézni a modell.

   
syam - Törzstag | 1491 hsz       Online status #202584   2014.04.14 22:28 GMT+1 óra  
Ez olyan facepalm-OS, nem?
alias aalberik
   
Elodin - Tag | 184 hsz       Online status #202577   2014.04.14 21:19 GMT+1 óra  
Egyébként illene. Olyannyira, hogy az volt a hiba

Azért nézegettem egy darabig az assimp-os részeket, meg az assimp flag-ekkel is játszadoztam, nem gondoltam volna, hogy itt lesz a gond.

Amúgy ott volt az, csak véletlenül kommentbe került egy jelenleg még használaton kívüli kódrészlettel együtt.

   
Pretender - Törzstag | 2498 hsz       Online status #202546   2014.04.14 16:22 GMT+1 óra  
Egyébként rajzoláskor nem kell az indexbuffert is bindolni? Mármint ez nem lehet a probléma, mert akkor más sem lenne igazán jó, csak kérdezem.

   
syam - Törzstag | 1491 hsz       Online status #202541   2014.04.14 16:03 GMT+1 óra  
Gondolom az IBO mindenhol rendesen be van kötve csak lemaradt az idézetből
Még meg lehetne nézni a Blender oldali mesh statisztikát és azt amit renderelsz.
Háromszög-szám ill. vertex-szám.
Gyanús, h assimp csinál vmit furcsán. Esetleg csinál vertex cache optim.-t?

Esetleg csontanimálva van a modell?
alias aalberik
   
Elodin - Tag | 184 hsz       Online status #202540   2014.04.14 15:57 GMT+1 óra  
Külön.

Kód:
class ShadedMesh
{
private:
    std::vector<Mesh> mMeshes;
...

class Mesh
{
private:
    GLuint mVB;
    GLuint mIB;
    unsigned int mNumIndices;
...

   
syam - Törzstag | 1491 hsz       Online status #202538   2014.04.14 15:53 GMT+1 óra  
Egy közös VBO + IBO-ba töltöd fel a mesheket vagy minden meshnek külön VBO + IBO-ja van?
alias aalberik
   
Elodin - Tag | 184 hsz       Online status #202533   2014.04.14 15:23 GMT+1 óra  
Biztos, hogy nincs túlcsordulás. Több mesh-ből áll a modell, és 5000 körüli a legnagyobb indexszám is.

Bufferek létrehozása egy mesh-re:

Kód:
void Mesh::init(const std::vector<Vertex>& vertices,
                 const std::vector<unsigned int>& indices)
{
    mNumIndices = indices.size();
    glGenBuffers(1, &mVB);
    glBindBuffer(GL_ARRAY_BUFFER, mVB);
    glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex)* vertices.size(),
                 &vertices[0], GL_STATIC_DRAW);

    glGenBuffers(1, &mIB);
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, mIB);
    glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(unsigned int)* mNumIndices,
                 &indices[0], GL_STATIC_DRAW);
}


Vertex és index listák kiszedése az importerből:

Kód:
ShadedMesh::ShadedMesh(std::string name, const aiScene* scene)
{
    mName = name;
    mMeshes.resize(scene->mNumMeshes);

    for (unsigned int i = 0; i < mMeshes.size(); i++)
    {
        const aiMesh* mesh = scene->mMeshes[i];

        std::vector<Vertex> vertices;
        std::vector<unsigned int> indices;

        for (unsigned int i = 0; i < mesh->mNumVertices; i++)
        {
            const aiVector3D* pPos = &(mesh->mVertices[i]);
            const aiVector3D* pNormal = &(mesh->mNormals[i]);
       

            Vertex v(Math::float3(pPos->x, pPos->y, pPos->z),
                Math::float3(pNormal->x, pNormal->y, pNormal->z));

            vertices.push_back(v);
        }
        for (unsigned int i = 0; i < mesh->mNumFaces; i++)
        {
            const aiFace& Face = mesh->mFaces[i];
            assert(Face.mNumIndices == 3);
            indices.push_back(Face.mIndices[0]);
            indices.push_back(Face.mIndices[1]);
            indices.push_back(Face.mIndices[2]);
        }

        mMeshes[i].init(vertices, indices);
    } //meshes iteration

} //Model construktor


Egy mesh kirajzolása:

Kód:
glBindBuffer(GL_ARRAY_BUFFER, mVB);
    glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE,
        sizeof(Vertex), 0);
   
    glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE,
        sizeof(Vertex), (const GLvoid*)sizeof(Math::float3));

    glDrawElements(GL_TRIANGLES, mNumIndices, GL_UNSIGNED_INT, 0);

   
Pretender - Törzstag | 2498 hsz       Online status #202506   2014.04.13 23:23 GMT+1 óra  
Bár elég valószínűtlen, de nem lehetséges, hogy több, mint 2^16 = 65536 vertex van, amit meg kell indexelni? Mert ha igen, és netán GL_UNSIGNED_SHORT (vagy nem is tudom hirtelen fejből a nevét) típusú indexeket használsz, akkor az a baj. Ha viszont nem így van, akkor lehet, hogy az importer a rossz. Esetleg a draw-nál nem jó elemszám van megadva, ezért csak egy részét rajzolja ki. Esetleg egy VBO feltöltés + rajzolás (+ esetleg importálás) kódot, ha feltöltesz, lehet, hogy elbújt ott valami huncutság...

szerk.:
Áh, látom, syam megelőzött...

   
syam - Törzstag | 1491 hsz       Online status #202505   2014.04.13 23:21 GMT+1 óra  
Vertex indexelési problémának tűnik.
Importkor lehet, hogy uint16-ban indexel viszont túl sok hozzá a vertex.
alias aalberik
   
Elodin - Tag | 184 hsz       Online status #202504   2014.04.13 22:25 GMT+1 óra  
Blenderben így néz ki egy modell, amit megpróbálok beimportálni Assimp segítségével.

Ez az eredmény.

Másik modellt probléma nélkül betölt. Bármi ötlet, hogy hol lehet a gond?

   
Pretender - Törzstag | 2498 hsz       Online status #202425   2014.04.10 20:35 GMT+1 óra  
Nahát, erre még igazából nem is gondoltam, pedig nem rossz ötlet. Eddig csak specifikus shadereket írtam meg, legfeljebb a statikus / animált vertex shaderek voltak egyben és define-okkal megoldva.

Ezt a dolgot akár úgy is meg lehet oldani, hogy van egy übershaderje az embernek, tele ifdefekkel, így a bejövő paraméterek függvényében készül el runtime a shaderkód, amit aztán lefordít.

   
syam - Törzstag | 1491 hsz       Online status #202422   2014.04.10 20:27 GMT+1 óra  
Mindenképp kell vmiféle shader-rendszer.
Legjobb ha "surface shadert" készítesz, ami úgy is tudsz paraméterezni, hogy "érdes, kék, fém".
De ha simán modulárisan, pipeline-szerűen építed fel az is nyerő nagyon.
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #202419   2014.04.10 20:12 GMT+1 óra  
Hát ez pedig ilyen. Nem egy nagy effort. Először nekem is kicsit fura volt, dx-ben anno teljesen manuálisan csináltam. Beállítottam a vertex shadert meg a pixel shadert külön-külön, így nem volt mindig muszáj váltani. Viszont hidd el, ha van egy jó kis rendszer rá, akkor sokkal követhetőbb így a dolog. Ráadásul nem olyan nagy effort shadert váltani.

Nálam pl. így néz ki egy shaderes rajzolás:
Kód:
shader->begin();
shader->setXY(locXY, value);
draw();
shader->end();


Sokkal zavaróbb tud lenni, hogy egyáltalán semmi helper funkció nincs a shaderekhez. Azaz a define-olást és include-olást is kézzel kell megírnod. Persze nem egy nagy dolog, string-beszúrás az egész, de akkor is...

   
Elodin - Tag | 184 hsz       Online status #202417   2014.04.10 20:05 GMT+1 óra  
Hát igen. Mondjuk amíg nem kell a scale, addig nem lehet probléma.
Ha eljutok odáig, lemérem a teljesítménykülönbséget, és lehet kiszedem én is

Ha más nem, ha vminek kell scale, akkor külön írok rá shader-t

Mondjuk már most is bosszant, hogy a shadereket egybe kell fordítani.
Amit tervezek, annál pl. az van, hogy sok vertexshaderhez két különböző pixelshader is tartozni fog. Mindegyik külön program

   
Pretender - Törzstag | 2498 hsz       Online status #202415   2014.04.10 19:43 GMT+1 óra  

Az a lényeg, hogy megvan. Egyébként lehet, hogy ezzel jól meg fogom szívni egyszer, mert én a mai napig a "sima" world mátrixot használom. Nem igazán tartom szerencsésnek mindig kiszámolni az összes inverzét, az animált modellekről nem is beszélve... Minden egyes animált modell minden egyes csontjához tartozó mátrix inverzét számolgatni / frame...

   
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]