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

Aktuelle Zeit: Do Mär 28, 2024 16:06

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



Ein neues Thema erstellen Auf das Thema antworten  [ 44 Beiträge ]  Gehe zu Seite 1, 2, 3  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 05, 2008 10:29 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Hallo, Ihr alle
Der lange Beitrag, den Lossy heute im Anfängerforum geschrieben hat, gibt mir zu denken. Das ganze klingt im Endeffekt ziemlich negativ.

Ich schreibe hier deshalb, weil ich versucht habe, mir auszumalen, was ein "Neuer" tun wird oder auf welche Hilfsmittel er zurückgreifen wird. Und ich habe versucht, mir vorzustellen, selber ein einfaches, selbsterklärendes Programm zu schreiben, das NICHT immediate Mode ist. Das Ergebnis wäre für einen Anfänger imho schlicht und ergreifend ABSCHRECKEND: Delphi + SDL + VBO? Ich selber habe so etwas ähnliches kürzlich mit indizierten Vertexarrays gemacht (Nur Delphi, ohne SDL). War aber auch nicht wirklich das Gelbe vom Ei für einen Anfänger.

Ich finde, Handlungsbedarf ist gegeben; es ist dringend. Es sei denn Ihr habt schon etwas im Hintergrund auf die Beine gestellt, ohne uns etwas zu sagen.
Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 05, 2008 11:36 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Das ist es, was ich in den Threads zu OpenGL 3 zum ausdruck bringen wollte. Irgendwann wird OpenGL 3 standard sein und OpenGL 2 verpönt, keiner wird es mehr nutzen. Und dann gibt es immernoch leute, die komplett unvertraut mit der Materie sind, die keine Ahnung von OpenGL haben. Das sind dann die Einsteiger, die sich mit VBOs rumschlagen müssen. Ich denke auch, dass da eine Lösung her muss, um es einsteigern möglichst einfach zu machen. Ich habe mir schon überlegt, ob ich eine Klasse zum simulieren des Immediate Modes über VBOs schreibe... Die Idee existiert noch, der erste Versuch ist aber leider nicht geglückt. Da das komplett entkoppelt von OpenGL wäre und erst beim endgültigen erstellen des VBOs an die Graka käme, müsste man sich auch keine größeren Sorgen um die Befehle machen, die zwischen glBegin und glEnd eigentlich nicht erlaubt sind. Diese würden dann sozusagen vor dem VBO ausgeführt.

Vielleicht kann ich ja diesmal sogar ernsthaft was zu den DGL-Projekten beitragen. Bisher hat das ja nur beim Wiki richtig geklappt ;).

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: Mi Nov 05, 2008 12:43 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich weiss nicht, ob das mit dem Immediate-Mode-Simulieren so eine gute Idee ist. Ich glaube, ein Anfänger kann ja durchaus begreifen, dass das einzelne Schicken der Vertices ein Problem ist, und dass er sie besser als Einheit betrachten sollte (man schickt ja auch die Texturen nicht Pixel für Pixel an die Grafikkarte). Ein Wrapper an sich klingt aber gut, finde ich. Lossy hat mal so etwas angedacht. Ich erinnere mich, dass er damals sagte: "das ist KEIN Model Loader". Und genau da dachte ich: warum eigentlich nicht? Ein gewrapptes VBO mit direkt angeschlossenem Model Loader wäre doch was. Aber es müsste alles ganz einfach und durchschaubar gehalten sein. Was ist z.B. mit diesem Restless-Loader? Wäre der nicht ein Kandidat dafür?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 05, 2008 12:47 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Das Problem beim Immediate Mode und VBO ist erstmal die Sync. .
VBO hat schon alle Vertice Daten und sendet diese dann mit einmal in den Speicher und wird dann auf anfrage gezeichnet.
Beim Immedate Mode werden die Vertice häpchenweise hochgeladen, sofort durch die pipeline gejagt(Transformation) und wenn genug Daten vorliegen, werden die Daten weiter in der Pipeline verarbeitet(restliche pipeline).
Das ganze wird also ziemlich lahm, wenn du eine Simulierung von Immediate über VBO machst und meiner Meinung auch recht Sinnfrei.
Wieso sollte ich etwas verwenden, was es nicht mehr geben wird und künstlich nochmal eingebaut würde.

Da wäre so als ob ich ein Feuerzeug in die Hand gedrückt bekomme, um Feuer zu machen und dann erstmal nen Feuerstein, kleine Äste und trockenes Moos suchen geh und dann damit Feuer mache. Ganz zu schweigen, dass ich ihn noch beibringen müsste wie man die Komponenten kombiniert um, das Feuer hin zu bekommen. Nur weil den alt eingesessenen OGL'lern teilweise VBO ein bischen komplex und ungewohnt vor kommt, bedeutet das nicht, dass es Neulingen auch so geht. Benutzt die Energie lieber, um ein gutes VBO Tut zu schreiben.

_________________
"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: Mi Nov 05, 2008 13:04 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Zum Thema VBO und Modelformat kann ich nur zustimmen, VBO macht das entwickeln von Modelformaten sehr einfach und wesentlich kürzer.
Mein Letzter Model Loader ist rund 200 Zeilen lang und ist direkt für VBO konzipiert.
http://wiki.delphigl.com/index.php/Modelformat
Ich finde VBO ehrlich gesagt wesentlich einfacher zu verstehen als den Immediate Mode und wesentlich einfacher zu benutzen.
Der Immediate mode ist viel zu kompliziert und hat viel zu viele Abhängigkeiten, die man Wissen muss.
Alleine schon der Fakt, dass ich wissen muss, welche Funktionen zwischen glBegin und glEnd Funktionieren und welche nicht, wieso es überhaupt so ist(render pipeline und synchronisierung zwischen cpu und gpu). Ich glaube viele sehen einfach nur den klassichen Fall glBegin(GL_QUADS); glvertice3f(...);glvertice3f(...);glvertice3f(...); glvertice3f(...); glEnd(); zu sehen aber nicht z.B. die Reihenfolge von glColor, glTexCoord, glVertice, glNormal die man beachten muss oder wieso glColor3f(1.0f,0.0f,0.0f); glVertice3f(...); glvertice3f(...); ... die Farbe für alle übernimmt(wissen über Statemachines also OGL interne Arbeitsweise).
Beim VBO muss ich zwar die doch recht komplexen Befehle zum Erstellen und Darstellen(viele Parameter) lernen aber damit war es dann auch schon mit schwer gewesen. Ich bin der Meinung, dass man die Mischformate(z.B. vertice,texcoord,color) bei VBO auch entfernen sollte, da man mit einzelnen Datenstreams(vertice, normals, texcoords, colors, indices) wesentlich performanter und Flexibler ist.

_________________
"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: Mi Nov 05, 2008 13:56 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich fände so eine Zusammenstellung auch gut. Dein Modelformat und ein VBO Wrapper obedrauf. Ja, sicher: ein KLEINER schneller Modelloader hat seine Meriten. Aber wir sind hier nicht alleine. Was sagen denn die anderen dazu?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 05, 2008 14:12 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
@Tak: Ich meinte jetzt auch nicht, dass sofort gezeichnet wird, sondern dass die API ähnlich ist. Das Zeichnen bzw das senden an die Graka sollte dann erst beim glEnd-Äquivalent erfolgen. Und das elementare Feature der VBOs, dass man die Daten später wiederverwenden kann, sollte auch irgendwie erhalten bleiben.

Restless kann VBOs und setzt sie afaik sogar voraus. Aber als Anfänger möchte ich auch nicht Blender oder so runterladen, installieren und verwenden lernen, nur um ein Quad aufm Bildschirm zu sehen. Aber eventuell könnte man darüber nachdenken, da ein paar samples mitliefern.

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: Mi Nov 05, 2008 14:27 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Aber folgendes Szenario kann ich mir GUT vorstellen: Ein Anfänger importiert irgendein Modell in Blender und exportiert es dann mit unserem Modelloader, um es direkt in seinem Delphi-Programm anzeigen zu können.

Im Augenblick hat Tak gar keine so schlechten Karten. Er hat nicht so viel Funktionalität drin, dafür ist der Loader klein und schnell. Restless kann z.B. auch Animationen, dafür ist er umfangreicher. Ob er langsam ist, kann ich nicht beurteilen. Vielleicht können die Autoren was dazu sagen? Vielleicht warten wir darauf. Ein Thema wie dieses sollte sowieso nicht in einer halben Stunde abgehandelt werden.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 05, 2008 17:00 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Prinzipiell sehe ich das in jedem Fall ähnlich. Irgendwas muss getan werden. Alleine auch schon um die Hardware wirklich passen ausreizen zu können (eigentlich auch jetzt schon). Wenn in OpenGL 3.0 Shader zwingend vorrausgesetzt werden, dann kann ein VBO eigentlich auch nur ein Anfang sein. Allerdings wird man dann früher oder später selbst hand anlegen müssen. Das wird nicht alles flexibel über irgendwelche Bausteine lösbar sein.

Die "alte" API auf neue Technik umzuheben find ich auch nicht ganz so gut. Ich finde schon, dass sich das auch nach neuer Technologie anfühlen sollte. Da würde ich mich auch nicht zu weit von den bestehenden Mechanismen entfernen wollen. Wenn es später selber machen will/muss, dann ist ja nur positiv, wenn er es in etwa schon jetzt hat machen müssen. Solche eine Lösung sollte in meinen Augen eher nur eine Hilfe sein.

Man sollte evtl auch bedenken, dass nicht jeder ausschließlich nur mit Modelen arbeiten wird. Besonders Anfänger wohl nicht oder falls man eher 2D arbeitet bzw mal eben was zum Testen. Und für ein Quad/Würfel da erst mal Blender benutzen zu müssen ist aber wohl auch nicht so toll. Dann ist der Code zwar klein aber die Erstellung unhandlich. Da muss man evtl. auch unterschiedliche Einsatzgebiete berücksichtigen. Vielleicht sogar mit 2 unterschiedlichen Lösungen (die evtl irgendwo eine gemeinsame Basis haben).

Zitat:
Ein Thema wie dieses sollte sowieso nicht in einer halben Stunde abgehandelt werden.

Das sehe ich allerdings auch so. Aktuell ist OpenGL 3.0 zwar ein bisschen draußen aber von etabliert kann hier noch keine Rede sein. Da muss man sich genau überlegen für welche Zielgruppe und Anwendungsgebiete es gedacht ist.

BufferObjects können mittlerweile auch noch für andere Dinge außer Vertexdaten benutzt werden. Seit OpenGL 2.1 gibt es auch noch PixelBufferObjects bzw seit 3.0 auch TexturBufferObjects. PixelBufferObjects können zum Auslesen und Schreiben von Pixeldaten (ReadPixels, TexImage etc) benutzt werden. Aber das sind aktuell auch eher Spezialfälle. Zum Beispiel Streaming von Texturen.


TAK nur zum Verständniss was meinst du mit Mischformate und einzelne Datenstreams? Hatte ich in dem Meinungsthread zu der VBO Unit schon mal gefragt aber keine Antwort bekommen. Meinst du dort die interleaved Benutzung eines VBOs oder die etwas räumlicher getrennte Variante (erst alle vertex werte dann alle color werte etc)? Denn es bleibt so oder so in einem Speicher, da nur ein Buffer gebunden wird. Deswegen verwirrt mich das etwas.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 05, 2008 18:22 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ich sehe kein Problem einem Interessierten Anfänger OpenGL 3.0 bzw. VBOs zu erklären. OpenGL war nie leicht. Es wurde nur von unseren Tutorialschreibern leicht zugänglich gemacht.

Meiner Meinung nach sollte man in Hinblick auf OGL3 folgendes tun:

1. Ein Einführungstutorial welches erklärt wo OpenGL herkommt. Was der Unterschied zwischen dem alten OpenGL und der neuen 3.0 ist. Wie es zu dem Schritt kam. Was man mit der alten machen kann und warum und für was man die neue nutzt.

2. Es wird ein Tutorial geschrieben welches im ersten Teil das berühmte bunte Dreieck mit OGL3 hinzaubert. Dabei würde ich vorschlagen, dass mittels der {{Hinweis}}-Vorlage für OGL1/2-Umsteigern Anmerlungen in das Tutorial integriert werden, wo es unterschiede gibt.
Im zweiten Teil sollte dann erklärt werden, wie man die bestehenden Tutorials auf OGL3 überträgt. Eventuell könnte man das an einem Beispieltutorial auch mal durchführen.

Wenn man sich die Zeit nimmt, dann glaube ich, kann man einen Anfänger auch dieses Thema vermitteln.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 05, 2008 20:26 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Mit Mischformate meine ich http://wiki.delphigl.com/index.php/glInterleavedArrays und mit Daten Streams meinte ich die einzelnen Komponenten(vertice, normals,...) als Array. Wenn man diese schön in einzelnen Arrays packt, dann kann man in der eigenen Engine viel mehr Regeln.
Ich habe z.B. in meinem letzten SceneGraph nur die Vertice gebunden, dann mein z-buffer pass gemacht und dann erst im 2. Pass normals, texcoords gebunden.
Wer mit deferred Shadern arbeitet wird dies auch schätzen.

Mit OpenGL 3.0 werden Materials eine größere Rolle spielen, wenn man Zeit und Nerven schonen will.
Dabei meine ich nicht die alte OpenGL1.1 Material implementierung, sondern eine Konfigurationsdatei, die mehrere Shader und Texturen in eine Zeichenvorschrift bringt und diese auf ein Model anwendet.
Oc2k1 benutzt in Lumina z.B. Scripte, die die Konfiguration eines Materials übernehmen und ich verwende in Karmarama Lua für die Backanleitung.
Diese Materials hab ich in 3 Teile untergliedert, Initialisierung, Exit und Draw. In Init Teil werden alle Medien(Texturen, Shader) geladen und Variablen sowie Konstanten zugewiesen, in Exit werden diese wieder Weg geräumt und im Draw werden die Ressourcen gebunden, gezeichnet und wieder entbunden.
Das ganze könnte man auch in etwas lahme XML files verpacken aber dafür für jeden zugänglich machen.

_________________
"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: Mi Nov 05, 2008 21:38 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Guten Abend.

Flash schrieb:
Zitat:
Ich sehe kein Problem einem Interessierten Anfänger OpenGL 3.0 bzw. VBOs zu erklären.

Ich hatte aber ein ungutes Gefühl heute Vormittag beim Lesen von Lossys Beitrag im Anfängerforum. Lossy drückt nur aus, was wir uns alle denken: dieses Forum hier ist DER Anlaufpunkt im deutschen Sprachraum für Leute, die was über OpenGL erfahren wollen. Können wir ihnen im Augenblick wirklich etwas Konkretes anbieten?

Also als erstes: Flash, ich würde das Tutorial Nr.1 übernehmen, die Historie und Erläuterungen zu OpenGL. Ich bitte Dich aber, mir rund ein Monat Zeit zu lassen.

Zu Deinem Punkt 2: Was meinst Du mit Hinweis-Vorlage? Gibts so etwas schon oder muss man das neu erstellen?

Und ich möchte einen Punkt 3 hinzufügen: man braucht eine neue Software dazu. Der bisherige Zugang soll erhalten bleiben; DGL hat sich etschieden, die Demos mit SDL zu machen, das sollte gleich bleiben, war ja wohl auch genug Arbeit, das ganze so einzurichten.

Aber, nachdem man ja auch das berühmte farbige Dreieck in einem OpenGL 3.0 Context nicht mehr mit glBegin/glEnd erzeugen kann und es z.B. Lossys glBitmap gibt, wäre es nicht an der Zeit es ihm hier nachzutun und etwas Ähnliches für VBO's zur Verfügung zu stellen? Nicht so ausgefeilt, natürlich. Etwas viel kleineres, dünneres, eine Art "Leichtgewicht". Eine kleine Schwierigkeit darf allerdings nicht unerwähnt bleiben: es ist möglicherweise nötig, einen "Fallback" auf VertexArrays einzubauen. Vielleicht findet sich einer, der einen solchen VBO-Wrapper schreiben würde? Dann hast Du doch auch gleich die Demosoftware, die Du etwas weiter oben haben wolltest.

Und diese Gelegenheit würde ich jetzt nutzen, dem VBO einen Loader beizugeben. Ich weiss schon, was Du jetzt sagen möchtest: Du willst niemanden bevorzugen oder benachteiligen. Und das sehe ich natürlich ein. Aber vielleicht können wir diesen Rebus auflösen? Sieh mal: Taks Modelloader ist keine Konkurrenz für den Restless, weil er einfach eine andere Nische besetzt. Er ist eine Alternative. Und dann gibts ja auch noch Noeskas 3DS Loader. Eine hübsche Bandbreite, würde ich sagen.

So. Dann werfe ich jetzt mal eine ganz provokante Frage hier in den Raum: Wenn wir uns einig sind, dass in Zukunft hauptsächlich VBO's genutzt werden, was in hohem Maße die Modelldaten bestimmt und - wie wir alle wissen - die Modelloader kompatibel zu den Modelldaten (also zu den VBOs) sein müssen, dann müssten all diese Modelloader ja doch auch untereinander austauschbar sein, nicht wahr? Zumindest bis zu einem gewissen Grad. Erzählt mir jetzt nichts von Tangenten / Vertexnormalen / Animationen, die mal geladen oder nicht geladen werden.

Rein grundsätzlich müsste das möglich sein. Und wenn die Loader daher austauschbar sind, dann wird doch auch gar keiner bevorzugt oder benachteiligt. Ich sehe das so: die VBOs bestimmen eine Schnittstelle. Diese Schnittstelle wird vom Modelloader bedient. Dann ist es dem Benutzer freigestellt, welchen von den zur Verfügung gestellten Loadern er nehmen will, denn ich kann jeden einzelnen anstecken und Daten von der Platte saugen. Das ist für Bilder eine allgemein akzeptierte Sache. Ich kann JPegs oder Filme mit ganz verschiedenen Programmen laden. Wie das genau gemacht wird, bleibt dem jeweiligen Programm überlassen. So etwas wäre doch auch ein gangbarer Weg für VBO's?

Denk mal drüber nach
Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 05, 2008 21:57 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich hab mal schnell ein Beispiel für Materials zusammen geklimppert.
http://karmarama.linuxprofessionals.org/upload/test.xml
Der Vorteil solch einer Vorschrift ist, dass man sie mit xslt sehr einfach in eigene Scriptsprachen konvertieren kann.
Wenn man Also wie ich oder OC2k1 eigene Systeme für Materials hat, dann kann man über XML und XSLT es ziemlich leicht laden. Auf die Variablen kann man dann je nach Implementierung unterschiedliche zugreifen und diese Beeinflussen. Damit könnte man dann auch Shader sinnvoll Verteilen, da Shader in der Regel noch abhängigkeiten in die Software haben(Variablen die z.B. mit TexturID's gesetzt werden müssen).

_________________
"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: Mi Nov 05, 2008 22:08 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Warum kann man so etwas nicht mit ins normale File dazunehmen? Dann brauchen wir doch mehrere Dateien, um ein Modell zu laden. Das sollte man eigentlich vermeiden.


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

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Hast du dir mal ein Spiel, aus sagen wir mal den letzten 7 Jahren, angesehen ?
Du hast eine Datei für das Mesh, mehrere für die Texturen, mehrere Shader, eine für Animation und eine für das Material.
Wiederverwendung ist wichtig, es spart Platz und macht den Ladeprozess kürzer.
Selbst wenn jeder ne 16MBit Anbindung und ein paar GB freihen Festplattenplatz hast, so dauert der Ladeprozess dann mal ewig, da in jeder File noch zusätzlich die Material Daten geladen werden, immer und immer wieder. Wenn du dann sagst "Man kann ja einfach den Namen in einem Materialmanager hinterlegen und wenn dieser schon da ist, wird der Teil einfach nicht geladen.", dann muss ich dir leider sagen, dass gerade sowas elendig lahm ist, weil du anfängst eine Datei stückchen weise zu lesen, noch Interrupts und CPU Samples verbrauchst.
Mehr als ein Materialnamen sollte man nicht im Meshformat hinterlegen.
Dies hat übrigens einen Vorteil, der gerne bei Consolen und großen Welten verwendet wird, die ganzen Daten werden gestreamt, also erst wird das Mesh geladen, dann die Shader und dann erst die Texturen(in der regel MipMap weise).

Zum Thema Modelformat würde ich noch was los werden.
Ein Modelformat, welches die einzelnen Arrays speichert hat zwar große Vorteile für Modelformat aber reicht noch nicht aus, wenn man Levels damit laden und speichern will. In Karmarama habe ich sehr viel mit einen SceneGraph Format experimentiert, was ja ein Levelformat entspricht.
Man führt einen Header und Body ein, der Header wird komplett geladen und der Body ignoriert.
Im Header stehen nur die Nodedaten, dazu zählen Position,Rotation,Skalierung, BoundingSphere(ein float als Radius), Meshdaten Größe, ID/Hash und Offset, sowie ein Bezeichner(habe ich auf 32Zeichen fixiert) und Kinder(wer mein Artikel im Wiki gelesen hat weiß, dass dies 8Byte kostet).
Somit ist ein Node 92Byte groß und kann alles, was das Herz begehrt, Hierachien, Instancing(durch Meshdaten ID/Hash) über mehrere Level und Modeldatein hinweg, Streaming(Meshdaten können bei bedarf nachgeladen werden), keine beschränkung auf ein Spatial System, Scriptfähig(durch den 32Zeichen Bezeichner) und super schnell und easy zu laden.
In mein System hatte ich noch Properties eingebaut, da Blender Properties auf jedes Blender Objekt setzen kann, welche ich für Entities verwende aber durch den Objektnamen, kann man auch dies in einer externen Datei/Script regeln.
Die BoundingSphere hab ich mit eingebaut, damit man sehr einfach(frustum culling) herraus bekommt, ob man ein Objekt laden muss und welche LOD Stufe man braucht. Man kann z.B. durch die BoundingSphere sehr einfach Objekte beim Rendern skippen, die nach der Transformation einen bestimmten Radius, auf dem Bildschirm unterschreiten. BoundingSpheres benötigen nur eine Position und den Radius und sind im Frustum Culling und vielen anderen Mathematischen Berechnungen am schnellsten, aufgrund der beschaffenheit.
Ein Spatial System kann man dann entweder parallel dazu mitliefern oder zur Laufzeit realisieren(z.B. Octree+Occlusion Culling).
Die Meshdaten liegen im Body und werden durch Meshdaten Größe, ID/Hash und Offset nutzbar.
Die Größe und offset erlauben uns dank serialisierung das ganze mesh mit einen zug zu laden, wenn die ID/Hash noch nicht schon im Ressourcenmanager vorhanden ist.

Man hat dann Model und Levelformat in einem, es deckt ein sehr weites Nutzungs Spektrum ab.
So genug Werbung gemacht und hoffe es war ausführlich genug, um es zu verstehen xD

_________________
"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  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 44 Beiträge ]  Gehe zu Seite 1, 2, 3  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 24 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.083s | 19 Queries | GZIP : On ]