Hi, ich hab mich mal wieder auf einen kleinen Fortbildungsschub eingelassen und mir die VBOs angelesen. An sich find ich die VBOs echt nicht schwer zu verstehen, allerdings macht mir der pseudo code von Sascha etwas zu schaffen. da gibt es nähmlich eine Zeile in der es heißt



diese Zeile ist an sich nicht allzu schwer zu verstehen, aber was ist "VBOPointer"? Was ist da für ein typ und wo bekomm ich es her? Oder ist damit das gemeint, was weiter oben im Tutorial einfach als "VBO" bekannt war? Wenn mir das jemand schnell mal erklären kann, dann komm ich auch schon wieder ein gutes Stück vorran.

Andere Frage zu dem Thema geht um das packed Record. Er verwendet dort einzelne Variablen S,T,X,Y,Z:Glfloat , kann ich auch einfach n array[0..4] of glfloat verwenden?

Danke soweit schonmal im vorraus!

_________________
Klar Soweit?

glMapBufferARB liefert einen Pointer zurück. Also die Adresse auf den Speicherbereich in den du deine VBO Daten schreiben kannst. Je nachdem wie du diese Daten ansprechen möchtest kannst du diesen Pointer als einen Pointer auf ein Record benutzen oder aber als untypisierten Pointer und dann mit diversen Speicherkopierbefehlen Speicher rein kopieren etc etc. Wichtig ist nur. Du bekommst dort die Adresse gesagt in der du die Daten ablegen kannst. Du darfst maximal so viel Daten reinschreiben wie das VBO Groß ist. Diese größe wurde bei glBufferData festgelegt.

Ich denke VBOPointer ist als Typ PVertex deklariert. Wobei ich gestehen muss, dass das Reinkopieren der Daten etwas umständlicher gemacht wurde als es eigentlich hätte sein müsste.

Zu der Frage mit dem Array. Was du dort benutzt ist vollkommen dir überlassen. Wenn du lieber ein statisches Array benutzt kannst du auch das machen. Wichtig ist nur, dass du die Daten irgendwie dort rein bekommst. Ich persönlich benutze auch lieber einen Pointer auf ein Record. Allerdings für die CPU ist es identisch ob du auf S oder auf [0] zugreifst. Dynamische Arrays sind allerdings Tabu, da diese nur ein Pointer auf echte Daten irgendwoanders sind.

Im Grunde genommen hat das Sascha auch so hingeschrieben:


Was mir aber bei dem Abschnitt in den Sinn kam. Was wenn ich Daten in das VBO schreiben will und lesen?
Hol ich mir dann zwei Pointer? Einen Read und einen Write Pointer?
Und was passiert, wenn ich dann per Write was reinschreibe, wird das automatisch und sofort in den Read Bereich übertragen (sind ja zwei eigenständige Speicherbereiche)?

Es gibt ja noch "Shared Memory" für die Interprocess Komunikation. Kann ich so einen Speicherbereich auch von anderen Threads auslesen lassen? (Keine Ahnung wozu das gut sein könnte. Nur prinzipiell.)

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

Du kannst ein VBO nur ein Mal mappen. Und wärend es gemappt ist kannst du es auch nicht zum Zeichnen benutzen.

Allerdings gibt es neben den Modis GL_READ_ONLY und GL_WRITE_ONLY eigentlich auch noch den Modus GL_READ_WRITE. Aber dieser sollte normal nicht benutzt werden. Denn in der Regel braucht man die Daten nicht lesend. Und das würde auch erzwingen, dass der Treiber die Daten erst zurück kopieren muss. Was erzwingt, dass die Grafikkarte damit gerade nichts macht etc. Wobei in dem Tutorial auch steht, dass man direkt in den Grafikkarten Speicher schreibt. Ich meine früher wurde so etwas zwar häufiger gesagt aber eigentlich ist es immer ein Speicherbereich im RAM der vom Treiber verwaltet wird. Entweder wird dort Grafikspeicher reinkopiert bzw der Speicher dann asynchron in den Grafikspeicher. Evtl ist diese Definition mit dem echten mappen auch so in der Spezifikation veranker. Keine Ahnung.

Threads: Also abgesehen davon, dass du nur einen Speicherbereich bekommst ist das wieder jeder Speicherbereich. Also du kannst das Problemlos an einen Thread übergeben und dort befüllen. Aber du musst dann halt aufpassen, dass du den Speicher wieder entmappst bevor du zeichnest. Das muss aber wieder im VCL Thread stattfinden. Und wozu das gut ist. Schau nur mal wie viele Leute Dual oder Quad Cores besitzen. Das kann man zum Beispiel benutzen um höher aufgelöste Modelle oder Texturen im Hintergrund zu laden und sie dann eben so nebenbei wärend des Rendern einzuspielen. UT3 macht so etwas.

danke für die antworten, hab es jetzt auch hinbekommen das VBO zu erstellen, allerdings wollen nu meine daten nicht mehr in mein array.
Das ist aber nicht im zusammenhang mit dem VBO, sondern ein fehler beim Filestream. Ich hab da beim lesen aus der datei und schreiben
in das Array, von wo ich die daten dann ins VBO schiebe, irgendwie ne acces violation.

Wenn ich das behoben hab werd ich ma n bild schicken. Geht bei mir gerade um terrain. Also das quasi einfachste 3d-objekt mit dem man VBOs
praktisch anwenden kann. Die Datei ist ne schlichte Heightmap mit 256 abstufung, somit hab ich für jedes Feld der landschaft ein byte. Sowas
lässt sich halt mit photoshop schnell erstellen, da man die daten ja mit einem 8bit-kanal in eine raw datei speichern kann und nen header für
weiter infos wie länge und breite schnell zufügen kann.
Als ich das noch im immediate-mode gezeichnet hab hat das wunderbar funktioniert, also geh ich mal davon aus, dass ich irgendwas zerschossen hab,
als ich den VBO part geschrieben hab.

genug gefaselt, ich werd ma weiter machen!

_________________
Klar Soweit?

Also wenn du mit einem Stream deine Daten sowieso per hand einließt, dann kannst du die Daten auch direkt ins VBO einlesen. Also in den gemappten Speicher. Denn wenn du erst deine Daten in ein Array ließt und dieses dann Feld für Feld in ein VBO kopierst, dann kopierst du die ganzen Daten doppelt. Und das könnte man relativ einfach optimieren, wenn man den Zwischenschritt mit dem Array sein lässt.

Allerdings. So etwas etwas geht natürlich nur, wenn du die Daten nicht noch außerhalb brauchst. Wenn du aber Berechnungen auf dem Array machen müsstest, dann geht das nicht. Dann muss man das mehr oder weniger auch über ein Array laufen lassen.

genau bei den Berechnungen liegt das Problem, da ich die Normalen anhand der umliegenden Felder errechne und das tu ich in dem Fall unmittelbar nach dem Lesen der Daten und kopiere dann alles zusammen in das VBO. ich könnte natürlich den Prozess beschleunigen, wenn ich 3weitere Kanäle in der Datei anlege um die Normalen mit abzuspeichern, aber warum sollte ich den Speicherplatz verschwenden, wenn ich beim Laden nur einen Augenzwinker mehr hab? Ob man das auf nen Vertexshader auslagern weiß ich nicht, dafür hab ich auch entschieden zuwenig Ahnung von Shadern und bin erstmal zufrieden, wenn ich überhaupt interessante Dinge auf den Bildschirm zaubern kann.

_________________
Klar Soweit?

VertexShader. Ich denke die würde man dazu nicht nutzen können, da du keinen Zugriff auf umliegene Vertices hast.

Deswegen habe ich ja den Zusatz mit den Berechnungen ja geschrieben. Wenn du die Daten nicht direkt 1:1 weiter gibst, dann gehts halt nicht. Zu mal es sich dabei wohl auch nur um ein einmaliges Laden (also nur beim Starten der Anwendung oder vergleichbares) handeln wird und dann spielt es auch keine wirklich große Rolle. Bzw würde sich der Aufwand für weiterführende Optimierungen wohl kaum lohnen. War aber nur eine Idee für den Fall falls du es 1:1 weiter geben würdest.

sooo, ich habe es tatsächlich geschafft, habe festgestellt, dass sich bei mir Fehler mit den Speicherblockgrenzen eingeschlichen haben und auch die Formeln für die Berechnung meiner Normalen etwas durcheinander gegangen sind. Zum Glück bin ich ein Wahnsinniger mensch und hocke auch noch bis 4uhr morgens an solchen sachen.

Wie versprochen häng ich das Bild mit an. Bei Fragen, Tipps oder kranken Ideen, einfach schreiben!

_________________
Klar Soweit?

Hübsch Immer weiter so.

Übrigens: die Fehler schleichen sich bei mir auch immer ein, wenn ich grade auf Fehlersuche bin. Und eigentlich ich auch deshalb WEIL ich bis um vier Uhr früh dran hocke.