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 #208725   2015.11.29 19:31 GMT+1 óra  
Ez már nem az alacsony szint

Van egy base parameter osztályom, ezt tudja a user használni. Ebben tárolok egyéb dolgokat is, például, hogy ez milyen típusú (Float, Vec2, stb.) paraméter, és, hogy ne kelljen mindig lekérdezni, el van tárolva az adott effekthez tartozó location is.

Ezekből vannak konkrét típusok, mint pl. Vec2Param, stb., ami tárol egy értéket, van hozzá getter/setter, illetve egy adott Effekthez be tudja magát állítani (glUniformXY hívások).

Igen, mint mondtam, abban az esetben, ha csak a vertex shader tér el, úgy nincs probléma, mert a uniform location ugyan az lesz a fragment shadernél. Azonban, ha különböznek, akkor különböző location-ök tartoznak ugyan ahhoz a shaderparaméterhez.

Viszont így később lehetőség nyílik vertex-shader módosításra is user oldalról, ahol viszont már biztosan különbözni fognak a uniform location-ök.

Mondjuk a user létrehoz egy "alma" vec4 paramétert a shaderjéhez. Használni fogja statikus mesheknél, animált mesheknél, és egyéb dicsőséges helyeken. Tehát létrejön egy Vec4Param típusú objektum, aminek van egy Vector4 értéke, hozzá getter/setter, és be tudja magát állítani egy Effecthez.

Amikor egy paramétert létrehozok és eltárolom a Shaderben, akkor hozzá is rendelem a locationt. Itt jön a képbe a több location, mivel több effektem is van (statikus meshhez, animált meshhez, stb.), és nem tudhatom előre (de, egyébként de, mert én írom a shadert ), hogy melyiknél fognak különbözni, így eleve felkészülve a "legrosszabbra", több locationt tárolok, egyet minden egyes effekthez (avagy shader-variációhoz, ha úgy tetszik).

Pszeudo-c++-kód jelleggel valami ilyesmi:
Kód:
enum Usage { StaticMesh, AnimatedMesh, ... };
#define USAGE_COUNT 2

class Param
{
    enum Type { Vec2, ... };

    Type type; // a paraméter típusa
    Location loc[USAGE_COUNT]; // az adott shader-variácóhoz tartozó uniform location

    void Apply(Effect* effect, Usage usage); // a usage-et használva a loc indexeléséhez
};

template <typename T>
class ParamValue : public Param
{
    // get/set..

    T value;
};

class Shader
{
    Effect* effects[USAGE_COUNT]; // egy-egy effekt mindegyik variációhoz

    void ApplyParameters(Usage usage); // az összes paraméter beállítása
};

   
Asylum - Törzstag | 5484 hsz       Online status #208724   2015.11.29 18:07 GMT+1 óra  
Nem értem, hogy miért viszed le a problémát az uniform location szintjére (annak fel se kéne merülnie ebben a kontextusban). A skinnelés egyébként is vertex shader-hez kötődik, ahhoz pedig nem kötődik a material, szóval a két probléma teljesen "diszjunkt". A magas szintű modellt gondold át, mert ez sokkal inkább tervezési hibának tűnik.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #208723   2015.11.29 14:01 GMT+1 óra  
Nem, vagy rosszul fogalmaztam meg a felvetést, vagy csak nem értetted meg. Tisztában vagyok vele, hogy a uniform mihez tartozik, és hogy mi mit csinál, kinőttem már az ovit.

A problémám a paraméterekkel van. Akarom mondani volt, mert megoldottam közben.

Ha a júzer készít egy shadert, akkor ő főleg a materialt akarja definiálni (mint UE4-ben pl.). Létrehoz pl. egy vector4 paramétert, amivel majd állítgatja a színt. Innentől kezdve őt nem érdekli, hogy ez most éppen animated meshre vagy mire van alkalmazva. Amíg a fragment shader részben nem tér el a két shader, addig nincs gond a locationnel, mert ugyan azt fogja visszaadni. Azonban, ha más a fragment shader is, akkor különbözhetnek a locationök is. Meg ugye eleve két effect kell (ahogy Te is írtad itt lentebb a kódban).

Egyelőre úgy tűnik, hogy megoldottam a problémát. Csináltam egy shader usage enumot, ami kvázi egy shader variációt ír le. Van egy static meshhez, animált meshhez, stb. És egy paraméternek pontosan ugyan ennyi darab uniform location is van eltárolva, ami kvázi az i. effekthez tartozó uniform location. Na mind1, nehéz kicsit körülírnom most, az a lényeg, hogy megoldottam.

   
Asylum - Törzstag | 5484 hsz       Online status #208722   2015.11.29 12:52 GMT+1 óra  
wtf? oO miért kell két location? nem lehet, hogy te OOP szemszögből basztad el a dolgot? (az uniform a shaderhez tartozik nem a meshhez!!!)

Kód:
OpenGLEffect* renderstatic = 0;
OpenGLEffect* renderanimated = 0;

GLCreateEffectFromFile("render.vert", 0, "render.frag", &renderstatic, "#define ANIMATED 0\r\n");
GLCreateEffectFromFile("render.vert", 0, "render.frag", &renderanimated, "#define ANIMATED 1\r\n");

...

if (mesh->IsSkinned())
    renderanimated->Begin();
else
    renderstatic->Begin();

mesh->Draw();
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #208714   2015.11.27 18:18 GMT+1 óra  
Igen, define-okat én is használok. A probléma inkább azzal van, hogy ha user defined paramétert akarok beállítani, akkor ott valahogy figyelembe kell venni, hogy most static mesheket, vagy animated mesheket akarok rajzolni, de ezt majd valahogy megoldom.

Igen, egyébként a locationt én is egyszer kérdeztem le, de tekintve az alább glsl kódot:
Kód:
#ifdef ANIMATED

#define NUM_BONES 60
uniform     mat4    bones[NUM_BONES];

#else // ANIMATED

uniform     mat4    world;

#endif // ANIMATED

akkor az ezután következő uniformok helye más és más lesz. Azaz, ha lekérem az "alma" nevű uniform helyét, akkor ahhoz gondolom 2 locaiont tárolok, egyet a statikushoz és egyet az animálthoz. Amikor meg apply-olom a paramétereket, akkor megmondom neki, hogy ez most static vagy animated rajzolás, és a megfelelő locaiont használom. Eddig legalábbis valahogy így csináltam. Na de ez már nem OGL.

   
Asylum - Törzstag | 5484 hsz       Online status #208711   2015.11.27 14:34 GMT+1 óra  
Az uniform locationt csak betöltéskor kell lekérdezni (ld. opengl kódjaim a githubon).

Duplikálás: én pont ezen probléma miatt írtam saját shader fordítót, ami képes template-eket is fordítani (konstans kifejezés paraméterekkel). Így végeredményben egy shadert írok csak meg, persze aztán kettő lesz belőle betöltés után.

Ha ilyet nem akarsz, akkor szintén a PBR demómban használtam olyat, hogy egy #define-t adok meg betöltéskor és aszerint forrdul más shader.

Ezt a hozzászólást Asylum módosította (2015.11.27 14:40 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #208710   2015.11.27 14:15 GMT+1 óra  
Bár ez már csak részben kapcsolódik ide, materialkezelés:

Unity esetén a material egy adott shadert használ, azoknak módosíthatjuk a paramétereit, de maguk az elérhető paraméterek a shaderben definiáltak.

UE4 esetén pedig maga a material definiál egy shadert is, így minden egyes materialhoz külön shader készül. Mármint amelyek nagyon különböznek, mert ott van az instancing materialok esetén is.

Végső soron a kettő elég hasonló, van egy base (shader), és van hozzá lehetséges override (material). A problémám ott kezdődik, hogy GPU skinning esetén máris duplázni kell a shadert, mert más a vertex transform, mások lesznek a uniform location-ök is, stb.

Apropó, a uniform helyét lekérni (glGetUniformLocation) költséges dolog?

   
Instalok - Tag | 607 hsz       Online status #208701   2015.11.26 14:50 GMT+1 óra  
Na igen, mondjuk az is kérdéses, hogy ez szokott-e a szűk keresztmetszet lenni. Nagy híve vagyok a deferred shading rendszereknek, és ott általában a textúrák írása a megterhelő, nem a bemenő adatok átpasszírozása.

   
Asylum - Törzstag | 5484 hsz       Online status #208699   2015.11.26 13:45 GMT+1 óra  
Külön VBO-ba ne pakolj...ezen speciel nincs ertelme sporolni...inkabb hasznald ki optimalisan a memoriat es a shader egysegeket (vcache optim, static batching ahol lehet, state management, stb.). Azok hoznak lényeges teljesítményjavulást.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #208698   2015.11.26 13:26 GMT+1 óra  
Én teljesen kihasználom a shader reflectiont - erre épül a saját API-m is.

Az alkalmazás létrehoz N db VBO-t megmondja milyen attribok vannak benne (név, méret).
A shader pedig megmondja milyen attribokra van szüksége (név, méret).

Amikor először találkozik a shader a mesh-sel a shader megnézi a mesh VBO-it és hogy azok tartalmazzák-e a neki szükséges attribokat. Ha több attrib van a VBO-kban az nem baj ill. mindegy melyik attrib melyik VBO-ban van.
alias aalberik
   
Instalok - Tag | 607 hsz       Online status #208697   2015.11.26 13:09 GMT+1 óra  
Szerintem ilyenekkel nem fogok trükközni, maradnak a külön VBO-k.

Az eddigi rendszer annyi volt, hogy, ha volt egy Mesh, akkor készítettem hozzá egy VBO-t. Azt, hogy abban milyen adatok vannak, maga a Mesh döntötte el. Tipikusan csak 2 fajta volt: egy a lentebb említett struktúrával, meg egy másik, amiben a csontanimhoz tartozó információk is voltak. Illetve volt egy külön is, amit full-screen quad rendereléshez használtam, abban csak pozíció és uv volt.

Ezután rajzoláskor átadtam paraméterként, hogy jelenleg melyik shader az aktív, és az milyen attribútumokat vár. Ez alapján beállítottam az attribútumokat. Régi kód:
Kód:
void DrawBuffer::beginDraw(const Effect* const _effect) const
{
    glBindBuffer(GL_ARRAY_BUFFER, vbo);
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);

    for (Effect::Attributes::const_iterator it = _effect->getAttributes().begin();
         it != _effect->getAttributes().end(); ++it)
    {
        VertexElement* const v = elements[it->first];
        glVertexAttribPointer(v->usage, GL::VertexAttribSize[v->type], GL::VertexAttribType[v->type],
                              GL::VertexAttribNormalized[v->type], vertexSize, GL_OFFS(v->offset));
    }
}

Ahol a v->usage egy olyan enum, amiben azt tárolom, hogy ez most pozíció, vagy normál, vagy miféle adat, a többi meg értelemszerű.

Mivel azt mondtad, hogy ezzel nem lehet spórolni, így a következő módosításon gondolkoztam:

A Mesh nem csak egy VBO-t tárol, hanem VertexLayout-hoz tartozó VBO-kat. Azaz, ha hozzáadok egy Mesh-t a jelenethez, akkor már tudnom kell, hogy az milyen shaderrel lesz kirajzolva, hogy annak lekérhessem az attribútumait. Miután ez megvan, megnézem, hogy van-e már ilyen VBO, ha nincs, akkor készítek egyet, ha van, akkor használom azt.

Maga a VBO létrehozása is trükkösebb, mert az adott layout alapján kell a megfelelő vertex struktúrát kiválasztani, abból elkészíteni az arrayt, és azt feltölteni a VBO-nak.

Ezzel viszont picivel jobban oda kell figyelni runtime material (vele együtt akár shadert) váltáskor, meg egyéb esetekben.

Valahogy így gondoltad? Valószínűleg std::map-et használnék, hogy rajzoláskor is gyorsan megtaláljam a megfelelő VBO-t a kívánt shader layout-ja alapján.

   
syam - Törzstag | 1491 hsz       Online status #208696   2015.11.26 12:38 GMT+1 óra  
Azon tudsz még spórolni, hogy amit lehet nem 4 hanem 2 vagy 1 byte-on tárolsz (ilyen tipikusan a normál v tangens). De minden adatot lehet kvantálni és eldönteni, hogy mennyi biten tudod tárolni. Emiatt is születnek a bizarrabbnál bizarrabb vertex attrib formátumok.
alias aalberik
   
Instalok - Tag | 607 hsz       Online status #208695   2015.11.26 12:02 GMT+1 óra  
Hát, akkor sajnos sávszélen nem lehet ezzel spórolni. Igen, gondolkoztam azon is, hogy akkor külön VBO-ban lesznek az adatok.

A külön VBO megoldásnak meg ugye annyi a hátránya, hogy előre ismerni kell, hogy a shadernek milyen attribute-jai lesznek. Ami nyilván nem megoldhatatlan, de az a megoldás nekem szebbnek tűnt, hogy elég csak rajzoláskor tudni, hogy éppen milyen shadert használunk.

Egyébként bonyolultabb technikáktól, illetve extrém körülményektől eltekintve, inkább pazarlok memóriát, mint sávszélességet. Az előbbiből több van.

   
syam - Törzstag | 1491 hsz       Online status #208694   2015.11.26 11:47 GMT+1 óra  
Tudtommal stride mennyiségű adat fog átmenni a buszon.
Ezt azzal tudod áthidalni, hogy több VBO-ban tároldod az attribokat, de abból meg kevésbé szeret olvasni.

Azt szokták javasolni, hogy különböző variációkban tárold a VBO-t.
Egyik leggyakoribb, hogy pl shadow renderhez sokszor elég a pozíció (+ néha UV) ehhez külön VBO. Egy másik VBO-t pedig "rendes" renderhez pozíció, UV, normál stb.
Memóriapazarló, de optimális a sávszélnek.

Ja és a pozíció mindig legyen az első attrib, mert sok gyártó erre optimalizál (pl. AABB számolás driver oldalon és egyéb agyrémek).

"Kirajzoláskor pedig fogom és az adott shadert figyelembe véve állítom be" - bizony mindig használd a shader reflectiont.
alias aalberik
   
Instalok - Tag | 607 hsz       Online status #208693   2015.11.26 11:16 GMT+1 óra  
Van egy struktúrám, amiben benne vannak olyan információk, mint a pozíció, uv, normal, tangent, és ebből van egy tömböm, ami leírja a vertexeket. Létrehozok egy VBO-t, majd feltöltöm az adatokat (glBufferData). Kirajzoláskor pedig fogom és az adott shadert figyelembe véve állítom be az attribute-okat (glVertexAttribPointer). Azaz, ha egy shadernek csak pozícióra van szüksége, akkor csak egyszer hívom meg ezt a függvényt.

A kérdésem a teljesítménnyel kapcsolatban lenne. Mivel a videómemóriába fel van töltve a teljes adat (a normal meg a tangens is, akkor is, ha nem használom), így memória szempontjából nem túl takarékos, ezt értem. Viszont mi van a sebességgel? Nyerek egyáltalán valamit azzal, hogy csak bizonyos attribute-okat használok, vagy onnantól kezdve mindegy, hogy a videókártya memóriájában van? Gondolom az azért nem mindegy, hogy mennyi adatot passzírozunk át a csövön.

   
Lord_Crusare - Törzstag | 1317 hsz       Online status #208456   2015.10.13 19:00 GMT+1 óra  
A kiejtés egész pontosan "juniti". Ezért nincs olyan, hogy "az unity", hanem "a unity".

   
Asylum - Törzstag | 5484 hsz       Online status #208455   2015.10.13 18:25 GMT+1 óra  
Mi junity-nak mondjuk
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Geri - Törzstag | 2196 hsz       Online status #208454   2015.10.13 13:44 GMT+1 óra  
mikroszoft, unití, jáva, vindovs

   
Instalok - Tag | 607 hsz       Online status #208452   2015.10.13 13:35 GMT+1 óra  
Ha már off: az is siralom, ha valaki a Unity-t "az Unity"-nek írja. Hogy ejted ki? Uniti? Egyébként örülök, hogy írtál erről is cikket, anno engem is foglalkoztatott a PBR. Elég tömény mateknak tűnik, szóval még nem ugrottam neki, na de majd egyszer.

   
zeller - Törzstag | 487 hsz       Online status #208451   2015.10.13 12:53 GMT+1 óra  
Na ja. Az unity egy siralom. De ez offtopic. Csak muszaj volt belerugnom

   
Asylum - Törzstag | 5484 hsz       Online status #208449   2015.10.13 07:59 GMT+1 óra  
Szerintem a PBR önmagában nem változtatja meg azt a tulajdonságot, hogy egy enginet ránézésre felismerj. Főleg a hibás implementációk miatt (Unity), vagy az ütős realtime GI miatt (Frostbite). Az UE4-nek is megvan a maga jellegzetessége (sok specular highlight).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
FZoli - Szerkesztő | 4893 hsz       Online status #208448   2015.10.13 06:22 GMT+1 óra  
Nem kívántam tovább érvelni ellened, mert a tapasztalat azt mutatja, hogy nincs értelme, de azért csak hozzászólom még ezt, tisztázandó, hogy nem azért nem írtam, mert pl. elakadt a szavam az elméd ereje felett, mint ahogy te gondolnád.

A kiindulópont az volt, hogy a PBR miatt vannak felismerhető hasonlóságok, erre jöttél h mióta van 3d gyorsítás, azóta a játékok kinézete ezen múlik. Erre mondtam h ez szerintem már túlzás, de ezt elvontan te is megfogalmaztad, magad cáfolva:

minnél közelebbi leszármazási vonalat vizsgálunk, annál jobban hasonlítanak, és minnél távolabbit vizsgálunk, annál kevésbé.

Legyen ennyi elég.

   
Geri - Törzstag | 2196 hsz       Online status #208445   2015.10.12 16:08 GMT+1 óra  
minnél közelebbi leszármazási vonalat vizsgálunk, annál jobban hasonlítanak, és minnél távolabbit vizsgálunk, annál kevésbé.

egy emlős gerinces, és egy nem emlős gerinces is máshogy néz ki, de valamennyire azért hasonlítanak.

egy gerinces, és egy gerinctelen állat is máshogy néz ki.

és pl egy oxigént lélegző, egy széndioxidot lélegző, és egy nitrogént lélegző életforma már teljesen máshogy néz ki.

egy másik bolygó élőlényeit pedig igencsak nehezen fogjuk tudni észrevenni, főleg, ha nem is szén-alapúak. a te példád is az én gondolatmenetemet igazolja.

   
FZoli - Szerkesztő | 4893 hsz       Online status #208444   2015.10.12 14:36 GMT+1 óra  
nah ezzel viszont nem értek egyet. Attól még, hogy ugyanaz az api, még nagyon messze vagyunk a kinézettől.

Ennyi erővel a raszterizált megjelenítők is meghatározzák a kinézetét a játékoknak, de így még sem kategorizálunk. Mintha azt mondanád, hogy minden földi életforma azonos, csak mert szénalapú.

   
Geri - Törzstag | 2196 hsz       Online status #208443   2015.10.12 14:11 GMT+1 óra  
fzoli: a 3d gyorsítás a játékok kinézetét egyértelműen meghatározza, mert ugyanazon apik alatt futnak, amik alapvetően ugyanúgy renderelnek. ~1996 előtt, tehát a 3d éra előtt sokkal nagyobb volt a grafikai diverzitás.

   
FZoli - Szerkesztő | 4893 hsz       Online status #208442   2015.10.12 13:42 GMT+1 óra  
Azért az én megfogalmazásomban is ott van, hogy hasznos, meg hogy csak picit öli ki Tényleg jobb vele dolgozni, viszont ma annyira minden rápörögtt a PBR-re, szinte csak post effektekben térnek el, pedig azért egy Sourceot egy Doom III enginetől mennyire meg tudtál különböztetni pl. hiába a festett hatású textúrák és a kontúros ábrázolás a Wowban, vagy a fotoreál textúrák BF3-ban, meg a teljesen más tonemapping ha a fényezési modell csattra ugyanaz, akkor ott motoszkál az érzés, mint amikor látsz egy játékot és "tudod" róla, hogy nna, ez Unity. Hiába más a model stíllusa vagy a textúra, süt róla, felismered. De persze lehetek egyedül a véleményemmel

   
Asylum - Törzstag | 5484 hsz       Online status #208439   2015.10.12 12:54 GMT+1 óra  
Nem öli ki, ez olyan mintha azt mondanád, hogy "ami fotorealisztikus az nem egyedi". Maga a PBR önmagában nem fotorealisztikus, ugyanúgy lehet használni az algoritmust egy WoW-ban mint egy BF3-ban. A munkafolyamatot könnyíti inkább, mert amit megcsinálsz egy nappali pályához az egy esti pályán is jól fog kinézni.

Nem vagyok földönkívüli
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
FZoli - Szerkesztő | 4893 hsz       Online status #208436   2015.10.12 08:27 GMT+1 óra  
Csak most tévedtem id,e szép munka, szépen összegyűjtötted és elég jól végig is veszi a cikk, grat! Anno mikor én beleástam magam, több nap volt az irodalmazás, és hegyekben álltak a jobb roszsak könyvjelzők... különösen amikor opptimalizálni szerettem volna... azátn rá is hagytam az U5-el, meg aztán kicsit félre is tettem, emrt iszonyatosan hasznos, csak meg van az a hátránya, hogy picit kiöli az egyediséget a kinézetből.

   
Viperion - Tag | 540 hsz       Online status #208435   2015.10.12 01:32 GMT+1 óra  
Asylum az a matek ott emberfeletti.
Soha nem értettem és nem is fogom.
Szerintem azok akik értik is azok földönkívüliek. Asylum te is az vagy.

   
Asylum - Törzstag | 5484 hsz       Online status #208423   2015.10.07 13:02 GMT+1 óra  
Nem tudok sűrűbben cikket írni mert baromi sok meló : / (ez is két hónap volt)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
zeller - Törzstag | 487 hsz       Online status #208420   2015.10.06 17:32 GMT+1 óra  
Jo cikk. Az elejebe tehettel volna tobb abrat a kepletekhez. Regen volt mar...

   
Asylum - Törzstag | 5484 hsz       Online status #208378   2015.09.28 20:44 GMT+1 óra  
Köszi, csak annyit szeretnék kérni, hogy a blogbejegyzésre (amit ide beraktam) mutasson a link, mert ott számolja a statisztikát
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2526 hsz       Online status #208375   2015.09.28 18:41 GMT+1 óra  
Done.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Lord_Crusare - Törzstag | 1317 hsz       Online status #208369   2015.09.28 11:56 GMT+1 óra  
Fú, köszi, ez baromi hasznos!

   
Asylum - Törzstag | 5484 hsz       Online status #208367   2015.09.28 10:11 GMT+1 óra  
Physically based rendering cikk:

http://darthasylum.blog.hu/2015/09/28/physically_based_rendering

Ha most visszaemlékszem arra, hogy annak idején milyen cikkek voltak itt az oldalon a Phong modellről, akkor ezt a technológiát egy újabb mérföldkőnek kell tekintem, sőt ez kellene hogy az új generáció standardja legyen innentől kezdve (a látszólagos nehézsége ellenére).

Lenne szíves valaki befrissíteni a blogszemlét? Szerintem ez megér annyit
Thx
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #207097   2015.03.17 13:35 GMT+1 óra  
Következőre már az lesz írok egy sajátot aztán tudom mi hol van honnét hova megy a sin meg a cos. Tegnap már átnéztem kézzel hogyan lehet forgatni 1-1 tengelyen. Kicsit tovább fog tartani, de 2D-be is írtam saját Vector2 osztályt és minden működött vele.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Asylum - Törzstag | 5484 hsz       Online status #207093   2015.03.16 22:24 GMT+1 óra  
Idézet

Lényegében rossz a forward.



Mert rossz oldalról szorzod...

Szvsz a jf ott kezdődik hogy saját matlibet írsz és nem hagyatkozol ilyen nem egyértelmű szarokra (glm ugyanilyen fos).

Ezt a hozzászólást Asylum módosította (2015.03.17 13:55 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #207087   2015.03.16 13:47 GMT+1 óra  
Nah igen ez a yaw, pitch, roll kamera kell nekem. De beírtam Asylum a kodod és hát nem igazán szuperál. Vmit még mindig elcseszek. Ja és OpenTK-t használlok, de ugyanaz mint a gl kb. Itt a kód:

Kód:
Matrix4 perspective = Matrix4.CreatePerspectiveFieldOfView(1.0f, Width / Height, 0.01f, 2000f);
GL.MatrixMode(MatrixMode.Projection);
GL.LoadIdentity();
GL.MultMatrix(ref perspective);

Matrix4 view = Matrix4.Identity;
view = Matrix4.Mult(view, camera.MatrixFromYawPitchRoll(camera.Yaw, camera.Pitch, camera.Roll));
camera.Forward = Vector3.Transform(new Vector3(0,0,-1), view);
camera.Position += camera.Forward / 10f;
view = Matrix4.Mult(view, Matrix4.CreateTranslation(camera.Position.X, camera.Position.Y, camera.Position.Z));

GL.MultMatrix(ref view);
GL.MatrixMode(MatrixMode.Modelview);
GL.LoadIdentity();


Azt csinálja hogy folyamat megy a Z tengelyen, de akármerre yaw-olok meg rollozok,.. mindig a Z tengelyen megy ugyanabba az irányba a kamera. Lényegében rossz a forward.
Instalok a te módszeredet még nem igazán próbáltam.

ui. a forgatós kodot innét vettem: http://www.opentk.com/node/3758 (ezt csak bemásoltam ránézésre nem igazán akartam megérteni )
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Asylum - Törzstag | 5484 hsz       Online status #207078   2015.03.15 22:27 GMT+1 óra  
Rossz oldalról közelíted meg...ha jól értem spectator kamerát akarsz (bár egy repülős játékhoz miért pont azt?), persze arra is lehet használni a lookat-ot csak nincs értelme. Milyen matlibet használsz?

Kód:
mat4 view = rotate(yaw, pitch, roll);
vec3 forward = view * vec3(0, 0, -1);

eyepos += forward * speed;
view = translate(eyepos) * view;
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #207073   2015.03.15 19:11 GMT+1 óra  
Csinálhatsz egy olyat, hogy készítesz egy orientation matrixot, amiben eltárolod a forgatást. Majd, ha megvan, hogy a középponttól mennyire szeretnéd látni a modellt, akkor eltranszformálod azt a vektort ezzel az orientation matrix-szal, valami ilyesmi:
Kód:
orientation.yawPitchRoll(rotate);
eyePosition = position + Vector3::transform(eyeOffset, orientation);

Majd ezzel már tudod használni a lookAt függvényt.

   
Bukta - Tag | 308 hsz       Online status #207072   2015.03.15 18:32 GMT+1 óra  
Okés köszönet, de az a forgatás akkor is kell a repcsi irányításához :/ . Van a kamera pos, meg van a target, és a targetet a kamera körül kéne mozgatni. De akárhogy csinálom mindig az origo körül mozgatja.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Instalok - Tag | 607 hsz       Online status #207069   2015.03.15 17:33 GMT+1 óra  
Van külön mátrix erre, amit te számolsz, az a world mátrix A view mátrixra nézd meg a lookAt nevűt. Ennek van 3 pozíciója: hogy honnan nézel, mit nézel, és mi a world up.

   
Bukta - Tag | 308 hsz       Online status #207068   2015.03.15 17:17 GMT+1 óra  
view = identity;
view = scale*rotate*translate;
Így és azem ez a jo sorrend. de csak forgatom. scale nem játszik.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Asylum - Törzstag | 5484 hsz       Online status #207067   2015.03.15 16:15 GMT+1 óra  
Hogyan számolod ki a view mátrixot?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Bukta - Tag | 308 hsz       Online status #207065   2015.03.15 15:58 GMT+1 óra  
Üdv

Jó régen forumoztam már itt, ugyhogy elejtek egy kérdést 3D-s repülős játékot akarok készíteni. Viszont már az elején elakadtam :/ megcsináltam a sík pályát -később domborzatot is- de a kamera mozgatás nem megy. Azt akarom h ha nyomom az előre gombot akkor a kamera menjen előre (arra amerre néz). Viszont akkor tudni kéne az irányvektort. Volt pár 5letem, de nem jöttek be. Nektek biztos nem nagy varázslat ezt megoldani .

Előre is kösz!
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Instalok - Tag | 607 hsz       Online status #207003   2015.03.12 11:35 GMT+1 óra  
Idézet
Asylum :
ui.: még jó hogy elolvastam, én is rájöttem egy kurvanagy marhaságra az engineben


Szívesen!

   
Asylum - Törzstag | 5484 hsz       Online status #207002   2015.03.12 10:10 GMT+1 óra  
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Dark_Secrets_of_shader_Dev-Mojo.pdf

ui.: még jó hogy elolvastam, én is rájöttem egy kurvanagy marhaságra az engineben

Ezt a hozzászólást Asylum módosította (2015.03.12 10:32 GMT+1 óra, ---)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 607 hsz       Online status #206990   2015.03.11 19:14 GMT+1 óra  
Igazából csak a lentebb említett problémáim vannak. Egyébként nem tudom elképzelni, hogy nagyon lassítana az, hogy éppen a vec3-nak melyik konstruktorát használom, illetve, hogy változóból kap-e értéket. A többit a szerény GLSL tudásomnak megfelelően írtam meg.

   
syam - Törzstag | 1491 hsz       Online status #206989   2015.03.11 18:21 GMT+1 óra  
Mi pontosan az a "mikre"?
alias aalberik
   
Instalok - Tag | 607 hsz       Online status #206988   2015.03.11 18:11 GMT+1 óra  
Van valahol valami tips & tricks gyűjtemény, hogy mikre érdemes ilyenkor figyelni?

   
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]