Hallo, Wölfchen
Wenn Du mir eine abgespeckte Version nochmals hier hereinstellst, könnte ich sie mir heute abend anschauen. Du hast in der Zwischenzeit den Quellcode offensichtlich geändert.
Viele Grüße
Traude

Hallo Traude,

ja, ich habe am code gefeilt insgesamt 8 verschiedene Varianten meiner Anwendung gemacht die alle auf ATI bei mir zuhaus laufen (mit glgeterror fehlerfrei), auf der 1800 FX von NVIDIA geht zumindest mein derzeitiger Favorit.. und auf der Quadro 2000 + Quadro 1000M abstürzen..

Geändert habe ich folgendes:

sowohl TVertex als auch TVBOVertexpack sind jetzt packed records.
TIndexBuffer ist jetzt ein gluint und kein Cardinal mehr, weil ich das irgendwo gelesen habe, das gehört so..

Die FillVBO procedure ist noch wie sie hier im ersten Post steht..

und rendern tu ich zur zeit so:


Wenn ich noch was nachliefern soll einfach sagen! Danke schonmal das du dir Zeit nimmst!!

Wolfgang

ich hab den Fehler gefunden!
Hurra! freu hüpf spring!

es war das Finalize! bzw das zu späte Finalize..
Wie ich ja schon im Eingangsposting geschrieben hatte wusste ich von Anfang an nicht wohin damit und habs ans Ende der Renderschleife gepackt, weil es im WIKI dazu nur hiess "noch aufräumen" oder so, da dachte ich das muß hintendran.

In Wirklichkeit gehört es vors Rendern ich machs jetzt bereits beim Laden... und schon läufts auf der NVIDIA Quadro 1000M hier..

Ich hoffe damit ist es dann auch für die Quadro 2000 auf arbeit ok... und für die Intel R Core 7i...

das wär schön...

und ATI akzeptiert das??

ich tu immer wieder gut eine NVIDIA zu haben...

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

ATI und auch die FX1800 sowie jeder billige aldi laptop der mir zwischen die finger kam (ok warn nur 2 stück).
im Grunde hats auf mehr rechnern funktioniert, als es nicht funktioniert hat etwa 7:3

Aber mal zurück zu dem Finalize... der Befehl ist mir neu und aus der Hilfe werd ich nicht wirklich schlau...



Ich hab noch mehr dynamische arrays im code, muß ich die auch finalizen?

Eigentlich muss man dynamische Arrays nie finalizen. Finalize ist für Records, welche mit New o.ä. erzeugt wurden und mit Initialize initialisiert.

grüße

_________________
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

@Lord Horazont:
Mit so einer Aussage wär ich vorsichtig:

Zitat aus meinem (zugegeben uralten) Delphi-Handbuch "Object Pascal Sprachreferenz":

@Wolfgang:
Derzeit benutze ich nur noch FreePascal, und in meinem derzeitigen FreePascal Handbuch scheint zu meiner Überraschung "Finalize" überhaupt nicht mehr auf. Da FreePascal sich immer noch ziemlich streng an Delphi hält, könnte das bedeuten, dass Finalize heutzutage etwas anderes macht als früher. Ich würde jedenfalls vorschlagen, statt des Finalize eine Freigabe-Routine zu benutzen, die in Deiner Delphi-Version für so etwas vorgesehen ist. Da ich Delphi nicht mehr benutze kann ich Dir hier nur sagen, was FreePascal jetzt vorsieht, nämlich SetLength(Variable,0).

Dieses "Finalize" benutze ich, um den normalen RAM-Speicher für das VBO freizugeben. Daher ist es, wenn Du den Inhalt des VBO in den Grafikkartenspeicher (GRAM) geladen hast und dann nicht mehr verändern willst, natürlich möglich, das VBO im normalen RAM nach dem Upload in den GRAM freizugeben. Ich mache das aber normalerweise nicht, denn üblicherweise benutze ich ein rund 4MB großes statisches VBO, wo ich alle meine Sachen reinpacke.

Man kann aber zB. auch Folgendes machen

VBO-Speicher im Ram erzeugen (irgendein dynamisches Array mit Namen "RAMDATA")

For X:= 0 To ichweißnichtwieoft
Daten in das RAMDATA laden
Neuen VBO auf der Gafikkarte (= GRAM) erzeugen (GenVBO VBO_X)
Daten aus dem RAMDATA in den VBO_X im GRAM laden
End //Of ichweißnichtwieoft

Dann darfst Du das RAMDATA natürlich nicht gleich nach dem ersten Upload freigeben, sondern erst, wenn Du mit all Deinen Uploads fertig bist. Das soll heißen, wann man das RAMDATA freigibt hängt davon ab, was man damit macht. Ich mache das z.B. meistens ganz zum Schluß. Es kommt eben darauf an, wie Deine Anwendung arbeitet.

Obwohl ich mich natürlich darüber freue, dass es jetzt bei Dir funktioniert, kann ich nicht wirklich glauben, dass es an dem "Finalize" liegt. Ich sehe mir Deinen Quellcode trotzdem noch an. Jedenfalls habe ich an Deinem Posting gesehen, dass ich offenbar zu wenig Kommentar dazu geschrieben habe.
Viele Grüße
Traude

@Traude



Witzigerweise ist das ja genau der Fall bei mir "ichweißnichtwiegroß" die meshes sind die einer laden will.. darum hab ich dynamische arrays und setze die mit setlength auf die entsprechende größe... bisher hab ich dann genau die arrays genommen und mit vertexarray und normalarray gerendert (ohne VBO)... jetzt mit VBO benutz ich die dinger nur noch um die VBO's zu befüllen und mach danach ein setlength(varray,0) und ein setlength(narray,0)


Ich kann halt nur sagen wie es sich bei mir verhält, und das steht ja schon im Eingagspost, das war den ATI karten völlig egal ob die zeile im code war oder nicht.. ohne das kam zwar kein Fehler (ATI) aber gesehen habe ich auch nichts.


Nuja kommt drauf an wen du erreichen willst, ich zähl mich immernoch als Anfänger und ich bin ja auch nur Autodidakt in Delphi, richtig gelernt (schule, studium) hab ich das nie. Mich hat das 4. Nachher reinen Tisch machen einfach in die falsche Richtung gelenkt, für jeden der es besser kann ist das vermutlich sonnenklar.

aber was in deinem Wiki Beitrag angeht bin ich fast sicher das das es falsch sein müsste, weil es mir den im ersten Post beschriebenen Compilerfehler bringt.
Ich hab in der Wiki zu glVertexPointer zwar gesehen das es für VBO's den offset abbilden soll aber vielleicht wurde das ja geändert? *schulterzuck*

Ich habe mir meine Testanwendung für diesen Artikel aufgehoben. Dort habe ich "POS_OFFSET" und auch den zweiten Offset ebenfalls wie oben angegeben definiert. Ich habe das jetzt nochmal kompiliert, und der FPC-Compiler hat das Pos-Offset akzeptiert, aber das zweite Offset angemeckert. Ich kann mich nicht mehr erinnern, wie es jetzt wirklich war, aber ich hoffe, Du glaubst mir, dass ich nicht absichtlich etwas Falsches ins Wiki geschrieben habe. Jedenfalls hast Du recht: Das Offset ist ein Pointer und sollte so definiert werden:


Ich werde das im Wiki korrigieren.




OK





Hier nur eine kleine Anmerkung: Normalerweise ist die Anzal der Indices größer als die Anzal der Vertices; das ist der eigentliche Grund, warum man Indices verwendet: sie ermöglichen ein kleineres Modell. Wenn man ein Viereck in Form von zwei Dreiecken rendert, dann hat es 4 Vertices und 6 Indices. Bei großen Modellen macht das ganz schön etwas aus. Aber der Code ist grundsätzlich OK.




Eine kleine Frage: die Daten sind in dem Model schon irgendwie drin, oder? Kann man diese Daten nicht gleich als VBO benutzen? Dann spart man sich das Umspeichern.


OK




Noch eine kleine Randbemerkung:
An sich stimmt das Offset. Aber Du beziehst Dich dabei auf den RAM-Buffer. Das solltest Du im Gedächtnis behalten. Das Offset sollte aber als Egenschaft des GRAM-Buffers gesehen werden. Das ist ein feiner Unterschied. Denn Du kannst mit Deinem RAM-Buffer weitere GRAM-VBO's befüllen, die ein anderes Vertexformat und somit auch ein anderes Offset haben. Terraindaten z.B. sehen möglicherweise anders aus als Daten für eine Spielfigur. Das heißt, es läuft sich darauf hinaus, dass man sich die Daten, die man fürs Zeichnen braucht, irgendwo merken muss.



Jetzt ist mir klar, was da passiert ist. Du hast hier in der Renderschleife immer und immer wieder den Speicherplatz für das VBO freigegeben. Dann hast Du klarerweise auch hier recht: die beiden Statements mit dem Finalize müssen aus der Renderschleife entfernt werden. Man könnte das Freigeben des Speicherplatzes - wie gesagt - nach dem Upload machen (vor der Renderschleife) oder bei Programmende.

Ansonsten ist das ganz OK.

Viele Grüße
Traude

Klar glaub ich dir und ohne deinen tollen Wiki Eintrag hätte ich heute keine VBO's also Danke! Freut mich das ich in Details an Verbesserungen mitwirken konnte. Ich hab das jetzt so geändert bei mir und es funktioniert tatsächlich


Das stimmt, kommt einfach daher das ich jetzt ewig schon mit Vertex und Normal arrays gerendert habe... das einmalige umspeichern kostet kaum zeit und den Speicher gebe ich ja danach mit setlength(varray,0) usw frei also kann ich bis auf weiteres damit leben.



hmm Programmende würde nicht gehen, zumindest bei mir und meiner ATI nicht, die rendert ohne das eine Finalize nicht. Ich habe das jetzt beim Upload drin es wird also einmal vorm ersten Rendern gemacht.

bis bald

Finalize ist nicht nur für records.....

generell jedes dynamische array (array of T... array[0..0] of T) lässt sich damit finalizen.

Ich fand nur deine Namensgebung für deine Vertexdaten etwas konfus.



oder so ähnlich...

passender wäre doch


das kann man auch beliebig weiter aufdröseln da es ja in der regel mehrere vertex typen gibt ...... VertexPosition, VertexPositionNormal, VertexPositionNormalTexCoord, VertexPositionNormalColorTexCoord usw... damit hat man das dann namentlich ähnlich dem input layout der shader gemapped.

Für die jeweiligen Vertextypen könnte man dann entweder class var oder consts nehmen um den jeweiligen stride oder sizeof festzunageln.

ja? nein? fettnäpfchen?