Das erinnert mich an diesen Thread: http://www.delphigl.com/forum/viewtopic.php?t=3213

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

Flash, dein Link da zu dem Feedback-Thread hat wohl die User von diesem Thread hier abgezogen...

Ich will doch nur wissen, wie man die Objekte nach Texturen sortiert bzw. Wie man Textursortierte Objekte in einem Octree so organisiert, dass VBOs, bei denen keine Texturwechsel erlaubt sind, damit klarkommen...

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Was haben denn VBO's mit Texturewechsel zu tun?
Du kannst ohne Probleme Texture1 binden, einige Indizes rendern,Texture 2 binden usw..
VBO's sollten nämlich auch nicht allzu häufig gewechselt werden und schon einige hundert Dreiecke enthalten.

Das geht? Ich dachte, es sei schwer mit VBOs einen Texturewechel zu machen...
Das gibt dem Ganzen natürlich eine kleine Wendung...

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Das einzige was das Binden eines VBO ändert, ist das alle Zeiger auf Vertex Daten z.B. bei glVertexPointer, als Index in den Buffer gesehen werden und nicht mehr als Zeiger auf die tatsächlichen Daten gesehen werden.

kannst halt nur nicht mehr alles in einem drawcall machen, sondern must drawarrays/elements/... halt entsprechend mehrfach aufrufen und dazwischen die Textur wechseln

Schluckt das nicht zuviel Performance oder sind aktuelle Grafikkarten nicht mehr so anfällig für viele Texturwechsel?

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Unter OpenGL ist die Sache mit den State Changes eh kein so großes Thema wie z.B. unter Direct3D, aber die Blöcke jeweils in eine verkettete Liste für das Material einzufügen und alles am Schluß zu rendern, schadet ganz bestimmt nicht. Der Hauptaufwand beim Wechsel eines Parameters hat die CPU. Die Sache mit den Texturewechsel kommt noch aus der Zeit, als der Texturecache kleiner war.
Andererseits sollte man von vorne nach hinten rendern, um maximal viele Punkte über den Z-Buffer auszuschließen.

Also so, wie es früher mit den BSP-Trees gemacht wurde, als diese noch hauptsächlich zur Grafikoptimierung da waren.
Da sorgten die ja dafür, dass die Szene von hinten nach vorne gerendert wird, weil damals der Depth-Test der Grafikkarte noch recht langsam war.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Und heute ist er eben sehr schnell, so dass es sich lohnen kann zuerst ohne Farbe zu rendern und nur den Depthbuffer zu füllen. Dann kann man bei aufwändigen Shadern im 2. Durchgang trotzdem nach Shadern,Texturen,VBO usw... sortieren und trotzdem wird alles durch den Dephtest weggecullt.

So, nach ewigem lesen dieses Threads, ob die Kleinigkeiten, die ich bemerkt hab, schon erwähnt worden, bin ich nun endlich bereit:

Als erstes möchte ich mich bedanken, für die Mühe des Tutorials, mir hat/wird es bei eingen Sachen sehr geholfen/helfen *top*

So jetzt noch ein paar Anmerkungen:

Das erste was mir aufgefallen ist [aber im programmiertechnischen Sinne kein Fehler darstellt], war beim TNode-Objekt der numv-Member, bei dem gesagt wird, dass er die beinhaltenden Vektoren-Anzahl speichert. Wenn man sich die HowManyPolygons-Prozedur anguckt, dann sieht man, dass diese Variable nicht die Vektoren, sondern Polygone zählt. deutet an sich auch darauf hin, dass Polys gezählt werden und keine Vektoren, dass sollte vielleicht mal geändert werden, weils doch für ein wenig Verwirrung stiften kann.

Als zweites etwas was an sich nur einen minimalen (falls überhaupt, ich kann es momentan nicht testen) Performanceschub bringen könnte bei der folgenden Funktion:



Es ist es so, dass sich "Add" in der Funktion niemals ändern wird, trotzdem wird für jedes Polygon, dass im Knoten ist neu verglichen und darum wollte ich mal diese minimale Änderung vorschlagen:



Gerade beim Hauptknoten würden ja bei entsprechnd komplexer Szene etliche Vergleiche auf Grund mehrerer Tausend Polygone gemacht werden, was nicht sein muss.

Dann ist da noch eine Kleinigkeit in der TNode.check-Prozedur:

Ich möchte meinen, hier im Forum irgendwo mal gelesen zu haben, dass Boolean-Wert der nicht auf TRUE gesetzt ist noch nicht unbedingt FALSE sein muss. Quasi wäre es doch eigentlich richtiger, dass "=TRUE" einfach wegzulassen, oder?

und nun letzteres, wobei aber TNode ein gutes Beispiel darstellt, noch eine eher Frage:
Wann sollte man ein Objekt und wann eine Klasse verweden?
[Bei Polymorphie ist es mir klar ]
Ich habe bisher eigentlich immer mit Klassen gearbeitet :S

MfG
bubble

PS: Irgendwie ist es mir schon ein bischen peinlich, diesen Thread aus seiner Gruft zu holen :S

_________________
Wenn Worte nichts als Worte sind,
dann müssen's Steine sein!
Solange - bis sie pleite sind - schmeißt Fensterscheiben ein!
- Fidl Kunterbunt -

Die ersten Vorschläge (erklärung der Variable ändern und Add Parameter) würde ich direkt übernehmen wollen. Dafür ein Danke und ein Bitte: Bitte direkt im Tutorial anpassen. Du hast das gerade durchgearbeitet und stehst somit tiefer im Stoff als der Tutorialschreiber selbst (der das vor ein paar Jahren zu File gebracht hat).
Du kannst dich im Wiki mit deinem Forenlogin einloggen und ändern.

Das mit dem True sollte erstmal geklärt werden. Das kannst du ja in Tests mal durchexerzieren. Aber da ich kein Delphianer bin, ist dies nicht mein Fachgebiet.

@Klassen vs Objekte: Als Java Mensch sag ich: Nimm Klassen.

Ist das Object in Delphi eine Art Singleton? Keine Ahnung...

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

Rein technisch sollte es keinen Unterschied machen. Ist aber lesbarer, wenn man das =True weg lässt.


Möchtest du die Frage nochmal in einem neuen Thread stellen? Ich beantworte sie gerne ausführlich, aber es ist denke ich besser, wenn das nicht in diesem Thread verschwindet (und abtrennen wäre hier hässlich, da die Frage eine von vielen in einem Post ist).

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

So die Änderungen sind jetzt im Wiki
Ich wusste garnicht, dass da jeder so leicht ran kann.

@Lord Horazont: Hab das Thema erstellt: klick

MfG
bubble

_________________
Wenn Worte nichts als Worte sind,
dann müssen's Steine sein!
Solange - bis sie pleite sind - schmeißt Fensterscheiben ein!
- Fidl Kunterbunt -

*spritzt Weihwasser auf den Thread*

Ich glaub, den schließ ich einfach mal ganz dreist, bevor hier noch mehr Leichen ausgegraben werden

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."