Jump to content

EASY

Mitglieder
  • Gesamte Inhalte

    3359
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von EASY

  1. Hallo, ... vorgestellt habe ich meine beiden "etwas anderen" Uhren ja schon an anderer Stelle... ... ich habe sie in den Katalog hochgeladen und sie warten auf Freigabe... P.S. Der "Road Steamer" ist nicht vergessen... ich wollte ihn mit Anhänger (Personenbeförderung) veröffentlichen aber das was an Modell dabei herausgekommen ist, hat mir gar nicht gefallen. So ruht das Projekt still vor sich hin... Gruß EASY
  2. Hallo BauerHeini, ... ganz so einfach, wie Du es Dir vorstellst ist es nicht. Die meisten Anlagen bilden in sich geometrisch geschlossene Figuren, da gibt es selbst bei einem einfachen Kreis schon 2 Lösungen für den Abstand der Gleiskontakte, wenn dann noch Abzweigungen hinzukommen gibt es schnell noch mehr Lösungen. Ich habe über die Schnittstelle mal einen Streckenverfolger in VB programmiert, der auch die Streckenlänge berechnet hat. Zuerst mußte die Richtung von einem Startpunkt festgelegt werden, dann ging es immer von einer Weiche zur nächsten und da mußte entschieden werden (per Abfragefenster) ob nun die aktuelle Weichenstellung gültig ist oder es mit einem anderen Zweig weitergeht. Das was Du als "nicht so schwer" bezeichnest, ist programmtechnisch so etwas wie die Suche nach einen Ausgang aus einem (erweiterten) Labyrinth, bei dem es (möglicherweise) mehrere Wege zum Ausgang gibt... und dann müßte der Anwender eindeutig angeben, welcher nun Gültigkeit besitzt z.B. durch vorheriges markieren der Strecke (bei größeren Anlagen auch nicht gerade eine Freude) oder durch voreingestelle Weichen (was bei fortgeschritternen Anlage in der EV zu schweren Irritationen führen kann)... (das Programm kann nicht wissen, welchen Du meinst...) ... mit Lua gibt es mit $("Objektname").transformation.scaling Zugriff auf die Skalierung... (ob das in der "normalen EV" auch geht, weiß ich nicht...) ... ich will nicht in Abrede stellen, daß es schön ist auf möglichst viele Parameter Zugriff zu haben, da dann natürlich mehr möglich wird, was entweder vereinfacht oder eben auch einfach nur Spass macht... Gruß EASY
  3. Hallo Timba, ... was eine "sinnvolle" Position der beiden geraden Gleise ist. Mit etwas mehr mathematischem Aufwand ließe sich noch darstellen ab wann die Position der beiden Gleisenden zu keiner Lösung mehr führt... wäre aber nicht zielführend, da sowieso die wenigsten Leute vorher nachrechnen würden. So ist es mehr als Anregung gedacht ein paar eigene Versuche anzustellen... dann bekommt man auch ein "optisches Gefühl" dafür, was durch einen Kreis verbunden werden kann und was nicht.... Gruß EASY
  4. Hallo Thomas, ... ganz so einfach ist es leider nicht... da es noch eine kleine geometrische Hürde gibt... Prinzipiell ist es eine Betrachtung von einem Kreissegment (siehe wikipedia). Der Winkel a ist der gemessene Winkel. Über die Koordinaten von P1 und P2 kannst Du die Länge der Sehne s berechnen (Pythagoras). (... ist überigens der halbe Winkel der beiden geraden Gleise gegeneinander... muß also nicht unbedingt "gepeilt" werden)) Der Kreismittelpunkt läßt sich so konstruieren... und den Radius so berechnen (siehe Kreissegment) r=s/2 / sin(a). Der Winkel für den Kreisbogen ist 2 * a. Das Problem bei der Sache ist nur, daß man die zwei Punkte P1 und P2 nur dann mit einem Kreisbogen verbinden kann, wenn diese Bedingung erfüllt ist... ... der Schnittpunkt der beiden Tangenten muß auf der Geraden, die senkrecht zu s bei s/2 ist, liegen. ... da ist noch etwas experimentieren angesagt. Gruß EASY
  5. Hallo, ... hast Du natürlich recht... "jein"... ist ein Programmabsturz oder es hängt. Ich habe mir noch schnell die MBS 64 bit Version installiert... dann geht es auf Anhieb... ... ist wohl doch eine Sache der Genauigkeit... der ausgelesene Winkel ist etwas anders... bleibt aber sehr grenzwertig -2.7177454731131e-010 2.7177413097768e-010 0.70710629224777 0.70710676908493 (32 bit) -2.7177457506689e-010 2.7177415873325e-010 0.70710635185242 0.70710682868958 (64 bit) Gruß EASY
  6. Hallo, ... nicht ganz... es verringert die Wahrscheinlichkeit des Fehlers, denn es ist dann eine Lösung für Fahrzeuge, die in x-Richtung ausgerichtet sind. Für Fahrzeuge, die in y-Richtung ausgerichtet sind bleibt das 90° Problem. Nur die Fahrzeuge die in x-Richtung ausgerichtet sind, sind in der deutlichen Überzahl. ... habe ich ausprobiert, es ändert sich nichts am Verhalten. Ich habe mir mal den Winkel ausgelesen, wenn die Anlage frisch gezogen ist... w.x=-2.7177454731131e-010 w.y=2.7177413097768e-010 w.z=0.70710629224777 w.w=0.70710676908493 Nachdem ich dem Gleiskontakt im Eigenschaftsfenster in z 90° zugewiesen habe, kommt folgendes Ergebnis (...denn geht es) w.x=-0.0 w.y=-0.0 w.z=0.70710664987564 w.w=0.70710676908493 Mathematisch noch genauer wäre w.x=0.0 w.y=0.0 w.z=0,70710678118654752 w.w=0,70710678118654752 ... so sehe ich es einmal als Grenzfall an, denn ich weiß nicht, mit welcher Genauigkeit programmtechnisch entschieden wird, in welche Richtung sich ein Fahrzeug in die eine oder andere Richtung beim Aufsetzen ausrichtet, wenn das Fahrzeug im rechten Winkel zur Ausrichtung der Fahrspur aufgesetzt wird. (exakt 90° müßte eigentlich eine 50% Chance geben...) P.S. MBS V5 5.1.0.0 (32 Bit) auf Windows 8.1 pro (64 Bit) Gruß EASY
  7. Hallo Goetz, ... bei mir schon... ich habe einmal versucht alle Fahrzeuge die falsch orientiert aus "Kontakt virtuelles Depot Ost Ausfahrt" herauszuziehen... ... meine Ausbeute nach kurzer Zeit... ... es sind alles Fahrzeuge, die in x-Richtung ausgerichtet sind. ... das ist nicht das Problem! ...ich habe zur Demo mal "Kontakt virtuelles Depot Ost Ausfahrt" in z-Richtung angehoben und die Autos so "gesammelt"... ... die Autos werden um 90 Grad gedreht. Das linke Auto ist als Modell in y-Richtung ausgerichtet und steht nach dem Drehen richtig. ... alle anderen Autos sind als Modell in x-Richtung ausgerichtet und werden um 90 Grad gedreht. Diese 90° sind das Problem. Durch das Einrasten auf die Straße erfolgt die restliche Drehung bis 180° (oder eben auf 0°)... es reicht also schon eine sehr sehr kleine Abweichung von 90° die darüber entscheidet, ob sich die Orientierung des Fahrzeuges beim Einrasten auf die Straße sich nach links (180°) oder rechts (0°) ausrichtet... Bei mir ist es so, daß bei frisch gezogener Anlage die Abweichung so ist, daß die "falsche" Orientiering sehr bevorzugt wird... weshalb ich den Drehwinkel von "Kontakt virtuelles Depot Ost Ausfahrt" etwas über 90° gesetzt habe... so werden die Fahrzeuge etwas weiter gedreht und die Vorgabe für das Einrasten für das Programm eindeutiger... Warum es bei mir so ist und bei Dir nicht... darüber läßt sich trefflich streiten... vor allem über die Frage die wievielte Stelle hinter dem Komma den Ausschlag gibt... Gruß EASY
  8. Hallo Goetz, das Problem ist die Ausrichtung des Gleiskontaktes und der Fahrzeuge. Der Gleiskontakt ist in y- Richtung ausgerichtet und " Kontakt virtuelles Depot Ost Ausfahrt" ist um 90° gedreht. Die Fahrzeuge sind teilweise in y-Richtung ausgerichtet (hat historische Gründe. In einer frühern Version (ich glaube sogar noch EP) sollten die Fahrzeuge in y-Richtung ausgerichtet sein, jetzt ist die Sollrichtung die x-Richtung was auch die meisten Fahrzeuge zutrifft). Wenn Du nun die Drehung (90°) des Gleiskontaktes an das Fahrzeug übergibst, dann stehen nur die Fahrzeuge, die in y-Richtung ausgerichtet sind richtig (Fahrtrichtung nach links). Eine Ausnahme bildet z.B. "Bus Post". Das Modell ist in -y-Richtung ausgerichtet und steht bei einer Drehung um 90° definitiv verkehrt herum. Bei den Fahrzeugen, die in x-Richtung ausgerichtet sind, ist es etwas komplizierter. Sie werden durch den Gleiskontakt (Referenz) um 90° gedreht. Sie müßten aber um 180° gedreht werden. Die restliche Drehung erfolgt durch das Einrasten auf der Straße. Wenn ich nun die Anlage frisch von Deinem Beitrag lade, dann habe ich relativ viele Fahrzeuge die bei "Kontakt virtuelles Depot Ost Ausfahrt" erst einmal nach rechts fahren, also genau verkehrt herum plaziert werden. Wenn ich nun die Rotation vom "Kontakt virtuelles Depot Ost Ausfahrt" in der z-Achse über das Eigenschaftsfenster noch einmal auf "90" setze, ist der Fehler weg und die Fahrzeuge fahren vorwärts nach links. Es ist wahrscheinlich ein Rundungsproblem (der Kontakt steht für das Programm auf 89,999°) und da dies kleiner als 90° ist rasten die Fahrzeuge falsch herum mit der Straße ein. Um sicher zu sein, habe ich dem Gleiskuntakt 91° mitgegeben und dann geht es ohne Probleme (außer z.B. "Bus Post") aber da liegt es am Modell und seiner Ausrichtung... Gruß EASY
  9. Hallo Goetz, ... bei Deinen Lösungsansätzen gefällt mir die Einfachheit der Lösung (auch wenn ich manchmal etwas länger brauche um nachzuvollziehen, was Du gemacht hast...) Bei der hinteren Spur "Kontakt virtuelles Depot Ost Ausfahrt" gibt es allerdings das Problem, dass die Fahrzeuge die da "herauskommen" zuerst einmal nach rechts an das Straßenende fahren um dort mit dem "automatischen Richtungswechsel" rückwärts nach links wegzufahren... nun gibt es aber eine ganze Reihe von Fahrzeugen bei denen diese Option nicht eingeschalten ist, diese stapeln sich dann an dieser Stelle... ... sollten die Fahrzeuge, die bei "Kontakt virtuelles Depot Ost Ausfahrt" herauskommen nicht erst um 180° gedreht werden, damit sie vorwärts nach links fahren? Gruß EASY
  10. Hallo, ... ich weiß, daß es an anderen Stellen hier auch schon mehr oder weniger angesprochen wurde, trotzdem hier ein kleiner Bericht der (verzweifelten) Lösungssuche. Ich hatte die Idee (noch) eine Uhr der etwas anderen Art zu bauen. Es ist zwar nur eine analoge Uhr aber mit digitalem Zifferblatt. Dabei bin ich allerdings auf folgendes Problem gestoßen: Ich wollte das Zifferblatt als Textur machen... ... damit die Geometrie der Uhr einfach gehalten werden kann. So hat die Uhr im ersten Bild etwa 500 Polygone (ließe sich auch noch reduzieren...) ...und ich habe mich gefreut... ohne LOD... einfach fertig. Beim in den Katalog stellen, mußte ich allerdings feststellen, daß ich mit der Texturgröße von 512 x 512 das Modell nur hochladen kann, wenn es einen Durchmesser von mindestens 2,4 Meter hat. Darunter sollte ich die Textur verkleinern. Da ich gerne nur einen Meter Durchmesser wollte, habe ich die Textur auf 256 x 256 verkleinert... ... ist aber dann in der Auflösung etwas "bescheiden", da es anfängt in der Darstellung auszufransen (trotz .png)... ... also dachte ich mir, wenn nicht über die Textur, dann eben im Modell... dann wird die Textur klein (64 x 64)... ... und noch eine für die halb.transparenten Scheiben (Zeiger) auch 64 x 64... ... Texturproblem gelöst!... dafür wird natürlich das Modell komplexer... ... mit vielen Polygonen (ca. 4500)... ... vor allem für die Erzeugung einer LOD-Stufe fast unmöglich zusammenzufassen. Da noch unter 5000 erfüllt es ja auch noch prinzipiell die Anforderung ohne LOD zu arbeiten... ... das Ergebnis ist auch bei 1 Meter Durchmesser oder (noch kleiner) eine scharfe Kontur im Zifferblatt... ... dieses Modell habe ich dann auch mal als Entwurf unter F66B251D-2B3E-44DD-B158-166A215C1C31 hochgeladen... (ist an die MBS-Zeit gekoppelt ["_Time" in der . anim] und ausgelegt für 24 Stunden)... Was mich eben nicht so ganz glücklich macht ist zu entscheiden, ob es nun "sinnvoll" ist, die "Hinterlist" anzuwenden und das Modell etwas sehr groß einzustellen (dafür wenig Polygone) und es dem Benutzer überlasse es zu skalieren... oder das Modell kleiner zu lassen, dafür hat es verhältnismäßig viele Polygone... Gruß EASY
  11. EASY

    Die etwas andere Uhr...

    Hallo, ... nachdem noch ein paar Klicks dazu gekommen sind (Danke!), werde ich versuchen daraus ein Modell für den Katalog zu machen... es wird von der Geometrie her noch eine kleine Herausforderung mit den LOD-Stufen... Gruß EASY
  12. EASY

    Die etwas andere Uhr...

    Hallo, ... danke für die Klicks... vielleicht gehe ich doch noch in mich und mache ein (Katalog-)Modell daraus... ... die Animation ist einfach aufgebaut... Der (doppelte) Exzenter ist der Antrieb (und die Anzeige der Minuten)... ... die untere Scheibe ist um die Exzentrität in -y verschoben... ... die obere Scheibe ist um die Exzentrität in +y verschoben... ... die beiden Scheiben sind Kinder vom Exzenter... Die Animation ist ausgelegt auf 12 Stunden. Dies bedeutet für den Exzenter (Minutenanzeiger) eine Animation von 0° bis -12 x 360° ("-" da im Uhrzeigersinn). Die beiden Scheiben sollen sich in dieser Zeit jeweils um +360° drehen (Stundenanzeige). (Diese Art von Getriebe dreht die Drehrichtung um) Da die beiden Scheiben Kinder vom Exzenter sind, drehen sie sich um -12 x 360° mit dem Exzenter. Um dies auszugleichen müssen sie sich um +12 x 360° drehen plus die eigene Solldrehung von 360°. So geht die Animation für die Scheiben von 0° bis (12+1) x 360°. [Ergibt sich also aus dem Übersetzungsverhältnis 12:1]... ... dann hier noch das Häkchen gesetzt... ... und der Exporter hat den Rest erledigt (die Animation mußte nicht einmal "gebacken" werden...). ... somit hält sich der Arbeitsaufwand für das Erstellen der Animation doch sehr in Grenzen... P.S. ... das größere Problem war die Außenkontur der Scheiben... Gruß EASY
  13. EASY

    Die etwas andere Uhr...

    Hallo, hier hat @BahnLand geschrieben: ... deshalb habe ich ein etwas anderes (sichtbares) Uhrwerk gebaut... mit einem Zykloidgetriebe... ... ich habe es mal absichtlich in die virtuelle Spielwiese gesetzt... da ich es momentan als Spielerei ansehe... ...für "nur" eine Uhr, ist es mit derzeit ca.20000 Polys schon etwas heftig... und ich weiß nicht, ob jemand "so eine" Uhr überhaupt verbauen möchte... (Links 12:00 Uhr; rechte 4:30Uhr) ...die Uhr ist als Entwurf hochgeladen unter C1002693-CCC9-4ED7-B66F-F9055550A82E ... Ihr könnt sie Euch ja mal ansehen und vielleicht etwas dazu schreiben... Gruß EASY
  14. Hallo Thomas, wenn Du nur um die z-Achse drehen möchtest, geht es auch ganz ohne Quaternionen . Das Rotieren um eine Achse gibt es als direkten Befehl: -- Rotation in der Z-Achse um einen Winkel (Winkelangabe in Radiant) $("Objekt").transformation:rotateZ(math.pi) -- rotiert um 180° in der Z-achse Hinweis: den ":" beachten... Gruß EASY
  15. Hallo, im Modell kann nur die Position für den Partikeleffekt "Dampf" festgelegt werden [ '_PEP - Particle Emitter Position, gibt die Startposition für Dampfpartikel an']. Der Effekt wird dann im MBS "erzeugt" und kann beim Hochladen des Modells noch angepasst werden (wie jeder Partikeleffekt vom MBS). Bisher geht das nur bei Fahrzeugen. Die Erweiterung auf alle Objekte besteht meines Wissens schon etwas länger als Wunsch. Bei den Häuschen auf manchen Anlagen, bei denen es aus dem Schornstein raucht, wurde dies im MBS nachträglich als Partikeleffekt "Rauch" hinzugesetzt. Teilchen von einem Partikelemitter in Blender existieren erst einmal (virtuell) nur in Blender. Um sie für das MBS im Modell zu exportieren, müssen die Partikel erst in "reale" meshes umgewandelt werden. Dies geht zwar prinzipiell, jedoch ist mir das bisher nur statisch gelungen... also als eine Momentaufnahme der Position der Partikel ohne deren "Flugbewegung" als Animation. Ob das überhaupt möglich ist, darüber habe ich bisher noch nichts gefunden... Gruß EASY
  16. Hallo Max, eigentlich wollte ich für heute die Kiste abschalten... geht aber nicht bevor ich Dir meine Hochachtung zu diesem Modell ausgesprochen habe... Gruß EASY
  17. Hallo, es hängt leider davon ab, welches YouTube Filmchen man gerade erwischt, was eine Bones-Animation erklärt. Die meisten beziehen sich darauf, dass das Modell aus nur einem Objekt besteht und das mesh von diesem Modell dann mit den Bones "verbogen" wird. Dies kann das MBS (noch) nicht darstellen. (Soll gerüchteweise in V6 kommen). Eine Bones-Animation kann allerdings auch mit einem Modell gemacht werden, das aus mehreren Objekten desteht. Wenn man diese Animation (für die einzelnen Objekte) dann backt, können die Bones wieder weg und das Modell läuft im MBS. Kleines Video zum Zeigen, wie es prinzipiell geht (nur das Backen ist nicht mit dabei) [Ab der Mitte des Filmes kommt die Animation] https://www.youtube.com/watch?v=vWjxdn1R0Ek Gruß EASY
  18. Hallo Andy ... als Studienobjekt sehr interessant... ein gefiedertes Tier mit Flugeigenschaften(*)... mit Motor und Zahnrädern... @metallix ...(*) ich habe es extra so umschrieben, damit bei Dir die Phantasie nicht gleich wieder durchgeht.... (Vogel, Vögel, vögeln...) Gruß EASY
  19. EASY

    3D-Engine

    Hallo @Neo, Das ist ein gutes Beispiel, warum eine andere 3D-Engine oder der Vergleich mit anderen Spielen keine Lösung ist. ... dann muß ich noch ein "gutes" Beispiel bringen für eine Textur-Animation. So wie ich es verstehe, ist es eine Animation die die Textturkoordinaten in der Animation speichert. Ein klassisches Beispiel wäre eine Ampel (3 Kreisflächen in einem mesh) Texturzuordnung 1. Frame... Texturzuordnung 2. Frame... Texturzuordnung 3. Frame... Texturzuordnung 4. Frame... ... so bräuchte man das ganze mit den "Klappen", die die Farbscheiben abdecken nicht... ... aber aus der zwischenzeitlichen Antwort von maxwei muß ich wohl schließen, daß die Texturanimation beim glTF Export wohl nicht unterstütz wird... ... hat sich also schon erledigt, bevor ich geantwortet habe... abschicken tue ich es trotzdem mal noch... Gruß EASY
  20. Hallo, ... die Achterbahn von maxwei hat mich dann doch neugierig gemacht, ob man Blender Physiks auch nehmen kann um Animationen zu erstellen. Da sich diese Animationen auch "backen" lassen, geht es auch prinzipiell fürs MBS (nur Keyframe Animation). Mein Versuchsaufbau sieht so aus... ... und so nach Ablauf der Animation... Wer interesse hat, kann sich das Ergebnis ansehen... unter DA230A47-329F-4BC2-BD45-8FE53159A300 ist das Modell als Entwurf hochgeladen... und wer es sich im Blender ansehen möchte... in der .zip ist das Blendermodell und einmal roh( mit Physiks Definitionen) und einmal mit gebackener Animation und eine kleine Textur... Versuche mit Physiks.zip (Hinweis: Dateien sind erstellt mit Blender 8.1 und gehen auch nur mit Blender 8.x) Anmerkung: ... die Parametrierung folgt etwas undurchsichtigen Gesetzen... und ich weiß nicht ob da überhaupt ein Physik-Studium helfen würde...) Gruß EASY
  21. Hallo Axel, ... Deine Art Segel zu setzen hat technisch gesehen interessante Aspekte (...konnte ich mir nicht ganz verkneifen... aber die Idee an sich ist gut) Gruß EASY
  22. Hallo Max, super gemacht... und noch ein extra für die Effekte in der Beleuchtung vom Schriftzug... (...nur 'mitfahren wollen' ist immer noch nicht [nicht einmal vorwärts...]) Gruß EASY
  23. Hallo FeuerFighter , ... der "Regenbogen" ist ein toller Effekt (hast Du sehr schön ungesetzt)... ich verstehe nur nicht so ganz, was was dahintersteckt... ... darum muß ich mal ganz dumm fragen... ist das so (als Logo) oder ein Graffiti? Gruß EASY
  24. Hallo Andy, ... habe ich mir auch schon mal angeschaut. Bisher verstehe ich es allerdings eher als eine Art "Verteiler" als wie Multithreading (man muß eine coroutine anhalten, damit die nächste weiter arbeiten kann)[?]... ...da ich momentan zu diesem Thema in Lua einiges an Möglichkeiten angesehen habe, mir allerdings dazu noch kein Plan eingefallen ist, lasse ich es erst einmal auf mich einwirken (festbeißen bringt nicht wirklich voran)... bis dahin... P.S. Lua kann man auch in der Pfeiffe rauchen... dann kommt man auf einem Lua-Trip... Gruß EASY
  25. Hallo Frank, ... sorry, ich war diese Woche auf einem Lua-Trip und habe Deine skalierbaren Ladungen erst heute entdeckt... hat mir sofort gefallen, da es die Umsetzung einer Möglichkeit ist, die zwar existiert aber nicht so offensichtlich ist (so etwas gefällt mir besonders) und ich wollte auch etwas dazu schreiben, da mir spontan die eine oder andere Idee kam, was möglich wäre (aber hast Du ja schon umgesetzt)... also nicht gleich ein Paar Tage später schon motzen... gib einem Spätzünder wie mir eine Chance sich dazu zu äußern... Gruß EASY
×
×
  • Neu erstellen...