Jump to content

~cab

Members
  • Content Count

    14
  • Joined

  • Last visited

Everything posted by ~cab

  1. Tach, ich habe aktuell 2 Modelle: - ein Modell wartet auf ein Lektorat - ein Modell wartet auf die Texturen; Und ich muss ohne Ende Vertices löschen, denn ich bin bei 58k/LOD0: was mich nicht stört, aber ich habe keinen Puffer mehr nach oben für eventuelle Umbau-Varianten, vgl T4D-Z Halle mit 2 Triebköpfen Aktuell ist eh alles doof: wegen Corona für nix Zeit. Dennoch habe ich das Interesse die beiden Modelle zeitnah fertigzustellen. Meine Frage ist: kommen mit der nächsten MBS-Version irgendwelche Features, die sich auf GFX beziehen? Normal-Maps etc? Ist da irgendwas geplant? Warte ich bis dahin oder mach ich die Modelle jetzt fertig und lad sie in den 5er Katalog? Beste Grüße
  2. Ich will ja gar nichts dazu sagen. Aber… Danke! Bei den T3/T4 Modell käme das gelegen. Nicht weil ich es drauf anlege, und schon gar nicht wegen des Bodys: der tuckert trotz endlosen Rundungen mit 2k herum (hrhr) Als ich mit dem Projekt anfing, das muss März gewesen sein, war ich wirklich sparsam. Abgesehen von den Drehgestellen, denn ich hab die Werkzeichnungen und da waren mir 8k Eckpunkte wirklich Brille. Stromabnehmer Typ ESS48 "nur" 3k. Gesamt 29k. Aber dann fing es an, erst langsam. 4 Türflügel: á 3k (da ist nicht mal die Sicke drin). Ich brauch 3, in Sonderfällen 5: Summe 9-15k. 26 Sitze: á 269. T3/T4 ohne diesen ganzen Klimmbimm sieht nicht gut aus. Nicht so, wie man ihn eben kennt. Das ist auch nicht mit Texturen zu beheben. Puffer nach oben soll immer gegeben sein, so dass ich später am gleichen Modell einfach eine 4. Tür einsetzen kann, ohne den Halben Wagen zu überarbeiten. Dann war noch Licht. Ich habe mir verschiedene Lösungen angesehen: @BahnLand war so freundlich etwas zusammenzufummeln, dass ich haben will. Genau so und nicht anders. Leider ist genau diese Lösung für das T4-Modell ein kleiner Wahnsinn Das Konzept geht wirklich auf, wenn man 30er-Jahre-Bahnen mit Bänken — oh, diese Sitze! — hat. Der ganze Kleinkram frisst dermaßen viel, dass ich ab einem bestimmten Zeitpunkt beschlossen hab "Sch*** drauf — löschen kannst später immer noch". Das Löschen schieb ich jetzt vor mir her… Durch die entstandene freie Zeit fiel mir bei genauerer Betrachtung auf, dass Modelle nicht konfigurabel sein werden. Seit dem liegt der T4D wirklich nur noch rum. Mein Verständnis einer Variation ist ein anderer Stromabnehmer/andere Lackierung, der Rest bleibt, wie er ist. Beim Betrieb des T4D in den 4 Betrieben, die ihn zu hunderten einsetzen, gab es aber nicht "die" Bahn. Je nach Entwicklungsstand/Charge mal ein Beispiel: Allein für DD kenne ich 5 verschiedene Stromabnehmer, 3 verschiedene Rückleuchten, 4 Lüfter für diese Zwangsbelüftung, 3 Prellelemente: in allen Kombinationen. Das wären 5*3*4*3 Variationen in der Standard-Lackierung… Leipzig und Halle waren auch sehr experimentierfreudig, Magdeburg weiß ich gar nicht…Ich denke niemand will 180 Variationen haben… Das erste, was mir dazu in den Sinn kam: zusammenklickbare Modelle. Leider mag die Engine überhaut gar keine Kontaktpunkte an einem Fahrzeug. Gruppieren geht, ist aber umständlich von der Benutzung. Das ist schon philosophisch, wehlab ich vor ein paar Wochen zu zusammenklickbaren Fahrzeugen schon einmal einen Thread aufmachen wollte. Habs dann gelassen, weil dei Meinungen hierzu sehr weit auseinander gehen könnten. Einen wirklichen Kompromiss sehe ich als Modellbauer in diesem Fall aber auch nicht: entweder man sucht sich eine Wagen-Nummer heraus und baut genau diese nach… — aber damit öffnet man die Büchse der Pandora: User-Anfragen nach Version X für Wagen Y. Wird es irgendwann etwas "zusammenklickbares" geben? Stelle den Body, 5 Stromabnehmer, Rücklichter in den Katalog und lass den User entscheiden, wie er welche Teile ans Fahrzeug pappt.
  3. ~cab

    Komplexe Weichenkonstruktionen

    Lustiges Spiel. Ich hab hier mal 3 Rechtecke mit 9, 13 und 15mm Breite angelegt.
  4. Hallo, weder gibt es O-Busse noch entsprechende andere Fahrzeuge mit Rollenstromabnehmern — und das wird wohl auch immer so bleiben. Alle anderen E-Fahrzeuge mit Stromabnehmern behelfen sich mit einer "MBS-genormten" statischen Höhe und die Oberleitung ist aktuell nur deshalb ein Spline, damit man es einfacher konfigurieren kann — aber technisch betrachtet handelt es mit jedem dieser Splines um ungenutztes Potential. Nimmt man die aktuellen Gegebenheiten, dann könnte Spline 1 das Gleis, Spline 2 eine Oberleitung, Spline1-User ist das Fahrzeug, Spline2-User könnte die Schleifkohle (_CP_Spline) sein. Schleifkohle folgt Fahrzeug. Das ganze kann man jetzt schon bauen. Nur der bewegliche Teil dazwischen fehlt: denn das ist imho inverse Kinematik und ich finde es verständlich, dass man auf Grund der Komplexität (entweder richtig oder gar nicht, und dann sind wir bei Bones) lieber die Finger davon lässt. Aber: Stromabnehmer!1111elf Ja, ich weiß: es gab Bahnen mit Unterstromzufuhr — aber nur punktuell, versuchsweise, gleiches für Akku-Bahnen. Ich überlege mit welchem "Hack" man auf derartige Kinematiksachen verzichten kann. Da stolperte ich letztens in diesem Forum nach Animations-Stop über LUA, damit man skripten kann, dass der Stromabnehmer zu Frame X gehen soll, damit er keine Wände im Betriebshof einreißt. Der Vorschlag ist aber nicht befreidigend, da ich dann erst ausrechnen muss, wie schnell das Fahrzeug ist, wie die Neigung der Oberleitung zur Schiene ist etc. um dann manuell den Frame anzuspringen — worüber eigentlich? Mit einem Fahrzeug-betritt-Gleis-Event? Alle 5mm ein Stück Gleis für ein neues Event: setze Stromabnehmer auf Frame 0.345? Oder mit einer Horde Timeout-Funktionen, die im 1s/24-Takt den Frame setzen? Und wenn ich 6 Monate später beschließe, das Fahrzeug soll mit 2km/h weniger auf den Betriebshof fahren, weil dort jetzt neue Weichen liegen, die nicht mit mehr als 4km/h befahren werden wollen, dann ändere ich 100-Timeout-Funktionen? Animationsstop via LUA ist zwar nice, aber nicht hierfür: derartiges für Stromabnehmer klingt nach Anti-Pattern… Etwas ähnliches kam mir aber auch schon in den Sinn, geht aber in eine andere Richtung und lässt sich aktuell nicht umsetzen. Das Thema des Threads könnte sein: Ich möchte via LUA mit den Koodinaten zweier Objekte spielen und über die Differenz einen Frame ansteuern. Ich habe das noch nicht zu Ende gedacht und eventuell denke ich auch falsch: Die Zutaten sind irgendwas mit Fahrzeug-Koordinaten (o. g. Spline-User1), zugehörige Zielkoordinaten an der Oberleitung (Spline-User2). Aus diesen beiden Koodinaten kann man dann die Soll-Höhe der Schleifkohle ermitteln und einen passenden Frame für die Stromabnehmerhöhe ansteuern. Das funktioniert am einfachsten wenn der Stromabnehmer in der Fahrzeugmitte sitzt, dann brauch ich nur die Z-Achse — in anderen Fällen steht die Distanz relativ zu den Fahrzeugkoordinaten. Bei Rollenstromabnehmern funktioniert das anders, denn der Rollenstromabnehmer ist drehbar gelagert. Das Problem ist hier eher nicht die Berechnung der Distanz zwischen Schleifkohle und Stromabnehmer-Halterung, sondern der Umgang mit der Animation/den beweglichen Teilen, denn es sind 2: um die Z-Achse sowie auf und ab. Es wäre ein bisschen heavy die Animationen in 2 Ebenen für 180°-Z-Achse mit jeweiligem Höhenwinkel zu rendern: 180° Z-Achse × (nur!) 45° Höhe = 8100 Frames Einfacher wäre es Rotation ist Softwareseitig über ein spezieles Objekt gelöst, dass sich um die Z-Achse dreht. Der Rest wäre dann wie bei "normalen" Stromabnehmern: auf und ab. Um das alles allgemeiner zu machen gibt es ein neues Objekt am Fahrzeug, dass seine eigenen Koordinaten mit sich herum trägt, falls der Stromabnehmer nicht in der Mitte des Fahrzeuges auf dem Dach montiert ist und entsprechend abweichende Koordinaten hätte. Zwei weitere für Soll- und Ist-Koordinate der Schleifkohle. Derer Daten kann ich abgreifen und aus der Differenz gezielt einen Frame für die Höhe ansteuern. Selbst wenn diese Spielerei nur alle 6 Frames berechnet würde, wäre das besser als gar nichts zu haben. Die Objekt-Hierarchie könnte dann so aussehen: 1. Fahrzeug (weiß jetzt schon wo es auf der Platte ist) 1.1 spezielles Empty#1 für Stromabnehmerhalterung wird am Gelenkmittelpunkt/Dach des Strobamnehmers positioniert (optional rotierbar um Z-Achse, weiß wo es sich am Fahrzeug befindet -> weiß wo es sich auf der Platte befindet, hat Tuple XYZ) 1.1.1 spezielles Empty#2 für Soll-Position Schleifkohle (kollidiert immer mit Splines oberhalb Empty#1, hat Tuple XYZ) 1.1.2 Modell Stromabnehmerhalterung 1.1.2.1 Modell Stromabnehmer (animiert auf/ab, Frame für Höhe via LUA aus… Empty#2-Empty#1… oder so) 1.1.2.1.1 Modell Schleifkohle 1.1.2.1.1.1 spezielles Empty#3 für Ist-Position Schleifkohle (positioniert an Oberseite der Schleifkohle, macht erst was, wenn Toleranzbereich Spline betreten wird, hat Tuple XYZ) -> Fahrzeug kommt auf Gleis: Empty#1 ist am Dach, Empty#2 dockt sich am Spline oberhalb des Fahrzeuges an. Beide wissen wo sie sind -> Animation "Stromabnehmer auf" wird gestartet -> Empty#3 kommt in Toleranzbereich für Oberleitungs-Spline, und erhält ein Bit "angelegt". Ab diesem Moment wird errechnet wie weit die Animation vor-zurückgespielt werden soll, um annähernd an #Empty2 zu kommen -> Update alle 0,1s oder so, dann wird die Animation entsprechend vor-/zurückgespielt. -> Berechnungen werden gestoppt wenn Fahrzeug steht -> Bit "angelegt" wird entfernt/Berechnungen werden gestoppt wenn "Strobabnehmer ab" abgespielt wird. Irgendwie… Ist dieser Ansatz diskussionswürdig? Gruß ~cab.
  5. Zusammengehackt sähe das irgendwie so aus: var = variable const = unveränderlicher Wert Angaben in Millimeter 1:1, ab Schienenoberkante, irgendwelche Beispielwerte --- const Sensitiver Bereich Spline Oberleitung: S. var Oberleitung Unterkante: L. var Sensitiver Bereich beginnt bei: Ls = L-S. --- Modell wird in den Katalog aufgenommen und damit eh mindestens einmal analysiert. Diese Werte werden mit dem Modell gespeichert: const Schleifstück Oberkante (Empty#3) b. Stromabnehmer unten: Su, definiert in Animation Frame 1. const Schleifstück Oberkante (Empty#3) b. Stromabnehmer oben: So, definiert in Animation Frame n. const Schleifstück Oberkante (Empty#3) Distanz: D = So - Su. const Schleifstück Oberkante (Empty#3) Distanz pro Frame: Df = D/Frame n. --- Beispiel: Modell mit linearer Animation für den Stromabnehmer über 60 Frames wird in den Katalog geladen; diese 4 Werte ändern sich nicht mehr: const Su sei 3900 @ Frame 1 const So sei 7000 @ Frame 60 const -> D = 7000-3900 = 3100 const -> Df = 3100/60 = 51,66666 (pro Frame bewegt sich der Stromabnehmer also um ~51,66666mm auf-/abwärts. Modell wird auf Anlage gezogen: var Distanz, die sich der Stromabnehmer aktuell bewegen kann: d. a) Fahrzeug steht irgendwo (Empty#2 findet keinen Spline oberhalb seiner selbst): -> d = D = 3100. -> Fmin = 1 -> Fmax = 60 Bei "Animation abspielen" wird die Animation von Frame Fmin (Su) bis Frame Fmax (60 [×Df+Su=So=7000]) abgespielt. b) Fahrzeug steht unterhalb Oberleitung (Empty#2 hat sich an Oberleitungsspline angedockt): L sei 5800 bei Koordinate X/Y. S sei 400. -> die Animation steht nicht auf Frame 1 -> dann gilt der Stromabnehmer als angelegt: -> d = L-Su = 5800-3900 = 1900. -> und das Schleifstück (Empty#2) steht irgendwo zwischen Ls (5800-400=5400) und L (5800) -> dann prüfe, ob die Animation an einem gültigen Frame steht: -> Fmin = 1 -> Fmax = d/Df = 1900/51,66666 = 36,77419 = 36 (besser Luft nach oben, als dass der Stromabnehmer über der Fahrleitung hängt.) Bei "Animation abspielen" wird die Animation von Frame Fmin (Su) bis Frame Fmax (36 [×Df+Su=5760=~L=~5800]) abgespielt. Ohne die Möglichkeit zu berücksichtigen, dass MBS "zwischen den Frames" abspielen kann, ansonsten die 36,77419 auf den entsprechenden float umrechnen. -> mach das alles noch einmal, sobald sich die Koordinaten des Fahrzeuges ändern, synchron oder alle 1s/5=0,2s…, -> wenn der Kontakt zum Spline abbricht oder das Schleifstück den Bereich L - Ls verlässt, spiele weiter bis Frame 60 und weiter wie unter a) -> stoppe, wenn die Animation manuell rückwärts abgespielt, weil Stromabnehmer abzezogen, wird. So ganz ohne Bones/Collision… Auf den ersten wart, der mir dieses Bild ins Gesicht klatscht: https://de.wikipedia.org/wiki/Datei:El_2-Industrieellok_4-1305.jpg Beim Anblick des Bildes gällt mir auf, dass der Ansatz selbst dann funktionieren könnte, wenn man mit exotischem Zeug kommt: Dazu müsste man das ganze Konstrukt nur um seine eigene Achse drehen — den zugehörigen Oberleitungs-Spline eben auch: Z ist dann X und der 0-Punkt nicht die Platte, sondern die Gleismitte.
  6. ~cab

    Klose Triebwerk

    Hallo @fmkberlin, da es dir erst mal nur um das Fahrwerk geht, hier ein Link zur Sächsischen III K. Das Prinzip müsste ja das gleiche sein: https://www.schienendampf.com/34487225nx30160/vorstellung-test-und-fahrberichte-f23/saechsische-iiik-t1554.html http://www.accucraft.de/Produkte/1_20_3/Dampflokomotiven_1_20_3__Live_/Sachsische_IIIK__Live_Steam_/sachsische_iiik__live_steam_.html Eventuell mal in entsprechenden Museen nachfragen, ob es mehr Infos gibt? Verkehrsmuseum Dresden z. B. hat ein Archiv: https://www.verkehrsmuseum-dresden.de/de/führungen-bildung/bibliothek-archiv Schönen Abend noch.
  7. ~cab

    DirectX: Totbox

    Vorab: Ich prog zwar selbst, aber meine Erfahrungen im Game-Design/DirectX/Shader gehen gegen null. Deshalb kann es sein, dass mein Verständnis für die 3D-Modelle etwas falsch und dieser Thread damit obsolet ist. Annahme: Ich erstelle ein Fahrzeug mit Fahrgestell. Dieses Fahrgestell liegt im Original hinter einer Blechklappe. Das Modell kann ich jetzt so bauen, a) dass ich das Fahrgestell ignoriere, da man dieses, bedingt durch die Blechklappe eh nie sehen wird, oder b) ich entscheide mich das Fahrgestell zu modellieren und später über eine animierte Blechklappe sichtbar zu machen (Werkstattaufenthalt etc). Mich interessiert b); Zustand Klappe geschlossen und Fahrwerk so nicht sichtbar: Imho hat es keinen Einfluss ob ich das Fahrwerk skaliere oder nicht, die Polygone werden mitgeschleppt und müssen mit jedem Frame neu berechnet werden, selbst wenn ich auf 0 skaliere. Die Normals über Keyframes zu flippen geht imho nicht (zumindest habe ich gerade nichts dazu gefunden) — und selbst wenn, weiß ich nicht, ob die Polygone des zu versteckenden Objektes immer noch berechnet werden, oder ob sich dass nur auf die Texturen bezieht. Meine Frage: würde die Möglichkeit funktionieren einen speziellen Cube zu definieren, zum Beispiel mit dem Namen _IGNORE, dessen Inhalte nicht gerendert werden? Zustand Klappe geschlossen und Fahrwerk nicht sichtbar -> Fahrgestell wird über Keyframe in die Koordinaten von _IGNORE gezogen und ist für MBS nicht mehr existent. Zustand Klappe geöffnet und Fahrwerk sichtbar -> Fahrgestell wird über Keyframe aus dem _IGNORE-Cube gezogen, ist für MBS sichtbar und wird gerendert. Ich stelle diese Frage, weil ich gerade ein Fahrzeug modelliere, dass ausfahrbare Puffer und andere Geschichten mitbringt, die in der Summe, selbst mit Gewalt, nicht unter 1000 Polygone zu bringen aber im Normalzustand des Fahrzeuges alle unsichtbar sind — und das wäre nur eine Fahrzeugseite. Gruß
  8. ~cab

    DirectX: Totbox

    Danke für die Antworten. Doch, alles gut Und das war die Frage gewesen: Könnte man das aushelbeln. Könnte ich als Programmierer einen bestimmten Bereich definieren, von dem die Engine zwar weiß, dass die Flächen da sind, diese aber erst zur Darstellung berechnet, wenn der der Fall eintritt, dass diese Flächen diesen Bereich verlassen und nicht permanent. Daran, dass eine entsprechende Prüfung allerdings rechenlastiger sein könnte als das eigentliche Rendern, hätte ich nun nicht gedacht. Danke @Neo für die Info. Edit: Screenshots für @BahnLand:
  9. ~cab

    DirectX: Totbox

    Immer vorhanden sein: im Sinne von "dem Renderer zur Verfügung stehen" oder im Sinne von "am 3D-Modell hängen"? Ich hab mal ein Dummy in Blender gebaut: Ignore.zip Die LOD-Stufen sind nicht das Problem: eher wenn man mit _ENV_X für Glitzerkram herumspielt bzw. Anti-Alias auf höchster Stufe stehen hat. Denn das fällt dort imho auch alles mit rein. Und ich gehe davon aus, dass die Skybox mitgerendert wird, selbst wenn ein Blech darüberliegt. Edit: Blender-File ausgetauscht. In der ersten Version war _Ignore parent von Torus, was zu Annahme hätte führen können, dass die Elemente eine Beziehung zu einander hätten. Es geht hier aber ausschließlich um die Koordinaten des _Ignore-Cubes und darum, was sich innerhalb dieser Koodinaten befindet und was nicht.
  10. [1] …sollte auch dann funktionieren, sofern Baumansicht deaktiviert ist. Ich bin Neuling in diesem Programm und hatte in der Testversion mal eine Kategorie angelegt, anschließend die Baumansicht deaktiviert. Es hat (mir zu lang) gedauert, bis ich herausfand, dass das nur dann geht, wenn man die Baumansicht aktiv hat. [2] Auch die beiden Checkboxen zur Aktivierung Baumansicht/Kleine Symbole sind in diesem Zusammenhang eher schlecht platziert. Der Button für das entsprechende Dropdown liegt im Suchfeld — an einer Stelle, an der ich eventuell eine Lupe als Submit-Button oder ein Zahnrad für Suchoptionen erwarten würde. Ich will niemandem auf die Füße treten – manchmal hilft nur der unbedarfte Blick eines Neulings: anfangs gab es noch mehr Punkte, die ich als wirklich störend empfand — unterdessen habe ich mich aber auch daran gewöhnt. Die Usability-Probleme sind damit nicht gelöst, sondern nur durch die Blindheit der Gewohnheit verschwunden. Vielen Dank.
  11. Hallo, bin neu hier und fang direkt mit einer Frage an: Was mach ich falsch? Der zu bauende Wagen ist asymmetrisch (Schienenkran), verhält sich aber auf dem Gleis so, als würden die Achsen/das Fahrgestell mittig sitzen. Erwartet hätte ich stattdessen das hier: Ich hab es probiert mit Koordinaten-0-Punkt an der Pfeilspitze als auch zwischen den Achsen. Bei Drehgestellen funktioniert es: Liegt das jetzt an der Engine oder an mir? – Falls ersteres: gibt es irgendwelche fummeligen Workarounds? Schönen Abend noch und Danke für Tipps.
  12. Wow! Die Mitarbeiter im Betriebshof konnten sich nur ein Funktionsmodell bei einer Skalierung von 1:100 ansehen. Alles andere hätte die Möglichkeiten des Tisches gesprengt. Ich hatte mir nie die Frage gestellt, was für Dimensionen so ein Tragschnabelwagen mit sich bringt, aber dein kleiner Arbeitswagen kommt gut vorran (bloß gut hier gibt es keine Physics, nen Tender wäre mir hier ständig umgekippt:
  13. Moin, vielen Dank für die ausführlichen Antworten, @BahnLand. Ein Mockup werde ich am WE mal bauen. Bei dem Herumgespiele mit Drehgestellen und Kupplungen habe ich festgestellt, dass Straßenbahn-Modellbauer sehr… tolerant sein müssen. Während es heute 3-4 Niederflurfahrzeuggrundtypen gibt die sich durchgesetzt haben (und hier alle wie im Original nachbilden lassen), herrschten in den von mir favorisierten Epochen I und II noch Pioniergeist — [(A)][2][A] — und Entgleisungen Die Lösung mit Einzelachsdrehgestellen funktionieren nur bedingt: bei bestimmten Fahrzeugkonstruktionen schiebt sich das Fahrzeug in die Kurve. Die Planung stört es dann, wenn ich im Modell Begnungsverbote einbauen muss, wo es im Original keine gibt, weil die Hüllkurve zu sehr vom Original abweicht. Versuch, deinen Gelenkwagen nachzubauen: Ja, ich weiß: bei den Achsfolgen, die Straßenbahnen mit sich bringen können, kann ein Programmierer schon mal einen leichten Brechreiz verspüren
  14. Hallo, danke für die schnelle Antwort. Ja, mit versteckten Einachsdrehgestellen funktioniert es: Der Nullpunkt des Fahrzeuges richtet sich danach, ob ich Drehgestelle benutze oder nicht? Wenn ich keine nutze ist er immer in der Wagenkastenmitte? Drehgestelle verschachteln geht wiederum nicht, oder? Als Beispiel der Trafo-Transport mit 3 (oder 4?) Drehgestell-Ebenen: https://www.bahnbilder.de/bild/deutschland~gueterverkehr~schwertransporte/737931/trafo-schwertransport-der-firma-ncs-gmbh.html
×