ich versuche gerade ein DungeonCrawler (ähnlich DungeonMaster) zu erstellen. Also feldweises Vorrücken und Drehungen um 90°. Jedes Feld beinhaltet das Aussehen der 4 Wände, Boden und Decke. Anfangs waren die Wände nur Quads mit Textur aber das sah mir zu platt aus. Inzwischen haben die Wände Absätze, Säulen und Alkoven und als Decke muß auch ein Kreuzgang herhalten. Die Sachen sind Quad für Quad als Displaylisten erstellt um die Szene baukastenartig bis zur Sichtgrenze zu erstellen. Das erstellen der "Bausteine" ist etwas umständlich und beschränkt. Kann man diese "Bausteine" auch einladen? Ich habe einen OBJ und MD3-Loader von Jan Horn gefunden leider haben sie Ladeprobleme bei einigen Szenen. Und dann noch glModel. Hat jemand damit Erfahrungen? Kann man die geladene Szene als Display List oder ähnlich ablegen um sich ein Baukasten zu erschaffen? Das ganze soll nur oGL 2.0 als Voraussetzung haben da einige der potenziellen Spieler nicht mehr mit ihrer OnBoard Grafikkarte können.
Ich hoffe es ist zu verstehen - Danke.
Zuletzt geändert von Twist am Mi Apr 22, 2015 06:48, insgesamt 1-mal geändert.
Damit kannst du ungefaehr...alles laden denke ich. Auch Collada oder sowas.
Ausserdem ist es OpenGL unabhaengig - du kriegst einfach die Vertex-, Normalen-, Farb- oder Texturkoordinaten. Guck dir einfach mal ein C Beispiel an, falls du trotzdem Hilfe brauchst, kann ich dir auch ein Beispiel basteln.
_________________ offizieller DGL Compliance Beauftragter Never run a changing system! (oder so)
Registriert: Mi Jan 31, 2007 18:32 Beiträge: 150
Programmiersprache: Pascal
Beim ausführen von was bekommst du den Fehler? Du brauchst nur eine *.dll/*.so von assimp und den pascal header aus dem repository. Der Viewer ist für dich eigentlich uninteressant wenn ich dich Recht verstehe.
habe über Ostern etwas Zeit mit Assimp verbracht aber C ist nicht mein Ding. Das einlesen der Meshdaten ist ja noch nachvollziehbar aber bei den Texturen verstehe ich den Beispielcode nicht mehr. Ich bräuche da bitte doch ein kleines Beispiel.
Registriert: So Aug 08, 2010 08:37 Beiträge: 460
Programmiersprache: C / C++ / Lua
Bei Texturen hat jedes einzelne Mesh seine eigenen Texturkoordinaten, die du auslesen musst (mTextureCoords[0], schau dir den Record an, die Kommentare sind recht ausfuehrlich: https://github.com/ev1313/Pascal-Assimp ... aimesh.inc ), die kannst du dann ja einfach mit den anderen Daten in ein VBO packen und ein passendes VAO fuer schreiben.
Ausserdem wird jedem Mesh ein Material (mMaterialIndex) zugeordnet. Die Materialliste musst du genauso wie die Meshliste aus deiner Scene laden und kannst dir dann daraus z.B. den Pfad der Textur, oder die Farbe raussuchen. Das musst du dann an den Shader uebergeben.
Examplecode hab ich hier leider gerade nicht und ich hab auch eher wenig Zeit welchen zu machen, sorry :\
Ich werde allerdings weitere Fragen versuchen bestmoeglich zu beantworten.
_________________ offizieller DGL Compliance Beauftragter Never run a changing system! (oder so)
Habe festgestellt, daß bei meinem Testobjekt zwar in Blender die Textur angezeigt wurde, die UV Koordinaten aber von Blender generiert wurden und nicht mit abgespeichert wurden. Mit UV-Mapping zeigt glModel jetzt auch die Texturen an.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2621 Wohnort: Berlin
Programmiersprache: Go, C/C++
Meine Erfahrung mit der Thematik. Bau dir ein Konverter.
Die Pflege eines eigenen Exporter ist Wahnsinn, selbst für Mittlere Firmen, mit 60 Mann war das eine schlechte Idee. Grafiker tendieren dazu unterschiedliche Programme zu verwenden und diese Updaten sich häufig und jedes benutzt andere Scriptsprachen und hat ein anderen Aufbau. Selbst der Support für ein Model Editor ist schon größer als ein Konverter zu bauen. In den meisten Projekten hab ich das gleiche gesehen. Artists exportieren FBX/Collada und ein Projekt spezifisches Tool lädt das und konvertiert das in das native Format. Das laden ist sehr einfach mit C++, da man entweder direkt das FBX oder Collada SDK verwendet oder wie ich bevorzuge assimp. Man hat dann 2-3 Zeilen für das Initialisieren/laden und schreibt dann schon direkt an dem export und das in der Sprache die man selber mit arbeitet. Noch dazu kann man solche Tools einfach zusammen hacken und muss nicht auf code quality und so achten. Ich hab mir angewöhnt command line tools zu bauen und das erste ist immer ein konverter und die weiteren arbeiten dann mit dem nativen Format. In mein letzten Projekt, in mein alten Job hatte ich dann noch ein Fenster Tool, welches einige Basis Konfigurationen wie zielplatform, export Verzeichnis, Threads, Toolchain und Projekt verzeichnis erlaubte(simples WPF C# Fenster). Die Funktionen kamen per xml ins Programm, wo ledeglich ein Taskname, Executable/Bash-Script und Parameter Feld gab.
Privat hab ich wesentlich mehr Zeit in die Thematik gesteckt und ein system service entwickelt, welcher im Hintergrund die gleiche Arbeit aber mit json(statt xml), ein File Watcher(statt Fenster Tool) und LuaJit(statt bash) macht. Lua ist Platformunabhängig und einfach zu lesen aber letzlich macht es nix anderes als. "Ist das Asset ein unterstützes Format? Dann führe Commandline Tool mit folgenden Parametern aus."
Im letzten Projekt hatten wir ein Format für animierte Meshes, eins für statische Meshes und eins für punktwolken(instancing z.B. Wälder, Städte, Props.). So ist der Code viel einfacher, schneller zu entwickeln und performanter.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Mitglieder in diesem Forum: 0 Mitglieder und 21 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.