07.03.2014, 17:58
Ruhm, Ehre, den Beweis dass du nicht nur tolle und semantisch tiefgründige Fragen stellen kannst, sondern sogar eine Lösung für diese Fragen findest, und eine verdammt gute Basis für ein Produkt im Unity Asset Store, das auch für 100$ einen reißenden Absatz finden würde.
Mecanim und das Humanoid Rigging sind mit Unity 4.0 eingeführt worden, als vermeintlichen Ersatz für das "alte" Animationssystem von Unity auf Basis von Animationen, die vollständig und für jedes 3D-Objekt separat geladen werden müssen. Die Idee, das Skelett für die Animation zu "generalisieren" und so Animationen von zB Motion-Capture-Quellen auf mehrere 3D-Modelle direkt in Unity übertragbar zu machen ist ja grundsätzlich genial. Das hat aber nicht nur ein, sondern gleich zig Probleme, begonnen bei den "vergleichbaren Muskelmaßen" der einzelnen Humanoiden Modelle und passend zur Animationsquelle, weitergehend über den nonexistenten API-Zugriff auf Mecanim und damit die nicht existente Möglichkeit, beliebige Charaktermodelle zur Laufzeit mit einem "Humanoid" Animator auszustatten, bis hin zur Unfähigkeit, Animationen zur Laufzeit in einen Mecanim Controller einzufügen, aus selbem Grund wie vorher.
Wie gesagt, STATISCHE Objekte zu importieren ist kein Kunststück, nicht im Entferntesten, sogar FBX-Loader sind durchaus möglich und denkbar. Jegliche "on the fly"-Charakteranimation ist aber mit Unity auf das "Legacy"-System beschränkt, d.h. Dinge wie Inverse Kinematics für Hände und Füße, Foot IK und dergleichen weitere praktische Werkzeuge sind dann schlicht nicht verfügbar. Und wie man bei Shadowrun sieht, musste Hairbrained Schemes die gesamte Editor-Funktionalität, die in Unity bereits vorhanden ist, vollständig replizieren, damit ein einigermaßen praktischer Editor zu Stande kommt, d.h. jegliche Funktionalität, die Unity über den Editor an sich bereits fixfertig anbietet, müsste für ein Modding, wie man es dort sieht, von null weg neu programmiert werden. Auch das Laden und Spawnen von den Objekten, die Datenhaltung für die Objektpositionen und -eigenschaften, das alles müsste nochmals von vorne programmiert werden, weil die Unity-Funktionalität zwar mit dem Unity-Editor wunderbar funktioniert, für das Modding aber nur bedingt geeignet ist, weil dafür auch ein großer Teil der Sourcecodes des Games zur Verfügung gestellt werden müsste.
Um also "wo ist das Problem" etwas einzuschränken: Mit dem gegebenen Budget und der gewählten Technologie wäre es nur mit erheblichem Mehraufwand möglich, eine Modability in einem wie ich finde unbefriedigenden Ausmaß zur Verfügung zu stellen. Und um nochmal auf deine Frage "was hättest du davon" zurückzukommen: Viele Unity-Entwickler wissen um die Stärke und Wichtigkeit der Modding Community, weshalb sie nach entsprechenden Techniken zu günstigen Konditionen (sprich Verhältnis Kosten zu Funktionalität) lechzen. Wenn du sowas hinbekommst, kannst du eine Stange Geld damit verdienen, weil es ein Werkzeug ist, dass extrem viele Entwickler einfach suchen, aber es sich als "wenige-Personen-Studios" einfach nicht wie besagte Hairbrained Schemes leisten können, mal eben mehrere Monate in die Neuentwicklung von Technologie zu investieren, die Unity für die direkte Entwicklung bereits anbietet. Unity wird verwendet, *weil* es Out-of-the-Box schon sehr viele Funktionen mitbringt, die eben eine Spielentwicklung mit solchen Studios in überschaubarer Zeit ermöglichen, plakativ gesagt muss man aktuell für die "gute" Moddingfähigkeit alleine fast mehr Zeit und Ressourcen investieren als für das eigentliche Spiel.
Man stelle sich vor, dass Unity ein Werkzeugkoffer für den Hausbau wäre, und um die Moddingfähigkeit zu erreichen, müsste man, obwohl der Werkzeugkoffer schon da steht, einen zweiten Werkzeugkoffer selbst zusammenstellen, mit dem man dann das Haus baut.
Insgesamt würde ich aber sagen, dass diese Diskussion nur für sehr wenige außerhalb der Technischen Werkstatt interessant sein dürfte, daher evtl. abtrennen und dorthin verschieben bitte, danke
.
Mecanim und das Humanoid Rigging sind mit Unity 4.0 eingeführt worden, als vermeintlichen Ersatz für das "alte" Animationssystem von Unity auf Basis von Animationen, die vollständig und für jedes 3D-Objekt separat geladen werden müssen. Die Idee, das Skelett für die Animation zu "generalisieren" und so Animationen von zB Motion-Capture-Quellen auf mehrere 3D-Modelle direkt in Unity übertragbar zu machen ist ja grundsätzlich genial. Das hat aber nicht nur ein, sondern gleich zig Probleme, begonnen bei den "vergleichbaren Muskelmaßen" der einzelnen Humanoiden Modelle und passend zur Animationsquelle, weitergehend über den nonexistenten API-Zugriff auf Mecanim und damit die nicht existente Möglichkeit, beliebige Charaktermodelle zur Laufzeit mit einem "Humanoid" Animator auszustatten, bis hin zur Unfähigkeit, Animationen zur Laufzeit in einen Mecanim Controller einzufügen, aus selbem Grund wie vorher.
Wie gesagt, STATISCHE Objekte zu importieren ist kein Kunststück, nicht im Entferntesten, sogar FBX-Loader sind durchaus möglich und denkbar. Jegliche "on the fly"-Charakteranimation ist aber mit Unity auf das "Legacy"-System beschränkt, d.h. Dinge wie Inverse Kinematics für Hände und Füße, Foot IK und dergleichen weitere praktische Werkzeuge sind dann schlicht nicht verfügbar. Und wie man bei Shadowrun sieht, musste Hairbrained Schemes die gesamte Editor-Funktionalität, die in Unity bereits vorhanden ist, vollständig replizieren, damit ein einigermaßen praktischer Editor zu Stande kommt, d.h. jegliche Funktionalität, die Unity über den Editor an sich bereits fixfertig anbietet, müsste für ein Modding, wie man es dort sieht, von null weg neu programmiert werden. Auch das Laden und Spawnen von den Objekten, die Datenhaltung für die Objektpositionen und -eigenschaften, das alles müsste nochmals von vorne programmiert werden, weil die Unity-Funktionalität zwar mit dem Unity-Editor wunderbar funktioniert, für das Modding aber nur bedingt geeignet ist, weil dafür auch ein großer Teil der Sourcecodes des Games zur Verfügung gestellt werden müsste.
Um also "wo ist das Problem" etwas einzuschränken: Mit dem gegebenen Budget und der gewählten Technologie wäre es nur mit erheblichem Mehraufwand möglich, eine Modability in einem wie ich finde unbefriedigenden Ausmaß zur Verfügung zu stellen. Und um nochmal auf deine Frage "was hättest du davon" zurückzukommen: Viele Unity-Entwickler wissen um die Stärke und Wichtigkeit der Modding Community, weshalb sie nach entsprechenden Techniken zu günstigen Konditionen (sprich Verhältnis Kosten zu Funktionalität) lechzen. Wenn du sowas hinbekommst, kannst du eine Stange Geld damit verdienen, weil es ein Werkzeug ist, dass extrem viele Entwickler einfach suchen, aber es sich als "wenige-Personen-Studios" einfach nicht wie besagte Hairbrained Schemes leisten können, mal eben mehrere Monate in die Neuentwicklung von Technologie zu investieren, die Unity für die direkte Entwicklung bereits anbietet. Unity wird verwendet, *weil* es Out-of-the-Box schon sehr viele Funktionen mitbringt, die eben eine Spielentwicklung mit solchen Studios in überschaubarer Zeit ermöglichen, plakativ gesagt muss man aktuell für die "gute" Moddingfähigkeit alleine fast mehr Zeit und Ressourcen investieren als für das eigentliche Spiel.
Man stelle sich vor, dass Unity ein Werkzeugkoffer für den Hausbau wäre, und um die Moddingfähigkeit zu erreichen, müsste man, obwohl der Werkzeugkoffer schon da steht, einen zweiten Werkzeugkoffer selbst zusammenstellen, mit dem man dann das Haus baut.
Insgesamt würde ich aber sagen, dass diese Diskussion nur für sehr wenige außerhalb der Technischen Werkstatt interessant sein dürfte, daher evtl. abtrennen und dorthin verschieben bitte, danke
.