Zufallsbewegung

[maxwei]

Hallo zusammen, 

es ist zwar kein definitiver Wunsch von mir sondern nur vielleicht eine Idee für eine der nächsten Versionen des MBS.

Ich habe auch keine Ahnung ob das umsetzbar, zweckmässig oder praktikabel ist, das kann nur @Neo beantworten.

Und zwar:

Man baut irgendein Polygon (bleiben wir jetzt mal 2-dimensional auf der Oberfläche), diese sollte geschlossen sein, jetzt könnte man diesem Polygon 
ein Minimum von 2 Parametern mitgeben. Parameter 1: Geschwindigkeitsbereich, Parameter 2: Winkelbereich.

Jedes Objekt welches über einen Antrieb verfügt beginnt mit genau dieser Bewegung im Zufallsbereich der o.g. Parameter sich zu bewegen wenn man es in dieses Polygon setzt und ändert seine Richtung im Winkelbereich wenn es an de Rand fährt(geht), so wie bei den Robotermähern.

Damit könnte man Boote am See (oder Schwimmer), Menschen am Gehsteig, Tiere im Gehege, usw. ganz einfach und durch Zufall bewegen lassen ohne irgendwelche Pfade vorzugeben.

Wie gesagt, nur eine Idee und keine Ahnung ob das machbar oder überhaupt gewünscht ist.

lg max

Bearbeitet 28. Mai 2020 von maxwei

[Andy]

Hallo Max,
in der Konsequenz bräuchte man also eine Animation für eine Richtungsänderung und eine für eine geradlinige Bewegung. Ferner bräuchte man wohl noch einen Radius (stelle dir einen Fußgänger vor, der fast auf der Stelle dreht, oder aber eine lange Kurve läuft). Die Kurvenanimation erfordert auf der Außenseite eine andere Schrittweite als auf der Innenseite. Dann gibt es noch den Unterschied Links/Rechtskurve. Um dies zu optimieren, wäre es natürlich sinnvoll beide Seiten unabhängig voneinander zu halten und die Animationen eben mit unterschiedlichen Geschwindigkeiten (oder Framesprüngen) auszustatten. Framesprünge sind da nicht so toll, weil sie nur ganzzahlige Vielfache der Grundgeschwindgkeit bringen würden. Also Animationstempo. So - unabhängige Einzelanimationen mit variabler Geschwindgkeit, und der Rest würde wohl mit Standardkommandos machbar sein. Einzelanimationen können wird schon. Eigentlich brauchen wir also nur die Animationsgeschwindigkeiten.

Gruß
  Andy

[BahnLand]

Hallo zusammen,

Steigungen und Gefälle darf es dann aber nicht  geben. Den  sonst würde der Fußgänger auf dem Gehsteig pflötzlich schweben oder im Gehsteig versinken. Denn es fehlt dann eben auch die "Zwangsführung" in der Vertikalen.

Viele Grüße
BahnLand

[Andy]

Hallo @BahnLand,
auch wieder wahr. Da muß ich in ein paar Videospielen mal schauen, wie die das gelöst haben. Das wird ja richtig komplex.

Gruß
  Andy

[Timba]

Hallo zusammen,

dieser "Robotermäher" muss dann allerdings auch in der Lage sein, die vorhandene Bebauung abzutasten, wenn man nicht will, dass er wie Superman durch Wände und vor Autos oder Züge laufen soll.

Gruß Timba

[Andy]

...und wir haben schonmal mindestens drei verschiedene Grundtypen:
- Loks und Kfz passen sich der Steigung an,
- Menschen und Seilbahnen versuchen im Lot zu bleiben,
- und Steine fangen an zu rollen...

Gruß
  Andy

[HaNNoveraNer]

Nette Idee,...

aber da sind zu viele Kollisionsabfragen drin, die viel Zeit kosten.
Das ist es m.M. nach nicht wert. Ist ja so schon recht langsam das MBS.
Es sei denn die Physic Engine macht sowas automatisch bzw. unterstützt dabei.
Gruß
Thomas

[Andy]

Hmmm. Das kann jetzt eigentlich nur Neo wissen, inwieweit da bereits Kollisionsabfragen drin sind, oder die Gleise/Straßen zur Laufzeit bereits in verketteten Bäumen vorliegen. Irgendwie muß er ja (insbesondere bei den verschiedenen Abspielgeschwindigkeiten) iterieren, um Gleiskontakte und Gleis betritt/verläßt erkennen zu können.
Eine Physics-Engine wünsche ich mir ja sowieso. Die Frage ist halt, inwieweit sie in MBS einsetzbar ist. Dafür weiß ich über diese Engines zu wenig. Und ja - langsamer sollten wir wirklich nicht werden. Da ist viel Hardwareunterstützung notwendig. Aber schau dir den neuen Blender-Renderer an. Der ist (von einer bezahlten 'externen' Crew) ganz besonders auf Hardwareunterstützung programmiert worden. Nur müssen die da auch irre viel gepuzzelt haben. Für einen Ein-Mann-Betrieb wohl nicht machbar.

Gruß
  Andy

[gmd]

15 minutes ago, Andy said:

Hmmm. Das kann jetzt eigentlich nur Neo wissen, inwieweit da bereits Kollisionsabfragen drin sind, oder die Gleise/Straßen zur Laufzeit bereits in verketteten Bäumen vorliegen. Irgendwie muß er ja (insbesondere bei den verschiedenen Abspielgeschwindigkeiten) iterieren, um Gleiskontakte und Gleis betritt/verläßt erkennen zu können.
Eine Physics-Engine wünsche ich mir ja sowieso. Die Frage ist halt, inwieweit sie in MBS einsetzbar ist. Dafür weiß ich über diese Engines zu wenig. Und ja - langsamer sollten wir wirklich nicht werden. Da ist viel Hardwareunterstützung notwendig. Aber schau dir den neuen Blender-Renderer an. Der ist (von einer bezahlten 'externen' Crew) ganz besonders auf Hardwareunterstützung programmiert worden. Nur müssen die da auch irre viel gepuzzelt haben. Für einen Ein-Mann-Betrieb wohl nicht machbar.

Gruß
  Andy

An alle poster in diesem thread,

habe die posts gelesen und auch so meine gedanken ueber animation im rahmen meines programms gemacht. 

Meine idee waere: Es gibt grundmodelle fuer animationen, die vom MBS bereitgestellt werden und die dann "umbaut" und ausgestaltet werden koennen. Also zum beispiel eine art streichholzmaennchen das all die eigenschaften hat wie in den posts beschrieben. Dann koennte man das als skelett benutzen. Aehnliches liesse sich fuer andere animationen machen. Der gedanke dabei ist, dass man nicht fuer jedes modell aufs neue die mechanik erfinden muss. Das gilt auch fuer andere animationen. Falls die parameter fuer solche animationen vom MBS offengelegt sind kann das auch von einem externen programm erreicht werden, aber das bedarf einer lesitungsfaehigen schnittstelle. Es ist ohnehin ineffizient, dass jeder eine "standardanimation" immer wieder neu definieren muss. Tueren, Fenster, etc. koennten alles vorgefertigte mechanismen sein, die separat erstellt werden und im MBS "zusammengesetzt" werden.  Das heisst zum beispiel in Blender wird eine oeffnung gelassen fuer eine tuer, die tuer wird getrennt definiert, und im MBS wird das montiert mit der eingebauten animation. Nur ein gedanke ...

gruss

Gmd

 

[Neo]

Hallo,

ich halte die Idee von max für einen interessanten Wunsch, sehe hier aber deutlich weniger Anforderungen. Der Nutzer erwartet keinen Fußgänger, der physikalisch korrekt den Fuß umdreht, wenn er die Richtung wechselt. Das ist nicht der Anspruch des Studios. Was max beschreibt ist vergleichbar mit dem Landschaftsplugin von Easy. Der Nutzer gibt einen Bereich vor, in dem sich Fahrzeuge scheinbar zufällig bewegen. Tatsächlich erzeugt das Studio in diesem Bereich lediglich unsichtbare Routen, auf denen sich die Fahrzeuge bewegen. Mehr lese ich aus max' Wunsch nicht heraus.

Die Herausforderung würde am Ende also darin bestehen, zufällig vernünftige Routen innerhalb eines Gebiets zu erzeugen, mit Kurven und Schleifen zum Umdrehen.

Viele Grüße,

Neo

[maxwei]

Hallo zusammen, ich muß jetzt nochmal nachsetzen (in der Zwischenzeit hat NEO geantwortet, ich schreibe aber weiter,.. ihr denkt alle viel zu kompliziert und habt glaube ich auch gar nicht richtig verstanden was ich meine, vielleicht habe ich mich ja auch schlecht ausgedrückt:

Also:

vor 15 Stunden schrieb Andy:

in der Konsequenz bräuchte man also eine Animation für eine Richtungsänderung und eine für eine geradlinige Bewegung.

Warum?, hast du ja jetzt auch nicht bei einer Richtungsänderung an einem Pfad und ist auch nicht notwendig.

vor 15 Stunden schrieb Andy:

Dann gibt es noch den Unterschied Links/Rechtskurve. Um dies zu optimieren, wäre es natürlich sinnvoll beide Seiten unabhängig voneinander zu halten und die Animationen eben mit unterschiedlichen Geschwindigkeiten (oder Framesprüngen) auszustatten.

Kann es nicht geben da der Winkel ja vorgegeben ist in einem Bereich, wenn der z.B. nur <3° ist, läft/fährt er/es fast den Weg gerade entlang, und zwar solange bis zum Ende des Polygons, von dort (per Zufall oder vorgegeben wieder <3° in eine Richtung, so kann ich ihn ganz locker rund um ein Haus laufen lassen.

vor 14 Stunden schrieb BahnLand:

Steigungen und Gefälle darf es dann aber nicht  geben. Den  sonst würde der Fußgänger auf dem Gehsteig pflötzlich schweben oder im Gehsteig versinken. Denn es fehlt dann eben auch die "Zwangsführung" in der Vertikalen.

Deshalb begann ich ja 2-dimensional, der nächste Schritt wäre dann eben in die 3. Dimension.

vor 3 Stunden schrieb Timba:

dieser "Robotermäher" muss dann allerdings auch in der Lage sein, die vorhandene Bebauung abzutasten, wenn man nicht will, dass er wie Superman durch Wände und vor Autos oder Züge laufen soll.

Das wird auch nicht passieren denn der Modellbauer ist ja für das Polygon verantwortlich so wie den Draht für den Rasenmäher legen mußt, auch um einen Baum herum.

vor 2 Stunden schrieb HaNNoveraNer:

aber da sind zu viele Kollisionsabfragen drin, die viel Zeit kosten.

Es gibt nur eine Kollisionsabfrage und die ist die grenze des Polygons, (vorerst einmal) und ob Menschen ineinander laufen passiert jetzt auch und ist in der Grösse noch irrelevant, kann aber in Zukunft abgefragt werden.
Von PKW's spreche ich ja noch nicht, das wäre ein ganz andres Kaliber.
Aber einfache und langsame Objekte müssten möglich sein.

lg max

 

[BahnLand]

Hallo @gmd,

im Prinzip kann man so etwas ähnliches auch schon heute basteln:
Man baue beispielsweise einen Quader mit Breite 80 cm, Höhe 190 cn und Tiefe 3 cm, füge diesem eine 90°-Dreh-Animation mit Drehachse an einer seitlichen Außenkante hinzu und erlaube für dieses "Modell" Tauschtexturen. Schon hat man einen Prototyp für eine animierte Tür, die sich in jede Türhöhle mit gleichen Ausmaßen einsetzen und mit beliebigen Texturen "bemalen" lässt. Mit einer aufgelegten Standard-Textur (im Modell selbst enthalten) könnte man diese Tür auch in Gebäuden auf zu veröffentlichenden Anlagen einsetzen. Mögliche Tauschtextuuren müssten dann aber ebenfall im Online-Katalog hinterlegt sein.

Gleiches könnte man auch mit Fenstern und anderen (vielfach einstzbaren) Objekten machen. Das Problem wäre nur, dass man am Ende ein großes Baukasten-Arsenal hätte, bei dem der Benutzer seine Modelle aus vielen Einzelkomponeten selbst zusammenstellen kann oder muss (je nach Sichtweise), und jedes deser einzelne Bauteile dann vom MBS als separates Modell bearbeitet werden muss. Die Anzahl der darzustellenden Modelle ist eine der Größen, die sich auf das Performanz-Verhalten des Modellbahn-Studios auswirken (bei gleicher Polygonzahl lässt sich ein einzelnes Gesamtmodell schneller darstellem als ein Konglomerat aus vielen Einzelteil-Modellen).

Viele Grüße
BahnLand

[gmd]

Hallo BahnLand,

vielen dank fuer die antwort. 

11 minutes ago, BahnLand said:

bei dem der Benutzer seine Modelle aus vielen Einzelkomponeten selbst zusammenstellen kann oder muss (je nach Sichtweise), und jedes deser einzelne Bauteile dann vom MBS als separates Modell bearbeitet werden muss. 

Das muss nicht so sein, jedes modell kann ja einen "default" haben, der ersetzt werden kann.  
Die anderen punkte kann man sicher loesen mit zukuenftigen versionen. Das heisst ja nicht dass diese diskussionen gleich zu einem feature in der naechsten version fuehren muessen, und ja auch nicht in voller schoenheit gleich realisiert sein muessen. 

Man kann das ja in stufen tun, wichtig is nur die richtung in die gedacht wird. Computer werden schneller und videokarten werden leistungsfaehiger.

Wie ich sagte, gedanken .. 

gruss

gmd

 

[Andy]

Dann bleiben wir doch der Einfachheit halber beim Rasenmäher.
So wie @Neo die Texturen auf die Bodenplatte sprüht, könnten eigentlich auch einige im Endeffekt nicht sichtbare Bewegungszonen-Texturen aufgesprüht werden.
Das Überschreiten einer solchen 'Rasen'grenze dürfte programmiertechnisch relativ einfach machbar sein. Bewegungsfunktionen innerhalb des Bereiches - da wären wir vielleicht wieder bei der Hookfunktion. Da könnte den Usern vielleicht erstmal ein Rahmen zum Experimentieren zur Verfügung gestellt werden - also - Bewegungsvektor rein, an einer Grenze Stop und Rückmeldung. Vielleicht reicht diese Beschreibung, dass Neo da eine Inspiration hat.

Gruß
  Andy

[maxwei]

Hallo @Andy, jetzt kommst du in meine Richtung.

lg max

PS: hat NEO weiter oben ja schon geschrieben daß er eventuell Interesse bekundet.

Bearbeitet 29. Mai 2020 von maxwei

[HaNNoveraNer]

Naja, ich dachte da nicht an EIN Objekt, sondern vielleicht mehrere Hühner, die in einem Stall rumlaufen.
Oder Tiere auf der Weide. Menschen laufen ja selten so rum außer Walking Dead.
Wenn die Tiere sich dann "durchlaufen" dürfen, ok, dann ist das natürlich einfacher und nur in 2D.
Würde zumindest wieder etwas "Betrieb" auf der Anlage verursachen.

Gruß
Thomas

[Andy]

Da ist früher oder später noch viel zu tun.
Stelle dir mal eine Gruppe Leute vor, die sich beidseitig an einer roten Fußgängerampel sammeln und dann aneinander vorbei auf die andere Seite wollen. Mit individuellen Laufgeschwindigkeiten! Das erreicht eine Komplexität, da kann man im Fachbereich Mathematik eine Diplomarbeit drüber schreiben.
Interessanterweise geht das in der Praxis wesentlich 'konfliktfreier', als in manch einer Situation, bei der sich zwei Leute auf der Straße begegnen und dann in mehreren Ausweichmanövern endlich lachend aneinander vorbei kommen.

Gruß
  Andy