OpenGL expert? GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS...

Permalänk
Medlem

OpenGL expert? GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS...

Hallå!

Jag undrar om någon vet om antalet som returneras genom denna "GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS" är max antal texturer jag kan använda samtidigt i mitt OpenGL program?

Gamla drivers verkar klara typ 12-14 på laptop tex, nyare drivers verkar klara 25 texturer eller mer, kanske 32 som returneras på denna dator i sign genom GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS.

Någon som vet något om detta?

MVH
Dalton Sleeper

Permalänk
Medlem

Det värdet säger hur många texturer du får ha bundet samtidigt till dina vertex- och fragment-program. Det är oftast inte nåhot som har med drivrutinerna att göra, utan en fysisk begränsning på grafikkortet.

Visa signatur

void@qnet
teeworlds, stålverk80, evil schemer, c, c++
Languages shape the way we think, or don't.

Permalänk
Medlem

Okey, dock har jag testat detta, om jag kör med en äldre grafikdrivrutin från ati så kan jag köra endast 12-14 texturer samtidigt, om jag lägger atioglxx.dll (cat 9.10) brevid exe-filen så klarar det minst 25, någon begränsning i drivrutin borde det vara, om inte en annan bugg..

Kanske ATi inte hade så bra OpenGL stöd för ett par år sedan? Kanske en limit för vissa OGL versioner, tex 2.0 har x & 2.1 har y?

Finns det något sätt att kunna använda fler än dessa texturer, skulle behöva betydligt fler.

Jag gör så här för inladdning av varje textur:

glActiveTexture(GL_TEXTURE0 + num_texture); ... LoadTexture(); num_texture++; ...

Textureringen sker genom shaders...

Permalänk
Medlem

Tror vi missförstår varandra lite. Behöver du verkligen ha alla texturer på en och samma gång? Alltså att fragmentprogrammet behöver läsa alla 25 (eller vad du nu behöver) per drawcall. Du kan ha väldigt många texturer inladdade, du kan däremot bara binda X st åt gången.

Oftast använder man bara 4-5 texturer åt gången, men man har en pool av kanske många tusen inladdade och så väljer man ut ett par av dem per drawcall.

Alltså:
När programmet startar gör du LoadTexture och sparar undan alla textur-ID:n. När du sedan vill rita en batch geometri gör du glBindTexture med det ID:t, sedan ritar du. Nästa batch gör du lika dant med. Om du skulle behöva använda flera texturer samtidigt (multitexturering, fragmentprogram som använder flera texturer) gör du alternerande anrop till glActiveTexture och glBindTexture tills alla dina texturer är bundna (notera, bara de som du vill använda under ett drawcall). Sedan kan du rita multitexturerat.

EDIT: om du nu verkligen skulle behöva fler än så många texturer på en och samma gång får du nog se om du kan packa dem. Skapa atlastexturer där du packar in flera texturer på samma. Kolla om du kan packa data i vertex-strömmar etc.

Får man fråga vad du försöker göra?

Visa signatur

void@qnet
teeworlds, stålverk80, evil schemer, c, c++
Languages shape the way we think, or don't.

Permalänk
Medlem

Se det som ett bildvisningsprogram tillsvidare, ett antal bilder ritas ut varje frame, med olika texturer såklart, över 32 bilder kan vara att föredra. Dock kanske man kan klistra dessa bilder till samma textur, sen använda texturkoordinater för att splitta bilden...

Edit: jag kanske gör fel kom jag att tänka på nu efter läst ditt, borde ju gå att binda på ett smartare sätt, i real time. Jaja, är lite ny på OpenGL får man väll säga, inom texturer iaf, vill dock lära mig allt.

Permalänk
Medlem

Då skulle jag helt klart rita en batch per bild, så slipper du lustiga filtreringsfel i skarvarna mellan bilderna.

I pseudokod:

StartGL(); arr texture_names = {"lol.png", "cat.png" } arr texture_ids; for all texture_names: texture_ids+= LoadTexture(name) // Du kan ha välding många sådana glActiveTexture(GL_TEXTURE0) // för säkerhets skull, denna är vald som default glEnable(GL_TEXTURE_2D) // säg att vi vill kommer ha en aktiv textur på unit0 vid varje drawcall while running: glClear(...) for all texture_ids: // ingen idé att köra glActive texture etc glBindTexture(GL_TEXTURE_2D, id) // bara X bundna åt gången (per draw call) SetTransform() // flyttar ut din geometri dit du vill ha den DrawGeom() // ritar den geometri du vill ha just denna bild på. Swap()

GL är inte annorlunda än D3D egentligen, bara interfacet som ser lite annorlunda ut.

EDIT: läste nog inte ditt svar tillräckligt noga... för du säger ju precis det jag svarade. Alt. hade jag inte druckit tillräckligt mycket kaffe

Visa signatur

void@qnet
teeworlds, stålverk80, evil schemer, c, c++
Languages shape the way we think, or don't.

Permalänk
Medlem


Okey, får lägga till ett extra call i min MaterialNode i scen grafen och se hur det går. Det som fanns där innan var UseProgram(shaderid), sen passande av textureid till shadern... då kan jag sätta den alltid till 0 antar jag då jag inte kör multi texturing än och binder varje bild till texture0?
Så jag skall köra bind på varje "bild" för varje runda då alltså, jag hade läst in alla innan samt binda allihop. Men om man bindar för varje bild, det blir ingen prestandaförlust, och texturerna ligger kvar i grafikminnet?

Jag dricker inte kaffe alls, kanske därför allt gick snett från början? Blir lätt för långa dagar...

Permalänk
Medlem

Prestandaförlusten är minimal. State changes innebär alltid lite, men det bör inte vara något större problem för dig. Finns inget som garanterar att texturerna kommer ligga kvar på grafikminnet, men så länge du laddar upp mindre data än vad du har minne så bör det vara ok. Helt upp till drivarna.

Visa signatur

void@qnet
teeworlds, stålverk80, evil schemer, c, c++
Languages shape the way we think, or don't.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av jdv
Prestandaförlusten är minimal. State changes innebär alltid lite, men det bör inte vara något större problem för dig. Finns inget som garanterar att texturerna kommer ligga kvar på grafikminnet, men så länge du laddar upp mindre data än vad du har minne så bör det vara ok. Helt upp till drivarna.

Okey, fint!
Ang minne, du vet inte nån extension man kan få mängden vram på nvidia kort? ati kort verkar fungera redan.