ZFX + Developia

Ich denke, daß jede Antwort, die wir nicht tippen müssen und die ihn mehr auf Abstand hält eine gute Antwort ist :).

Gruß Kimmi

Wenn ihr einverstanden seid werde ich den Patch, den er gepostet hat, bei Gelegenheit mal durchgucken und einchecken, sofern mir daran nichts uebles auffaellt. Was ich nicht einsehe ist allerdings, dass ich den existierenden MDL Code aendern soll – er soll seinen Importer weiter vorne registrieren und sicherstellen dass dieser Dateien, die nicht zu ihm gehoeren, zurueckweist.

Jupp, dem stimme ich zu. Ich hatte seine Äußerung bezüglich der Importer-Registrierung zunächst voll falsch verstanden. Glücklicherweise habt ihr da noch mal genauer drauf geschaut. Ich bin gespannt, was er an Code einreichen wird.

Gruß Kimmi

Ich bin ja mal gespannt, wie sich die Situation noch entwickeln wird. Nach seinen letzten Kommentaren war ich schon fast wieder soweit, mich in die Diskussion einzumischen.

Meiner Meinung nach ist die jetzige Strategie eh das einzig Richtige, das wir machen können, nämlich versuchen, ihn ruhig und freundlich, aber trotzdem bestimmt auf den Boden der Tatsachen zurückzuholen. Auch ich kann übrigens aus meiner Open-Source-Erfahrung bestätigen, dass er eine völlig weltfremde Einstellung hat…

Edit: Ein sehenswerter Vortrag: http://video.google.com/videoplay?docid ... 1522818645

Ochja, ich hab deinen Edit erst jetzt gesehen. Wirklich sehenswert. Ich sehe mickp die ganze Zeit vor mir :-)

Uebrigens hab ich gesehen dass ein neuer Loader hinzugekommen ist -- was hat der fuer einen Status? Ich will gerne mal testen, konnte aber keine Testfiles finden :-)

Zum Blender-Loader waere noch zu erwaehnen dass er Fortschritte macht. Aktuell werden die meisten statischen Blender-Szenen geladen, (meistens) auch mit Materialien.

Zur Zeit wird nichts in Assimp-Datestrukturen geladen, deswegen ist da noch kein Testfile zu finden. Das ist der Quake-3-Loader. Dafür mußte ich noch unzip in die Contribs einchecken, da die PK3-Files nicht anderes sind als Zip-Archive. Wenn man sich etwas ansehen kann, schreie ich!

Gruß Kimmi

Geht klar. Ich hab die vc8 Workspaces nun auch aktualisiert, nachdem Thomas ja schon bei vc9 aktiv wurde. Der tuple-Bug sollte auch gefixt sein -- sorry, ich hab etwas zu spaet realisiert dass es um den Workaround ging und dass ich das verbockt hatte.

Wegen Tuple-Bug: kein problem. Ich habe es bisher noch nicht geschafft, mein Linux anzuschmeißen, sonst hätte ich mich chon darum gekümmert.

Gruß Kimmi

Hab uns mal zum Collada-Wiki hinzugefuegt:

https://collada.org/mediawiki/index.php ... _directory
https://collada.org/mediawiki/index.php ... rt_Library

Wie sieht es eurer Meinung nach mit Wikipedia aus? Ich bin da eher zoegerlich, denn ich hab einige Seiten von kleinen Libs gesehen, die irgendein uebereifriger Admin als 'vermutlich vom Autor selber erstellt, bla, bla ...' gebrandmarkt hat.

Und? Wenn das Interesse groß genug ist, werden die in der regel auch wieder zurück eingetragen :), habe ich festgestellt.

Gruß Kimmi

Ich habe mal zwei kleine CMake-Fixes committed, mit denen Assimp auch hier auf OS X 10.6 einwandfrei gebaut und installiert wird.

Ich habe übrigens gerade begonnen, an einem kleinen Viewer in D (mit Qt und OpenGL) zu arbeiten, um die SWIG-Bindings für Assimp bzw. mein D-Modul für SWIG zu testen und auch für D so etwas wie Sample Code bereitstellen zu können. Irgendwelche Wünsche/Vorschläge/Anregungen?

Anregungen hoechstens dass ich auf das Ergebnis gespannt bin :-) Evtl. koennte der Viewer auch der Standardviewer fuer Nicht-Windowse werden, oder AssimpView eines Tages sogar ersetzen (wobei selbiger zwar eine unbrauchbare Quellcodebasis hat, aber eben doch ueber eine ganze Menge Features verfuegt …).

Uebrigens hat auch Matthias im C#-Binding etwas Viewer-Artiges am Laufen.

Man kann übrigens mittlerweile auch mit der ZFXCE Modelle von Assimp geladen ansehen. Das Ganze wird mit OpenGL gerendert.

Gruß Kimmi

Dank Chromanoid haben wir nun auch ein neues Mini-Icon, das auch als Threadicon zur Verfuegung steht.

Nachdem wieder einmal jemand auf der Mailing-Liste sinngemäß gemeint hat »Ihr solltet CMake nicht benutzen, weil ich es nicht mag« – es hat sich übrigens herausgestellt, dass er eine non-standard-Distribution von MinGW benutzt, also ganze zwei Pfade in der GUI händisch angeben muss:

Ich denke, wir sollten uns eine offizielle Position darüber zurechtlegen, welche Build-System wir unterstützen bzw. anbieten. Mein Vorschlag wäre, die Makefiles, XCode-Workspaces, etc. im Repository zu lassen, sofern sie nützlich für jemanden sind, aber ausdrücklich darauf hinzuweisen, dass sie nicht unterstützt werden, und zwar funktionieren können, das aber nicht müssen. CMake würde ich dann als Standard-Build-System deklarieren, das auf allen Plattformen (ich selbst habe zwei Linux-Varianten, Windows MSVC/MinGW und Mac OS X GCC 4.2 getestet) zumindest irgendein funktionierendes Ergebnis produziert.

Was haltet ihr davon?

Ach ja, ich habe dazu absichtlich (noch) kein Thema auf der Mailing-List erstellt, weil das Kern-Team ja eh hier mitliest und ich nervige Zwischenrufe gerne vermeiden würde, bis sich wenigstens die Committer einig sind…

Ich stimme zu. CMake hab ich zwar noch nie benutzt, aber es soll wohl solide Ergebnisse liefern. VC9 bzw. VC10 werden von uns ja mitgewartet. Und bei VC8 und XCode steht nach meinem Wissen bereits ein README daneben, dass explizit auf die Deprecatediertheit der Dateien hinweist.

Also auch ich halte das für einen gangbaren Weg. CMake als Haupt-Build und den Rest nebenbei laufen lassen. Wenn sich herausstellt, dass sich CMake als zu große Hürde herausstellt, würde ich die gewünschten Makes per CMake generieren und dann einchecken -> Tschakka! Das mindert dann vielleicht die Einarbeitungshürden.

Gruß Kimmi

Zustimmung.

(bezieht sich auf die, auf der ML angesprochene, lizenztechnische Trennung des Modell-Repos)


Kimmi, die pk3-Datei im Repos - woher stammt die, bzw. ist sie eindeutig BSD-kompatibel?
Jonathan, wie sieht es mit den Ogre-Dateien aus?

Ich hab mich entschieden Modelle, die als Verwendung 'free for any purpose' oder 'public domain' angeben als BSD-kompatibel zu zaehlen. Alternative Lizenzen oder Verwendungseinschraenkungen (Non-Commercial, Creditspflicht, …) sind ein Disqualifikationsmerkmal. Jemand was dagegen? Irgendwelche Anwaelte mit Fachbereich Copyrightrecht in der Naehe? :D

PS: ich ziehe sie jetzt alle mal nach /test/model-nonbsd, kann man ja immer noch aendern.

Keine Antwort ist auch eine Antwort, aber das Thema scheint vonseiten der Fedora-Jungs geklaert zu sein.

Stichwort 'Release' (1.2 wenn ich es richtig im Kopf hab :-)).

da wir grade ein bisschen Public Momentum zu haben scheinen, schlage ich vor das zu nutzen um baldmoeglichst zu releasen, zumal schon wieder 130 SVN-Revisionen vergangen sind, ungefaehr ein Drittel davon Bugfixes im Assimp-Kern.

Mein Vorschlag waere, Mitte November zu releasen (z.b. das WE 13./14.). Meinungen?

Viel zu tun gaebe es nicht. Die Maintainer der Bindings sollten alles auf den aktuellen Status bringen bzw. zum Erstrelease bereit machen (C# wurde z.B. meines Wissens noch nie mitgeliefert – wie sieht es damit aus?). Die neuen Loader (Q3BSP, Blend) weiter getestet werden.

Sorry, ich war auf Rügen und konnte nicht antworten, weil in unserem Hotel kein WLAN verfügbar war. Die Lizens des Q3-BSP-Files ist von einer Seite im Netz, damit hast du sie meiner Meinung nach richtig einsortiert.
Ich würde bis Mitte November die Texturen und Lightmaps für Q3-BSP nachreichen. Dazu habe ich noch eine Frage: Wie wollen wir mit Archiven umgehen beziehungsweise wollen wir nach aussen überhaupt mit Archiven umgehen? Normale PK3-Dateien mit den BSP-Leveln + Texturen sind Zip-Archive. Ich habe hierfür ein spezielle FileSystem-Klasse implementiert. Allerdings können wir zur Zeit noch keine Archive "mounten" bzw. aus diesen Texturen direkt von Benutzersicht aus importieren. Wollen wir diese Option für ein 1.2'er Release anbieten?
Mir schwebt so etwas vor wie eine hasMountedArchive()-Methode, um sich eine Instanz des Filesystems zu holen. Intern haben wir das ja eh schon vorbereitet. Probleme sehe ich in Richtung C-Interface.
Meinungen dazu?

Gruß Kimmi

Bauen wir eine Importer-Lib oder ein Betriebssystem?

Ok, in Kurzform:
Ich habe ein Zip-FileSystem erstellt, um die für Q3-Levels benötigten Archive auszulesen. Wollen wir dieses Zeug für den Benutzer bereitstellen oder wollen wir die Daten auf Assimp-Datenstrukturen mappen?

Gruß Kimmi

Die Texturen kannst du doch mit dem ZIP-Filesystem innnerhalb von Assimp aus dem Archiv auslesen und als aiTexture's rausgeben, oder? Ich wuerde fuer 'nur' einen Loader keine groessere Sachen ins oeffentliche Interface aufnehmen wollten, zumal das Laden von Archiven ja nicht direkt zu unseren Aufgaben gehoert. Wir koennten es aber recht einfach in die Default-Implementierung des IOSystems aufnehmen, ich hab nur das Gefuehl dass das den Pflegeaufwand enorm erhoeht.

Klar, allerdings sind da noch andere Sachen wie zum Beispiel Shader drinn. Daher die Frage: Wollen wir die Daten auf Assimp-Daten mappen? Mir ist es egal, wollte hier nur ein paar Meinungen zu hören. Der Aufwand ist der gleiche und Assimp-Daten wären mir persönlich lieber. Aber vielleicht hat da ja noch wer eine bessere Idee.
Das mit dem Archiv-Auslesen ist bereits implementiert, sonst würde der Q3-BSP-Loader gar nicht gehen. Sicherlich könnte man dem Nutzer abverlangen, zunächst einmal ein PK3-Archiv selbst zu entpacken und dann die darin enthaltene Datenstruktur Assimp vorzusetzen. Das ist aber in meinen Augen nicht so "kundenfreundlich", da alle mir bekannten Q3-Levels als PK3-Archive ausgeliefert werden. Letztendlich soll der Loader mit beiden umgehen können.

Gruß Kimmi

Dann waere ich dafuer es einfach auf Assimp-Daten zu mappen. Die Q3BSP-ZIP-implementierung ist dann ja intern in Assimp verfuegbar -- wer mehr Q3BSP-Daten braucht, kann sich den Quellcode deines Loaders schnappen und sie ohne viel Aufwand an sein Programm durchreichen.

Ich denke das ist eine gute Loesung -- der Standarduser kriegt Modelldaten im Assimp-Layout, wer mehr will muss ein bisschen rumbasteln :D

Ok, ist mir auch lieber. Alles andere hat so ein "Geschmäckle"... Allerdings kommen da noch Shader und Entities dazu. Keine Ahnung, wie und ob wir die abbilden wollen. Kameras bieten wir ja eh schon an, Positionen von Modellen muss ich mal sehen.

Gruß Kimmi

Gut, dann halten wir das mit dem angepeilten Release-Zeitpunkt mal so fest. Ich kuemmere mich dann um die Fein-Koordination wenn der Termin etwas naeher rueckt. Bis dahin schlage ich vor dass wir erstmal einen Aufnahmestop fuer neue Loader verhaengen (z.B. aus der mickp-Ecke) :-)

Ich habe mir jetzt noch nicht wirklich Gedanken zum Release gemacht, aber einen Punkt sollten wir bedenken:

Wenn ich mich richtig erinnere, ist seit dem letzten Release die Binärkompatibilität flöten gegangen (welche. Das heißt zum einen, dass alle Nutzer ihre Applikation rekompilieren, und im Fall von Bindings diese zwangsläufig updaten müssen (z.B. ich bis zum Release die D-Bindings im Repo), zum anderen, dass wir die soversion auf unixioden Systemen um eins erhöhen müssen.

Insofern wäre vielleicht zu überlegen, ob das Release nicht besser die Version 2.0 bekommen sollte – sonst haben wir nämlich wenn wir in Zukunft ein Release herausbringen sollten, das binärkompatibel ist, keine Möglichkeit, das in der Versionsnummer auszudrücken (es gibt ja nur aiGetVersionMinor und aiGetVersionMajor).

Außerdem sind ja einige komplett neue Interfaces/Datenstrukturen dazugekommen, von dem her wäre das aus meiner Sicht sogar mehr oder weniger gerechtfertigt. Oder wollen wir mit Assimp 2 warten, bis mick-p uns dazu überredet hat, Exporter für alle Formate zu schreiben? ;)

@C#-Bindings: Bis auf 1-2 kleine Probleme funktioniert der SWIG-Port ganz gut. Der .net-Viewer ist allerdings eine eigene Sache. Mal abgesehen von den MDX-Abhaengigkeiten (ist ja erst ein paar Jahre veraltet) liest er auch kaum eins der Models. Allerdings weiss ich auch nicht, inwiefern das fuer euch relevant ist.

Fuer unser Projekt funktioniert Assimp ink. Blender-Importer auf jeden Fall hervorragend. Grosses Lob und vielen Dank an dieser Stelle an euch. :)