Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 23:44

Foren-Übersicht » Sonstiges » Meinungen zu den Projekten
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 14 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: @glVBO.pas
BeitragVerfasst: Mo Sep 22, 2008 15:29 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Meinungen, Wünsche, Anregungen, Diskussionen etc. ;)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Sep 22, 2008 15:48 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Ohne es ausprobiert zu haben fange ich einfach schonmal mit dem Meckern an ;) (für einen Test fehlt mir im Moment leider die Zeit, aber meine Ideen und Hinweise würd ich trotzdem gern abgeben).

Also... Wird das mit den mehrere Daten vom gleichen Typ, also z.B. mehrere Texturkoordinaten, noch dazukommen? Das wäre für Shaderanwendungen sehr wichtig, auch Vertexattribute sollten nicht außer acht gelassen werden.

Ansonsten finde ich das ne Klasse Idee, weil ich mich mit VBOs immernoch schwer tue und sowas auch mal angefangen haben wollte, aber irgendwie ist immer wieder was dazwischen gekommen ;).

Gut Glück!
Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Sep 22, 2008 19:32 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Lord Horazont hat geschrieben:
..., aber meine Ideen und Hinweise würd ich trotzdem gern abgeben

Da bitte ich doch drum. :) Missstände etc kann man nur ausgleichen, wenn man sie kennt und jeder hat andere Prioritäten. Wer also ein Anliegenhat und es nicht sagt ist selber Schuld.

Lord Horazont hat geschrieben:
Also... Wird das mit den mehrere Daten vom gleichen Typ, also z.B. mehrere Texturkoordinaten, noch dazukommen? Das wäre für Shaderanwendungen sehr wichtig, auch Vertexattribute sollten nicht außer acht gelassen werden.

Ansonsten finde ich das ne Klasse Idee, weil ich mich mit VBOs immernoch schwer tue und sowas auch mal angefangen haben wollte, aber irgendwie ist immer wieder was dazwischen gekommen ;).

Ja das ist mir wärend dem Schreiben des Posts auch so aufgefallen, dass das mitunter doch etwas unpraktisch sein könnte. Aber ja. dann wird das etwas sein was in jedem Fall recht hoch priorisiert sein wird. Wobei VertexAttribs auch noch gar nicht unterstützt werden. ;)

Allerdings bin ich für Vorschläge offen die die Adressierung beim Datenschreiben betreffen. Denn aktuell positioniere ich die Daten mit dem ElementTypen und der Dimension. Nur die Dimension wäre dann überflüssig. Wenn man 2 mal das Gleiche braucht dann kann man es seperat erstellen. Wenn man beim AddElement einen Index zurück liefert und diesen dann bei Write übergeben müsstem dann hätte man wahrscheinlich manchmal 0 Plan wo man gerade Daten hinschreibt. Weswegen der ElementTyp schon ganz angenehm ist. Aber da immer noch einen ElementZähler ist auch irgendwie na ja, denn dann gibts immer 2 Parameter was bei vielen vermutlich übertrieben wäre, denn ich denke häufig wird man das eher nicht brauchen. (Das es notwendig ist steht außer Frage). Ich habe nur gerade geschrieben was mir so durch den Kopf ging. Ich weiß ich sollte das zukünftig lassen. Könnte den ein oder anderen verschrecken. :twisted:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Sep 22, 2008 23:52 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich habe ein wenig in die glVBO.pas hineingesehen und bin bei der eher kleinen Methode BindIndexBuffer hängengeblieben. Ich habe keine wirklichen Kenntnisse über VBOs, denn ich habe sie bisher noch nicht verwendet, nur das Tutorial durchgelesen. Aber ich habe mich vor kurzem mit den VertexArrays beschäftigt. Und ich glaube mich erinnern zu können, dass dort die Möglichkeit besteht, mehrere Indizes anzugeben. Stichwort: Level Of Detail. Wäre eine Option für Dein Vorhaben.

Die Idee einen Wrapper für VBO zu schreiben finde ich sehr gut, denn Pascal-Programmierer halten sich im allgemeinen von Zeigern fern. *duck und weg* :P


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Sep 23, 2008 10:07 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Och also ich mag Zeiger. Muss wohl meine masochistische Ader sein. :twisted:

Und ja. Vertex Arrays sind den Vertex Buffer Objects recht ähnlich. Nur, dass die Buffer Objects im Speicher der Grafikkarte arbeiten. Das mit verschiedenen Indizes sollte aktuell eigentlich schon über seperate Instanzen vonTglVBO gehen. Allerdings das mit den mehreren Instanzen ist auch nicht so das Wahre. Wobei das aber mitunter auch Vorteile haben kann. Beim Mappen zum Beispiel. Dynamische Strukturen etc. Allerdings alles in einer Instanz hat auch seinen Charm.

Wobei der aktuelle Aufbau auch nur ein erster Versuch ist. Also das steht alles noch überhaupt nicht fest und gibt sicher noch bessere Designs. Aber ich bin für Idee, Vorschlag oder Wünsche jeglicher Art dankbar. :)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Sep 23, 2008 12:50 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich denke du solltest mal die Klasse ein bischen aufbrechen.
Das macht alles ein bischen flexibler.

*kleines gedankenspiel an*
Also eine Klasse VertexBufferObjectArray, welche mehere VertexBufferObjectData enthalten kann.
Eine Klasse VertexBufferObjectData, welche jeweils ein VertexBufferObject, VertexAttributObject und UserDataObject fassen kann, also ein Container.
UserDataObject kann der Entwickler ein Pointer Hinterlegen, VertexAttributObject enthält settings und Attribute für ein VBO und VertexBufferObject enthält das VBO.
UserDataObject ist nur ein Container und braucht nicht mehr als ein pointer.
VertexAttributObject könnte dann z.B. GL_VERTEX_ARRAY,GL_NORMAL_ARRAY,... enthalten und GL_ELEMENT_ARRAY_BUFFER,... sowie andere nützliche Attribute zu einem Buffer enthalten.
VertexBufferObject ist dann der Buffer selber.

So ist ein VertexBufferObjectArray ein komplettes Mesh.
Wobei jedes Kind in der Liste ein Teil vom Mesh ist, z.B. Vertexbuffer, Indexbuffer,TexturCoordBuffer,... .
Durch das Ableiten von dieser Klasse und das überladen der Draw, Bind, UnBind Methode, kannst du dann bequem alles machen, was du willst.
Ein Parameter VertexBufferObjectData kannst du bei Bind und UnBind dann nutzen um z.B. für ein eigenes Modelformat an die UserData zu gehen, wo noch nützliche Infos liegen. Im Draw kannst du deine bind und unbind Befehle effektiv gestalten.
*kleines gedankenspiel aus*

Also sowas in der Richtung halt. ^^
Weil eine Klasse in der ich AddVertex,AddNormal,... finde ich nicht so gut.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Sep 23, 2008 15:11 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Ich find diese einzelnen Add-Methoden gerade für Anhänger des Immediate Modes (wie ich einer bin *duck*, wobei ich das ändern muss) sehr praktisch. Für Einsteiger wird das sehr gut sein, wenn der Immediate Mode irgendwann ausgestorben ist, da ich mir vorstellen kann, dass man, wenn man gerade in die Grafikprogrammierung einsteigt, VBOs einen einfach erschlagen.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Sep 23, 2008 21:11 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Was aufbohren angeht bin ich da in jedem Fall für. Das ist auch wirklich nur eine aller erste Idee mit dem Schwerpunkt auf die pointerlose Erstellung von Vertexdaten. Mir persönlich geht da eher um einfache Bedienung. Da bin ich auch mehr oder weniger bereit ein bisschen Features/Flexibilität zu opfern.

Ich denke es liegt daran, dass ich gerade ziemlich erkältet bin und ich mich mit allem etwas schwer tue. Aber ich muss gestehen, dass ich dein Post 5 Mal gelesen habe und mir ehrlich nicht sicher bin, ob ich da so recht verstanden wie du das meinst. Wenn du für jeden Typen (Vertex, Color, Normalen) ein extra Objekt hast, dann sind ja einzelne Teile eines einzelnen Vertex mitunter vollständig seperat abgelegt und werden seperat verwaltet. Andere alternative wäre, dass es eigentlich mehr als nur ein Objekt geben wird. Aber die Objekte an sich jeweils ein eigenes vbo kappselt was in sich konsistent ist. Nur eben, dass es mehr als eines gibt. Ala Liste.

Bei meinem Vorschlag ist es aber nicht so, dass es so etwas wie ein AddNormal geben wird. Es wird eine dynamische Vertexdefinition erstellt und dann wird eine Anzahl X dieser Vertices erstellt. Beim Binden kann man dann wieder die einzelnen Elemente auswählen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 03, 2009 09:36 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich schreibe grade an der Doku für mein Projekt. Da lass ich mich immer furchtbar leicht ablenken, weil alles andere viiiiel interessanter ist. Du erinnerst Dich vielleicht, dass ich irgendwo mal den Vorschlag gemacht habe, eine Loader-Schnittstelle in dem VBO-Objekt vorzusehen. Ich habe jetzt eine herzeigbare Variante geschrieben. Ist keine fertige Schnittstelle, nur die Idee, wie es gehen könnte.

Folgendes wollte ich mache können:
MyVBOMesh:= TVBOMesh.Create(....)
MyVBOMesh.LoadFromFile(........)
Und er soll prinzipiell das Format selber prüfen und dann den dafür vorgesehenen Loader selber auswählen. Im schlimmsten Fall sagt er mir, dass er das nicht laden kann, weil er keinen solchen Loader hat. Genau so wie ein anständiger Image-Loader eben.

Folgende Voraussetzungen hatte ich mir vorgegeben:
*** Das Loader-Objekt muss ganz getrennt vom VBO-Objekt sein
*** Die Daten, die geladen werden sollen, müssen vom VBO-Objekt gehalten werden (Speicherplatz anfordern und freigeben darf nur das VBO-Objekt selbst, das ist sehr wichtig)
*** Fürs Uploaden der Daten habe ich die Variante „im Hauptspeicher zwischenlagern“ gewählt, weil ich die Daten noch brauche, um irgendwelche Dinge damit anzustellen, Stichwort: Physikdaten erzeugen
*** Dem Loader muss die Möglichkeit gegeben werden, das File wiederholt lesen zu können. Bei Bildern sind alle zum Laden nötigen Daten meistens im Dateiheader vorhanden, bei Meshes ist das häufig nicht so. Manchmal haben nicht mal die einzelnen "Chunks" einen Header, z.B. wichtige Angaben für das Anfordern von Speicherplatz (wieviele Vertices folgen jetzt?) stehen manchmal einfach nicht drin. Da bleibt einem eben nichts anderes übrig, als die Vertices selber zu zählen, das bedeutet: wiederholtes Parsen. :evil:

Diese letzte Forderung lässt ein Dilemma entstehen: eigentlich sollte das VBO-Objekt das Loader Objekt beherrschen. Das geht aber nicht, weil beim Laden der Loader die Führung übernehmen muss: Vorwärts/Rückwärts parsen, Achtung jetzt kommen 80 Texturkoordinaten, und hier kommen die Daten dafür und hoppla, jetzt müssen wir ein paar Chunks zurück.

Das hört sich ganz harmlos an, aber ich habe einige Zeit darüber gebrütet. Es muss nämlich der Loader sein VBO-Objekt kennen aber umgekehrt muss auch das Objekt seinen Loader kennen, denn es muss ihn ja erzeugen können. Ich hatte zuerst eine Variante mit Callbackroutinen. Das hat zwar funktioniert, aber angesichts des Ergebnisses habe ich eine zusätzliche Forderung aufgestellt:

*** Der Code muss leicht lesbar sein. :roll:

Und dann habe ich alles wieder verworfen, weil ich beim bloßen Ansehen des Codes Magengeschwüre gekriegt hab.

Jetzt hätte ich etwas Einfacheres, in Pascal natürlich, bei mir läuft es unter Windows und Linux. Interessiert Dich das? Ich frage vorher, weil ich das Ding aus meiner Maschinerie herauslösen muss. Wenns Dich interessiert, würde ich mir die Arbeit machen, ein funktionierendes Delphi-Projekt draus zu machen und den Code hier herein zu stellen.
Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 03, 2009 13:04 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Wieso muss das Objekt seinen Loader kennen?

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 03, 2009 14:09 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Na, irgendwer muss doch entscheiden, welcher Loader gebraucht wird: entweder ist es ein OBJ- oder ein MD5 oder ein Milkshape oder Collada oder ein IchWeißNichtWasFürEin- File. Diese Feststellung obliegt dem VBO-Objekt. Aufgrund dieser Entscheidung muss es einen OBJ- oder MD5- oder MilkShape- oder Collada oder IchWeißNichtWasFürEinen Loader erzeugen. Wenn das VBO-Objekt die Loaderklasse nicht kennt, kann sie auch keine solche erzeugen sondern nur eine Exception werfen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 03, 2009 14:29 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Na ja. Aber das darf keine Sache des grundlegenden BufferObjektes sein. Wenn dann sollte maximal die grundloader klasse die Formate kennen. Wobei ich da aber sogar eher dazu tendieren würde, dass die einzelnen Formate nur Ableitungen des Basisloaders sein sollten. Denn wie wahrscheinlich ist es, dass man versucht ein Format zu laden was man nicht kennt. Ich würde behaupten, dass es eher unwahrscheinlich ist. Ist aber nur meine Meinung, die keinesfalls immer richtig ist. Ich persönlich kenne mich mit solchen loadergeschichten einfach überhaupt nicht aus.

Was dein Angebot angeht sage ich schon mal danke. Allerdings aktuell kannst du dir die Arbeit wirklich sparen. Denn ich habe, mangels Zeit, seit dem letzten Post noch keine weiter Zeile Code geschrieben. Also wäre die Investition deiner Zeit da derzeit vergebens.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 03, 2009 17:51 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
@traude: Das klingt ganz klar nach einer Factory. Die liefert anhand der Datei, den passenden Loader zurück.
Der Loader selbst lädt nur, Das VBO selbst hält die Daten nur vor. Entscheidungen was wann gemacht werden soll gehört in keine von beiden wirklich rein.

Mal einen schlauen Spruch bringen: "Jede Klasse hat eine Aufgabe und nur diese Aufgabe." Hab ich mal wo gelesen. ;)

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Feb 03, 2009 21:11 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Naja, da bin ich nicht so ein Purist. Wenn ich nur zwei Objekte habe und der Code, der nirgends reinpasst, ist nur ein paar Zeilen lang, - denn viel mehr ist es ja wirklich nicht -, dann quetsch ich es irgendwo rein. Diese Funktionalität des Auffinden des Formats habe ich ja auch noch gar nicht drin. Es ist nur die Demonstration einer Idee, nichts weiter.

Das Stückchen Software, was ich da geschrieben habe, war ja eigentlich nur als Diskussionsbeitrag gedacht. Vielleicht war ich ein wenig überschwenglich. Wenn es nach Drängeln ausgesehen hat: das wollte ich nicht, tut mir leid.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 14 Beiträge ] 
Foren-Übersicht » Sonstiges » Meinungen zu den Projekten


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 14 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.122s | 17 Queries | GZIP : On ]