Hi,
ich habe gerade VBOs mit Multitexturing implementiert und stehe vor einem Phänomen, von dem ich nicht weiss, ob es tatsächlich eine Performanceschwäche ist, oder ich etwas falsch mache.
Um Detailtexturing auf meinem VBO zu implementieren habe ich eine Basistextur, die über das gesamte VBO von 0 bis 1 gezogen wird (UV).
Die Detailtextur nutzt die gleichen UV Koordinaten aber mit einem Faktor multipliziert, der das Detaillevel widerspiegelt.
Normalerweise müssen UV Koordinaten ja zwischen 0 und 1 liegen, aber wenn ich die Filter der Detailtextur auf repeat setze, übernimmt OGL das Tilen ja für mich.
Wenn ich verhaeltnismaessig kleine Faktoren wähle (1-5), sehen die FPS bei 18k vertices noch ok aus (>100).
Bei größeren Faktorwerten (>50) gehen sie aber massiv in den Keller und das nur der Textur wegen.

Liegt der Fehler wirklich da?
Wenn ja wäre es ja sinniger wenn ich die Berechnung selber übernehme und die Texturfilter zurücksetze..

Typischer Fall für einen DGL Benchmark, oder?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Mh und wie genau ist das jetzt gemeint? Soll ichs einfach mal selbst durchtesten und dann bescheid geben oder verfügt die DGL über irgendeinen Benchmark, mit dem man sowas angenehm testen kann?

Schau mal ob du mit Traudes Code was anfangen kannst.
Falls nicht dann werd ich mal auf meine ToDo Liste schreiben, eine Spezifikation für den Benchmark abzuliefern.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hast du für deine Detailmap auch MipMaps aktiviert? Ich vermute das auf einen Bildschirmpixel bei einem Faktor von 50 relative viele Texel der Detailtextur kommen. Wenn dann kein MipMapping aktiviert ist müssen für jeden Bildschirmpixel alle diese Detailtexel verarbeitet werden.

MipMapping sollte man eigentlich nahezu immer aktivieren, es sei den man ist sicher das man es nicht benötigt. Mipmaps benötigen 1/3 mehr Speicher, sind dafür aber schneller und reduzieren obendrein noch einige Artefakte die beim vergrößern/verkleinern auftreten.

_________________
Yeah!

Mipmapping ist aktiviert ja

@Flash: Traudes Code? Ist mir ein Post entgangen?

Ich glaube in diesem Thread hatte Traude mal einen Laufzeitvergleich versucht zu implementieren.
Da ging es um zwei Kollisionsmethoden.

viewtopic.php?t=8371

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Nein, Du irrst Dich, es war im OffTopic-Forum: http://www.delphigl.com/forum/viewtopic.php?t=8464

Und es ist in Pascal geschrieben.

Naja ich hab keinen Pascalcompiler mehr
Ich werds einfach mal selbst was testen und schaun was bei rauskommt

Klingt für mich erstmal garnicht merkwürdig, da es abhängig von der Texturauflösung völlig korrekt sein kann. Wenn deine Detailtextur hast, die mit sagen wir 256x256Pixel kommt und die MipMaps entsprechend 128,64 und so weiter sind, du dann die Textur 50x auf das Bild bekommst, dann hast du so oder so ein größeren Aufwand, da bei einer benötigten Texturauflösugn von z.B. 23x9 der shader 32x32 und 16x16 aus dem Speicher holt, diese texel für Texel verarbeitet und entsprechend mehr Texel angefasst werden als notwendig. Wenn du nun eine Textur mit 256x256 2x auf z.B. 1024x768 darstellst, dann hat er trotzdem nur 256x256 Pixel auch wenn er eigentlich 512x3hundertquetch bräuchte(und auch nur eine statt 2 Mipmaps verarbeiten muss), um perfekt zu rendern. Die Performanceeinstürze sollten allerdings nicht also groß sein. Das ganze betitelt man gerne mit Over- und Undersampling.
Das wäre schon mal eine Möglichkeit, wieso das ganze etwas einbricht und die extra Last von VBO noch dazu.
Möglich wäre auch, dass dir schlicht die MipMaps fehlen, sollten diese nicht von dir generiert oder mit geladen sein, geht das richtig böse in die FPS. Wobei es bei es dann genau dieses Phenomän beschreiben würde, was bei dir auftritt, dass bei großen Darstellungen die FPS sehr stabil ist und beim kleiner werden diese rapide runter geht.
Allerdings hast du auch nicht gesagt, was bei dir "massiv in den Keller" bedeutet, sind es 10% weniger oder 80%, das ist auch noch so eine Frage.
Wenn es z.B. von 800FPS auf 600FPS fällt, dann ist das nicht weiter tragisch aber wenn es z.B. von 800FPS auf 300FPS fällt liegt, dann stimmt wirklich was nicht.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

kein Detailmapping: 145 FPS
5 faches Detailmapping : 120 FPS
50 faches Detailmapping: 22 FPS
100 faches Detailmapping: 13 FPS

is sogar noch etwas extremer als dein Beispiel. Wie gesagt Detailmapping ist enabled. ich hab deine Erklärung nicht ganz verstanden, war mir zuviel gerechne, aber meine Vermutung ist, dass wenn ich die Textur Repeaten lasse, ogl jeden Rendervorgang die Texturkoordinaten errechnet, um die textur korrekt zu strippen. Und bei 100 fachem Detailtexturing auf nem Quadratischen Feld werden daraus 100*100 = 10000 Texturberechnungen. Könnte mir schon vorstellen, dass da eine vorkalkulation und dann das weglassen von REPEAT sinniger wäre. Ich gucks mir mal an

Nicht schlimm. Was ich damit sagen wollte ist, dass du immer einen Overhead hast, wenn die benötigten Texturstufen(MipMaps) unter der Orginalgröße liegen. Es wird zum berechnen des Texels, auf dem Monitorpixel erstmal 2 MipMaplevel benötigt, die oversampled und undersampled Stufe(nächst höhere Texturauflösung als Bildschirmauflösung und nächst geringere Texturauflösung). Man hat sehr selten genau die Auflösung einer MipMap, die gerade für das Render notwendig wäre, dadurch entsteht aber ein gewisser overhead beim berechnen des Monitorpixels, da je nach Texturfilter entsprechend viel mehr Nachbartexel angefasst werden müssen um eine korrekte Interpolation, des Texels in bezug auf die Bildschirmauflösung und Größe der Textur in der Szene, zu realisieren.
Allerdings war mein Gedankengang nicht weit genug gegangen, ich hab das Caching nicht beachtet, das greift bei den niederen MipMapstufen sehr stark und kompensiert das rein theoretisch wieder. Also dürfte der Effekt nicht auftreten.

Ich stelle mal ne wüste vermutung auf aber benutzt du für die Detailtextur eine Modifizierte Texturmatrix also skalierst die Texturkoordinaten per Texturmatrix oder passiert das über ein Shader ? Sollte es ersten sein, dann könnte ich mir auch vorstellen, dass vieleicht ein Fehler beim errechnen des MipMap-Levels vor liegt. Am besten wäre, wenn du das ganze mal testest, indem du 2x UV Texturkoordinaten im VBO mit schickst, wobei du das 2. Paar mal mit z.b. 50 multiplizierst und den weg über Texturmatrix oder Shader weg lässt. Sowas wäre aber wirklich schlimm.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Nein ich setzte die Originaltextur mit uvkoordinaten von 0-1 und die Detailtextur mit uvkoordinaten von 0-1*Level. Dadurch kann natürlich alles zwischen 0 und 50 bei Level=50 rauskommen, deswegen dachte ich, müsste OGL hier ziemlich viel rumrechnen. Shader und Texturmatirx nutz ich nciht

OT: Ich hab die Spezifikation für den DGL_Benchmark ins Wiki gesetzt. In diesem Thread kann darüber diskutiert werden.

_________________
Blog: kevin-fleischer.de und fbaingermany.com