BlExFoS

Nachdem ich nun schon auf Grund einer Anfrage nun schon etwas am Werkeln bin und mich weitere Anfragen erreichten:





Momentan geschieht das auf Basis von Automatisierung. Das bedeutet, dass die Programme dazu geöffnet sein müssen und sich die Maus in Teilen des Prozesses von allein bewegt.

Bei Blender lässt sich das meinerseits leider nicht ändern, da ich keine Zeit habe, mich in Python einzuarbeiten, und das Blender-Interface leider auch keine nutzbaren Controls zur Verfügung stellt. Das bedeutet leider, dass man einen Einstellungsmarathon durchlaufen muss, damit mein Exporter die Koordinaten der Schaltflächen weiß. Danach darf an der zu nutzenden Blender-Version auch nichts mehr geändert werden! War Blender bei der Konfiguration im Vollbild auf Monitor eins, muss es auch beim Export so sein, da die Schaltflächen-Koordinaten sonst abweichen! Momentan probiere ich die Koordinaten abhängig von der Fensterposition zu machen, aber das war bisher nicht von Erfolg gekrönt.

NifSkope hingegen sollte sich nahezu unauffällig automatisieren lassen. Unter Umständen kann ich hier die Änderungen sogar direkt an der jeweiligen nif-Datei vornehmen, sodass NifSkope nicht geöffnet sein muss.


Geplante Features:

• Kompletter Export: Blender + NifSkope
• Blender-Export: Lediglich der Export aus Blender wird ausgeführt
• Nif-Anpassungen: Lediglich die Anpassungen in NifSkope werden ausgeführt
• Stapelverarbeitung: Unbeaufsichtigte Bearbeitung mehrerer Dateien hintereinander

Getestet wird bereits (ausführlich) mit Modellen von AlbiTheReal und Schmelz - Danke dafür.

Allerdings bräuchte ich noch einen sinnvollen oder wenigstens gut klingenden Namen für das Programm, da mich der Projektname irgendwie an schwarze Füße erinnert. :roll:

*Es handelt sich dabei lediglich um den Projektname! Dieser sollte (und wird es hoffentlich) sich bis zum Release noch ändern.

Malo schrieb:

Wie wird sich das Verhalten mit den Dismemberment Part die ja alle ihren eigenen Nummern Code haben.

Zum Vergrößern anklicken....

Ich nehme an, Du beziehst dich hierauf? Darüber habe ich mir bisher noch keine Gedanken gemacht. Allerdings besagt die verlinkte Anleitung ja, dass man "nur" die Strings mit den entsprechenden Zahlen ersetzen muss - beispielsweise "BP_LEFTLEG" mit 37.
Theoretisch bräuchte ich also eine Liste mit den möglichen Strings und den Nummern, mit denen sie normalerweise ersetzt werden. Das sollte sich dann mit einer einfachen Ersetzungs-Funktion realisieren lassen.

Malo schrieb:

Und mit unterschiedlicher Anzahl an NiTriShapes?

Zum Vergrößern anklicken....

Die Anzahl der NiTiShapes sollte sich auslesen lassen. Und dann werden die nötigen Änderungen einfach an jedem NiTriShape vorgenommen.
Oder verstehe ich deine Frage jetzt falsch?

Schmelz schrieb:

Danke; freut mich, dass du dich der Aufgabe so umfassend annimmst!
Wenn ich dir irgendwie helfen kann, stehe ich natürlich weiterhin zur Verfügung!

Zum Vergrößern anklicken....

Ok, damit gehört deine Seele mir! :evil:
Im Ernst: Solange ihr meine Rückfragen beantwortet wird alles gut. :lol: Ich bin mit 3D-Modelling für Skyrim absolut nicht vertraut und brauche daher euer Wissen. Ihr wisst, was getan werden muss, ich kann es in ein Programm umsetzen (hoffentlich).

------------------------------------------------------------------------------------------------
Mein Plan sieht momentan so aus:

1. Die im Video gezeigten Schritte automatisieren (in der Hoffnung, dass es sich dabei wirklich um den Standard-Weg handelt).
2. So viel wie möglich der NifSkope-Automatisierung in direkte Dateiänderung umwandeln.
3. Die Sache mit den Dismemberment-Parts angehen. Hier scheint es eine Liste mit den String-Zahlen-Äquivalenten zu geben. Daran werde ich mich mal orientieren.

Weitere Funktionen können gerne gewünscht werden. Ich meine, bei SandraX etwas zum Import in Blender gelesen zu haben. Ich benötige dann allerdings möglichst detaillierte Anleitungen.

Zu den sicherlich nett gemeinten Spenden:
Ich lehne dankend ab! Es freut mich zwar, dass der einen oder anderen Person etwas an meiner freizeitlichen Programmier-Arbeit liegt und bereit wäre, dafür zu zahlen.
Allerdings biete ich meine Programme kostenlos an und will mich auch nicht durch Spenden unter Druck setzen lassen eine bestimmte Funktion einzubauen oder das Projekt einem meiner anderen Projekte vorzuziehen - ohne mit diesem Satz jetzt irgendjemand etwas unterstellen zu wollen.
Ich bitte dies zu akzeptieren.

Ich schließe mich dann mal mit Neuigkeiten an.

Da die aktuelle NifSkope-Version auf Qt setzt ist eine Automatisierung nicht möglich!


Ok, genug Panik und Enttäuschung verbreitet. Ich meine damit eine sinnvolle Automatisierung durch Mausbewegungen, -klicks und simulierten Tastatureingaben.

Eine Automatisierung durch Dateiänderungen ist aber möglich! An dieser wird momentan auch gearbeitet. Der Vorher-Nachher-Vergleich und die Analyse der Änderungen im Hexeditor dauert leider etwas, weshalb bisher "nur" folgende Dinge vollautomatisch geschehen:

• Reset Block Details
• Änderung der beiden "User Version"-Einträge
• Konvertierung von NiNode in BSFadeNode
• "IntegerData" in BSXFlags zu 138 ändern
• "Flags" in bhkCollisionObject auf 129 ändern

Aktuelle Vorausstzungen:

• Python 2.6.6 (falls jemand den automatisierten Export nutzen will)
• Blender 2.49b (falls jemand den automatisierten Export nutzen will)
• PyFFI (falls jemand den automatisierten Export nutzen will)
• nifScript for Blender 2.49b (falls jemand den automatisierten Export nutzen will)
• NifSkope 1.1.1
• Modelle, die wie im Video gezeigt vorbereitet wurden (beispielsweise Kollision schon in Blender geschrumpft)

Aktuell wird das Teil in AutoIt entwickelt (wegen der Blender-Automatisierung). Eventuell reiche ich auch noch eine mit Qt erstellte Version nach. Diese dürfte nochmal einen Tick schneller sein (weil C++ meistens schneller ist als AutoIt - bei gutem Stil), bringt aber dank benötigter Framework-DLLs anstatt ein paar Kilobyte (AutoIt-Version) mindestens 10 Megabyte auf die Waage. Ich kann natürlich auch auf die Qt-Framework-DLLs verzichten (dann sind es in C++ auch nur ein paar KB), dafür gibt es dann aber kein graphisches Interface in Qt (in AutoIt ist das in den paar KB schon enthalten). Die Qt-Version enthält dann allerdings die Blender-Automatisierung nicht!

Für die bereits geleistete Arbeit dürft ihr mich jetzt loben - oder fertig machen, wenn ihr meint, dass wäre für die vergangene Zeit zu wenig. :lol:
Ansonsten hätte ich gerne ein wenig Feedback zum letzten Absatz. Vor allem im Bezug auf die mögliche Qt-Variante, ein graphisches Interface (oder reicht euch Batch?), ...

Für die bereits geleistete Arbeit dürft ihr mich jetzt loben

Zum Vergrößern anklicken....

Ist hiermit geschehen.
Als "Fan" des Terminals, bzw. der Eingabeaufforderung würde mir eine simple Stapelverarbeitung ausreichen.
Keep it simple eben.

Wirst du den Benutzern eine Möglichkeit geben, die Materialeinstellungen ihrer Kollisionen über deinen Exporter zu definieren?

Zum Vergrößern anklicken....

Nein, ich bin knallhart und lasse das später manuell anpassen.

Wirst du den Benutzern eine Möglichkeit geben, die Materialeinstellungen ihrer Kollisionen über deinen Exporter zu definieren?

Zum Vergrößern anklicken....

Ok, meine erste Antwort war ein Witz. Es wäre natürlich sinnvoll, wenn man die zu nutzenden Materialien irgendwie einstellen kann. Daher werde ich das schon irgendwie umsetzen.

Wenn ja, wie wäre das ohne grafische Oberfläche benutzerfreundlich möglich?

Zum Vergrößern anklicken....

Ohne graphische Oberfläche = Batch/Shell/Terminal/Eingabeaufforderung (nenne es, wie Du willst). Und im gleichen Satz schreibst Du von Benutzerfreundlichkeit? Der Code würde dann möglicherweise so aussehen (Pseudo-Code, frei erfunden):
Hier würde dann die Datei "C:\meine nifs\Voll tolle Nif.nif" angepasst werden. Sie hat zwei mindestens zwei Materialen, wobei das erste auf "material1" und das zweite auf "material2" gesetzt wird. Sollten weitere Materialien enthalten sein, werden diese hier nicht verändert. Für weitere Materialien könnte man natürlich weitere Parameter anhängen.
Für besonders unfreundlich halte ich das System nicht. Allerdings soll es Leute geben, die nicht gerne mit Eingabeaufforderungen arbeiten. Außerdem müsste der Benutzer für jede nif-Datei wissen, wie viele Materialien sie enthält und auf was diese gesetzt werden sollen. Das bedeutet: Nif in NifSkope öffnen -> Materialien zählen und notieren, welches wie gesetzt wird -> Code-Zeile(n) schreiben
Allerdings wäre es graphisch nicht viel anders. Auch hier muss der Benutzer wissen, welcher Materialeintrag auf was gesetzt werden soll. Allerdings könnte man hier eventuell alle vorhandenen Einträge in einer Tabelle anzeigen lassen.

Neun Monate sind inzwischen seit meiner letzten Meldung hier vergangen. Neun Monate, in denen einiges passierte.

Der größte Teil der Zeit wurde, ich gebe es zu, für andere Dinge als „BlExFoS“ genutzt. Aber auch in der Zeit, die ich in dieses Projekt investierte, tat sich viel.
Das Projekt, wie es hier bisher beschrieben wurde, existiert nicht mehr! Das ist jetzt kein Grund zur Panik, da es lediglich bedeutet, dass der Blender-Teil des Exports nicht umgesetzt wird.





Nachdem ihr euch nun die ganzen Hintergrundinformationen durchgelesen habt (oder auch nicht), will ich euch den aktuellen Stand nicht vorenthalten.

Das im Video gezeigte Modell wurde von AlbiTheReal vom Team Kinetic (http://team-kinetic.de/ bzw. http://www.youtube.com/user/KIneticMods) für die Entwicklung, Tests und Info-Videos zur Verfügung gestellt.

Am Entfernen der einzelnen Properties aus den NiTriShapes arbeite ich momentan.
Wie ich das Setzen des „Has Vertex Colors“-Eintrags umsetzen werde, weiß ich noch nicht. Das Problem dabei ist, dass ich theoretisch die Anzahl der NiTriShapes und den Wert des Eintrags wissen müsste. Er könnte ja bereits auf „yes“ stehen und dürfte somit nicht geändert werden.
Da ich die Anzahl der NiTriShapes für „Update Tangent Space“ aber sowieso benötige, könnte man die eventuell vor der Anpassung vom Benutzer erfragen.

Ein weiteres Problem wird das Kopieren der „BSLightningShaderProperty“ aus einem anderen Modell sein. Die Lösung hierfür ist momentan, dass die Automatisierung nach dem Speichern des Modells endet und der Benutzer die benötigen Branches manuell kopiert.
Die Schritte nach dem Kopieren der Branches sollten sich wieder automatisieren lassen, sodass ich mir eine zweigeteilte Automatisierung als bestmögliche Lösung vorstellen könnte.

Hinweis:
Die langsamen Mausbewegungen und die Stopps werden in den Release-Versionen nahezu nicht mehr wahrnehmbar sein. Das ist momentan nur zu Debug-Zwecken so.

PS: Nachdem der Blender-Teil nun ja nicht mehr automatisiert wird und „BlExFoS“ auch kein Name für ein Release ist, bin ich für Namensvorschläge offen.

Sodele, der erste Teil, also bis zur BSShaderPPLightningProperty, ist umgesetzt!

Dazu musste das Interface ein wenig verändert werden. Das Ergebnis ist im Anhang zu sehen. Außerdem habe ich für das Bild mal einen Durchlauf an Albis Modell mit der normalen Geschwindigkeit, also ohne Debug-Pausen und -Bremsen, erstellt. Das Ergebnis: Knappe 77 Sekunden wurden benötigt. (Die eine oder andere Optimierung ist hier eventuell möglich.) Wer von euch schlägt die Zeit? Aber bitte fehlerfrei und das auch nach 20 Dateien noch. :lol:

PS: Ich benötige immer noch einen sinnvollen Name für ein Release.