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

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.

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

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

EnumDisplaySettings
ChangeDisplaySettings

Hmm, pedig okés mindkét link...

(Zárójeleket nemszereti)

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.


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.

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

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?

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

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:]

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?

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

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.

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?

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

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

Értem, ThX

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?

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.

Psyche Builder.

Nem rossz, nem rossz.
A grafikus motor neve: psyche eng1ne
logó is van: http://saweb.atw.hu/logo.html

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.

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.


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.