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.
klickverbot hat geschrieben:Ich habe TortoiseSVN gerade entfernt und neu installiert – das bin/-Verzeichnis wird sehr wohl zum systemweiten Pfad hinzugefügt. Oder habe ich dich hier falsch verstanden, Schrompf?
Ne, das passt schon. Ich weiß halt nur nicht, ob die Exe nun zu TortoiseSVN gehört oder ob in jeder Subversion-Install vorausgesetzt werden kann. Denn wenn wir die als Make-Step integrieren, dann scheitert ja der Build auf allen Systemen, auf denen die Exe fehlt. Ganz zu schweigen von Linux-Nutzern und Mac-Leuten.
Gibt es denn eine Möglichkeit, einen Build Step als "optional" zu markieren, so dass der Build auf jeden Fall weitergeht?
In CMake sollte das kein Problem sein (ich kann es mir zumindest nicht vorstellen), und für die VC++-Integration müsste man eventuell ein kleines Wrapper-Skript schreiben.
SubWCRev gehört zu TortoiseSVN, Subversion selbst hat aber ein Tool namens svnversion, das man alternativ verwenden kann. CMake unterstützt Regular Expressions, es wäre also kein Problem, die SubWCRev-Variable mit dem Output von svnversion zu ersetzen. Unter Windows/VC++ müsste sich aber bitte jemand anderer eine Lösung mit svnversion überlegen (zum Beispiel, indem die Datei sonst direkt aus dem Batch-Skript geschrieben wird). Wenn keines der SVN-Tools gefunden wird, dann wird eben Revision 0 angenommen und dem Benutzer eine Warnung präsentiert.
Ich kann mich einmal an die CMake-Implementierung setzen, möchte aber zuerst auf die VC++-Lösung warten, da CMake sicher flexibler ist…
Zuletzt geändert von klickverbot am 06.04.2010, 14:35, insgesamt 1-mal geändert.
So, ich habe gerade mal die Subversion-Settings auf Sourceforge angesehen und die unterstützen Python-Hooks. Allerdings scheint es noch kein Skript zu geben, welches die Revision einträgt. Da kann man nun aber das Folgende machen:
1. Skript in Python schreiben, welches die Revision vopn SVN abfragt ( wie das geht, weiß ich leider noch nicht, aber so etwas wird unter Garantie unterstützt oder man nimmt serverseitig halt svninfo ).
2. Pythonskript als Hook einbinden, welches nach einem Commit ein aktualisertes Revision-File committet ( ausgenommen das File revision.h, um einen Endlosloop zu vermeiden ). Sourceforge bietet für solche Zwecke extra ein entsprechendes Webinterface an.
Was für Vorteile das hat? Das läuft serverseitig, der Committer muß sich nicht darum kümmern, welches Betriebssystem das hat. Jeder Commit aktualisiert automatisch die Revision.
Was haltet ihr davon, das würde das Problem ( wie ich finde ) an der richtigen Stelle lösen. Und ich kann mich darum kümmern.
Klingt gut. Aber mach dir bitte nicht zuviel Arbeit. Wenn du siehst dass das sehr viel aufwaendiger wird als gedacht, gehen wir lieber doch zum Custom-Buldstep zurueck. Das ist vielleicht nicht ganz so elegant, aber das Ergebnis zaehlt :-)
Ich hab ihm grade geantwortet. Vor dem Absenden hab ich dann leider alles rausgeschmissen was mir zu boese vorkam, wenn ich es mir jetzt durchlese kommt es mir fast schon zu harmlos vor.
Ich habe ihn mal darum gebeten, daß er den Hintergrund seiner Ideen näher erläutert. Die von ihm angesprochene Datenstrukturen kenne ich aus physikalischen Simulationen. Vielleicht hat er da noch Hintergedanken, die uns außer Ärger doch tatsächlich einen Nutzen bringen könnten.
Oder er ist halt einfach ein Spaddel :).
Ich glaube der redet einfach sehr gern sehr viel. Er redet immer von sehr vielen Sachen die er gern tun würde, aber ich glaube, wenn man ihm einfach mal ein bis zwei Monate zeit gibt etwas wirklich umzusetzen ist ganz schnell wieder Ruhe im Schacht.
Der Typ nervt doch einfach nur. Große Sprüche nur um der Aktivität Willen. Und jetzt stellt sich auch noch heraus, dass seine großen Umbauten für ein paar exotische Dateiformate von Playstation1-Spielen gedacht sind. Das kann er sich an den Hut stecken. Assimp lädt 3D-Daten für Echtzeit-Grafik. Fertig. Und die Leute, die die Lib für ihre Raytracer benutzen, haben sich ja auch noch nicht beschwert.
Komische Vorstellungen hat der, nachvollziehbarer Platzer :D ! Du bist dir aber schon im klaren, daß der jetzt trotzdem weiter machen wird mit nerven. Einfach austrocknen lassen hilft immer noch am besten gegen Trolle!
Wenn ich als quasi Unbeteiligter etwas dazu sagen darf:
Ihr tut euch selbst und anderen einen Gefallen, wenn ihr, so noch nicht geschehen, wie er auch vorgeschlagen hat, auf der Website deutlich macht wofuer ASSIMP gedacht ist (Daten zum Rendern auf Standard Graphikhardware aufbereiten, wenn ich das dort richtig interpretiere) und wozu ggf. eben nicht.
Auch wenn man immer argumentieren kann, dass man fuer Lau eben auch nichts erwarten darf, so weckt man doch indem man etwas veroeffentlicht gewisse Erwartungen, und diese sollten von vornherein moeglichst frei von Missverstaendnissen sein.
Assimp aims at providing a full asset conversion pipeline for use in game engines / realtime rendering systems of any kind but is not limited to this audience.
Es soll ja auch nicht so klingen dass die Daten fuer andere Zwecke nicht brauchbar waeren :-)
Noch was: ich hab in der aktuellen Version der Website die Beschreibung des SVN-Checkouts geaendert:
The latest source is available via SVN. Be aware, however, that we can't make any guarantees that a particular revision compiles and works fine on your platform. For production use, our recommendation is to use a stable release. For anonymous checkout use:
Und ich in dafuer unsere Politik tatsaechlich entsprechend zu aendern. User sollen dieses Release nun verwenden, experimentierfreudige gerne den Trunk. Andere Projekte kriegen ja immer noch genug Feedback zur aktuellsten Version deswegen. Ich denke wir verschaffen uns so die Freiheit auch groeßere Aenderungen durchzufuehren. Außerdem werden Commits in den Trunk dann ungefaehrlicher, was ich sehr begrueßen wuerde :-)
»Meinungen?«: Ich wollte gerade etwas Ähnliches vorschlagen, meine nicht sehr gewichtige Unterstützung hast du, Alexander. ;)
On a related note: Ich würde auf der »Downloads«-Seite klar stellen, dass der Git- und der Mercurial-Clone keine offiziellen Repositiories sind, die regelmäßig aktualisiert werden, sondern lediglich »privat« von manchen Entwicklern genutzt werden, und sie lediglich bereitstehen, um anderen Nutzern ein neuerliches komplettes Importieren der ganzen Versionsgeschichte zu ersparen (zumindest ist es bei meinem Git-Repository so). Vielleicht wäre es auch sinnvoll, die beiden Überschriften zu entfernen und die Links zu den Repositories als Anmerkung in den SVN-Abschnitt zu verfrachten…
Gut, habs geaendert. Um nochmal dran zu erinnern: Samstag ist Release-Day. Bitte nur noch ueberschaubare Aenderungen, also entweder Bugfixes oder Doku-Updates.
Bislang hat noch niemand im SFForum oder auf der ML gemeckert dass in den Download-Paketen was fehlt. Irgendwie kann ich nicht dran glauben. Kann irgendjemand hier bestaetigen dass es mit den Dingern tatsaechlich moeglich ist Anwendungen gegen Assimp zu linken bzw. im Falle des ZIPs Assimp selber zu kompilieren (Windows wie Linux wie Mac)? (bei mir klappt's).
Ich werde die Pakete wieder hochladen (mach ich dann wohl am Samstag Nachmittag). Dann steht die ganze spaßige Ankuendigungssache an. Freiwillige? Sollte man vielleicht schonmal einen Text verfassen der dann ueberell reingepostet werden kann? Wo ueberall Ankuendigungen?
Ich probier mich mal, weil ich sonst bisher nix außer Stänkereien beigetragen habe :-)
----
New Assimp Release available
A new release of the <link>Open Asset Import Library</link> (short: Assimp) is now available. Assimp is a portable library to load 3D scenes and models from 20+ different file formats, including Collada .dae, 3DSMax .3ds, Lightwave .obj, Milkshape .ms3d and DirectX .x. Assimp is geared mainly towards 3D engines and other GPU-accelerated rendering, providing the data in an straight-forward in-memory format and offering a multitude of post processing steps to further enhance the imported data. It supports meshes including multiple UVs, vertex colors and tangent space, bones, scene hierarchies, materials, node/bone animations, lights and cameras. The post processing steps include cleanup, validation, normal and tangent space generation, vertex cache optimisation, righthand to lefthand conversation and many more.
The new release contains all the updates, bugfixes and new features since the last release at May 2009. New formats included Collada, MS3D, Ogre Models and <wasnnoch?>. The build system has been improved, VS8, VS9 and cmake are supported out of the box now. Experimental FBX support is in the works at the moment.
Assimp is written in portable C++ and has been tested on both 32 and 64bit, little and big endian system on Linux, Windows and Macintosh. A C++ and a plain-C interface is provided, bindings for Python, D, BlitzMax are available. C# and Java are supported, too, albeit limited at the moment. Assimp has no external dependencies except Boost, and an optional NOBOOST target is provided as well.
---
Korrekturen erwünscht. Was wären denn noch erwähnenswerte größere Errungenschaften seit dem letzten Release? Mai 2009 ist ja nun schon ne Weile her.
[edit] Beleidungen von NOBOOST-Nutzern entfernt. 8-)
Du könntest noch schreiben, daß mein BSP-Loader ebenfalls in Arbeit ist und in eienm zukünftigen release dabei sein wird.
Assimp is geared mainly towards 3D engines and other GPU-accelerated rendering, providing the data in an straight-forward in-memory format and offering a multitude of post processing steps to further enhance the imported data
Müßte das hier nicht ... and offers a multitude of post ... heißen?
Hoert sich gut an, finde ich. Die erwuenschten Korrekturen: :-)
models from 20+ different file formats
models from 25+ different file formats
(es sind sogar ueber 30, aber einige sind ja nicht so sonderlich ernst zu nehmen)
New formats included Collada, MS3D, Ogre Models and <wasnnoch?>
New formats included Collada, MS3D, Ogre XML Models and TrueSpace.
(Wenn ich so ueber die Liste blicke hat sich davon abgesehen nicht sooo viel veraendert - hauptsaechlich Bugfixes ohne Ende)
C# and Java are supported, too, albeit limited at the moment.
(Wuerde ich weglassen - sind halt in Arbeit, aber eigentlich nicht praktisch nutzbar)
Experimental FBX support is in the works at the moment.
More formats are in development.
(Ich hab auch Loader in Arbeit bzw. Planung. Aber wieso die und FBX und Q3bsp nicht einfach einbauen und erst spaeter den großen Hammer raushauen?)
Ich nehme mal an, niemand hat zufaelligerweise eine digitale Signatur fuer PE Binaries herumliegen und kann uns diese ausborgen (waere ja egal auf welchen Namen die laeuft)? Ich mag es nicht so gerne wenn UAC unseren Installer gleich mal als boese brandmarkt.
Schrompf hat geschrieben:
The new release contains all the updates, bugfixes and new features since the last release at May 2009. New formats included Collada, MS3D, Ogre Models and <wasnnoch?>. The build system has been improved, VS8, VS9 and cmake are supported out of the box now. Experimental FBX support is in the works at the moment.
Wegen Ogre: Da die Animationen noch nicht immer korrekt funktionieren (d.h. es gab mal ein Testmodell, wo die Animation zufälligerweise korrekt aussah, aber eben nur eins), wäre ich dafür, 2-3 Zeilen auszukommentieren, damit im stabilen Release keine total kaputten Features hängen.
Statische Modelle sollten eigentlich genügend gehen, Materialien funktionieren ja auch prinzipiell aber ich habe nunmal als die grob funktionierten mit Animationen angefangen, also ist das ganze noch nicht sehr ausführlich getestet.
Vielleicht sagt ihr auch, dass selbst der Teil für statische Modelle + Materialien nicht ausgereift genug ist und im stabilen Release gar nicht auftauchen sollte, damit könnte ich auch leben.
Fertig machen werde ich den Loader auf jeden Fall (brauche ihn ja für mein Projekt), aber halt nicht bis morgen früh.
wäre ich dafür, 2-3 Zeilen auszukommentieren, damit im stabilen Release keine total kaputten Features hängen.
Ok, wenn du das fuer sinnvoll erachtest: klingt gut.
Nochwas: ich mache die Paketuploads und den Branch morgen so zwischen 16-18 Uhr wenn die SF.net Downtime nicht dazwischen funkt. Die CHM-Doku wuerde ich dann auch gleich neu bauen, ihr koennt es euch also sparen den HTML Workshop laufen zu lassen wenn ihr Doku Fixes eincheckt.
So, da ich jetzt nicht mehr zum Testen der D-Bindings auf x86_64 gekommen bin, habe die aktuelle Situation kurz in der dAssimp-README vermerkt. Übrigens gibt es vom Referenzcompiler für D ohnehin (noch?) keine 64 bit-Versionen, das Problem hält sich also in Grenzen…
1.1 Branch steht. Wer noch was einzufuegen hat: bitte in diesen committen und den Trunk in Ruhe lassen. Pakete mache ich spaeter am Abend (das alles nochmal sauber durchzutesten braucht doch etwas mehr Zeit als erwartet). Bitte etwaige Commits mit mir via Skype/ICQ koordinieren.
