Hallo zusammen,

ich versuche mich gerade an einem OBJ Loader für Java.
Zum testen nehm ich das Sponza Model von Crytek, das ich mit folgenden infos ausgelesen habe:



Danach erzeuge ich für alle Faces dreiecke, da die Geometry definition Polygone, bzw. Triangle-Fans sind und nicht dreiecke.
Während ich diese erzeuge generiere ich ein Mesh mit frischen Indices und Vertices:



Wie man sieht, haben vertices und indices die gleiche anzahl, was natürlich Speichertechnisch nicht wirklich so toll ist.
Denn wie wir wissen hat z.b. ein Quad das aus 2 Dreicken besteht, wenn es paralell liegt 4 Vertices mit jeweils 6 Indices. Man sparrt sich also schon 2 Vertices bei einem Quad.

Deswegen nutzen ja brauchbare modelling tools - Algorythmen die schon vorhandene Vertices mit entsprechendem Index herausfinden können und die Indices anpassen, oder schon von vornerein keine vertices duplizieren.

Das habe ich nun selbst versucht, allerdings klappt das nicht so wie es ich mir vorgestellt habe oder ich habe etwas falsch verstanden.

Was ich versucht habe, ist beim Generieren der neuen Vertices, den vorhandenen Vertex-Index in meinem vorhandenem Vertex-Array zu suchen und dann entsprechend keinen neuen Vertex erzeugen, sondern den Index einfach auf den gefunden zu setzten.
Klingt einfach, funktioniert aber überhaupt nicht... es wird nie ein vorhander Vertex gefunden und immer ein neuer angelegt.

Die Equals Funktion für das Vertex Class funktioniert aber, diese habe ich alleine schon überprüft.

Vielleicht ist irgendwo ein logigfehler?

Hier ist ein wenig code, wäre super wenn ihr mir mit dem Problem helfen könntet.
Sorry für java aber wenn ich was ausprobieren will dann mach ich das nur noch mit java und LWJGL, da kann man wesentlich schneller und effizienter Programmieren, zumindest wenn man nicht im Speicher rumwusseln muss -.-

OBJLoader.java (Yay, ein wavefront obj loader)
http://pastebin.com/qbhY4t1y

Vertex.java (Simple vertex klasse)
http://pastebin.com/3v4psaVd

Face.java (Face vom Mesh)
http://pastebin.com/zZT8y3Br

Mesh.java (Das finale Mesh das aus dem OBJLoader erzeugt wird, hier sind auch die vertex such methoden drin)
http://pastebin.com/pRfPsyqd

Compares.java (Vertex, Vector3f, Vector4f nutzen dieses zum vergleichen von floats und überschreiben alle equals)
http://pastebin.com/NW0p5Zw7

Hier der eigentliche code der das Mesh befüllt (ist auch im OBJLoader.java enthalten):


Brutal langsam ist das ganze leider auch, also das Suchen nach dem passenden Vertex das nicht funktioniert -.-

Danke,
Final

So schnell kanns gehen, ich musste ja unbedingt zufällige Farben pro Face haben...
Color auf default wert gesetzt, passt.

Naja, viel spass mit dem code, ist ja immerhin ein halbwegs funktionierender Wavefront OBJ Loader.



Allerdings hätte ich noch eine Frage:

Wie kann man dann die Vertex-Index-Suche Beschleunigen ? Ich habe ja schon einen Cache eingebaut... der aktuell auskommentiert ist.
Mal schauen ob der was bringt...

OMG, das war richtig schnell... 2 sekunden das Sponza modell geladen mit java:



Und wie wir sehen, yay... nicht annährend mehr soviele vertices wie vorher

Java hashCode() und HashMap sind toll:

Ich weiß nicht, ob das eine gute Lösung ist, aber in einem aktuellen Projekt verwende ich dafür folgendes:
Ich habe eine HashMap von Vertex auf Index. Entsprechend natürlich eine Hashfunktion definiert für den Vertex.
Dann eine Liste von Vertices und eine Liste Indices.
Beim Hinzufügen eines Dreiecks in das Mesh prüfe ich für jeden Vertex, ob die Map ihn schon enthält. Wenn ja, hab ich meinen Index. Wenn nicht, generiere ich einen neuen Index und schmeiß das Paar in die Map sowie den Vertex in die Vertexliste. Der Index wird auf jeden Fall in die IndexListe geschrieben.
Beim Aufbau der Buffer kann ich nun einfach über meine Vertexliste iterieren und reinschreiben. Der Indexbuffer dito.
Source (Ogre3D):
https://bitbucket.org/philiplb/ogrevolu ... hBuilder.h
https://bitbucket.org/philiplb/ogrevolu ... uilder.cpp

Musst du da wirklich vier Floats erzeugen um den Hash zu berechnen…?

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

Na toll. Den Loader hätte ich ein paar Monate früher gebrauchen können. Jetzt hab ich schon einen.

Aber mal Spaß bei Seite: Mein Loader war performance-technisch nicht so der Bringer.
Habe dann einen Cache im ModelManager zwischengeschaltet, der die Vertex / Indizes etc. in eine Binar-Datei haut.
Das ist dann doch noch um einiges schneller. Meistens um ein Faktor zwischen 20 und 30 schneller als jedes Mal die OBJ Datei durchzuparsen. Hab leider keine genauen Zahlen zur Hand, aber das Sponza Modell hat doch schon einige Sekunden gebraucht im OBJ Format. Aus dem Cache nur einige 100 ms.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Ähm, genau das habe ich am ende auch gemacht.



Naja, klar das ASCII parsen langsamer ist als binary vordefinierte Strukturen zu lesen, aber ich finde es schon das hier ziemlich flott für java:



Total also 2,1 Sekunden für den Gesamten ladevorgang.

Allerdings muss ich dazusagen, das ich erstens noch kein VBO+IBO dafür erstelle und zweitens das auf meinem Alienware Notebook laufen lassen.
http://www.sysprofile.de/id34565

Allerdings habe ich nun das Problem, das zu Rendern... Im Wireframe, Immediate mode unoptimiert gerendert mit GTX 580M sehr ruckelig.

Es gibt aber eine Sache die ich Java hasse und das sind FloatBuffer oder ByteBuffer -.- Da wünscht man sich Pointer von C++
Leider notwendig für Texturen und alle arten von Buffern in OpenGL bei java

Hihi, 2sekunden sind für ein so generisches Format wie Obj schon recht flink.
Willst du das als Zwischenformat verwenden oder soll das das endgültige Binaryformat werden ?
Als zwischenformat würde ich heute eher auf FBX setzten, da gibt es auch Bibliotheken von Autodesk.
Als Binaryformat würde ich besser gucken wie dein Code die Daten haben will und entsprechend anpassen.
Lieber ein paar bytes verfeuern als noch irgendwas zur ladezeit zu generieren und zu konvertieren.

Die meiste Zeit geht für den Festplattenzugriff drauf.
Ich hatte damals ein Hardwarenahes format für C++ gebastelt.
http://wiki.delphigl.com/index.php/Modelformat

Das war zu HDD Zeiten also knapp 66% der Zeit sind nur für das laden vom Filesystem.

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

Projekte: https://github.com/tak2004

*schnief* Irgendwie hat das mit dem hashCode und das zusammen packen der Koordinaten nicht wirklich funktioniert, nun brauch ich 6.5 Sekunden zum laden und optimieren. Naja, aber ich habe eine Idee wie ich das noch schneller hinbekomme.

Habe mal ein Screenshot vom gerenderten Sponza Model dazu gepackt.
Nicht wundern, die Farben sind pro Face zufällig gesetzt, sieht lustig aus ^^