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

Aktuelle Zeit: Fr Nov 27, 2020 06:31

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 44 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 21:03 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
I0n0s: Das ist natürlich irgendwo ein Argument. Zu viel im SDK und es wird einfach nur undurchsichtiger als so schon. So eine VBO Demo lässt sich aber wohl einrichten. Unabhängig von einer solchen Unit.

Die Unit und solch eine Demo würde ich aber nicht unbedingt direkt in einem Zusammenhang sehen. Das sind meiner Meinung nach schon 2 getrennte Dinge. Evtl sollte die Unit auch nur als "Fremdlib" mit ins SDK aufgenommen werden. Vielleicht ist diese Diskussion im direkten zusammen mit dem SDK auch nicht ganz passend. Es geht ja schon so in die Richtung Unit die von einigen geschrieben wurde um das Arbeiten zu erleichtern. Also damit man sich eben nicht selber mit den Pointern rumschlagen muss.

Modelloader: Ich weiß nicht ob dieser Begriff dort genau das richtige trifft. Denn ein Modelloader ist in der Lage zum Beispiel 3DS oder OBJ einzulesen und diese Objekte darzustellen. Im Falle von 3DS müssen die normalen umständlich per Hand berechnet werden. Restless zum Beispiel geht ein ganzes Stück weiter und lädst definition von Knochen etc. Und das ist evtl etwas viel des Guten. Denn dann würde die Unit nur als Modelloader gesehen werden. Was wohl eher unter dem Begriff Modelloader gemeint war ist die Möglichkeit die Vertexdaten in eine Datei zu schreiben bzw sie wieder einzulesen. Aber wenn man da was einliest, dann sollte man evtl auch unterschiedliche Meshes berücksichtigen. Denn ohne wäre es zu unflexible und so würde es schon ganz okay sein. Viel mehr würde ich da im moment aber wohl nicht sehen.

Sprachenunabhängigkeit. Vom Prinzip her vollkommen okay. Wobei es da aber Leute geben muss die so etwas auch pflegen. Und Java wiederrum kann nicht mit Pointern umgehen. Von daher weiß ich nicht in wie weit es dort zu Problemen kommt, wenn so etwas versucht umzusetzen.

PS: Die Unit die ich da mal als ersten Versuch gestartet hatte ist genau für so etwas ja eigentlich gedacht war. Hatte es da ja auch als "moderiertes Communityprojekt" deklariert bzw nur als aller aller erste Idee.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Nov 06, 2008 23:05 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Überfülltes SDK: also ich stöbere von Zeit zu Zeit gern im SDK. Dort war z.B. das Cal3D zu finden, das ich sonst überhaupt nicht kennengelernt hätte.

Ich wiederhole mal, was sich bisher ergeben hat. Flash, Tak und Lossy und Lord Horazont sind ganz offensichtlich für eine VBO-Unterstützung. I0n0s meint, es könnte nicht gewartet werden, weil zu wenig Human Ressources vorhanden sind.
Für einen Loader gibt es Für und Wider.

Also einmal der Reihe nach:

Loader: ich mache jetzt mal ein pragmatischen Vorschlag. Wie wäre es, wenn wir dem VBO eine Loader-Schnittstelle verpassen? Ich meine eine Streaming-Schnittstelle, an die man einen Loader anstecken kann. Das ist wirklich nicht viel Aufwand und sagen wir mal, vielleicht erbarmt sich einer und passt dann seinen vorhandenen Loader an.

Software-Wartung: Die Pascal-Variante würde ich warten (es sei denn, jemand anderer möchte das machen), ich glaube nicht dass das ein großer Aufwand sein würde. Bei anderen Sprachen muss ich passen, denn davon verstehe ich zu wenig. Dann wäre I0n0s damit nicht belastet und müsste nur ein wenig Speicherplatz dafür reservieren.

Tutorial: Für das Tutorial findet man bestimmt einen Autor, und wenn nicht, springe ich ein, auch das ist mir kein großes Problem.

Für die Software selber gibt es sogar mehrere Anwärter. Das ist mir ein viel größeres Problem. Also, ich denk nicht dran das zu entscheiden. Einmal keppeln reicht mir für heute. Außerdem bin ich gar nicht dafür zuständig. :wink: Ich glaub, ich schlaf mal drüber.
Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Nov 07, 2008 00:31 
Offline
Forenkatze
Benutzeravatar

Registriert: Mi Okt 22, 2003 18:30
Beiträge: 1940
Wohnort: Närnberch
Programmiersprache: Scala, Java, C*
Hallo zusammen,

selten melde ich mich in den letzten Tagen zu Wort, aber die Aktivität in diesem Thread hat mich aufmerken lassen. Kann es sein, dass hier um etwas an sich total simples mehr Aufheben gemacht wird, als die Sache rechtfertigt? Anfangs wurde festgestellt, dass die Verwendung von VBOs für Anfänger abschreckend sein kann, jetzt ist die Rede von Modell-Loadern. Imho geht die Diskussion ein wenig arg auseinander.

Eine sprachunabhängige Schnittstelle für eine VBO-Bibliothek halte ich für etwas Overkill. Der gemeine Anfänger will nichts weniger als mit Tonnen von neuen, unbekannten Bibliotheken bombardiert werden. OpenGL alleine ist schon ein Buch mit sieben Siegeln.

Ich stimme absolut zu, dass man dem Einsteiger zeigen muss, wie er ein VBO erstellen kann und damit umgehen muss. Im Grunde also nichts anderes als das bestehende Tutorial von Sascha: Tutorial_Vertexbufferobject nur für Anfänger leicht verständlich aufgearbeitet.

Am liebsten würde ich den Ansatz verfolgen, die Tutorials, so wie sie sind, im Großen und Ganzen zu belassen und um Beispielcode für OpenGL3 zu erweitern (An den Stellen, wo glBegin; und glEnd; in den Beispielen genutzt wurde).
Der Intermediate Mode ist schlichtweg leichter für Anfänger zu lesen und daher würde ich in Erwägung ziehen, ihn in den Tutorials beizubehalten.
Aber da lass ich mich auch gern umstimmen ;)

Eine Wrapper-Bibliothek, die die Intermediate-Aufrufe entgegennimmt und in VBOs umwandelt, finde ich ebenfalls nicht wirklich passend. Das versteckt die Logik dahinter zu sehr und der Einsteiger lernt nicht mehr OpenGL, sondern das, was wir daraus machen.
Sicher, eine gewisse Abstraktion ist für das Lernen hilfreich, jedoch denke ich, dass das der falsche Weg wäre.

Stattdessen möchte ich den Vorschlag in den Raum werfen, dass mitunter eine einfache Klasse zum Verwalten der VBOs, die ihren Umgang erleichtert, besser wäre. Im Rahmen von easySDL. Die Klasse muss (und sollte) nicht wahnsinnig groß sein, sondern v.A. den Einsteiger vor all zu viel Pointer-Hantiererei bewahren. Inwiefern das so umsetzbar ist, müsste man noch prüfen. Ich denke aber, das wäre ein gangbarer Weg.

just my six cents,
~ Philipp

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Nov 07, 2008 02:13 
Offline
DGL Member
Benutzeravatar

Registriert: So Jun 04, 2006 12:54
Beiträge: 263
Eine Intermediate nach VBO biblieotek hatte nur einen einzigen sinn: Sie würde langfristig den IHVs etwas code ersparen. Nachteil wäre, das zusätzlicher code noch mehr performance verbraucht.

Viel sinvoller ist es einen anfänger erkennen zu lassen welche vorteile VBOs haben. z.B. werden sehr häufig glVertex und ander befehle in einer schleife verwendet nur um ein schon vorhandenes daten array an OpenGL weiterzugeben. Ein besonders häufiger Fall sind einfache modellformate wie OBJ oder MD2 deren datenstrukturen sich eigendlich relativ leicht in VBO kompatible datenstrukturen umwaneln lassen.

Ein anderes beispiel sind selbstgebaute einfache objekte wie quads oder würfel. Oft werden diese durch eine reihe von glVertex befehlen auf die schnelle in den code eingefügt. Der große Nachteil ist, das dieser code zwar einfach erscheint, jedoch ein VBO basierender code nicht länger wäre und später zu einem vollwertigem model loader ausgebaut werden könnte.


Zui den interleaved array kann man nur sagen, das selbst bauen einfachr ist als ständig dokumentation zu wälzen. Man kann sich es einfahc machen, in dem man ein array aus strukturen alloziert (ein wenig auf die ausrichtung auchten und gegebenfalls ein paar dummy chars dranhängen) und als offset die adresse auf das entsprechende element einer Nullpointerinstanz übergeben. Damit spart man sich zumindest in C jegliche offset Berechnungen.
Ob interleaved arrays einen geschwindikeits vorteil haben ist fraglich, jedoch können sie sinnvoll sein um die anzahl der VBOs zu reduzieren in dem man untrennbare daten so vereint.

Nebenbei sind in dem VBO Extension paper auch mal wirklich brauchbare beispiele drin. (ANdere dagegen sind ein wahrer alptraum in denen man erst mal alle erraten darf)

_________________
Lumina plattform unabhängige GLSL IDE


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Nov 07, 2008 09:19 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Frase schrieb:
Zitat:
Stattdessen möchte ich den Vorschlag in den Raum werfen, dass mitunter eine einfache Klasse zum Verwalten der VBOs, die ihren Umgang erleichtert, besser wäre. Im Rahmen von easySDL. Die Klasse muss (und sollte) nicht wahnsinnig groß sein, sondern v.A. den Einsteiger vor all zu viel Pointer-Hantiererei bewahren. Inwiefern das so umsetzbar ist, müsste man noch prüfen. Ich denke aber, das wäre ein gangbarer Weg.

Zu dem gleichen Ergebnis sind wir gestern auch gekommen.

oc2k schrieb:
Zitat:
Viel sinvoller ist es einen anfänger erkennen zu lassen welche vorteile VBOs haben.

Ja, genau. Wir wollen nichts verstecken, sondern erleichtern. Der Umgang mit Pointern ist nicht jedermanns Sache. Was hier genau der Wrapper macht, ist nicht nur im Source Code ersichtlich, sondern soll zusätzlich im Tutorial erläutert werden.

Zitat:
Ein anderes beispiel sind selbstgebaute einfache objekte wie quads oder würfel. Oft werden diese durch eine reihe von glVertex befehlen auf die schnelle in den code eingefügt. Der große Nachteil ist, das dieser code zwar einfach erscheint, jedoch ein VBO basierender code nicht länger wäre und später zu einem vollwertigem model loader ausgebaut werden könnte.

Hier möchte ich jetzt noch einmal einhaken. Ihr müsst Euch vorstellen, was wir da tun. Wir zeigen einem Anfänger, wie er ein Dreieck mit einem VBO zeichnen kann. (!) Das ist ungefähr so, als ob man eine Hand voll Sand mit einem Sattelschlepper transportiert.

Warum ich einen Loader vorgeschlagen habe: ein Vbo schreit m.E. nach einem Loader. In meinen Augen ist ein VBO ohne Loader ein kastriertes Ding. Wo soll ich denn die vielen Daten, die ich jetzt mit dem Vbo schnell zeichnen kann, hernehmen, hm?

Also zumindest eine Schnittstelle für einen Loader wäre dringend zu empfehlen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Nov 07, 2008 10:42 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Wartung: Also was eine Wartung angeht sehe ich das eher sehr entspannt. Wer da was macht kann man ja spontan entscheiden. Ich denke da sollten aus Gründen der Sicherheit sowieso schon auch mehrere dann drüber schauen.

VBO vs. OpenGL 3.0: Wenn 3.0 irgendwann mal etabliert ist, dann werden sie in jedem Falle zwang sein. Aber bis das so weit ist wird wohl noch etwas Zeit vergehen. Interessanter ist da doch eigentlich der Punkt, dass VBOs bereits seit OpenGL 1.5 (2003) fest im Kern verankert sind und wie selten sie eigentlich benutzt werden. Und das liegt daran, dass der eigentliche Aufwand doch so einige abschreckt. Mich persönlich ja auch. Aber VBOs würdenauch jetzt schon lohnen. Das würde ich also nicht zwingend mit 3.0 im Zusammenhang sehen.

Loader: Was verstehst du denn da unter einer Schnittstelle? Also, dass das VBO irgendwie befüllbar ist ist vollkommen logisch. Ob das nun ein Entwickler per Hand erledigt oder ein Loader spielt ja für das VBO in erster Linie nicht die ausschlaggebende Rolle. Allerdings direkt einen Loader für irgendein Format sehe ich bei dem VBO ehrlich auch nicht so recht. Denn solch ein Loader bräuchte ein Format was entsprechende Features unterstützt und dann zu mindest für Blender ein Ausgabeskript. So etwas kann dann sehr schnell zu einem Fass ohne Boden werden. Als Loader gibt es zum Beispiel ja auch Restless. Wenn ich das richtig mitbekommen habe, dann werden dort ja wohl auch schon VBOs benutzt. Also denke ich wird für Restless eine solche VBO Unit vermutlich nicht so interessant oder auch nötig sein. Bzw wird in Restless ja auch einiges mehr gemacht. Von daher würde man ohne die Restless Klassen ja wohl so oder so nicht weit kommen. Und wenn sie sich entscheiden sollten die VBO Klassen intern benutzen zu wollen, dann müssen sie sie ja nur befüllen können. Und das Befüllen eines VBOs ist zu mindest aus meiner Sicht einer der Hauptpunkte die man so oder so benötigt. Da bedarf es dann eigentlich keiner gesonderten Schnittstelle mehr. Und die Benutzung eines VBOs ist ja verhältnissmäßig starr.

Was das Befüllen angeht hatte ich ja schon mal eine erste anfängliche Idee zu Code gebracht. Dabei wird es wichtig sein, dass man größere Datenmengen genau so einfach dort hineinbekommen wie auch einzelne Werte eines Vertices. Das von oc2k1 angesprochene Alignment kann durchaus sehr tückisch sein. Und das sollte man zu mindest Anfänger abnehmen. Oder Leuten wie mich, die sich darum nicht kümmern wollen.

Evtl müsste man auch einfach sagen, dass man das erst einmal ganze bewusst sehr einfach hält und schaut welche Wünsche entstehen, wenn man es tatsächlich benutzt. Wenn konkreter Bedarf besteht kann man es ja immer noch erweitern. Denn wenn man versucht alles abzudecken wird es wieder irgendwo zu kompliziert. Bei der glBitmap habe ich auch so das ein oder andere eingebaut wo ich mir sehr sicher bin, dass es noch nie jemand benutzt hat. Das muss ich aber mit mir rum schleppen. Teilweise steckt da ja auch sogar ein bisschen mehr Entwicklungsaufwand dahinter. Der aber genau genommen für die Katz ist.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Nov 07, 2008 12:20 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Zitat:
Loader: Was verstehst du denn da unter einer Schnittstelle?

Zunächst möchte ich mal klarstellen, dass es selbstverständlich möglich sein muss, die Daten auch im Hauptspeicher ins VBO zu füttern. Aber davon ganz unabhängig möchte ich Euch Folgendes zu Bedenken geben:

Es ist jetzt ein paar Monate her, da wollte ich einen langen Betrag ins Off Topic schreiben, weil ich da grade (lustigerweise zum gleichen Zeitpunkt wie Tak) über ein neues Modelformat nachgedacht habe. Aber ich hab meinen langen Beitrag wieder entsorgt. Weil mir ohnehin keiner zuhören wird.

Zu diesem Thema habe ich damals im GameDev-Forum sinngemäß Folgendes gelesen:
Zitat:
"Warum können wir uns auf keinen Loader einigen? Weil jeder Loader untrennbar mit dem Modell verbunden ist und jeder sein eigenes Modell hat und daher auch seinen eigenen Loader braucht."

An dem Satz hab ich einige Zeit gekaut, denn warum sind die Modelle so unterschiedlich? Wir brauchen Daten, die letztendlich zu einem zweidimensionalen Bild auf der Grafikkarte verwurstet werden. Und seien wir ehrlich: im Untergrund kann z.b. DirectX auch nichts anderes manchen als OpenGL. Die Daten, die dorthin fließen, sind gleich, die Prozesse sind ähnlich, warum um Himmels willen, braucht jeder einen anderen Loader? hab ich mich gefragt. Es gibt ja Ansätze für allgemeine Loader: Collada zum Beispiel. Das ist so übertrieben, dass mir ganz schlecht wird.

Ich verlange jetzt von meinem Loader, dass er für OpenGL optimiert ist. Was ich damit sagen will, ist: Wenn ich OpenGL zugrunde lege, komme ich über die Datenstruktur immer zu einem ganz bestimmten Aufbau für einen Loader. Ich kanns drehen wie ich will, ich komme immer zu etwas Ähnlichem wie ein OBJ-Format. Wie die Daten auf der Platte vorliegen ist ziemlich egal: Text/Binär.
Ich gehe jetzt z.B. von einen Modell aus, das keine Animationen dabei hat, sagen wir mal: ein einfaches Haus mit Textur, oder auch nur ein Würfel. Zusätzlich weiß ich schon, dass ich OpenGL mit VBO verwenden werde. Wie der Loader dafür aussehen muss, ist praktisch FESTGELEGT.

Man KANN (ich weiß es, denn ich habe es gemacht) so einen Loader auch weiterentwickeln. Ohne Restless zu kennen, behaupte ich jetzt mal: da ist höchstwahrscheinlich auch nichts anderes gemacht worden. Ein solchermaßen aufgebauter Loader hat also Potential. Das ist keine Sackgasse.

Versteht mich jetzt nicht falsch: ich will Euch nicht meine oder auch irgendjemandes Software aufdrängen. Sondern ich möchte Euch zeigen, dass man, wenn man ganz konsequent ist, immer zur gleichen Lösung kommt. Wenn wir eine bestimmte Art und Weise auswählen, wie wir unsere Daten an OpenGL schicken, kommen wir immer zum gleichen Loader-Code. Aus diesem Grund behaupte ich, dass man, wenn man diesen Loader (der geradzu winzig ist und sich mit reinem Programmcode ohne irgendwelche Libs verwirklichen läßt) schon nicht dabeihaben will, wenigstens eine Schnittstelle dafür angibt. Dieser Schnittstelle kann es praktisch egal sein,in welchem Format die Daten vorliegen. Am besten ist es eben, wenn sie in einem VBO-ähnlichen Format vorliegen.

Lossy: Du kannst Dir diese Schnittstelle leicht selber ausmalen: wie kriegst Du Deine Daten von der Platte in Dein VBO (ein VBO, das so simpel wie möglich ist) z.B. mit FileStream; dann hast Du Deine Schnittstelle. Das VBO sagt zum Loader: "Hast Du Vertices? Ja? wie Viele? Mhm. Bitte hier in diesen Puffer leeren."

Denn was passiert:
1. Wir haben ein Tutorial für VBO, sieh Dir das an
2. Fein ich kann ein Dreieck zeichnen. Kann ich auch eine Figur zeichnen?
3. Du musst Daten laden. Schreib Dir Deinen Loader selber. Hier schreibt sich jeder seinen Loader selber.
4. Wie schreibt man einen Loader?
5. Sieh nach im Tutorial XY...
6. Hilfe! wie krieg ich die Daten vom Loader in den VBO?
....

Und weißt Du, wer sich das antun wird Lossy? Dreimal darfst Du raten.....


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Nov 07, 2008 16:18 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2576
Wohnort: Berlin
Programmiersprache: C/C++, C#
Zu diesem Thema habe ich damals im GameDev-Forum sinngemäß Folgendes gelesen:
Zitat:
"Warum können wir uns auf keinen Loader einigen? Weil jeder Loader untrennbar mit dem Modell verbunden ist und jeder sein eigenes Modell hat und daher auch seinen eigenen Loader braucht."

Den Satz sollte man als Button in das Texteingabe Formular hinzufügen.
Es ist einfach mal völlig korrekt und unterschreibe ich sofort.
Wieso ?
Simples Beispiel: Ich benutze jetzt einfach mal mein Modelformat und Oc2k1 kommt an und sagt, ich brauche aber Tangenten und Binormalen im Format und für mein Geometry Shader will ich auch Splines definieren können. Tada... Mein Daten Modell ist nicht mit dem von Oc2k1 sein kompatibel und umgekehrt.

Man muss erstmal zwischen Mesh und Model unterscheiden, das Mesh sind OpenGL Daten und ein Model sind zu interpretierende Daten, die zu einem Mesh gemacht werden.
Darum kann man z.B. ein einheitliches Texturformat, Meshformat, Shader basteln aber kein Model, Material oder Level Format.

_________________
"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: Fr Nov 07, 2008 17:00 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Ich persönlich kenne mich mit Modellen gar nicht aus, da ich sie noch nie benötigt habe und wohl auch nie benötigen werde. Entsprechend ist mein Wissen dort nur begrenzt. Wenn man in irgendeiner Form eine einheitliche Lösung anstrebt, dann finde ich das in jedem Fall gut. Ich bin absolut kein Fan davon, dass jeder sein eigenes Ding vor sich hin brödelt.

Was mich allerdings etwas iritiert ist das ein Modelloader und die Kappselung einer OpenGL Funktionalität da so stark miteinander verwoben zu sein scheinen. In meinen Augen ist ein VBO ein Bestandteil eines Modelloaders. Bzw das VBO dient zum Ablegen und Zeichen von Vertexdaten. Und das ist ein Bestandteil eines Modelloaders. In Programierersprache würde ich also sagen, dass der Loader eine eigenständige Klasse ist der eine oder mehrere VBO Klasse benutzt. Bzw evtl sogar, dass der Loader von der VBO Klasse abgelitten ist. Aber mein persönlicher Stil würde mir eher zu Erstem raten.

Das die VBO Klasse entsprechend aufgebaut sein muss, dass man dort Daten auf den verschiedensten Wegen hineinbekommt ist vollkommen klar. Das einer der Wege ein TStream sein kann steht ja auch vollkommen außer Frage. Alleine schon deswegen, weil man evtl. erstellte Daten mal abspeichert und später wieder verwenden möchte. Nur wenn es darum geht, dass man komplexe Formate einliest, dann sollte das wohl jemand machen der über einem VBO steht. Ein VBO ist sozusagen nur ein einzelnes Mesh und ein Modelloader ist ein Verwalter von verschiedenen Meshes. Besonders um Anfänger nicht zu sehr zu verwirren würde ich das vielleicht sogar räumlich in 2 verschiedenen Units trennen. Dann könnte man so etwas auch erweitern ohne an einem VBO etwas ändern zu müssen.




Um da evtl noch was anderen klar zu sagen. Wenn ich Modelloader höre, dann höre ich auf keinen Fall etwas was 10000 Vertices von der Festplatte liest. Sondern etwas was komplexe Strukturen einliest. Und die komplexen Strukturen würden aus mehreren Meshes bestehen die evtl sogar noch unterschiedlich definiert sind. Und genau darauf beziehen sich alle meine Annahmen und Aussagen. Evtl liegt das Problem ja bereits in dem Verständniss des Begriffes "Model-Loader" begraben. Möchte ich auf gar keinen Fall ausschließen!


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Nov 08, 2008 07:56 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Tak2004 schrieb:
Zitat:
Simples Beispiel: Ich benutze jetzt einfach mal mein Modelformat und Oc2k1 kommt an und sagt, ich brauche aber Tangenten und Binormalen im Format und für mein Geometry Shader will ich auch Splines definieren können. Tada... Mein Daten Modell ist nicht mit dem von Oc2k1 sein kompatibel und umgekehrt.

Nun ja, das mag in einer fortgeschrittenen Stufe so sein, ja. Aber am Grundlevel? Ich will nur die Daten für ein VBO laden, ev. mit einer Textur dazu. Weder oc2k noch Du sind als toller 3D-Programmierer auf die Welt gekommen. Viel interessanter wäre zu wissen, wie der erste Loader ausgesehen hat, der mit dem man angefangen hat zu experimentieren. Und ich wette, wenn man Deinen ersten Loader mit seinem ersten Loader vergleicht, sind die Unterschiede schon viel kleiner.

Lossy Ex schrieb:
Zitat:
Um da evtl noch was anderen klar zu sagen. Wenn ich Modelloader höre, dann höre ich auf keinen Fall etwas was 10000 Vertices von der Festplatte liest. Sondern etwas was komplexe Strukturen einliest.

Du sprichst hier von einem ausgefeileten Loader z.B. für ein Spiel. Ich spreche von einem einfachen, kleinen winzigen Loader für Anfänger, mit dem er erste Tastversuche anstellen kann.

Jedes Kind lernt anders. Jeder Mensch hat eine andere Methode, um sich neue Fakten "in den Kopf zu hängen". Aber eines ist bei allen gleich: man muss zunächst einmal ein Loch in ihre natürliche Barriere gegen neuen Lernstoff bohren. Wie macht man das? Man macht sie neugierig und versucht ihnen ein Aha-Erlebnis zu bescheren. Wenn Du ihnen jetzt etwas Fertiges vor die Nase hältst, dann ergreifen sie die Flucht. Eine ganz natürliche Reaktion. Es gilt hier genau das gleiche wie oben beim VBO: ein toller Loader ist in dieser Situation einfach nicht angebracht.

Es gibt ein Delphi-Forum, das einige Zeit die Auffassung vertreten hat, dass sie nur Experten haben wollen. Dort herrschte ein ziemlich rüder Umgangston. Ich weiß auch nicht, ob sie das mit den Experten wirklich erreicht haben. Es ist mir auch ziemlich egal. Ich bin dort schon lange nicht mehr gewesen :wink: Was ich aber mit Bestimmtheit weiß, ist, dass Experten nicht vom Himmel fallen. Man muss sie heranziehen. Das ist eine lange und mühsame Sache denkt Ihr Euch jetzt vielleicht. Aber ist das nicht genau der Daseinszweck dieser Website?

Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Nov 11, 2008 10:58 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Hatte in den letzten Tagen leider nicht ganz so viel Zeit.

Traude hat geschrieben:
Du sprichst hier von einem ausgefeileten Loader z.B. für ein Spiel. Ich spreche von einem einfachen, kleinen winzigen Loader für Anfänger, mit dem er erste Tastversuche anstellen kann.

Das ist zu mindest das was ich unter dem Begriff Model Loader verstehe. Und ich denke vielen anderen wird das nicht anders ergehen. Evtl sollten wir da später (auch um Verwirrungen und Missdeutungen des Projektes zu vermeiden) den Begriff Model-Loader eher nicht direkt gebrauchen. Vielleicht sollten wir eher so etwas wie "stored vertex buffer objects" dazu sagen. (nur ein Geistesblitz. Muss nicht immer gut sein ;) ). Denn sonst könnte ich mir auch gut vorstellen, dass das Projekt missverstanden und nur auf den Loader reduziert wird. Und dann werden sich vermutlich Featureanfragen nach Loaderfunktionen häufen. Und das ist ja eigentlich nicht ganz was damit beabsichtig ist. Also das ist zu mindest eine Befürchtung von mir.



Ich würde da aber evtl auch vorschlagen, dass man die beiden Sachen auch räumlich trennt. Also BufferObject und Loaderteil vielleicht sogar in 2 Units. Bzw wenn man als Grundlage meinen ersten Versuch sieht, dann würde ich die Klasse auch noch mal in 2 Klassen "zerreißen". Dann wäre alles strikt nach Funktionalität getrennt. Und das wäre für den Überblick und den Lerneffekt einfach nur positiv.

TBufferObject enthält die Verwaltung eines BufferObjectes. Also erstellen/löschen/binden. Speicher alloziieren, Daten uploaden, Speicher mappen etc.
TVertexBufferObject ist eine Ableitung von TBufferObject. Diese Klasse wäre dann etwas spezieller und würde eine Definition eines VertexBufferObjectes erlauben. Bzw wäre auch in der Lage das Bufferobject mit Daten zu befüllen. Also wenn man das per Code macht entweder Werte eines Vertex oder eben komplette Bereiche etc.

TSimpleModel (mir ist kein bessere Name eingefallen) wäre eine Klasse die nicht in der Vererbung von TBufferObject enthalten ist sondern sie würde "nur" beliebig viele Instanzen von TVertexBufferObject benutzen. Also beliebig viele kleine Meshes die zu einem Objekt zusammengefügt werden. Diese Klasse wäre dann also der erste wirkliche Anwendungsfall der VBO Klasse.


Das wäre zu mindest so eine Idee für eine Struktur. Ich bin mir aber noch so gar nicht im klaren wie man die erste Klasse aufbauen sollte. Denn BufferObjects kann man auf verschiedene Arten benutzen. Also entweder man erstellt die Daten komplett lokal und lädt diese dann mit glBufferData in das BufferObject. Oder aber man sagt ich möchte 5MB Speicher alloziieren, mappt diesen (writeonly) und schreibt dann seine Daten dort hinein. Der Vorteil dabei ist, dass der Speicherbereich aus dem Treiber stammt und dann asynchron zur Karte übertragen wird, wenn diese mit aktuellen Aufgaben fertig (Streaming). Wärend die erste Methode ein synchrones Übertragen erzwingt. Bei der zweiten Methode muss man aber von Anfang an wissen wie groß die Daten sind. Die dürfen dann aber nicht größer werden. Wenn die Daten lokal sind wäre das egal, da man die mal eben in einen größeren Bereich kopieren kann.

Evtl wäre es da mal interessant zu erfahren wie VBOs bereits eingesetzt werden? Also mit der Frage ziele ich speziell auf oc2k1 und tak. Natürlich dürfen auch alle Anderen was dazu sagen. Steht ja völlig außer Frage. ;)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Nov 11, 2008 13:02 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Entschuldige, dass ich mich ein bissel vordränge. Ich fasse mich ganz kurz.

Zitat:
Vielleicht sollten wir eher so etwas wie "stored vertex buffer objects" dazu sagen

Wie wir es nennen, ist mir egal. Hauptsache, es gibt so etwas.

Zitat:
Ich würde da aber evtl auch vorschlagen, dass man die beiden Sachen auch räumlich trennt. Also BufferObject und Loaderteil vielleicht sogar in 2 Units.

Da bin ich für jede Alternative zu haben. Eine Unit, zwei Units, .... was immer Du willst. Vielleicht nur ein klitzkleiner Vorschlag? Der Loader sollte mit einem einfachen Grafik Format kompatibel sein. Also etwas, was es in Blender als Exporter gibt. *Duck*

TBufferObject, TVertexBufferObject, TSimpelModel,...ist mir alles recht. Hier finde ich die Hauptsache, dass man nicht alles so zu wrappt, dass man den Untergrund nicht mehr sieht.

Zitat:
Ich bin mir aber noch so gar nicht im klaren wie man die erste Klasse aufbauen sollte.

Na, ich denke wir sollten uns für die Implementierung zwischen Schnelligkeit und Flexibilität entscheiden. Wir sollten jetzt nicht den Fehler machen und das Ding überfrachten. Ausbauen kann man es später immer noch. Das ist ja das Schöne an OOP. :wink:
Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Nov 15, 2008 10:23 
Offline
DGL Member

Registriert: Di Jun 06, 2006 09:59
Beiträge: 474
Ich arbeite momentan an einem OOP wrapper für VBOs. Ich denke dass das interface bald fertig sein dürfte, die implementierung braucht aber wohl noch etwas. Da ich helper objekte verwende ist der code aktuell allerdings nur in neueren Delphis zu gebrauchen.

_________________
Bild


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Nov 15, 2008 13:40 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Helper Objekte? Für die Schnittstellen zum Daten einfüttern?

Äh, und Experten sind hier dringend gefragt. Es geht einfach darum, was die Leute am nötigsten brauchen. Wenn jemand einen Wrapper schreiben will, was würdest Du zum Beispiel vorschlagen?

Ich selber habe letzte Woche meinen ersten VBO geschrieben, ich geb es ja zu. Und ich habe gleich einen schweren Fehler gemacht: Ich habe es viel komplizierter implementiert als nötig. Mit Index, der gar nicht gebraucht wurde. :oops: Die vielen Möglichkeiten haben mich verwirrt. Ich wollte eigentlich ein Beispiel fürs SDK schreiben. Aber ich muss es nochmal überarbeiten.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 44 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 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.032s | 17 Queries | GZIP : On ]