Welcher Bergsteiger

[fmkberlin]

Hallo Gemeinde,

ich brauche mal Euren Rat! Welchen der beiden Bergsteiger soll ich veröffentlichen?

Der Linke hat nur die 6 Anfangs-Frames, während der Rechte mit 18 Frames durchgesteilt ist.

Ich kann mich nicht entscheiden!

Grüße aus Berlin

Frank.

[Holzwurm]

Hallo Frank,

den "Linken". ;)

Gruß Stefan

[fmkberlin]

Danke Stefan!

Meine Frau ist auch der Meinung und ich habe ebenfalls in diese Richtung tendiert. Wollte aber noch wenigstens eine andere Meinung hören.

Grüße aus Berlin

Frank

[BahnLand]

Hallo Frank,

ich nehme Dich mal beim Wort und liefere Dir noch eine "andere" Meinung (auch wenn Du ursprünglich sicher nur "zusätzliche" Meinung gemeint hattest) .

Ich finde, dass der rechte Bergsteiger besser aussieht, weil bei ihm der "Schnapp" nicht stört. Dass der rechte Bergsteiger nicht voran kommt, liegt ja sicher nicht am Modell, sondern weil Du ihn über die Ereignissteuerung nicht wie den linken nach oben fortbewegst (oder irre ich mich da?). Meinst Du mit "Frames" die Bewegungsphasen? Deren Anzahl spielt doch bezüglich des Darstellungsaufwands durch die Grafikkarte keine Rolle (die Anzahl Polygone und Unterobjekte bleibt doch gleich - oder hast Du beim rechten Bergsteiger zusätzliche Unterobjekte definiert?).

Was mir noch aufgefallen ist: Die Arme und Beine beider Bergsteiger bewegen sich immer gleichzeitig nach oben. Damit hätten die Bergsteiger zu diesem Zeitpunkt keinen Kontakt mehr zu Fels - also Absturz oder Zurückfallen ins Seil. Wäre es ein zu großer Aufwand, die Hände beim Strecken der Beine (und damit Hochschieben des Körpers, 1. Phasen-Abschnitt) am Fels zu lassen, erst nachträglich die Arme nach oben zu strecken, damit die Hände einen neuen Angriffs- oder Festhaltepunkt im Fels bekommen (2. Phasen-Abschnitt), und dann erst die Beine nachzuziehen (3. Phasen-Abschnitt), damit anschließend die Beine wieder gestreckt und damit der Körper wieder ein Stückchen weiter nach oben geschoben werden kann (1. Phasen-Abschnitt im nächsten Zyklus)?

Viele Grüße von einem "Griffel-spitzenden"
BahnLand

[fmkberlin]

Hallo BahnLand,

Danke für Dein Griffel-spitzen! Ich bin für konstruktive Kritik immer offen. Als Erstes, der Kollege soll nicht direkt am Berg kraxeln, sondern am Seil. Beide Modelle werden über die Ereignissteuerung bewegt. Ich habe mich vielleicht etwas missverständlich ausgedrückt. Der linke Bergsteiger hat nur die ersten 6 Frames (Bewegungsphasen) von den 18 Frames des anderen Modells. Das hat genau drei 3 Phasen-Abschnitte, 1.) Arme anziehen und Beine strecken 2.) Arme nach oben schieben 3.) Beine anziehen! Die Hätten dann vielleicht noch ein bischen ausgefeilt weden müssen. Es wirkt bei diesem Modell, als ob der Oberkörper überhaupt nicht voran kommt. Leider lässt sich das nicht anders animieren. Deshalb ja auch dieser gleitende Gang der andern Menschen (Stichwort-Glatteis ) Ich muss den Rumpf des Modell immer an der gleichen y-Position lassen. Sonst entsteht ein Ruckeln. Was hab ich nicht alles beim gehenden Schrankewärter-Laumann versucht. Anders geht es oder kann ich es nicht. Auf Wunsch meiner Regierung und nach der Meinung von Holzwurm ist es nun doch der linke Bergsteiger geworden. Und es soll sein Geheimnis bleiben, wie er es anstellt alle vier Glieder gleichzeitig nach oben zu bewegen und trotzdem nicht runter zufallen. Vielleicht liegt es an der Geschwindigkeit, mit der er es macht Übrigends, wenn ich ihn am Fels klettern lassen würde, wäre der Bewegungsablauf ja noch etwas anders, Arme und Beine müssten sich ja jeweils gegenläufig bewegen. Das würde Aussehen, als ob eine Schidkröte wild mit dem Extremitäten rudernd, langsam den Berg hinauf rutscht.

Grüße aus Berlin

Frank

[BahnLand]

Hallo Frank,

dass Du überhaupt so etwas hin bekommst, finde ich schon großartig. Ich hätte da wahrscheinlich nicht so ein glückliches Händchen.

Gehe ich Recht in der Annahme, dass dich der Rumpf Deines Bergsteigers mit konstanter Geschwindigkeit nach oben bewegt?
Dann liegt es vermutlich daran, dass es nicht so richtig funktionieren will.
Hast Du mal versucht, den Rumpf des Bergsteigers nur dann in die "Zielrichtung" zu bewegen, wenn er die Arme anzieht und die Beine streckt, und sonst die vertikale Position (oder Position in Gleis-Richtung) beizubehalten?

Ich hatte einmal in irgend einem Simulationsprogramm (weiß nicht mehr, ob es das Modellbahn-Studio, der alte 3D-Eisenbahnplaner oder der Meyer'sche Bildschirmschoner (mit 2-dimensionalen Fahrzeugen von der Seite) war) eine Gleisbettmaschine "In Aktion" gesehen. Dort bewegte sich der Rahmen mit konstanter Geschwindigkeit vorwärts, während der Gleisstopf-Mechanismus sich an einer Stelle unter der Karosserie auf das Gleis niedersenkte, kurz zum Stopfen inne hielt, sich dann wieder vom Gleis anhob, um dann mit "erhöhter" Geschwindigkeit an die nächste Gleisstopf-Stelle zu fahren. Sich nun wieder an derselben Stelle relativ zu dem sich gleichmäßig bewegenden Rahmen befindend, wurde nun das gesamte Szenario wiederholt.

An dieses Szenario erinnert mich Dein Bergsteiger: Der "Rahmen" ist hierbei ein "unsichtbares Gebilde",ein "transparenter Quader", der sich mit konstanter Geschwindigkeit am Seil "nach oben bewegt". Der Rumpf des Bergsteigers entspricht dem "Stopfteil" der Gleisstopfmaschine, der - solange die Beine nachgezogen oder die Arme ausgestreckt werden - an derselben vertikalen Stelle verharrt. Die Hände und Füße des Bergsteigers sind ebenfalls "kleine Stopfteile", die zeitlich versetzt zum Rumpf des Bergsteigers nach oben geschoben werden, wobei die Arme und Beine gelenkig mit dem Rumpf und natürlich mit den Händen und Füßen des Bergsteigers verbunden sind. Der "unsichtbare Quader" dient als "Bezugsobjekt" für alle sichtbaren Bestandteile des Bergsteigers, wobei dann deren vertikale Verschiebung (wie beim Stopfteil der Gleisstopfmaschine) schneller als die Bewegung des mit konstanter Geschwindigkeit ansteigenden "unsichtbaren Quaders" sein muss, damit die "Standzeiten" dadurch ausgeglichen werden und sämtliche beweglichen Teile des Bergsteigers nach Abschluss des Bewegungs-Zyklus relativ zum "unsichtbaren Quader" sich wieder an der ursprünglichen Position befinden. So müsste eigentlich (zumindest theoretisch) eine gleichmäßig erscheinende Aufwärtsbewegung des Bergsteigers möglich sein. 

Ob sich diese in der Theorie (zumindest für mich) plausibel erscheinende Vorgehensweise auch tatsächlich mit einem überschaubaren Aufwand auf Deinen Bergsteiger übertragen lässt, steht wieder auf einem anderen Blatt.

Also: Wenn Du den Bergsteiger nicht mehr ändern möchtest, lass ihn so. Schon die Idee, einen solchen Bergsteiger zu animieren, finde ich genial. Aber vielleicht hast Du auch Lust, die oben beschriebene Vorgehensweise einmal "auszuprobieren". Wenn ja, wäre ich auf das Ergebnis sehr gespannt.

Viele Grüße
BahnLand

[fmkberlin]

Hallo BahnLand,

Dein Vorschlag ist faszinierend! Ja, es könnte funktionieren. Wäre aber mit einem ganz schönen Aufwand für die Animatonen verbunden. Die Glieder des Bergsteigers verändern nicht nur ständig ihere Positionen, sondern auch die Winkel.

Werde darüber schlafen!

Grüße aus Berlin

Frank

[BahnLand]

Hallo Frank,

ich hätte da noch ein paar ergänzende Bemerkungen zur Realisierung des Bewegungsablaufs:

Bei der Codierung der Animation geht man ja von einem "stillstehenden" Objekt, also beim obigen Beispiel von einem sich nicht bewegenden "unsichtbaren Quader" aus. Dies bedeutet, dass die Bewegungen der Hände, Füße und des Rumpfes immer hin und her "pendeln". Die Rückwärts-Geschwindigkeit des Pendel-Vorgangs muss hierbei genau der späteren konstanten Vorwärts-Geschwindigkeit des "Unsichtbaren Quaders" entsprechen, damit die Körperteile sich bei der "beweglosen" Positionierung über dem "Untergrund" oder an der "Felswand" tatsächlich nicht bewegen. Die Vorwärts-Geschwindigkeit richtet sich dagegen nach der Länge des Animationszyklus. D.h. sie darf (und muss) genau jene Zeit beanspruchen, die übrig bleibt, wenn man vom Gesamtzyklus die "Rückwärtsbewegung" (und eine eventuell eingebaute Bewegungs-"Pause") abgezogen hat.

Ich habe jetzt mal auf einer kleinen Kreisbahn Deinen Radfahrer und Deinen gehenden Opa etwas genauer "studiert". Dabei ist mir aufgefallen, dass die Tret- oder Schritt-Geschwindigkeit Deiner beiden Figuren unabhängig von der Fortbewegungsgeschwindigkeit konstant ist (der Radfahrer betätigt nur die "Gangschaltung", der Opa zappelt bei Geschwindigkeit 1 mit den Beinen und wird bei Geschwindigkeit 100 "fortgeschleift" - bei Geschwindigkeit 11 (im Modellmaßstab H0) sieht der Gang des Opas annähernd "normal" aus). Die Konstanz der Geschwindigkeit des Bewegungsablaufs bei beiden Figuren liegt daran, dass Du für deren Animationen das Schlüsselwort "_AnimRunLoop" verwendet hast. Du solltest hier das Schlüsselwort "_AnimWheel" verwenden, wie es Seehund für seine Stangenantriebe verwendet hat. Dann würde der Radfahrer entsprechend der eingestellten Fortbewegungsgeschwindigkeit schneller oder langsamer treten, und der Opa würde entsprechend schnellere oder langsamere Schrittbewegungen machen.

Schade, dass Seehund sich "Verabschiedet" hat. Sonst hätte er uns anhand eines Beispiels zeigen können, wie er die "_AnimWheel"-Animationen realisiert hat. Aber vielleicht hat ja auch ein anderer Hobby-Kollege bereits Erfahrungen damit gesammelt, oder Neo gibt uns einen Tipp.

So. Das waren so meine Ideen, die mir zu diesem Thema noch eingefallen sind.

Viele Erfolg beim Anwenden/Ausprobieren und viele Grüße
BahnLand

[fmkberlin]

Hallo BahnLand,

habe es eben ausprobiert. Eine Umbenennung der Animation von _AnimRunLoop in _AnimWheel bringt erst mal garnichts. Der Schrankenwärter bewegt sich weiter mit konstanter Geschwindigkeit, egal welche Lok-Geschwindigkeit gewählt wird. In der Wiki steht-

Zitat

_AnimWheel - Animationszeit hängt von der Radrotation ab -> z.B. für Gestängeanimationen oder als Ersatz für "Radanim".

Kann es daran liegen, das kein RadAnim oder keine Rotation in dem Modell vorhanden ist? Da fehlt uns doch der Seehund! Wenn ich dann mal Zeit habe, werde ich mich noch mal mit den Radfahrern beschäftigen. Da könnte ich ja das Tretlager in RadAnim umbenennen.

Aber jetzt noch mal zu Deinem Vorschlag, mit dem unsichtbaren Grundkörper, als Basis für den Bergsteiger. Hier müssten die einzelnen Körperglieder alle über die Parent-(Eltern-Kind)-Funktion nit dem Rumpf verknüpft sein. Ich habe aber Probleme damit, solche Unterobjekte, wenn sie in der Animation um mehr als eine Achse bewegt werden, sauber ins MBS zu bekommen. Sie erscheinen dann leicht verdreht verschoben und ich muss sie im Blender nach Gefühl, so verschieben, dass sie dann im Studio passen. Zumindest die Arme des Bergsteigers bewegen sich um alle 3 Achsen.

Ich möchte aber noch mal betonen, das Deine Idee, mit dem unsichtbaren Grundkörper sehr gut ist! Vielleicht kann ich sie bei zukünftigen Profekten verwenden.

Viele Grüße aus Berlin

Frank

 

[BahnLand]

Hallo Frank,

warte noch ein bisschen - ich bin gerade etwas am herumprobieren, und möglicherweise bekomme ich was hin (bin allerdings ein Sketchup-Bauer , was aber bezüglich der Animationen kein Problem darstellen sollte).

Muss aber jetzt kurz weg, sodass ich wohl erst heute Abend weiter probieren kann.

Viele Grüße
BahnLand

[EASY]

Hallo,

... bei mir funktioniert z.B.

_AnimWheel;0;360

...also _AnimWheel;Startframe(=0);Endframe(=360) ohne weiteren Zusatz (Autoplay, Loop) in der .anim Datei

Gruß
EASY

[fmkberlin]

Hallo EASY,

bei was für einer Animation? Rotation oder Positionsänderung?

Grüße aus Berlin

Frank

[EASY]

Hallo Frank,

Zitat

bei was für einer Animation? Rotation oder Positionsänderung?

... das spielt keine Rolle... es bertifft die (Teil-) Animation, die zwischen Anfangsframe und Endframe von _AnimWheel definiert ist...
... was die Animation "macht" (Rotation, Positionsänderung oder Skalierung oder eine Mischung dieser Möglichkeiten), hat keinen Einfluß...

... ich habe ein einfaches Beispiel gemacht, in dem alles drei auf einmal vorkommt...
... in der .zip ist .blend, .x, .anim

Noch der Form halber: die .x und die .anim müssen beim Hochladen in den MBS-Katalog im gleichen Verzeichnis sein und den gleichen Namen haben... die .x als Rollmaterial in den Katalog stellen...

Gruß
EASY 

Demo1.zip

[fmkberlin]

Hallo EASY,

eine eindrucksvolle Demo, dafür, das es geht!

@ Alle,

Danke für Eure Ratschläge. Ich werde den Kraxler noch mal überdenken und entscheiden ob er in der linken Version bleibt oder ob ich die Animation noch mal komplett neu aufbaue.

Erstmal werde ich alle meine Fehrradfahrer umbauen. Dort habe ich es geschafft mit _AnimWheel eine von der Geschwindigkeit abhängige Tretfrequenz hinzubekommen. Den Großvater habe ich schon mal in Test als Demo eingestellt.

Grüße aus Berlin

Frank

[BahnLand]

Hallo zusammen,

so, ich bin jetzt auch so weit. Es hat ein bisschen gedauert, weil ich mir noch über Einiges klar werden musste.

Im Anhang findet Ihr ein ZIP-Paket, das die im nachfolgenden Bild gezeigte Anlagen-Demo und die zugehörigen Objekte als x-Dateien enthält. Diese könnt Ihr direkt in den Katalog übernehmen. anim-Dateien benötigt man hierzu nicht, weil ich die AnimationSet-Definition direkt mit "_AnimWheel" bezeichnet habe.

Nun aber zur Erklärung:

 

Die Bewegungsabläufe für einen "Geh"- und "Kletter"-Vorgang lassen sich tatsächlich so realisieren, dass die am Boden oder am Kletterseil "fixierten" Hände und Füße auch wirklich in dieser Position verharren, während der restliche Körper sich vorwärts bewegt (der Einfachheit halber sind die "Figuren" der Demo sehr einfach gehalten: grün und blau sind Hände und Füße, gelb ist der Rumpf). Allerdings gibt es hierbei folgende Einschränkung:

Die in einem Bewegungszyklus zurückgelegte Strecke muss im Maßstab H0 exakt 62,83 mm betragen. Wird diese Wegstrecke für einen Zyklus nicht eingehalten, rutschen die in bestimmten Zeitabschnitten eigentlich "fixierten" Körperteile nach vorne oder hinten weg. Wie kommt es zu dieser etwas "krummen" Zahl?

Lässt man Rollen mit verschiedenen Durchmessern, die als "RadAnim" gekennzeichnet sind, über das Gleis rollen, wird man feststellen, dass alle Rollen unabhängig von ihrem Radius nach derselben Streckenlänge eine volle Umdrehung vollführt haben. Zu große und zu kleine Räder rollen also nicht korrekt ab. Misst man die Wegstrecke für eine solche volle Umdrehung nach, kommt man auf die obigen 62,83 mm. Dies ist (auf 2 Stellen hinter dem Komma abgeschnitten)  genau das 2*PI-fache von 1 cm, also der Umfang eines Kreises mit 1 cm Radius. Diese Zyklus-Länge ist offenbar im Modellbahn-Studio fest eingebrannt und neben der RadAnim-Animation auch für die _AnimWheel-Animation gültig. Das mit "_AnimWheel" animierte Objekt hat sich also in der Baugröße H0 nach dem Ablauf eines kompletten Animations-Zyklus um exakt 62,83 mm weiterbewegt. Hieran muss sich die Bewegung von Händen und Füßen relativ zur Fortbewegung des gesamten Körpers orientieren, wenn man gehende oder kletternde Personen als animierte Modelle realisieren möchte.

In der beigefügten Beispiel-Anlage habe ich Z-Gleise als Basis für die zu bewegenden Objekte herangezogen. Damit reduziert sich auch die Wegstrecke für einen kompletten Bewegungszyklus im Verhältnis Z : H0 (oder 87 : 220) .Auf der Anlage ist sowohl ein Quader mit der Länge der H0-Wegstrecke (62,83 mm) als auch mit der Länge der Z-Wegstrecke (24,85 mm) abgebildet. Mit letzterem lässt sich genau die zurückgelegte Wegstrecke durch den abstrakten "Läufer" und den abstrakten "Kriecher" nachvollziehen. Stellt man das Gleis des "Kriechers" auf, wird hieraus der "Kletterer".

Ich habe es nicht "nachgemessen", aber mir scheint die sich aus der zu überwindenden Wegstrecke für einen Zyklus ergebende "Schrittweite " für ein Modell-Menschlein zu groß zu sein. Hier könnte man möglicherweise Abhilfe schaffen, indem man in der x-Datei die dort in der AnimationSet-Definition spezifierte Wegstrecke beispielsweise für H0-Anlagen im Verhältnis "Z : H0" reduziert und dann die auf H0 skalierten "Menschlein" über Z-Gleise marschieren lässt. Ich weiß allerdings nicht, ob dies tatsächlich ausreicht.

Ich habe auch ausprobiert, an der "AnimTicksPerSecond-Schraube" zu drehen. Das hat aber nichts genützt. Egal, welchen Wert ich dort eingegeben habe: Die Wegstrecke für einen Bewegungszyklus blieb immer gleich. Dies ist auch "logisch" nachzuvollziehen, da sich ja eine Radumdrehung am Gleis nicht an der Zeit sondern an der Geschwindigkeit orientieren soll: (hohe Geschwindigkeit = schnelle Bewegung, niedrige Geschwindigkeit = langsame Bewegung). Allerdings wäre es schön, wenn das Modellbahn-Studio bei Rollmaterial die "AnimTicksPerSecond" um-interpretieren könnte nach "AnimTicksPerPathLength" (also Animationsschritte pro Weglänge). Dann wäre man von der "festen Zyklus-Weglänge" unabhängig und könnte die "_AnimWheel"-Animation individuell an die Modell-Verhältnisse (z.B. an die Größe der "H0-Menschlein" und deren "biologische Schrittweite") anpassen. 

Frage an Neo: Wäre eine solche Anpassung des Modellbahn-Studios realisierbar?

Viele Grüße
BahnLand

Lauf-kriech-kletter-demo.zip

[fmkberlin]

Hallo BahnLand,

habe es diesen Beitrag ein bisschen spät entdeckt. Werde mich Morgen (Heute, aber etwas später) damit beschäftigen. Irgendwann lässt die Aufnahmefähigkeit von alten Leuten am Tag etwas nach

Grüße aus Berlin

Frank

[fmkberlin]

Hallo BahnLand,

eine tolle Demo! Vielen Dank für Deine Forschungsarbeit. Ja, es würde wohl funktionieren.

Aber, bei dem linken Klettermaxen ist es ja zu einem unerwarteten Nebeneffekt gekommen - Das Abseilen! Das Modell wird nicht über die EV gesteuert sondern er seilt sich einfach beim Richtungswechsel so ab. Bei der von Dir vorgeschlagenen Animation wäre dieser Effekt weg. Deshalb bleiben die Seilkletterer so. Aber ich werde demnächst versuchen, ob es mir gelingt, mit Hilfe Deiner Vorschläge, einen Felskletterer zu basteln. Bei dem wäre der Bewegungsablauf beim Absteigen, durch den Richtungswechsel dann doch einigermaßen realistisch.

Nochmal Danke für Deine Bemühungen!

Grüße aus Berlin

Frank

[fmkberlin]

Hallo BahnLand,

wieviele Frames (Einzelschritte) haben der Kriecher und der Geher?

Grüße aus Berlin

Frank

[BahnLand]

Hallo Frank,

dem "Geher" habe ich 3 Zustände ("Frames") verpasst, wobei der letzte Zustand mit dem ersten identisch ist. Die Bewegungsabläufe sind die Übergänge von Zustand 0 nach Zustand 1 und von Zustand 1 nach Zustand 2 (= Zustand 0). Da es sich hier jeweils nur um eine geradlinige "Positionsänderung" handelt, reichen diese wenigen Angaben aus, um die in der ausgeführten Animation sichtbare Bewegung (lineare Interpolation zwischen den aufeinander folgenden Zuständen) zu realisieren.

  Animation {
    {Fuss_gruen}      
    AnimationKey {
      2;           // Position
      3; // 1.083914, 0.287356, 0.211633
      00;3; 1.646414, 0.287356, 0.211633;;,
      01;3;-1.478586, 0.287356, 0.211633;;,
      02;3; 1.646414, 0.287356, 0.211633;;;
    }
  }
  Animation {
    {Fuss_blau}     
    AnimationKey {
      2;           // Position
      3; //-0.916086, 0.287356, -0.248137
      00;3;-1.478586, 0.287356, -0.248137;;,
      01;3; 1.646414, 0.287356, -0.248137;;;
      02;3;-1.478586, 0.287356, -0.248137;;,
    }
  }
}AnimationSet _AnimWheel {

Da Du aber nicht nur die "Fußsohlen" verschieben, sondern auch die Ober- und Unterschenkel um das Knie herum "biegen" möchtest, wirst Du die Positionsänderung vermutlich entlang einer Kurve führen und zusätzlich den "AnimationKey" für die Rotation verwenden. Du wirst daher mit Sicherheit mehr "Zwischenschritte" benötigen. Die (lineare) Streckenlänge für einen vollen Bewegungsablauf (die Strecke, die das gesamte Modell in einem Bewegungszyklus zurücklegt) ist jedoch von der Anzahl der Zwischenschritte unabhängig und wird sich deshalb dadurch nicht verändern.

Dem "Kriecher" habe ich 4 Zustände (3 Bewegungsphasen) verpasst. Auch hier wirst Du mehr Zwischenschritte benötigen.

  Animation {
    {Haende}      
    AnimationKey {
      2;           // Position
      4;//  4.681615, 0.344828, -0.018252
      00;3; 6.764948, 0.344828, -0.018252;;,
      01;3; 4.681615, 0.344828, -0.018252;;,
      02;3; 2.598282, 0.344828, -0.018252;;,
      03;3; 6.764948, 0.344828, -0.018252;;;
    }
  }
  Animation {
    {Fuesse}      
    AnimationKey {
      2;           // Position
      4;// -4.513788, 0.344828, -0.018252
      00;3;-6.597121, 0.344828, -0.018252;;,
      01;3;-2.430455, 0.344828, -0.018252;;,
      02;3;-4.513788, 0.344828, -0.018252;;,
      03;3;-6.597121, 0.344828, -0.018252;;;
    }
  }
  Animation {
    {Rumpf}     
    AnimationKey {
      2;           // Position
      4;//  0.083914, 1.034483, -0.018252
      00;3; 0.083914, 1.034483, -0.018252;;,
      01;3;-1.999419, 1.034483, -0.018252;;,
      02;3; 2.167247, 1.034483, -0.018252;;,
      03;3; 0.083914, 1.034483, -0.018252;;;
    }
  }
}AnimationSet _AnimWheel {

Die obigen AnimationSet-Definitonen habe ich übrigens aus den x-Dateien des obigen ZIP-Pakets "lauf-kriech-kletter-demo.zip" heraus kopiert.

Übrigens ist mir gerade beim Schreiben dieser Zeilen der Gedanke gekommen, dass Du die "Riesenschritte" der Figur (im Verhältnis zur Größe des von Dir zu erzeugenden "Menschleins" dadurch reduzieren könntest, dass Du die Schrittlänge halbierst, dafür aber die Bewegungsabläufe verdoppelst (es wird ja vom Modellbahn-Studio die gesamte Zustandsfolge als ein vollständiger Bewegungszyklus ausgewertet). Ich glaube, dass ich diesbezüglich noch einen Versuch starte. Ich werde mich dann nochmal melden.

Viele Grüße
BahnLand

 

 

[fmkberlin]

Hallo Bahnland,

Danke erst mal für Deine Anwort!

Grüße aus Berlin

Frank

[BahnLand]

Hallo Frank,

meine zuletzt geäußerte Vermutung hat sich bestätigt. In der beiliegenden ZIP-Datei findest Du 2 Läufer-Varianten, bei denen ich die Schrittlängen halbiert bzw. geviertelt und dafür die Phasenzahl verdoppelt bzw. vervierfacht habe. Stelle die beiden "Figuren" nach ihrem Import beide hinter den auf der Anlage bereits platzierten Läufer und beobachte das Ergebnis.

Viele Grüße
BahnLand

Lauf-kriech-kletter-demo_2.zip

[fmkberlin]

Hallo BahnLand,

das ist sehr interessant! Wobei es doch ein weinig nach Trippelschritten aussieht. Ein kleines Problem ist, das man durch die Vorgaben, von _AnimWheel; nur eine begrenzte Anzahl an Frames zu Verfügung hat. Bei wenigen Frames lässt sich aber eine Animation teilweise nicht mehr flüssig darstellen. Deine Forschungsarbeit wird mir bei zukünftigen Projekten sehr helfen. Deshalb, nochmal ein großes Dankeschön!

Denn, nach vielen Rückschlägen und wieder von Vorn anfangen ist es mir, Dank Deiner Tipps gelungen den Klettermaxen fertigzustellen! Da er aber erst noch feingeschliffen werden muss, werde ich ihn dann in meinem anderen Fred vorstellen.

Er hat insgesamt 18 Frames, in drei Abschnitten. Alle animerten Unterobjekte fangen, bei ihrem Namen, mit _AnimWheel an. Ich musste doch eine .anim-Datei, mit _AnimRunLoop;1;18;AutopPlay;Loop ,schreiben. Das MBS hat sonst eine normale Animation mit Endlosschleife erkannt, Bei Geschwindigkeit=0 hat der arme Kerl immer noch, auf der Stelle weiter geackert.

Also dann ein gutes Nächtle aus Berlin

Frank

Ein kleiner Nachtrag: BahnLand - ich habe lange nicht soviel auf der Tastatur herumgeklappert, wie in diesem Fred, weil ich absolut kein Freund davon bin! Sei mir also nicht böse, wenn ich mal nicht so ausführlich Antworte.

 

[BahnLand]

Hallo Frank,

wie Du Deine Unterobjekte nennst, ist im Prinzip egal. Es spricht also nichts dagegen, sie z.B. _AnimWheel1, _AnimWheel2 usw. zu nennen. Wichtig ist dagegen, dass das Modellbahn-Studio erkennt, dass die gesamte Animation (alle Unterobjekte zusammen) eine "_AnimWheel"-Animation ist. Dies kennzeichnest Du entweder durch die Benennung des kompletten "AnimationSet"s mit "_AnimWheel" unter Verzicht auf die ".anim"-Datei (wie ich es gemacht habe) oder durch Hinzufügen der ".anim"-Datei, wo aber dann der darin befindliche Eintrag mit "_AnimWheel" bezeichnet sein muss. Da Du diesen aber mit "_AnimRunLoop" bezeichnet hast, wird vom Modellbahn-Studio die Animation nicht als "AnimWheel"-Animation erkannt, weshalb Dein Kletterer unabhängig von seiner Fortbewegungs-Geschwindigkeit "zappelt".

Übrigens besagen die Eintrags-Ergänzungen "AutoPlay" und "Loop", dass die Animation automatisch starten und in einer Endlosschleife ablaufen soll. Dies sind die Standard-Einstellungen und brauchen nicht explizit angegeben zu werden. Was Du aber eigentlich möchtest, sind die Zusatzangaben "NoAutoPlay" und "NoLoop", um den automatischen Start und die Unendlichschleife gerade zu unterdrücken! Ich vermute aber (da ich die ".Anim"-Datei ja weglassen konnte), dass diese Parameter bei "AnimWheel"-Animationen nicht ausgewertet werden (Neo: kannst Du das bestätigen?).

Was die "Trippelschritte" anbelangt, so war das nur ein Beispiel, wie man die Schrittweite trotz der festen Streckenlänge für den Gesamtzyklus durch deren "Teilung" verkürzen kann. Von den 3 Beispielen würde meines Erachtens die Schrittweite des "Laeufer2" am besten "passen".

Und dass die Anzahl der "Frames" (Einzelschritte im Bewegungszyklus) beschränkt sein soll, kann ich nicht nachvollziehen. So wie ich anstelle der 3 Zustände (2 Bewegungsstufen) beim "Laeufer" 5 Zustände beim "Laeufer2" (4 Bewegungsstufen) und 9 Zustände beim "Laeufer2" (8 Bewegungsstufen) untergebracht habe, kannst Du theoretisch auch 65 Bewegungsstufen (oder eine andere Anzahl) unterbringen. Nur wirst Du dann natürlich nicht die Schrittweite verkleinern und entsprechend die Schrittzahl des Läufers erhöhen, sondern stattdessen einen Schritt (der bei meinen Beispielen jeweils durch genau eine Einzelstufe in der Animationssequenz dargestellt ist) in viele Stufen ("Frames") aufteilen (wie beim "Daumenkino"), sodass jeder einzelne "Schritt der Figur" wie in einem "Film" flüssig ablaufen kann (dasselbe gilt natürlich auch für der "Kletterer"). Ich habe vor, Dir diesbezüglich noch ein Beispiel zu liefern, werde aber dafür noch ein Weilchen brauchen. Aber vielleicht helfen Dir trotzdem auch diese Zeilen schon weiter,

Viel Grüße
BahnLand

[BahnLand]

Hallo Frank,

auch wenn Deine Bergsteiger bereits fertig und meiner Meinung nach sehr gut gelungen sind, hat es mich doch noch in den Fingern gejuckt, meinen "Läufer" mit halbwegs realistischer Schrittweite und mit "gebogenem Bewegungsverlauf" (realisiert durch eine Menge von Zwischenschritten) noch fertigzustellen. Die Füße werden nun beim "Vorwärts-bewegen" angehoben und abgeknickt, während sie bei der Bewegung "nach hinten" am Boden bleiben. Es hat ein Weilchen gebraucht bis es letztendlich geklappt hat, auch wenn sich die Logik, die sich hinter dem AnimationKey "Rotation" verbirgt, mir noch nicht so richtig "erschlossen" hat.

Viele Vergnügen beim Betrachten der letzten Variante meines "Läufers" im beiliegenden ZIP-Paket wünscht
BahnLand

 

Laeufer5.zip

[fmkberlin]

Hallo BahnLand,

das sieht sehr gut aus Schade, das wir erst jetzt darauf kommen! Denn ich werde meine ganzen bewegten Menschen nicht alle ändern. Aber auf meiner ToDo-Liste stehen irgendwo noch Nordic-Walker. Dann werde ich mich nochmal mit dieser Geschichte beschäftigen.

Grüße aus Berlin

Frank