Assimp - Brainstorming zum Release

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Naja, Curved Surfaces werden ja bislang nicht unterstuetzt. Wenn ein Loader anfaengt, sie zu laden dann sind sie nach dem ersten Exportieren verschwunden und der zweite Importvorgang arbeitet mit den tesselierten Daten. Insofern wuerde das Testkriterium auch da funktionieren :-)

Ich werde das bei Gelegenheit mal in die Testsuite einbauen, sonderlich viel Aufwand sollte es nicht sein denn das Vergleichen von Modell-Dumps ist ja schon lange implementiert.

@Schrompf: ja, das hiesse dann dass man eben keine Identifier mit rand() generiert :-)
Nach meinem Wissen ist stringstream und Konsorten von Haus aus "en_us.UTF8", bis man eine andere Locale imbued. Was für ein phantastischer Satz.
Das waere ja absolut wundervoll. Aber bist du dir da sicher?

EDIT:

Der Standard zu getloc sagt:
Returns: If no locale has been imbued, a copy of the global C++ locale, locale(), in effect at the time
of construction. Otherwise, returns the imbued locale, to be used to perform locale-dependent input
and output operations.
.. also ist die Default-Locale fuer Streams locale(), dessen Eintrag meint sagt:
Default constructor: a snapshot of the current global locale.

Effects: Constructs a copy of the argument last passed to locale::global(locale&), if it has been
called; else, the resulting facets have virtual function semantics identical to those of locale::classic().
also hinge das Resultat vom aktuellen Wert von locale::global ab.

Uff.

locale::classic ist wohl das was du meinst, der Standard nennt es die 'C'-Locale, dahinter verbirgt sich vermutlich US-ASCII mit einem undefinierten 8ten Bit. Ist aber irrelevant, wir koennen Assimp's Output nicht davon abhaengig machen was fuer eine locale aktuell gesetzt ist.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Dann muesste inbue(locale("C")) aber funktionieren, oder nicht?
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Aramis hat geschrieben:Naja, Curved Surfaces werden ja bislang nicht unterstuetzt. Wenn ein Loader anfaengt, sie zu laden dann sind sie nach dem ersten Exportieren verschwunden und der zweite Importvorgang arbeitet mit den tesselierten Daten. Insofern wuerde das Testkriterium auch da funktionieren :-)
...
Das ist gerade die Frage: will man, wenn man die Unterstützung anschaltet, das Auflösen von Assimp machen oder benötigt man die Daten anderweitig ( um das z.B. per DX11 auf der GPU machen zu lassen ). Löst man alles per Processing-Step auf oder will der Anwender die Daten haben?

Aber das ist auch eigentlich eher als ein Beispiel gemeint gewesen: in dem Moment, wo man irgendwo Vertex-Daten aus Modell-spezifischen Daten generiert, wird man mit dem Kriterium Probleme bekommen. Entweder, weil man die Beschreibungsdaten "verliert" also in Vertexdaten rausschreibt oder weil man durch die Berechnung Genauigkeitsverluste bekommen wird, sofern diese single-precision ( also Floats ) sind.
Ich habe mich mit so etwas schon öfter bei FE-Daten auseinandersetzten müssen, daher meine Warnung. Das Kriterium klingt einfach, kann aber je nach Anwenung richtig rumzicken beziehungsweise die Anwender können zickig werden.

Gruß Kimmi
Benutzeravatar
Schrompf
Moderator
Beiträge: 4854
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf »

Nö, das Kriterium passt in jedem Fall, da das Auflösen von evtl. Higher Order Primitives halt beim ersten Laden passiert. Alex' Prüfkriteriumg dagegen besagt nur, dass ein exportiertes File nach dem Import und erneuten Export wieder genauso aussehen muss. Und das ist mehr oder weniger garantiert.

Das andere Thema ist dann, dass Assimp keine Higher Order Primitives unterstützt. Um die zu erhalten, müsste man das Speicherformat aufbohren. Und da habe ich wieder Angst, dass dabei so eine Gurke wie Collada rauskommt, wo 98% aller Features nie benutzt werden.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Wenn Sichtprüfung reicht, sehe ich da auch keine Probleme. Will man die per Skript gegen prüfen, zum Beispiel in einem automatisiertem Test, dann wird das eklig. Besonders, wenn man die Plattform noch wechselt.

Und die Unterstützung von Curved-Surfaces und dergleichen wird nie interessant? Gerade in Hinblick auf die Möglichkeiten von DX11 könnten da Wünsche hochkommen, oder?

Gruß Kimmi
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Ich sehe da erhebliche Probleme, alles unter einen Hut zu bekommen. Wenn man alleine mal ueberlegt, wie viele Moeglichkeiten es gibt Kurven und Curved Surfaces mathematisch zu definieren. NURBS duerfte sicherlich die gaengigste und am hoechsten verallgemeinerte Variante sein, aber was haben wir aktuell fuer Formate, die NURBS-Surfaces beinhalten koennen?

Ich habe beispielsweise fuer meinen IFC-Importer (dessen Geschichte ihr ja kennt) linear extrudierte Kurvenprofile implementiert, und sogar eine simple Form Boolescher Operationen.

Wenn wir solchen Kram ins das Hauptinterface hineinpacken, werden wir ein CAD Programm :-)
Zuletzt geändert von Aramis am 19.07.2011, 17:37, insgesamt 1-mal geändert.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Das ist in der Tat ecklig, ich kenne das Spiel noch von den Curved Surfaces von den BSP-Leveln.

Gruß Kimmi
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Erste ObjExport-Version ist mal eingecheckt, nun mit imbue(std::locale("C")).

Jetzt ergibt sich folgendes Problem: wenn ich eine Szene lade, Postprocessing darauf anwende und dann wieder exportiere, weiss der Exporter natuerlich nicht, welche PP-Steps angewendet wurden.

Wenn man also aktuell aus dem Viewer heraus exportiert, ist die Handedness der exportierten Modelle falsch, die Texturkoordinaten sind invertiert und die Winding-Order stimmt ergo auch nicht.

Mein Vorschlag um das ganze zu beheben:
  • aiScene bekommt einen mPrivate-Member, den Assimp intern verwaltet. Der wird sicher in Zukunft noch weitere Begehrlichkeiten wecken, einstweilen will ich aber eigentlich nur die Liste der auf die Szene angewendeten Postprocessing-Steps darin speichern.Wir haengen ihn hinten dran, damit bleiben wir binary-compatible.
  • Die Exporter gehen davon aus, dass die ihnen uebergebene aiScene Assimps Default-Konventionen ohne Postprocessing folgt - mit einer Ausnahme: die kuenstliche Beschraenkung auf das Verbose-Format fuer Vertizes macht in meinen Augen hier nur wenig Sinn.
  • Die Exportfunktion erhaaelt einen mPreprocessing-Parameter, der eine Auswahl der regulaeren PP-Steps akzeptiert, u.a. ConvertToLeftHanded, FlipWindingOrder etc. Die koennen die User nutzen um Assimp's Default-Format zu erhalten. Bedauerlicherweise muessen wir dafuer intern eine Kopie der Szene erstellen, denn Export nimmt natuerlich eine const aiScene* (und alles andere waere widersinnig).
  • Intern koennen Exporter dann die in der Szene enthaltene Liste von PP-Steps auswerten um ggf. weitere auf die Kopie der Szene anzuwenden. Beispielsweise werden viele triangulieren muessen, es waere schwachsinnig das jeden Exporter aufs neue implementieren zu lassen.
Lacht mich nicht aus. Das ist die einfachste, portableste und vollstaendigste Loesung die mir einfiel :-)
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Zum Speichern des Zustandes des Modelles halte ich das für sinnvoll.

Gruß Kimmi
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Ok,

Thomas bist du auch mit aiScene::mPrivate und dem Gedankengang dahinter einverstanden?
Benutzeravatar
Schrompf
Moderator
Beiträge: 4854
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf »

Ja, ist ok. Ich hatte das damals sogar schon mal angefangen, damit jede Szene privat die Importerinstanz speichern kann, von der sie stammt. Das war als Vereinfachung des C-Interfaces gedacht, damit der keine globale Sammlung von Importern mehr braucht und damit auch keine Thread-Synchronisierung, wodurch die letzte Abhängigkeit von Boost verschwunden wäre, die nicht Header-only ist. Hab diesen Umbau dann aber irgendwo in der Hälfte abgebrochen, weil ich dazu auch das Log-System hätte aufräumen müssen. Das war mir in dem Moment zuviel Arbeit, auch wenn ich es immernoch für notwendig erachte.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Stimmt, da war noch was. Ich sollte mir eine ToDo-Liste anlegen.

Gruß Kimmi
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Ja, vielleicht koennen wir das jetzt nachholen, die globale Liste im C-Interface ist ein Graeuel.

Code: Alles auswählen

struct ScenePimpl {

    unsigned int ppApplied;
    Importer* importerInstance;
};

… eigentlich koennten wir darueber ganz einfach einen privaten Logger in die Importer 'injecten' (nehme an, das hast du gemeint). Nur befuerchte ich, dass es damit eben noch nicht getan ist, der Umbau der einzelnen Importer koennte ziemlich aufwaendig werden. Leider ist die Szenen-Instanz nicht in allen Importern als Member verfuegbar und wenn dann nicht unter einem einheitlichen Namen, also kann man es nur schwerlich mechanisch ersetzen.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4854
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf »

Nene, ich hätte den Logger eher als Parameter an ImportScene() gereicht und dann per Parameter durch alle Importer und PPSteps durchgereicht, die den Logger in einer MemberVar der Basisklasse zwischenspeichern. Dann noch globales Suchen&Ersetzen, um alle Verweise darauf in mLogger->Bla() umzuwandeln und fertig ist der Lack. Das hat aber mit dem aktuell diskutierten Thema nicht viel zu tun, das war nur ein Randgedanke von mir, weil ich mich im Zuge der Boost.Thread-Beseitigung schonmal mit dem Thema beschäftigt hatte.
Zuletzt geändert von Schrompf am 22.07.2011, 16:39, insgesamt 1-mal geändert.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Stimmt, das waere bedeutend schoener :-)

Aehm .. ich setze heute oder morgen mal die bisher besprochenen Aenderungen um, dann koennen wir das ja vielleicht daran anschliessen. Leider bedeutet das wirklich eine Aenderung des Kern-APIs (da DefaultLogger::create etc. ja wegfiele), d.h. vielleicht sollten wir uns von vornherein darauf einstellen, dass das naechste Release die Nummer 3.0 tragen wird :-)

Uebrigens ist die Doku teilweise wirklich veraltet. CMake als Buildsystem wird nirgendwo erwaehnt (INSTALL und README habe ich mal aktualisiert) und ausserdem ist sie fast voellig Windows-zentrisch. Export fehlt auch.
Zuletzt geändert von Aramis am 22.07.2011, 16:42, insgesamt 1-mal geändert.
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Wie ich schon mal zu Schrompf meinte: sagt mir auch zu.

Gruß Kimmi
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Ok,

hier mal der auf "Open" gefilterte und vorab etwas aufgeraeumte Bugtracker. Kriegen wir das in naechster Zeit hin? Wie sieht es bei euch zeitlich aus? :-)

https://sourceforge.net/tracker/?group_ ... id=1067632
Benutzeravatar
Schrompf
Moderator
Beiträge: 4854
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf »

Puh. Ich könnte mir zwar mal einen Tag Zeit nehmen, aber ein subtanzieller Teil der offenen Issues ist so ein WischiWaschi-Zeugs, was bei uns funktioniert, aber dem OP nicht passt. Hm.

Collada-Export muss auch mal werden. Und ConvertToLH als eigene Klasse rausziehen, damit verschiedene Importer und Exporter den auch benutzen können.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Die erwaehnten Aenderungen an aiScene sind eeendlich (ich komme grade irgendwie zu gar nichts) drin. Im Zuge dessen haben sich noch etliche weitere groessere und kleinere Eingriffe ergeben. Siehe die Commit-Message.
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

Oh, mick-p fühlt sich jetzt wohl etwas auf den Schlips getreten, aber ich finde dieses »hier ist mein toller Patch, und aufräumen könnt ihr selbst«-Gehabe einfach völlig unangemessen.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Er hat nicht eben ernsthaft die ersten 3 Buchstaben unseres Projektnamens missbraucht um dich zu beleidigen? :-)

Ich lese da raus, dass du dich der bisherigen Reaktion auf den Patch grundsaetzlich anschliesst. Ich hatte urspruenglich vor, ihn selber anzupassen, hab dann aber beim Anblick von ComplexScene aufgegeben.
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

Das ist eben das Problem, das wir schon einmal hatten: Mick hat so eine Art »Code-Dump«-Vorstellung von Open-Source-Software, und wenn man ihm beibringen will, dass es eben nicht so funktioniert (weil später andere seinen Code warten müssen), fühlt er sich beleidigt oder nicht ernst genommen. Ich weiß nicht, ob ich an deiner Stelle das Risiko eingehen würde oder nicht – andere Meinungen?
glassbear
Establishment
Beiträge: 324
Registriert: 08.04.2003, 18:09
Alter Benutzername: Enrico_
Echter Name: Enrico
Wohnort: San Diego
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von glassbear »

klickverbot hat geschrieben:Das ist eben das Problem, das wir schon einmal hatten: Mick hat so eine Art »Code-Dump«-Vorstellung von Open-Source-Software, und wenn man ihm beibringen will, dass es eben nicht so funktioniert (weil später andere seinen Code warten müssen), fühlt er sich beleidigt oder nicht ernst genommen. Ich weiß nicht, ob ich an deiner Stelle das Risiko eingehen würde oder nicht – andere Meinungen?
Ich war auch mal so :oops: , bin jedoch mittlerweile dagegen. Mittel- und langfristig macht das nur Probleme.
Ein Hoch auf uns Männer... Auf die Frau, die uns HAT ( oder hat, und nicht weiß, dass sie uns hat ) ...auf die Idiotinnen ... besser gesagt VOLLPFOSTINNEN ... die uns hatten und uns verloren haben ... und auf die GLÜCKLICHEN, die das Vergnügen & Glück haben werden uns kennenzulernen!
Benutzeravatar
Schrompf
Moderator
Beiträge: 4854
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf »

Mich erreichte eine Mail.
mail hat geschrieben:Hi, I was wondering if there is any known time, of when Assimp will support Java.

Currently I program online 3D Java Demos:
for example:
http://have2chat.net/benchmark

And wanted to make a 3D model viewer online, and was hoping to use Assimp for model support.

Is there currently anyone dedicated to the develop of Java with Assimp.
If so will it be accessable via JNI, or will it be implemented as pure Java?

- David
Was soll ich darauf antworten? Haben wir denn erkennbare Java-Unterstützung?
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Huh, das habe ich etwas aus dem Fokus verloren. Fakt ist: klickverbot's SWIG Bindings muessten mit etwas Aufwand auch fuer Java funktionieren, oder? :-)
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot »

… die aber wiederrum ich etwas aus dem Fokus verloren habe – keine Ahnung, ob sie zur Zeit überhaupt in brauchbarer Form sind (müsste ich mir vom einem etwaigen nächsten Release auf jeden Fall noch einmal anschauen).
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis »

Fuer alle, die nicht auf der ML mitlesen:

Ein freundlicher Mensch namens IOhannes hat Pakete fuer Assimp in Debian-Unstable hineinbekommen. Damit koennte in absehbarer Zeit stable folgen und somit auch alle Debian-Derivate (es gab ja bereits vorher Pakete, aber nur ueber ein Launchpad-PPA).

http://packages.debian.org/source/sid/assimp

Davon abgesehen findet ihr hier einen Blender 2.59 Build mit Assimp-Import-Addon. Mit dem haben die hier vertretenen Assimp-Member nichts zu tun und er scheint auch nicht voellig fehlerfrei zu sein, aber ich hoffe dass sich in die Richtung noch was tun wird.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4854
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf »

Im Sourceforge-Forum hat sich jemand gemeldet, der Probleme mit dem Ogre-Loader hat. Der stammt doch von Jonathan Klein, oder? Jonathan, liest Du hier noch mit? Kannst Du evtl. mal seine Probleme anschauen? Einige davon sind vielleicht leichte Ziele.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2367
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Jonathan »

Ja, das ist noch eine Baustelle. Ich guck mal rein, aber ich hatte das letzte mal einige Compilerprobleme mit Assimp (man erinnert sich vielleicht), und hab auch sonst einiges zu tun. Aber es steht definitiv auf meiner Liste, nur halt nicht oben.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
kimmi
Moderator
Beiträge: 1405
Registriert: 26.02.2009, 09:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi »

Bezüglich des Debian-Packages: ich wäre für den einfachen Patch, der in der ML vorgestellt wurde. Andere Meinungen?

Gruß Kimmi
Antworten