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, 20:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Assimp - Brainstorming zum Release

Beitrag von Aramis » 12.07.2009, 21:59

Ich hab dieses Posting jetzt mehrere Wochen erfolgreich aufgeschoben, weil mir immer etwas dazwischen kam oder ich keine Lust hatte einen längeren Text zu schreiben ... :-)

Langsam sollten wir unsere Planungen für ein Assimp Release 1.0 konkretisieren. Wir haben ja via ICQ und auch hier im Forum mehrfach darüber gesprochen - auch wenn wir grade alle ziemlich beschäftigt sind, fände ich es schön diesen Meilenstein nun langsam aber sicher anzupacken. Ich hoffe, ich habe nicht ganz den Überblick über das Projekt verloren - hier ist mal der aktuelle Todo/Planungs-Stand, soweit mir bekannt:

Von rave3d weiß ich, dass er beabsichtigt die Arbeit an Assimp.NET wieder aufzunehmen und hoffentlich zum Release abzuschließen.
Thomas, von dir hab ich im Kopf dass es sich nur um Kleinigkeiten am Collada-Loader handelte - falls noch nicht alle beseitigt - sowie, mit einem großen Fragezeichen, MS3D. Kimmi, neben dem CMake-Kram sagtest du letztens nicht was von Q3 BSP - wenn ja, wie sieht es damit aus, ist das noch aktuell bzw. soll noch in's Release?

Ich hab _die meisten_ meiner zahllosen Bugs und Problemstellen, die in der ersten ToDo-Liste vor einem halben Jahr enthalten waren, mittlerweile gefixt. Zum Release will ich nun noch zwei etwas größere, aber bereits recht weit fortgeschrittene Punkte definitiv fertigkriegen. Zum einen jAssimp, zum anderen die Regressionstests. Letzteres wäre mir insbesondere wichtig weil wir es bei den letzten 'Releases' nie geschafft haben nicht kurz vorher noch neue Bugs einzuschleußen, die das Laden des einen oder anderen Testmodells dann peinlicherweise verhindert haben :-) Das muss nicht sein. Ich denke, ich hab jetzt eine Lösung gefunden die äußerst zuverlässig ist und gleichzeitig verhältnismäßig kompakt (Wie von Kimmi vorgeschlagen setzt sie auf Python, greift aber zum Vergleichen von Modelldumps auf assimp_cmd zurück).

Für alle Interessierten auch noch eine Liste von allem, was sich in den letzten Wochen/Monaten so hinter den Kulissen getan hat. Da nicht alles über's SF.net-Forum lief, sondern sich wild über E-Mails, IRC und einer Reihe anderer Kommunikationsmedien verteilte, hat sich vielleicht noch nicht alles herumgesprochen:
  • Mark Sibly hat seinem B3D-Importer Unterstützung für geskinnte Meshes hinzugefügt. Funktioniert bestens, im Repos hat's auch Testmodelle.
  • sueastside vom CrystalSpace-Team hat PyAssimp aktualisiert. Im ./scripts-Verzeichnis hat es ein Python-Skript, das mit viel regexp-Magie die python-Bindings aus den C++-Headern generiert. D.h. wenn jemand die Datenstruktur änderte, wäre es erforderlich selbiges Skript erneut auszuführen und danach das ./port/PyAssimp-Verzeichnis einzuchecken.
  • Im Forum hat's einen Herr, der sich mal an optionaler Anbindung an's FBX-SDK versuchen will. Halte ich für eine gute Idee, ich würde FBX-Modelle auch gerne lesen können. Mal gucken, was draus wird.
  • Hinzugekommen sind Hilfsfunktionen um Assimp-Modelle aus Buffern im Speicher laden zu können
  • Nach wiederholten Downtimes der SF.net Seite ist nun ein neues Design zu bestaunen - haben die Jungs von SF.net richtig _supertoll_ hingekriegt. Immerhin funktioneren mittlerweile die meisten Funktionen wieder ganz brauchbar. Was erst los ist, wenn sie die Foren, wie angekündigt, auf phpbb3 umgestellt haben, will ich gar nicht wissen.
Die Fragen, die afaik noch zu klären wären:
  • Wollen wir überhaupt ein Release? :-)
  • Wann wollen wir das Release anpeilen? Wollen wir uns gleich auf einen fixen Termin festlegen? Ich wäre für in ca. 7-9 Wochen
  • Soll es einen vorgeschobenen Release Kandidaten geben? Könnte man durchaus machen, alleine hier auf ZFX hat es genug Assimp-User um so etwas wie einen Vorabtest zur Sicherung der Qualität durchzuführen. Falls die entsprechenden Personen dazu bereit sind :-)
  • Was für Releasepakate soll es geben? Ich bin dafür, wie bisher auch, ein SDK und ein Binärrelease anzubieten (wobei letzteres wirklich nur die Binaries von AssimpView und Assimp umfasste, und keine Header oder lib's).
  • Wie soll das Buildsystem aussehen ... wir haben jetzt Scons, CMake, make, vs8, vs9, xcode ... u.v.a. ... wollen wir einfach das Chaos an Projektdateien und Skripten mitliefern oder uns auf eine universelle Lösung wie CMake beschränken? Ich tendiere zu Ersterem, weil einfacher.
Alex

klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 20:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot » 12.07.2009, 23:10

Passt zwar jetzt nicht ganz zum Thema, aber: Ein nahendes Release wäre für mich wohl auch Motivation genug, meine 1:1-Portierung des C-Interfaces nach D zu komplettieren und zu veröffentlichen. Mittlerweile hat mich auch schon irgendjemand darauf angesprochen, der über den Quellcode meines kleinen Software Rasterizers auf Github gestoßen ist...

Meine erste Antwort auf die Frage nach dem Buildsystem wäre zwar gewesen, ausschließlich CMake mitzuliefern, da so keine Verwirrung aufkommen kann, auf Windows dürften aber VS (und damit die VC-Projektfiles) wesentlich weiter verbreitet sein. Insofern würde ich zumindest die Konfigurationen für CMake und VS8 beilegen.
Zuletzt geändert von klickverbot am 13.07.2009, 19:25, insgesamt 1-mal geändert.

Benutzeravatar
Sternmull
Establishment
Beiträge: 264
Registriert: 27.04.2007, 00:30
Echter Name: Til
Wohnort: Dresden

Re: Assimp - Brainstorming zum Release

Beitrag von Sternmull » 13.07.2009, 19:07

Zum Buildsystem: Die naheliegende Lösung ist doch die CMake-Quellen und ein paar der populärsten generierten Ausgaben von CMake beizulegen (hab ich auch schon bei anderen Projekten so gesehen). Windows-User sind im allgemeinen daran gewöhnt das sie einfach einen Doppelklick auf die .sln machen können ohne sich erst angucken zu müssen wie CMake funktioniert :-) Man sollte aber keine VS9 Solution beilegen, sondern eine ältere. VS kann Projekte automatisch beim öffnen updaten, aber nicht "downdaten". D.h. eine Projektversion für das älteste VS die von VS9 gelesen werden kann macht alle glücklich.
Wenn man zusätzlich noch generierte Unix Make Files beilegt, dürften 90% aller User versorgt sein. Der Rest muss halt selber mal CMake.

Matthias Gubisch
Establishment
Beiträge: 272
Registriert: 01.03.2009, 20:09

Re: Assimp - Brainstorming zum Release

Beitrag von Matthias Gubisch » 14.07.2009, 08:36

Hallo zusammen

also zum Thema Buildsystem:
CMake-Quellen sollten wir beilegen, desweiteren, VS8 und VS9 Soulution (uprgraden ist zwar recht und schön funktioniert aber leider nicht immer zu 100%) Unix-Makefiles sollten imho auch dabei sein.
Was haltet ihr von Projektdateien für Eclipse oder Netbeans? auch im hinsicht auf Alexanders JavaPort?
Allgemein würde ich sagen lieber zuviele Projektdateien als zuwenig...

Weil ich finds immer ganz praktisch wenn man sich sowas runterlädt und dann einfach mal schnell builden und ausprobieren kann ohne erst irgendwas zusammenbasteln zu müssen.


zum Thema Assimp.NET die Interfaces wachsen recht schön im moment, ich hoffe ich kann im Laufe der nächsten zwei Wochen die Interfacedefinition nebst Doku einchecken.
Und dann muss ichs nur noch implementieren, hoff dass ich das dann auch relativ flott schaffe...

Grüße
Matthias
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben

Benutzeravatar
kimmi
Moderator
Beiträge: 1388
Registriert: 26.02.2009, 10:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi » 14.07.2009, 09:02

Bin für einen Release. Zur Zeit würde ich VC8 + CMake + normalen Make für Unix / Linux mitausliefern. Ein CMake-File habe ich noch für die Tests auf der ToDo, die kriege ich aber definitiv fertig.
Der Q3-Kram ist noch nicht weit gediegen, da ich nicht dazu komme, das anzufassen. Ich würde also eher nicht damit rechnen, daß es bis zum Release fertig wird ( aber vielleicht geschehen ja noch Wunder ).
Von den weiteren Punkten meiner ToDo habe ich zur Zeit noch nichts fertig gestellt. Mal sehen, wann das was wird.

Gruß Kimmi

Benutzeravatar
Ingrater
Establishment
Beiträge: 103
Registriert: 18.04.2007, 21:52

Re: Assimp - Brainstorming zum Release

Beitrag von Ingrater » 14.07.2009, 10:47

Es wäre auch sehr nett wenn ihr ein mingw-make file beilegen könntet. Ich hab mir zwar bisjetzt in meiner IDE (Code::Blocks) immer selbst ein Projekt gebastelt (import von vc projekt + anpassungen) aber so ein makefile wäre schon was feines...
Das ganze würde eventuell auch dadurch aktuell werden, dass ja jetzt seit kurzem der gcc 4.4.0 für Windows portiert wurde.

Benutzeravatar
kimmi
Moderator
Beiträge: 1388
Registriert: 26.02.2009, 10:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi » 14.07.2009, 10:49

Die kannst du dir mit CMake generieren lassen. Schau mal hier: http://www.cmake.org/cmake/help/cmake2. ... WMakefiles

Gruß Kimmi

Benutzeravatar
Ingrater
Establishment
Beiträge: 103
Registriert: 18.04.2007, 21:52

Re: Assimp - Brainstorming zum Release

Beitrag von Ingrater » 14.07.2009, 12:34

Wenn das so einfach geht, könntet ihr die ja auch mit cmake generieren und beilegen ;-)
Ich finds manchmal ätzend dass ich für jedes Lib das ich verwenden will mich in ein anderes build system einarbeiten muss.

Benutzeravatar
Schrompf
Moderator
Beiträge: 3848
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf » 14.07.2009, 12:53

Jupp, geht mir ähnlich. Ich pack jedesmal einfach alle Assimp-Dateien aus den betreffenden Verzeichnissen in mein bestehendes Projekt und ärger mich dann ein bisschen, wenn da irgendwas drin ist, was nicht dazu gehört, experimentell ist oder erst irgendwelche Defines braucht, um zu kompilieren. Da ist es schon gut, dass VS2008 der Quasi-Standard ist und ich mit dem Strom schwimme.

Zum Release: wenn ich mehr Freizeit zu verschenken hätte, müsste ich mich eigentlich noch um ein Rudel Bugs im Collada-Loader kümmern. Und ich habe immernoch die MS3D-Specs und Testmodelle zu Hause rumliegen, die ich auch mal in einen Loader verwursten wollte. FBX wird ja nun von so jemandem aus dem Sourceforge-Forum übernommen. Wieviel davon aber nun noch wird bis zum Release, weiß ich nicht... wenn ich mich jetzt festlegen lasse, werde ich nachher wieder angezählt, wenn ich mich doch nicht drum gekümmert habe :-)
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.

Benutzeravatar
kimmi
Moderator
Beiträge: 1388
Registriert: 26.02.2009, 10:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi » 14.07.2009, 13:04

Ich kann ja mal ne Python-Gui zusammenklickern, die das Generieren mach ( so wie die im Nebula-Device ). Dann muß man nichts mehr in die Tasten hauen, ein einfaches Klicken reicht :-)...
Und der Sinn von CMake ist ja gerade, daß man möglichst wenig Build-Enviroments parallel pflegen muß. Wenn wir nun wieder alles einchecken, haben wir die Pflege gleich mit an der Backe. Und das ist schon jetzt nicht wenig.

Gruß Kimmi

Benutzeravatar
Schrompf
Moderator
Beiträge: 3848
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf » 14.07.2009, 13:54

Naja... nein. Das Problem an den Projektgeneratoren ist halt, dass immer die Spezialeigenschaften hinten runterfallen. Sei es LTCG oder schlicht fp:fast. Wir müssen die erzeugten Builds ja nicht einchecken, sondern nur dem Release beilegen.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.

Benutzeravatar
kimmi
Moderator
Beiträge: 1388
Registriert: 26.02.2009, 10:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi » 14.07.2009, 14:30

Das wäre eine Idee, können wir gern machen!

Kimmi

Benutzeravatar
Sternmull
Establishment
Beiträge: 264
Registriert: 27.04.2007, 00:30
Echter Name: Til
Wohnort: Dresden

Re: Assimp - Brainstorming zum Release

Beitrag von Sternmull » 14.07.2009, 18:28

Mit Kleinigkeiten wie Compiler- oder Linker-Flags hat CMake eigentlich auch kein Problem. Die lassen sich durch Manipulation von ein paar Variablen hinzufügen, auch abhängig vom Zielsystem und Toolset.

Benutzeravatar
kimmi
Moderator
Beiträge: 1388
Registriert: 26.02.2009, 10:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi » 14.07.2009, 18:36

Ein Problem ist wahrscheinlich schon, sich cmake zu installlieren und zu benutzen. Wenn jemand Visual-Studio gewöhnt ist, möchte er halt auch entsprechende Project-Files vorfinden. Von da aus kann man so etwas für einen Release von mir aus schon mit zureichen. Für die Entwicklung können sich die Developer dann ja jeweils ihr eigenen Enviroment generieren.

Gruß Kimmi

Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 20:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis » 18.07.2009, 11:39

Ingrater hat geschrieben: Es wäre auch sehr nett wenn ihr ein mingw-make file beilegen könntet.
Es hat im Repos ein zusammengehacktes mingw-Makefile für assimp und assimp_cmd (makefile.mingw). Ich hab es grade getestet, es funktioniert tadellos - jedenfalls mit der vorletzten gcc-für-Windows Version.

Kleine Neuigkeit: das Assimp-Sample kompiliert und läuft jetzt auch unter Linux. Ich denke, die Sample- wie auch die Dokumentationsfront ist für's Release erstmal abgedeckt. Das sollte jedem reichen um Assimp bei sich zum Laufen zu bringen :-)
Dateianhänge
assimp-linux.png

Benutzeravatar
Schrompf
Moderator
Beiträge: 3848
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf » 18.07.2009, 12:50

Schick. Ich hab dafür jetzt zwei seltsame Mails bekommen von jemandem, der anscheinend D Bindings geschrieben bzw. aktualisiert hat. Das liest sich dann so:
johnktbk@gmail.com hat geschrieben: Hello, i've updated bindings for D.
I am now testing it with DirectX10:
http://www.picamatic.com/view/4483629_scr/

But i am not sure about calling conversion. There are a lot of enums, in C they unnamed. But in binding i gave them a name:
enum aiTextureOp
So to use them need to write something like:
aiTextureOp.aiTextureOp_Multiply etc.

How do you think, should i make them unnamed too?
tja... in der ersten Mail hat er noch ein Archiv mitgeschickt, dass wir mit ins Contrib-Verzeichnis packen könnten. Das aktualisierte hat er jetzt nicht mehr geschickt. Nuja... ich werd ihm mal vorsichtig antworten.

Bye, Thomas
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.

Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 20:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis » 18.07.2009, 13:22

Hm .. Klickverbot hat ja auch ein D-Binding. Offen gestanden hätte ich da deutlich mehr Zutrauen :-)

Seine Frage finde ich etwas merkwürdig .. aiTextureOp.Multiply wäre irgendwie das naheliegendste, oder etwa nicht?

Benutzeravatar
Schrompf
Moderator
Beiträge: 3848
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf » 18.07.2009, 14:04

Aramis hat geschrieben:Hm .. Klickverbot hat ja auch ein D-Binding. Offen gestanden hätte ich da deutlich mehr Zutrauen :-)

Seine Frage finde ich etwas merkwürdig .. aiTextureOp.Multiply wäre irgendwie das naheliegendste, oder etwa nicht?
Hab ich ihm auch so geschrieben. Er meinte, seine Bindings wären auf denen von Klickverbot aufgebaut und dann erweitert/vervollständigt. Aber frag mich mal, was die Unterschiede sind...
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.

klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 20:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot » 18.07.2009, 20:47

Irgendwie finde ich das schon ein bisschen steil – ich meine, da ich ja lediglich die C-Header 1:1 nach D umgeschrieben habe, kann man sich zwar denken, dass ich nichts dagegen habe, dass jemand meinen Code verwendet, bzw. rein rechtlich wahrscheinlich auch kaum etwas dagegen haben kann. Aber ich hätte mich ehrlich gesagt schon über eine kurze Nachricht gefreut, wenn jemand meinen Code von Github nimmt und für seine Zwecke verwendet/erweitert (nein, das ist nicht derjenige, von dem ich oben schon geschrieben habe, dass er mich kontaktiert hätte).

Mittlerweile habe übrigens auch ich eine Nachricht von diesem Herren erhalten: »I found your application with sources....IT'S ROX! […] Man, thank you very, very, very much for such gift!« Zu einigen Leuten dürfte es wohl nicht so ganz durchgedrungen sein, dass im Internet zugänglicher Sourcecode nicht automatisch heißt, dass man sich daraus beliebig bedienen kann – wäre »d4« nicht nur ein kleines Demonstrationsprojekt, wäre ich jetzt wohl sauer. ;)

Aber zurück zum Thema: Die naheliegenste Möglichkeit wäre natürlich aiTextureOp.Multiply – in meinen »Bindings« steht das auch schon so drinnen.

Ich kann natürlich nicht wissen, was dieser Vladimir (sofern ich den kyrillischen Absender richtig lese) noch geändet hat, aber mein Code war eigentlich nur eine schnelle Anpassung der für mein kleines Projekt relevanten C-Header nach D. Allein schon, weil ich nicht einmal alle Teile Assimps portiert habe, kommt es zum jetzigen Zeitpunkt nicht in Frage, den Code in Assimp aufzunehmen.

Ich habe mich aber gerade daran gesetzt, die D-Bindings einmal zu komplettieren und etwas aufzuhübschen. Das (Zwischen-)Ergebnis gibts dann (in den nächsten Tagen) auf http://github.com/klickverbot/dassimp.

Gibt es schon eine Richtlinie, wie bei zukünftigen Releases mit ABI-Veränderungen umgegangen wird? Im Moment habe ich eine Überprüfung auf aiGetVersionRevision() im Loader, die aber sicher strenger ist, also nötig, sobald es Releases gibt…

Edith sagt überhaupt nichts mehr…
Zuletzt geändert von klickverbot am 22.07.2009, 18:21, insgesamt 1-mal geändert.

Benutzeravatar
Schrompf
Moderator
Beiträge: 3848
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf » 18.07.2009, 22:18

Ich wusste nicht, dass Dich das stört, wenn jemand Deinen Code weiterentwickelt... allerdings kann ich auch nicht beurteilen, was der Kerl eigentlich geändert hat und ob das nun besser oder schlechter ist. Ich ging einfach davon aus, dass er sein Zeugs, wenn er es mir zuschickt, auch unter der Lizenz des Projekts veröffentlicht haben will. Aber wer weiß... theoretisch müsste man dafür ja irgendwas offizielles aufsetzen.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.

klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 20:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot » 18.07.2009, 22:34

Mich stört es auch nicht, wenn jemand meinen Code weiterentwickelt, zumal ich die nach D konvertierten Assimp-Header ja auch schwer als meinen Code bezeichnen kann. Ich hätte mich nur über eine kurze Nachricht seinerseits (und seine Verbesserungen) gefreut, wenn er sich meiner Arbeit bedient, bzw. vor allem, wenn er das Ergebnis dann veröffentlichen will.

Ich würde die »fertigen« Header dann einfach mit dem Assimp-Lizenzvorspann versehen (übrigens: die Datumsangabe sollte wohl auch 2009 einschließen) und wenn ihr wollt, könnt ihr sie offiziell aufnehmen. Sofern sich das C-Interface nicht radikal ändert, dürfte sich der Pflegeaufwand ja in Grenzen halten.

Benutzeravatar
Schrompf
Moderator
Beiträge: 3848
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf » 19.07.2009, 01:00

Ok, dann ist da kein böses Blut entstanden. Darf ich Dir die D-Bindings zuschicken, wenn der Kerl mir welche sendet? Ich kann deren Brauchbarkeit nämlich nicht bewerten.

[edit] Oh fuck, jetzt droht er mir damit, sich auch um die C#-Bindings zu kümmern.

Am Interface wird sich nichts mehr ändern, wenn es nach mir geht. Assimp unterstützt alles, was ich für wichtig halte. Die weitere Arbeit würde sich nach meiner Betrachtung auf neue Formate und Bugfixing beschränken.

Ich glaube, ich hab jetzt oft genug "meine Meinung" betont, um klarzustellen, dass andere Leute das anders sehen könnten. Daher auch die Warnung: es gibt andere Bestrebungen, um zum Beispiel Vertex-Animationen oder Splines einzubauen. Ich halte das für herzlich unnötig, aber mancher mag's. Diese Erweiterungen würden dann eine ziemliche Änderung an den Schnittstellen erfordern.

Oh. Ah. Moment. Wenn ich grad mal bei Schnittstellen bin: wollen wir die alte Änderung noch einbauen, das Material nicht pro Mesh, sondern pro Meshinstanz im Node anzugeben? Das wär eine ziemliche Änderung und kaum abwärtskompatibel zu machen, aber ich empfände es als passender zu den aktuell üblichen Strukturen von 3DEngines.

Die Änderung im Klartext: aus aiMesh würde die Membervar "unsigned int mMaterialIndex" verschwinden. Oder zumindest als "deprecated" markiert werden mit dem Hinweis, dass sie nur das erstbeste Material enthalten würde. Stattdessen würde die Meshinstanz-Liste in aiNode von "unsigned int" auf eine "struct aiMeshInstance" umgebaut werden, die aus "unsigned int mMeshIndex" und "unsigned int mMaterialIndex" bestehen würde. Damit ist es möglich, einen Mesh mehrfach mit verschiedenen Materialen zu instanziieren - das entspricht dem gängigen Verhalten von 3D-Engines, wie ich sie kenne.

Nachteil: Umbau der API, kaum abwärtskompatibel. Wenn man allerdings den alten Member behalten und mit dem ersten auftretenden Materialindex füllen würde, würde jeder alte Source noch funktionieren und bei den wenigsten Dateien würde sich überhaupt ein Unterschied ergeben. Es wäre wirklich nur für die innere Konsequenz. Was haltet ihr davon?

Bye, Thomas
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.

Benutzeravatar
Zudomon
Establishment
Beiträge: 2112
Registriert: 25.03.2009, 08:20
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Zudomon » 19.07.2009, 01:09

Schrompf hat geschrieben:Die Änderung im Klartext: aus aiMesh würde die Membervar "unsigned int mMaterialIndex" verschwinden. Oder zumindest als "deprecated" markiert werden mit dem Hinweis, dass sie nur das erstbeste Material enthalten würde. Stattdessen würde die Meshinstanz-Liste in aiNode von "unsigned int" auf eine "struct aiMeshInstance" umgebaut werden, die aus "unsigned int mMeshIndex" und "unsigned int mMaterialIndex" bestehen würde. Damit ist es möglich, einen Mesh mehrfach mit verschiedenen Materialen zu instanziieren - das entspricht dem gängigen Verhalten von 3D-Engines, wie ich sie kenne.

Nachteil: Umbau der API, kaum abwärtskompatibel. Wenn man allerdings den alten Member behalten und mit dem ersten auftretenden Materialindex füllen würde, würde jeder alte Source noch funktionieren und bei den wenigsten Dateien würde sich überhaupt ein Unterschied ergeben. Es wäre wirklich nur für die innere Konsequenz. Was haltet ihr davon?
Ich möchte mich nicht groß einmischen, nur ein kleiner Vorschlag. Wie wäre es, wenn ihr beides einbaut? Also dass das Instanzmaterial nicht gesetzt werden muss, und dann das Standard Objektmaterial genommen wird.

Benutzeravatar
Schrompf
Moderator
Beiträge: 3848
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Schrompf » 19.07.2009, 02:01

Ja, das war mein Vorschlag, nur mit umgedrehter Priorität: der Materialindex im Node ist immer gültig, aber alter Quelltext wird immernoch einen halbwegs korrekten Materialindex im Mesh finden.

Nebenbei: ich hab gerade durch Google gelernt, dass Assimp bei den Italienern der "italienischen Abdichterverband" ist. Das sind die Jungs, die Kunststoffe auf oder in Rohre spritzen. um sie dicht zu bekommen. Sollte uns das zu denken geben? Ich denke, nicht.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.

Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 20:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis » 19.07.2009, 02:03

Meine Meinung zu dem Vorschlag kennst du ja - gute Idee, macht ein paar Stellen etwas eleganter - aber potentiell viel Arbeit. Vor allem muss ich grade schon wieder an diesem verdammten Viewer-Code denken, bei dem ich irgendwie das Gefühl hab dass die Änderung doch ein Weilchen dauern könnte. Aber von mir aus.
. Stattdessen würde die Meshinstanz-Liste in aiNode von "unsigned int" auf eine "struct aiMeshInstance" umgebaut werden, die aus "unsigned int mMeshIndex" und "unsigned int mMaterialIndex" bestehen würde. Damit ist es möglich, einen Mesh mehrfach mit verschiedenen Materialen zu instanziieren - das entspricht dem gängigen Verhalten von 3D-Engines, wie ich sie kenne.
Ich würde der Einfachkeit halber in aiNode einfach ein separates Array für die Materialindizies anlegen - damit sinkt der Anpassungsaufwand enorm. Ist selbiges Array NULL, so werden die Meshmaterialien benutzt.
Gibt es schon eine Richtlinie, wie bei zukünftigen Releases mit API-Veränderungen umgegangen wird? Im Moment habe ich eine Überprüfung auf aiGetVersionRevision() im Loader, die aber sicher strenger ist, also nötig, sobald es Releases gibt…
Ich denke, dass eine API-Änderung (außer im aktiven Development-Branch) stets auch eine Erhöhung der Versionsnummer mit sich bringen wird, ein Test auf major.minor sollte also ausreichend sein. Die aktuellen Assimp Windows-Builds tragen seit einiger Zeit die Versionsnummer 0.5 - das Release wäre wohl sinnigerweise 1.0, weitere Releases dann 1.1, 1.2, ... oder hat irgendjemand eine andere Lieblingsversionierungsphilosophie? Wir können auch mit 0.01 anfangen :-)

PS: Ich brüte immer über kleinen Datenstrukturänderungen an aiLight und aiCamera. Wenn sich ein Vorschlag herauskristallisiert hat, poste ich ihn zur Diskussion. Bis dahin würde ich alle Binding-Macher bitten beide Datenstrukturen für's erste zu ignorieren.

klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 20:22
Echter Name: David N.

Re: Assimp - Brainstorming zum Release

Beitrag von klickverbot » 19.07.2009, 03:09

Aramis hat geschrieben:PS: Ich brüte immer über kleinen Datenstrukturänderungen an aiLight und aiCamera. Wenn sich ein Vorschlag herauskristallisiert hat, poste ich ihn zur Diskussion. Bis dahin würde ich alle Binding-Macher bitten beide Datenstrukturen für's erste zu ignorieren.
Ich habe die Strukturen jetzt in ihrer aktuellen Form drinnen, mit Änderungen werde ich dann bis kurz vorm Release warten.
Schrompf hat geschrieben:Ok, dann ist da kein böses Blut entstanden. Darf ich Dir die D-Bindings zuschicken, wenn der Kerl mir welche sendet? Ich kann deren Brauchbarkeit nämlich nicht bewerten.
Die darfst du mir natürlich gerne schicken, allerdings bezweifle ich nach der einen Frage ein bisschen, ob er wirklich recht viel weiter ist als ich… Sobald meine Bindings soweit fertig sind, werde ich ihn wieder mit der Bitte, sie doch zu testen, anschreiben.

Den aktuellen Stand meiner Arbeit gibt's auf http://github.com/klickverbot/dAssimp zu bewundern.
Ich bin übrigens gerade dabei, die Doxygen-Kommentare auf DDoc-Stil umzuschreiben (nein, das ist leider nicht sinnvoll automatisierbar), damit man mit D-Bordmitteln eine schöne API-Dokumentation generieren kann. Dabei sind mir einige Fehler aufgefallen, die ich in den nächsten Tagen mal hier posten werde. Jetzt heißt's aber erst einmal: Schlafen. ;)

Benutzeravatar
kimmi
Moderator
Beiträge: 1388
Registriert: 26.02.2009, 10:42
Echter Name: Kim Kulling
Wohnort: Luebeck
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von kimmi » 19.07.2009, 18:27

@Schrompf: Warum nicht beides einbauen und die alte Lösung als deprecated markieren. Im nächsten Release, sprich 2.0, wird die dann herausgelöst. So kenne ich das Vorgehen zumindest aus anderen Projekten und da hat das fast immer geklappt. Und so vermeiden wir versehentlich eingebaute Bugs kurz vor einem neuen Release.

Gruß Kimmi

Benutzeravatar
Sternmull
Establishment
Beiträge: 264
Registriert: 27.04.2007, 00:30
Echter Name: Til
Wohnort: Dresden

Re: Assimp - Brainstorming zum Release

Beitrag von Sternmull » 20.07.2009, 19:46

Als ich gestern ein wenig in der Doku gelesen hab sind mir zwei Tippfehler aufgefallen:
  • - Im C++ Beispiel steht "ASSIMP::Importer importer;", der Namespace heißt aber "Assimp"
    - In der Beschreibung zu "aiProcess_OptimizeGraph" hat einer die shift-Taste
    verfehlt "..., use the AI_CONFIG_PP_OG_EXCLUDE_LIST<7tt>"
Der Vorschlag von Schrompf, den Materialindex pro Instanz zu setzen, ist mir übrigens innnerhalb der Doku auch schon unter die Augen gekommen (hab leider nicht mehr im Kopf wo genau das Stand). Ich persönlich find den Vorschlag super.
Die Angst vor Bugs vor der Release kann ich verstehen. Schön wärs allerdings wenn die neue Lösung die alte ersetzen würde (da es dann weniger Potential für Verwirrung auf Seiten der User gibt). Überlegts euch gut, nach der Release werden die User zumindest für die nächsten Versionen eine abwärtskompatible API erwarten.

Meinen Einstieg in Assimp fand ich übrigens ganz angenehm (auch wenn ich erst ein paar Zeilen ungetesteten Code damit geschrieben habe). Fein gemacht :-)

Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 20:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Aramis » 20.07.2009, 20:50

Verdammt, das kommt davon wenn man meint clever zu sein und mittels find'n'replace 20 verschiedene Schreibweisen des Namens Assimp auf einen gemeinsamen Nenner bringen zu können :-) Wird korrigiert, danke für den Hinweis.

Benutzeravatar
Thoran
Establishment
Beiträge: 194
Registriert: 15.05.2009, 12:51
Wohnort: Stuttgart
Kontaktdaten:

Re: Assimp - Brainstorming zum Release

Beitrag von Thoran » 21.07.2009, 13:42

Sorry, wenn ich hier als aussenstehender poste, aber eure Disussion über cmake und build-systeme hat mich interessiert.
kimmi hat geschrieben:Ein Problem ist wahrscheinlich schon, sich cmake zu installlieren und zu benutzen. Wenn jemand Visual-Studio gewöhnt ist, möchte er halt auch entsprechende Project-Files vorfinden. Von da aus kann man so etwas für einen Release von mir aus schon mit zureichen. Für die Entwicklung können sich die Developer dann ja jeweils ihr eigenen Enviroment generieren.

Gruß Kimmi
Bei eure Diskussion bleibt ein bißchen außen vor, daß eine *.sln harte Pfade zu Dependencies hat. Nun weiß ich nicht ob das bei Euch ein Problem ist und wie weit ihr Dependencies habt, aber in so einem Fall würde ich cmake jedem anderen Buildsystem vorziehen. Wenn ich ein OpenSource-Projekt runterlade, daß nur *.sln beilegt und ich diese dann öffne und es nicht out-of-the-box kompiliert, dann trete ich es meist schon in die Tonne, weil es mich zu einem gewissen Grad frustriert und das Rungeklickere in VS zum ändern von Pfaden echt nervig ist. Wenn ich cmake files habe, dann lasse ich mich zumindest darauf ein cmake-gui aufzurufen und nen configure-run zu starten. Je nachdem wie gut die beigelegten cmake-module und die Dependencies entsprechend dokumentiert sind, tut das dann ja auch ganz gut.

Aber wie gesagt, ich bin außenstehender.

Thoran
Wer Rechtschreibfehler findet, darf diese gerne behalten.
Mein Entwicklertagebuch
Aktuelle Projekte: Universum: Domination (ehemalig AlphaOmega),Universum: Sternenjäger
Spieleengine Unreal 4

Antworten