Maximale Textur Groesse, Frage zur Geschwindigkeit
-
way schrieb:
Du solltest nicht eine große Textur laden, dass ist unschön und lastet gleichzeitig viel Speicher aus.
Du musst dir einen Textur-Manager schreiben.Mehrere Texturen in eine groessere zu packen ist bei Shader-Programmierung gaengige Praxis weil die Anzahl der Texture-Units stark begrenzt ist.
Bei der Playstation1 war zb der gesamte Texturspeicher so aufgebaut.
-
Hallo
Mehrere Texturen in eine groessere zu packen ist bei Shader-Programmierung gaengige Praxis weil die Anzahl der Texture-Units stark begrenzt ist.
Interessant. Ist das nur bei Shadern so oder verfolgt man dieses Prinzip auch in anderen Bereichen?
btw:
Mit einem Textur-Manager hat es damals prima geklappt.Mfg.
way
-
hellihjb schrieb:
way schrieb:
Du solltest nicht eine große Textur laden, dass ist unschön und lastet gleichzeitig viel Speicher aus.
Du musst dir einen Textur-Manager schreiben.Mehrere Texturen in eine groessere zu packen ist bei Shader-Programmierung gaengige Praxis weil die Anzahl der Texture-Units stark begrenzt ist.
Bei der Playstation1 war zb der gesamte Texturspeicher so aufgebaut.Es spricht ja auch Grundsätzlich nichts dagegen mehrere Texturen auf eine zu packen, es solte aber schon in überschaubaren Rahmen und Sinnvoll bleiben. Wenn man aber wie der Theradersteller die Maximale größe nehmen will nur weil sie da ist sieht da snicht sher Sinnvoll aus weil man sich damit ja auch schnell einen höheren Speicherverbrauch einhandelt weil man zB mehr Modelel laden muß als man mit Einzelltexturen bräuchte.
Zu der Begrenzung kann ich nichts sagen, mit Shadern hatte ich noch nich viel zu tun, aber is es nicht so das jeder Shader seine eigenen Texturen nutzt?
-
weil man sich damit ja auch schnell einen höheren Speicherverbrauch einhandelt weil man zB mehr Modelel laden
Der Ansatz ist eigentlich eher andersrum:
Man hat viele kleine Modelle (mit unterschiedlichen Texturen) und moechte diese zusammen in einen grossen Vertexbuffer packen und am Stueck zeichnen ohne zwischendurch fuer jedes einzelne Modell Renderstates veraendern zu muessen - also muessen alle Texturen in eine.
-
hellihjb schrieb:
weil man sich damit ja auch schnell einen höheren Speicherverbrauch einhandelt weil man zB mehr Modelel laden
Der Ansatz ist eigentlich eher andersrum:
Man hat viele kleine Modelle (mit unterschiedlichen Texturen) und moechte diese zusammen in einen grossen Vertexbuffer packen und am Stueck zeichnen ohne zwischendurch fuer jedes einzelne Modell Renderstates veraendern zu muessen - also muessen alle Texturen in eine.Ja wenn ichw eis das ich viele kleine habe und wo sie Liegen, habe ich aber wenige große mit evrschiedenen texturen fahre ich andersherum besser, denke das muß man sowieso von Fall zu Fall unterscheiden wie mans macht.
EDIT:
Ich würde gerne mal in dem zusammenhang ein konkretes Beispiel anführen.
Nehmen wir mal folgendes an, du hast ein Strategiespiel, in diesem gibt es ein Panzermodel, sagen wir mal 200 Vertizes, mit 4 verschiedenen Texturen die Schaden anzeigen, die Texturen sind deckungsgleich können also einander einfach ersetzen. Nun befinden sich auf dem Feld 100 Panzer die sich bewegen und schaden nehmen. Was ist jetzt schneller?
a) Das Model einmal in einen vertexbufefr laden und von dort aus mit verschiedenen Weltmatrizen Rendern udn jeweils die passende Textur nehmen, was 100 rendercalls anch sich zieht
b) Das Model laden und einen Vertexbuffer mit 100Panzern erstellen udn die Vertices für Position und Textur mit jedem Bild ändern um dann nur 1 Rendercall zu haben?
-
Nehmen wir mal folgendes an [...]
Was ist jetzt schneller?Das kann man pauschal nicht beantworten.
In diesem Beispiel stellen weder die 200*100 Vertices noch die 100 Render-Calls einen Flaschenhals dar, darum ist es eigentlich egal welche Loesung ggf "schneller" waere.Sind erheblich mehr Render-Calls notwendig muss sich eine situationsbedingte Loesung einfallen lassen.
Die gesamte Transformation von der CPU erledigen zu lassen ist dabei sicher suboptimal.
Eine Moeglichkeit waere zb die notwendigen Informationen (in diesem Fall pro Objekt eine Transformationsmatrix und ein Texture-Offset) in eine zusaetzliche Textur zu schreiben und im Vertex-Shader auszulesen (setzt Shader-Model 3 voraus) und anzuwenden. Jeder Vertex enthaelt dann eine zusaetzliche Texturkoordinate die festlegt zu welchem Objekt er gehoert.
-
c) alle in einem VB, ueber den Vertexshader fuer jeden panzer x,y offset+cos/sin in eine float4 einbauen. ein drawcall, nur 100consts veraendert, kein VB update -> beste performance.
-
Das weder das eien noch das andere ein Flaschenhals ist ist mir klar, es war mehr eine Hypotetische Frage.
Die 2 Ansätze finde ich interessant, hab leider nicht soviel wissen über Shader, klingt aber nicht schlecht.
-
ist aber ein alter hut, ne menge spiele machen das so, das lief auf ner GF3 schon gut, das lustige ist, das lief sogar auf einer GF4MX (die keinen hardware vertexshader hatte) noch gut. so konnte ich ein paar hundert kleine animierte einheiten durch die gegend schubsen *hehe*
aber ich glaube das problem was lukas loesen moechte entsteht eher durch multitexturing. er hat vermutlich zwei texturesets mit unmengen von texturen und waehlt dann von beiden pro objekt eine kombination. da hat man dann auch pro objekt einen texture switch, vielleicht sogar mehrere falls das objekt in mehrere drawcalls zerteilt werden muss, weil z.b. seine lightmap nicht in eine texture page passte.
entsprechend denkt er jetzt an die loesung mit riesigen texturen.
das kann speicherprobleme geben.
-
Naja bei 4096x4096 is sone Textur schon 64MB groß, da sis nich ohne.
Hast du eig nen Litheratur/Tutorial Tip zu den Vertex Shadern? Das was du da geschrieben hast fidne ich interessant abe rirgendwie hab ich bisher nie was gefunden was die Shader mal ausreichend behandelt.
-
zum anfangen vielleicht: http://http.developer.nvidia.com/GPUGems/gpugems_pref01.html
ist sogar online lesbar (einfach rechts auf die kapitel klicken). zum wirklichen anfangen bei 0 sind auch die nehe tutorials oder die dx-sdk doku ganz gut (mit dem shader workshop)
-
Danke schau ich mir mal an. Der Shaderworkshop nützt mir leider nix, nehme Dx9 und hab damit ja Shader 3 der Workshop vom letzten SDK ist aber leider auf Shader4 zugeschnitten.
-
-
Nochmal danke, das hilft mir schonmal sehr weiter.
-
Schön, dass in diesem Thread noch anderen geholfen werden kann ^^
Also ich hatte nicht zwangsläufig vor, die maximale Texture-Größe auszunutzen. Ich wollte lediglich wissen, ob das Programm langsamer wird, wenn man mit großen Texturen arbeitet. Ich selbst gehe eher mal davon aus, dass das kein Problem sein sollte.
Ich habe das gefragt, weil ich zur Zeit ein Test-Programm schreibe, das Lightmaps generieren soll. Das funktioniert auch schon ganz schön (hier mal ein Beispiel Bild: http://softpixelengine.sourceforge.net/GalleryImg33b.jpg)
Jedoch muss ich die einzelnen Lightmaps, welche mein Programm für jedes einzelne Dreieck generiert, später zusammen auf eine Lightmap bringen. Denn wenn ich tausende von kleinen Texturen habe, muss ich diese Texturen jedesmal mit den OpenGL Funktionen wechseln. Habe ich abe wenige große, dann muss ich das mit OpenGL oder eben Direct3D nur ein paar mal machen und kann die Grafikkarte die tausenden von Dreiecken durchlaufen und rendern lassen.Sind die lightmaps erst einmal zusammen gefasst, muss ich natürlich auch noch prüfen, ob einige "Einzel-Lightmaps" sich wiederholen, z.B. nur helle oder nur schwarze die sicherlich recht häufig vorkommen, um so viel Platz zu sparen wie möglich. Schließlich kommen bei großen Szenen manchmal über 100.000 Dreiecke zusammen. Und 100.000 Texturen ist nun auch wieder Mist.
Danke übrigens für euren Rat
Mfg Lukas
-
eine der bekanntesten seiten dazu: http://www.blackpawn.com/texts/lightmaps/default.html
wie du siehst, hat man manchmal vorteile die dreiecke nicht einzeln zu sehen sondern moeglichst als quads anzufassen, wie du sicherlich auch schon im quake sourcecode entdeckt hast... ich wollte es nur nochmal erwaehnen
-
Ja klar, das hat sicher auch Vorteile. Ich habe das so gelöst, dass ich in eine "Einzel-Lightmap" immer zwei Dreiecke packe.
Also so in etwa:
*-------* | 1. / | | / | | / 2. | *-------*
