|
|
Thx, gl, asszem igazad van
Ezek szerint alapértelmezett, hogyha a textúrám szürkeárnyalatos
Kipróbálom, azt ha nem megy, akkor fpeti kulcsszava + google
Szerk.: Vagy lehet, hogy a szín értékeit beszorozza a textúra értékeivel, És így hozza létre, és alapból ugye a fehér szín miatt jelenik meg a textúra változatlanul
Szerk2.: Igen, ebben az esetben át kell alakítani a textúrámat, hogy minden szín fehér legyen, az alpha pedig a megnyitott képnek megfelelő, így lehet majd színezgetni
Ezt a hozzászólást Joga módosította (2008.07.28 03:07 GMT+1 óra, ---)
|
|
|
Idézet Joga :
Részecskerendszereknél szoktam látni, hogy egy részecskének az alphamapját( fehér: 1.0 alpha..Fekete: 0.0 , szürke 0.5, stb ) Nyitják meg textúraként, majd ezt valahogy a kiválasztott színnel kombinálják ( glColor3f )
Ilyet hogyan kell csinálni, mit kell beállítani?Esetleg nem tud valaki egy kis leírást?
per-pixel alpha blending-nek hívják ezt talán.. csak DX-ben tudom, hogy kell, de hátha rá tudsz ezzel keresni.
|
|
|
Nem egészen értem mire gondolsz, de olyan van, hogy egy szürkeárnyalatos képet töltesz be textúraként és azt használod. Akkor ha a poly kirajzolása előtt a színt pirosra állítod pl, akkor ahol a textúrán fehér van ott lesz teljesen piros, ahol fekete ott ugye fekete. Ez az alapértelmezett működés. De át is lehet állítani a glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, xyz); fgv-vel. (xyz lehet pl GL_MODULATE, az az alap).
Ha baromságot mondtam, valaki javítson ki.
Ezt a hozzászólást gaborlabor módosította (2008.07.27 14:00 GMT+1 óra, ---)
|
|
|
Részecskerendszereknél szoktam látni, hogy egy részecskének az alphamapját( fehér: 1.0 alpha..Fekete: 0.0 , szürke 0.5, stb ) Nyitják meg textúraként, majd ezt valahogy a kiválasztott színnel kombinálják ( glColor3f )
Ilyet hogyan kell csinálni, mit kell beállítani?Esetleg nem tud valaki egy kis leírást?
|
|
|
Próbálta már valaki az OpenGL Window Framework nevű találmányt?
GLUT-ból elegem lett, mert nem lehet normálisan kilépni a mainloopból, freeglutban van glutLeaveMainLoop() de az meg hibát dobott, mi szerint inicializálást előtt akartam kilépni a hurokból... Na akkor telt be a pohár, elolvastam beast cikkeit meg a NeHe-s tutorialt, a kettőből összehegesztettem valamit, ablakos módban működik, fullscreennél elszáll a prog.
Arra gondoltam, minek szívni az ablakozás megírásával, biztos írtak már rá valami elegáns megoldást mondjuk egy osztály formájában, és azt találtam, amit fentebb linkeltem. A feature listája egész szép.  Ha nincsenek vele kapcsolatban negatív tapasztalatok akkor közelebbről is megnézem, mert 1. ránézésre nagyon bejövős.
|
|
|
Örülök, hogy összejött. 
ezzel a vistával csak a gond van...
|
|
|
Idézet gaborlabor :
Nem saját kódja van, hanem pl PhysX sample. Meg legújabb driver. (lásd physx topic)
Rákerestem Google-ban, és ezt találtam:
http://www.opengl.org/pipeline/article/vol003_7/
Én nem olvastam végig, de ír erről a problémáról is. Elsőnek megpróbálnám kikapcsolni az Aero-t.
Hát öcsém tökön döföm magam.  
Kilőttem a feladatkezelőben a dwm.exe-t és már megy is.
Nem gondoltam volna hogy csak ennyi az egész.
Örök hála..
|
|
|
Nem saját kódja van, hanem pl PhysX sample. Meg legújabb driver. (lásd physx topic)
Rákerestem Google-ban, és ezt találtam:
http://www.opengl.org/pipeline/article/vol003_7/
Én nem olvastam végig, de ír erről a problémáról is. Elsőnek megpróbálnám kikapcsolni az Aero-t.
|
|
|
forráskód?
Szerk.: Ha beraksz valami tárgyat, akkor megy?
Lehet, hogy bekapcsoláskor nem törlöd le egy színnel az egészet, ezért oloyan, mintha átlátszó lenne
|
|
|
Hi,
Lenne nekem egy érdekes problémám.
Az OpenGL-es samplek nem működnek megfelelően.
Megnyílik a windows-os ablak és tök átlátszó a keret kivételével.
íme: Screenshot
|
|
|
Thx
Szerk.: Találtam egy példaprogramot is
offset.c
Ezt a hozzászólást Joga módosította (2008.05.06 10:38 GMT+1 óra, ---)
|
|
|
Íme az én (valszeg favágó) módszerem:
Először kirajzolod rendesen. Aztán
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
Meg feketére állítod a színt, és akkor szerintem nem is kell kikapcsolni a textúrázást, úgyis fekete lesz.
És kirajzolod mégegyszer.
Lehet, hogy z-fighting lesz belőle. 
De ha kikapcsolod a depth testet (glDisable(GL_DEPTH_TEST)), akkor az azért nem jó, mert akkor az összes éle látszani fog. (Egyébként a glDepthFunc-al lehet szabályozni a depth test működését.)
Én ezt próbálnám ki:
glPolygonOffset
szerk.: az "OpenGL röviden"-ben van egy példa, ami pontosan azt csinálja, amit te szeretnél, asszem valami tölcsért vagy mit rajzolnak ki így. A könyvem nincs itthon, nem tudok belenézni, de ha jól rémlik, ők is a glPolygonOffset-et használják.
|
|
|
Azt hogyan lehet megcsinálni, hogy egy testet úgy rajzjak ki, hogy az élei feketék legyenek?..Szóval én először arra gondoltam, hogy kirajzolom a testet( GL_QUADS, stb ), aztán meg az éleket ( GL_LINE_LOOP ), de ilyenkor elvileg a depth buffer miatt van, amikor a látom a vonalat, van amikor nem, ha jól tudom
vagy be lehet állítani, hogyha a depth bufferben egyezés van, akkor is rajzolja ki azt, amit akarok, vagy ez mindig véletlenszerűen, vagy előre meghatározott módon van?
|
|
|
Azóta kommenteztem a wglCopyContextes részt, most már ment mind2 kontexttel a dolog a suliban, itthon viszont a Voodoo3-mal kék halál lett, és szintén 0 hivatkozás... sajnos így nem tudok debuggolni, hogy egyből kék halál lesz, mindenesetre gyanítom, hogy kb akkor, mikor csinálom az új contextet... a neten kerestem, de nem találtam olyan példaprogit, ami csinálna 2 ablakos, 2 rc-s rendszert...
|
|
|
Kössz kicsy.
|
|
|
Kösz, ezzel sikerült megoldani.
|
|
|
Ezt a hozzászólást kicsy módosította (2008.04.11 07:44 GMT+1 óra, ---)
|
|
|
Hello!
Opengl-ben hogyan tudom beállítani a kép (vagy monitor) frissítési frekvenciáját? És még azt is lekéne ellenőrizni, hogy a monitor milyen frekvenciát támogat, mert pl sima crt-re 85 Hz-et, de egy LCD -re csak 75 Hz-et szeretnék beállítani. Ja és nem GLUT-ot használok, hanem simán hozom létre a windows ablakot.
|
|
|
Hello!
A hajam égnek áll már! 
Továbbra is a rendering contextes problémával szenvedek.
Előzmény: szerettem volna, ha futás köben bármikor lehetett volna új ablakot csinálni. Persze több ablakhoz is lehet ugyanazt az RC-t használni, de én külön RC-t szeretnék minden ablakhoz, hogy pl. ha más beállítást adok a másik ablakhoz, pl. ott már legyen élsimítás, akkor tényleg különbözzenek.
Na most, ha utólag csinálok RC-t, akkor azzal az a baj, hogy úgy lenne szép, ha megosztanám a textúrákat. Itt eleve bukik a dolog, mert a wglShareLists csak akkor működik jól, ha az elején hívod meg, tehét még 1 textúrád sincs. Ja és persze további kritérium, hogy a 2 rendering contextnek ugyanaz a pixel formatja legyen, pedig én pont azt akarom, hogy különböző is lehessen.
Gondoltam jó, egye-fene, mikor csinálok új RC-t, akkor fájlokból újra megcsinálom oda is a textúrákat. Otthon ment is, de itt suliban egyszerűen egy alap dolognál bukik el a dolog. Itt egy Geforce 6150 IGP van, és a wglCreateContext()-re másodszorra se NULL-t ad, tehát elvileg létrehozza a másik kontextet, DE amikor a wglCopyContext()-tel átmásolnám az első RC beállításait a 2.RC-be, akkor sok0000011-es memóriacím-hivatkozással elszáll az nvoglnt.dll. Tehát valami NULL hivatkozás van, valami osztálypéldány vagy strukt lehet, ami gondolom 0, a 11 meg a taghivatkozásból adódó offszetcím. Na mindegy, nálam nem NULL semmi,mert külön ellenőrzőm is. Ma megnézem, hogy mi történik Voodoo3-mal.
Valami ötlet, hogy lehetne még ezt jól megcsinálni?
Vagy valakinek ha van egy 2 RC-s progija, ami 2 ablakba rajzol, megdobhatna vele, hogy kipróbáljam a suliban... talán a driver defektes, de mivel nem vagyok rendszergazda, meg sem próbálhatom a drivercserét.
|
|
|
Elvilag ez nem jelenthet neki gondot, mert hát maga a parancs pont normalokra van kitalálva.
Mindegy, egyenlőre félre tettem, és maradtam sima Vertex Array-nél.
EDIT:
Na átalakítottam az egész extenson rendszert, egyszerűbb lett, és ennek hozományaként az ARB_vertex_buffer_object is átalakult, most működik.
Csak át kellett nézni az alapokat, mindig megfogadom, hogy nem dolgozom előre megírt kóddal, na tessék, csak át kellett írni.
Ez a sor eddig nem is szúrt szemet, és fogalmam sincs így utólag, hogy miért van belerakva.
Kód: #define GL_ARRAY_BUFFER_ARB 0x8892
#define GL_STATIC_DRAW_ARB 0x88E4
typedef void (APIENTRY * PFNGLBINDBUFFERARBPROC) (GLenum target, GLuint buffer);
typedef void (APIENTRY * PFNGLDELETEBUFFERSARBPROC) (GLsizei n, const GLuint *buffers);
typedef void (APIENTRY * PFNGLGENBUFFERSARBPROC) (GLsizei n, GLuint *buffers);
typedef void (APIENTRY * PFNGLBUFFERDATAARBPROC) (GLenum target, int size, const GLvoid *data, GLenum usage);
Na gondoltam megosztom ha esetleg valaki találkozik hasonlóval a Nehe VBO tutor kapcsán, mert az tökéletesen működik, amig nem dolgozod bele a normalokat.
Ezt a hozzászólást DMG módosította (2008.03.22 15:18 GMT+1 óra, ---)
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
én még nem láttam ilyet bár én már csak vertex attributumokkal dolgozok;
talán az lehet a gond, h a normal csak 3 komponensű lehet (de ha vertex attribként adom meg akkor ilyen probléma nincs) és a stride bekavarhat...
alias aalberik
|
|
|
Tud esetleg valaki olyanról, hogy a GL_ARB_vertex_buffer_object-nek valami problémája lenne a Normálisok leképezésével?
Ugyanis 1.3-as OpenGL-ben csak ezt tdom használni tudomásom szerint VBO-ra, és amint engedélyezem a Normal leképezést a progam elszáll egy futásidejű hibával.
Leellenőritem többszőr is, telejsen ugyan azt a sémát követi a normálisaok tárolása, mint a textúra pontoké, vagy a vertexeké,és mégsem, VBO nélkül tökéletesen leképezi VBO-val lerohad.
Valaki esetleg találkozott már ezzel?
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
Hát akkor első körben marad a redundancia, mert 2.x-re azért nem szeretném lekorlátozni a fejlesztést.
Aztán idő közben hátha megvilágosulok.
Kösz az infókat.
H aez most a prog.hu lenne, menne a pont
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
amit írtam módszer tényleg nem hatékony
a vertex array az kliens oldalon van, tehát rendszermemóriában, a vertex buffer van szerver oldalon, tehát a video memoriában;
a redundancia abban az esetben jelent hátrányt, ha cpuval akarsz vmit számoltatni (pl. animálás), mert akkor uazt a vertex poziciot többször kell kiszámolni;
a 64/128 mega vram pedig bőveeeen elég:]
alias aalberik
|
|
|
Viszont a nagy könyv szerint a glBegin glEnd párosítás a lehető legrosszabb a sebesség szempontjából.
Viszont ha tényleg ezt választanám, akkor sem nagyon értem ennek a módját.
Viszont halottam, hogy mivel a Vertex Array úgyis memóriába töltődik, így nem kell foglalkozni a redundanciával, mert hát van elég memória, ez esetben nem is lene gond, csak a VBO meg a videó memóriából vesz el ha jól tudom, az meg azért végesebb mint a RAM.
Szóval, mit javasolsz, érdemes a redundancia kiküszöbölésével szórakozni, vagy törődjek bele?
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
hmm,
hát van 1 nyakatekert megoldás:
az opengl egy indexellel címzi meg az összes arrayt (vertex,texcoord etc), ha ha gldraw... parancsot használsz;
ha azonban glbegin és glend között rajzolsz, akkor a glvertexpointered (és minden más ami együtt indexelődik vele) lehet array és glarrayelementtel hivatkozol rá viszont minden mást manuálisan kell átadnod
alias aalberik
|
|
|
WOW
Amúgy meg már megörültem kora reggel, hogy érkezett válasz a problémámra.
EDIT: Tyű és ezzel a posttal most meg is bontottam az egyenletet.
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
off:
WOW: syam hsz == DMG hsz (387-387 hozzászólás  )
|
|
|
Kéne egy kis help.
Most kezdtem el tüzetesebben foglalkozni, a VBO-val, meg a hasonló vertex buffer területtel, és most döbbentem rá, hogy ahhoz, hogy az objektumot rendesen ki tudjam rajzolni glDrawElements-el, ahhoz minden egyes pontot redundánsan kell tárolnom, ha több normal, vagy több textura adatot akarok használni rajta.
Egyből rágugliztam, és olvastam is, hogy 1.x-ben iez van tessék szeretni, mert ez nekünk jó. és a multi indexeket csak 2.x tudja.
Na van esetleg erre valami trükk, hog yne kelljen redundáns adatokat tölteni a bufferbe, vagy agyaljak rajta?
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
ha jol tudom oglben ez is hasonlóan müködik, tehát mindegyik color buffer vagy fixed vagy float és mindegyikre uaz a maszkolás és blendezés vonatkozik - gf8nál van lehetőség külön maszkolásra és blendezésre
"akkor (általában) egyszerre 4 szín bufferbe tudsz renderelni" - a framebuffernek manapság nem csak 1, hanem max. 4 szín buffere lehet; ez tulajdonképpen a MRT, tehát egy PBuffer/FBO van, de ahhoz több színbuffer tartozik
alias aalberik
|
|
|
EZ DX alatt is így van, ott a külön buffereket Render Targeteknek hívják és ha egyszerre többe is akarsz képet rajzolni akkor azt meg Multiple Render Targetnek (MRT). DX9-nél meg asszem már alapból elvárás h tudja a kártya a NPo2 méreteket kezelni. Amire viszont figyelni kell (ez OGL alatt nemtudom hogy így van e, tehát ez részben kérdés is), hogy a jelenlegi kártyák (Geforce6-om legalábbis biztos) nem tudnak egyszerre különböző bitmélységű buffereket (render target-eket) használni -> Pong-omnál akartam MRT-t használni és 1 menetben kirajzolni glow-t, diffuse color-t és velocity-t is, ez utóbbit Vector4 formában (gondolom 64 bites, de XNA-ban már más a jelölés mint DX-ben) míg a többit Color (normál 8bit-4 csatorna felállásban) formátumban, és egy nagy fekete semmit kaptam.
OGL-nél egyszerre FBO-kba lehet több helyre is rendeleni? Ez most a leírásod alapján nekem nem volt tiszta ("akkor (általában) egyszerre 4 szín bufferbe tudsz renderelni" by syam).
|
|
|
hmm,
mivel manapság szinte már-már kötelező vmilyen post process technikát használni ezért min. pbuffert használnak; ezenkívül még van FBO, de sajnos az "még nem minden kártyán tud mindent"
ha a kártya támogatja a NPOT méretű textúrákat, akkor teljesen mértékben a képernyő felbontásával egyező buffert tudsz készíteni és felhasználni textúraként sőt ha ARB_draw_buffersed is van, akkor (általában) egyszerre 4 szín bufferbe tudsz renderelni, mint1 multitextúrába renderelés
ha pedig valódi HDR-t szeretnél, ami mindenképp post processt igényel akkor pedig float texture-t kell választanod
már csak az a kérdés, h miért lassabb nálam FBO, mint PBuffer
alias aalberik
|
|
|
|
Idézet ShAdeVampirE :
...csak én azt hittem (...) h az egy spéci, gyorsított cucc
Jól hitted.
A pbuffer lényege, hogy egy, a frame buffertől eltérő felbontású másodlagos "frame buffert" hozhass létre, és ezt akár közvetlenül textúrának használva renderelhess például nagy felbontású shadow mapeket.
A driverek 4096x4096ig szokták támogatni, de egyes kártyákkal csak 2048x2048ig elérhető.
Én nem használom ki, de az engine támogatja, és képes használni.
Ha nem használsz mondjuk shadow mapeket, akkor gyakorlatilag semmi értelme nincs neki.
Szokták még a renderelést is erre elvégezni, hogyha utána postprocesszálsz, mert akkor jobb esetben egy frame buffer copy-t megspórol a kari.
|
|
|
Ok, csak én azt hittem (bár pbuffer-be nem nagyon mentem még bele) h az egy spéci, gyorsított cucc, de ezek szerint csak egy sima buffer.
|
|
|
hát de nem is olyan bonyolult csinálni egyet...
width * height * sizeof(unsigned long) -out lefoglalsz ez böven elég 32 bites szineknek alfa meg minden turo vanbenne ráadásul összefüggö memoriaterület (mert hát ez a buffer is).
|
|
|
Idézet ShAdeVampirE :
Hülye kérdés, de DX alatt pbuffer-nek van vmi megfelelője? V csak én nem találtam?
LPD3DXBUFFER pBuffer = NULL;
DWORD NumBytes = 800*600*4;
HRESULT ret = D3DXCreateBuffer( NumBytes, &pBuffer );
if(ret != D3D_OK){
return;
}
|
|
|
Hülye kérdés, de DX alatt pbuffer-nek van vmi megfelelője? V csak én nem találtam?
|
|
|
Idézet syam :
udvz,
nem tudja vki, ha pixel buffert használok akkor annak RCje lehet azonos az ablak RCjével?
sacc: nem.
eredetiDC=wglGetCurrentDC();eredetiRC=wglGetCurrentContext();
arnyek_pbuffer_hDC=wglGetPbufferDCARB(arnyek_pbuffer_hPBuffer);arnyek_pbuffer_hRC=wglCreateContext(arnyek_pbuffer_hDC);
aztán viszontlátás.
|
|
|
udvz,
nem tudja vki, ha pixel buffert használok akkor annak RCje lehet azonos az ablak RCjével?
alias aalberik
|
|
|
Még azért egy négyzet után korai engine-t tervezgetni, de ez már off és legközelebb szerintem oda irkáljunk.
U.I. Ja meg szerintem tesóddal tervzetess valami logót inkább. Mire elkészül a rendszer a logó is talán. Mindenütt nem lehet helytállni. Vagy programozás, vagy grafika.
|
|
|
|
Open GL-ben rutinos programozót keresek egy egyedi munkára. (nem játékfejlesztés)
Ha valakit érdekel, meszaros.miklos@freemail.hu címre várnék visszajelzést.
|
|
|
Psyche Builder.
Ezt a hozzászólást ~Cre@tine~> módosította (2008.02.15 03:41 GMT+1 óra, ---)
|
|
|
már most lehet gondolkodni azon, hogy mi legyen a neve.
lehet kicsit kreatívabb is, mint: game maker,fps creator..stb.
|
|
|
Igaz, hogy én mindig az .ISO változatot használtam eddig, hogyha újra kell telepíteni a rendszert, vagy valami, ne kelljen újra letöltögetni mindent. Akkor a netes telepítőben lehet ez benne sincs.
Jó nagy fába vágtad a fejszét. Arra vigyázz, hogy az OpenGL kezdőknek könnyű, de a tanulási görbéje más, mint mondjuk az XNA-nál, ahol nem nehezebb egy textúrázott, shaderes 3D modellt se betölteni, mint egy négyzetet. Egy időben dolgozgattam benne, nekem annyira nem jött be, hátha neked igen.
|
|
|
kosz, hogy a felhívtad a figyelmem MaNiAc cikkére. elfogom olvasni.
a sünis könyv megvan. átnézem azt is. csak az ott használt matematikát kéne jobban megértenem.
hát nem tudom, de én amikor telepítettem a VC# Expresst, akkor .NET nélkül fel se rakja.
jelenleg egy ilyen: http://www.silentworks.hu/index.php
progi tervezésén dolgozom. lehet elötte kidobok vmi egyszerü lovoldozos fpst.
ha vmi érdemlegeset csinálok akkor felteszem ide is.
|
|
|
Idézet psyche :
itt az egyik legegyszerűbb technika arra, hogyan üzemeljük be a Taot C# alatt.
http://saweb.atw.hu/opengl.html
Na itt már végre látszik mit csináltál. Nem kötözködés képp, de azt a részt töröld ki, hogy .NET 3.5 letöltése/telepítése, mert fölösleges, ha a VC#-t is felrakod, mivel a telepítő CD, vagy DVD alapból tartalmazza azt.
Ezt pedig teszteld le. precedens
Lehet .NET 3.5-nél mindegy.
Kód: [STAThread]
static void Main()
Ha megvan a sünis, könyv a benne lévő ogl progikat 1-1 ben fel tudod használni Tao-val is. Sok sikert!  (Be is regeled a projectet, ha lesz valami?)
|
|
|
Jah, bocs, elnéztem. 
Azért nem véletlen, hogy pl. Doom3 engines játékokat is mind újra kell inditani egy beállitás elfogadásához...
Egyébként ez a sharelists-es megoldás amolyan félhivatalos, szóval...
S mivel nem új dologról van szó, gondolom van rá rendes implementáció nvidia és ati részről is.
Tegyél egy próbát, teszteltesd különböző konfigokon és kiderül mennyire életképes.
|
|
|
Nem értem, miért kell átmeneti RC. Nem elég a régi meg egy új?
A nagy hsz-emben írtam: Idézet Amit most nézegettem, a wgl-es rc manipuláló függvények. Sikerült működőképessé tenni az új rc-vel való dolgozást úgy, hogy wglCopyContext(régi_rc, új_rc, GL_ALL_ATTRIB_BITS), aztán wglShareLists(régi_rc, új_rc), és törlöm a régi_rc-t.
Szóval működött az, amit csináltam, a gondom az egésszel az MSDN-en leírt, számomra aggasztó mondat: Idézet All rendering contexts of a shared display list must use an identical pixel format. Otherwise the results depend on the implementation of OpenGL used.
Ez alapján a régi és az új RC-nek is megegyező pixel formátumot kell használnia. Nálam ez nem teljesül, mivel az új pixelformátum annyiban tér el a régitől, hogy kérek benne sample buffereket.
|
|
|
Legújabb project:
Smashed Potatoes
Legutóbb frissített project:
Smashed Potatoes
Friss kép a galériából:
|