gmd

ja die habe ich ja auch formatiert -- siehe den anderen post. ah ich glaube ich habe verstanden : Die aktionen in der ev wie Toggle Turnout -- sind einfach auf elementare funktionen wie state zurueckgefuehrt und die sind ja in der xml beschrieben. Ist das richtig so ? grudss Gmd

Neo, gibt es noch andere editor methods ausser denen im Wiki zur neuen externen schnittstelle ? Bin dabei die neuen funktionen vorzubereiten, die event transformation ist so gut wie fertig, bin dabei die anderen funktionen anzupassen. Noch eine frage zum verstaendnis: Zum beispiel die aktion geschwindigkeit setzen gibt es nicht mehr als method, sondern nur als lua script ueber layout.invokeScript; ist das richtig so ? oder habe ich etwas nicht verstanden. Hast du eine xml datei mit allen Aktionen der EV ? die script datei hat keine aktionen oder editor methods gruss Gmd

Nochmal Hi, sorry fuer die mehrfachen posts aber ich dachte es koennte nuetzlich sein. Habe deutsch und english mit inhaltsverzeichnis gemacht.. nur html Falls gewuenscht kann ich auch das stylesheet posten. gruss Gmd Lua_Toc.zip

Hi again, und hier die pdf files, falls das bevorzugt wird. Gruss Gmd Lua_PDF.zip

Hi everyone, anbei drei files. Formatierte datei = English und Deutsch und stylesheet fuer xslt falls jemand spielen moechte Gmd Lua_Formatted.zip

Hi everyone, Being home for a week and not having my desktop (it's in the caravan down south), was playing on a laptop with some layout variations. Two things came up, which always were a bit of an annoyance to me over the years: 1. It would be really nice to be able to apply ramp modifications to group of splines (tracks). One has to release the group to do that and then group again. 2. When using terrain features it would be nice if each function (up, down, smooth etc.) could remember the settings individually. Building terrain requires a lot of switching between the functions and usually the settings for size and strength, and maybe even form of brush is different. Would be great that settings remain for each function separately. Oops, sorry just realised that I wrote in English, wasn't intentional. I am back next week on my desktop and will give XLST a go, unless somebody else has already done the formatting of Neo's command list. Still kinda embarrassed about the plunder with the AI. Regards Gmd

Haha, da hast du wohl recht .. Aber ein fundus an ideen .. gruss Gmd

Da hast du wohl recht. Ich verwende den AI zum programmieren und das ist ein 100% factcheck, entweder es geht oder es geht nicht .. und zum texten fuer webseiten.. das kann man ja auch selbts korrigierenn .. der rest ist fragwuerdig gruss Gmd

Ich habe den AI nochmals befragt woher das dokument kommt das er ausgespuckt hat als formatierung fue das XML. Hier ist die Antwort .. Ich glaube wir haben aus versehen die dokumentation der EEP implementierung bekommen. Hmmm... ich denke das alleine ist eine diskussion wert ueber sinn und unsinn eines AI. Dann habe ich die Frage gestellt: How does that compare with 3D Modellbahn Studio und die antwort is unten angeheftet Und falls das zuviel fremdwerbung ist, kann Neo den thread ja loeschen, fuer mich ist allerdings weder EEP noch RocRail wirklich konkurrenz. Wow, wieder was gelernt ... und fakten sorgfaeltiger checken gruss Gmd The provided Table of Contents (TOC) has some overlap with both EEP (Eisenbahn-Experten-Programm) and Rocrail, but the overall structure aligns more closely with EEP Lua scripting. Here’s a comparison: 1. EEP (Eisenbahn-Experten-Programm) Key Indicators: EEP uses onStart, onStop, onObjectAdded, and other event-driven Lua functions. Extensive use of layout objects like Vehicle, Signal, Track, Switch, and Block. Lua scripting with defer(), toTime(), and playSound() is characteristic of EEP's simulation scripting environment. EEP has UI-related functions such as showPopup, playEffect, and safety-related controls (enableEmergencyBrake). Matching Sections: Event Parameters, Global Variables/Functions, Events, Layout Objects, Vehicle Properties, Signal Settings, Functions for Event Scripts, and Animation Control are all common in EEP. Depot-related and contact settings (e.g., triggeredBy, isActive) also appear frequently in EEP. 2. Rocrail Key Indicators: Rocrail supports Lua scripting for automation but is more focused on integration with MQTT, network communication, and event-based commands for train control. Rocrail typically emphasizes train schedules and actions but may not have as many animation functions (e.g., playEffect, setCamera) as listed in your TOC. Rocrail tends to focus more on track feedback, occupancy detection, and external control using scripts. Matching Sections: Network-related commands, event registrations, and vehicle tracking (trackVehicle, stopTrackingVehicle) do align with Rocrail. Functions like getConnectedBlocks, sendCommandToVehicle, and external communication (connectToServer) match Rocrail's architecture. Conclusion: Based on the structure and variety of features like UI effects, signal and contact functions, and the animation controls listed in your document, this TOC matches EEP's Lua scripting environment more closely. If you’re using EEP, this makes sense. Rocrail’s scripting is more focused on command-based control rather than UI animations and vehicle properties in such detail. Let me know if you’d like a detailed example comparison, or if I should extract additional details to confirm! -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Comparison with 3D Modellbahn Studio Lua Scripting: 3D Modellbahn Studio is a sophisticated 3D model railway simulation software that supports Lua scripting for layout automation, similar to EEP and Rocrail. Here’s how the features in your table of contents compare with 3D Modellbahn Studio's capabilities: Similarities: Event System: 3D Modellbahn Studio supports event-based triggers like onSimulationStart, onObjectAdded, and onObjectRemoved, similar to your "Events" section (3.1 OnStart, 3.3 OnObjectAdded). Lua scripts in 3D Modellbahn Studio can listen to events related to vehicles, signals, contacts, and switches, matching the types in your "Layout Objects" (5.x) section. Object References and Properties: Your TOC mentions Vehicle, Signal, Track, Switch, Camera, Depot, etc., which are also core simulation elements in 3D Modellbahn Studio. Properties like currentSpeed, maxSpeed, and stateCount (sections 7.x and 8.x) are typical in both 3D Modellbahn Studio and EEP for controlling vehicle behaviors and signal states. Functions for Event Scripts: Functions like print(), math.random(), and wait() are standard Lua functions used in 3D Modellbahn Studio for script debugging, randomness, and delays (sections 6.x). The ability to control objects (playSound, setSignalState, spawnVehicle, etc.) appears in both environments. UI and Animation Controls: Both EEP and 3D Modellbahn Studio support animations (playAnimation, setCamera, showPopup), indicating that visual storytelling and camera effects are part of the simulation scripting. Differences: Focus on 3D Visualization: 3D Modellbahn Studio emphasizes immersive 3D layout visualization and has detailed animation controls (startAnimation, stopAnimation), which are noted in your document. Some UI controls like showMessage, showAlert, and resetCamera may be more relevant to interactive user interfaces rather than purely automation-focused scripting like Rocrail. Network and External Communication: The "Network Communication" and "External Communication" sections in your TOC align more with Rocrail’s network-centric approach but may have some support in 3D Modellbahn Studio for cloud-based layout sharing rather than MQTT communication. Schedule and Depot Management: The sections on schedules (12.x) and depots (10.x) indicate a system with train management logic, which 3D Modellbahn Studio supports in simpler form but may not be as extensive as EEP’s detailed timetable and depot functions. Conclusion: Your TOC is highly aligned with 3D Modellbahn Studio, especially for event-based control, animations, vehicle properties, and user-defined variables. Some parts, such as detailed network synchronization (35.x) and statistics export (30.x), may indicate additional features beyond 3D Modellbahn Studio's primary focus, pointing more toward EEP or Rocrail. If your simulation includes detailed schedules and train operations, EEP remains a strong contender. Would you like me to dig deeper into specific sections or assist with more detailed examples from 3D Modellbahn Studio?

Ich wuerde mal sagen das hat der AI getraeumt. Ich habe den inhalt nicht geprueft ob er wirklich dem original entspricht, h atte mich nur ueber die lanege gewundert aber nicht weiter darueber nachgedacht. Deckt sich mit den anderen erfahrungen mit dem AI , man braucht manchmal viele anlaeufe bis was vernueftiges rauskommt. Also wahrscheinlich doch besser mit XLST. Danke Easy das du das aufgedeckt hast ... Und entschuldigung dass ich da nicht sorgfaeltiger war. gruss Gmd

Und hier die englische version Wenn jemand lust hat selbst einen versuch zu machen, ich habe das mi ChatGpt 4o gemacht .. die freie version ist 4omini, habe keine ahnung was die version macht. Jedenfalls 4o kommt nach etwas insistieren zu einem halbwegs brauchbaren ergebnis. Gruss Gmd Script Definitions_LUA_English.zip

Hier eine etwas bessere version. Habe 3 file formate im zip mht fuer browser use ohne page breaks, docx zum nachbearbeiten wenn jemand lust hat die table of contents aktiv zu machen (word hat automatische TOC, die header sind ja gesetzt), und ein pdf mit page breaks. Ich bevorzuge die mht version da sie am besten zu lesen ist und compakt. Ich habe den AI noch etwas gekitzelt mir ein besseres ergebnis abzuliefern, aber zu mehr habe ich viel zeit (lust) muss ich sagen. Dieses ergebnis is ok, meiner meinung gemessen an der zeit die ich damit verbracht habe .. Werde noch die englische version machen .. Fuers Wiki muesste es noch etwas huebscher werden, aber vielleicht findet sich ja jemand .. Gruss Gmd Script Definitions_LUA_Deutsch.zip

2 html files, simple formatting hoffe das gefaellt Gruss Gmd ScriptDefinitionsFullFormatted_EN.zip

Nun macht mal halblang. Hier denkt jeder mal wieder nur an sich selbst. Neo und das MBS braucht verbreitung und je mehr benutzer es gibt um so mehr kann das MBS wachsen. Fuer mich ist es mehr als 5 oder 14.50 wert NICHT mit Steam zu dealen. Es ist "invasive" und annoying. Ein einfuehrungsangebot in Steam ist hoffentlich eine erfolgreiche sache fuer Neo, dann kann er oefter upgrades verkaufen. Leute die Steam benutzen sind ja gewoeht fuer jeden furz zu zahlen. Ihr solltet mal den wert des MBS schaetzen und nicht ueber ein paar euro gackern. Das MBS ist meiner meinung mit abstand das beste produkt in seinem segment. Ich habe EEP und auch Scarm getestet, Scarm hat die Lizenz refunded bei rueckgabe, EEP nicht. Was zahlt man denn fuer ein regelmaessiges upgrade bei EEP und mal ganz abgesehen von den modellen. EEP hat so eine fuerterliche oberflaeche und anlagen sind schwerfaellig zu bauen ... Der 3D MBS editor ist convenient und macht spass zu bauen. Ich bin kein freund von 2d plaenen etc. Interactiv die anlage bauen is genausogut wie die anlage benutzen wenn sie fertig ist. Der ganze prozess macht spass und das ist bei anderen programmen nicht der fall. Ihr koennt ja nach Steam wechseln, ich jedenfalls verzichte gerne auf einen Kaffee pro jahr um davon fern zu bleiben. Das sinf halt mein 2c. gruss Gmd

Hallo mal wieder, habe an meinem abschnitteditor weitergebastelt. Zu jedem abschnitt koennen teilabschnitte und eigenschaften zugeordnet werden (die bilder unten an der gruppe). Teilabschnitte sind separate sichten auf teile des gbs fuer diesen abschnitt. Ein bahnhof oder ein haltepunkt kann zugeordnet werden (oben rechts), und auch ein stellwerk (oben links). Alle anderen symbole sind plan- und steuerbare ablaeufe. Jedes bild representiert eine darstellung von daten mit moeglicher eingabe. Fuer jeden ablauf wird eine schablone vorgeneriert (templates) die vom "GBS pult" abgerufen werden koennen, mit hilfe der gleichen symbole wie hier im diagramm. Ist einem Abschnitt ein bahnhof oder haltepunkt zugeordnet, steht er fuer einen fahrplan zur verfuegung. Die linke gruppe stellt den derzeit maximalen umfang and definitionen dar. Mit funktionen wie schliessen und oeffnen koennen die gruppen verkleinert werden. Das diagramm kann beliebig gross werden. Die anordnung der komponenten ist vollautomatisch, man braucht also nicht lange mit "ordnen" verbringen. Fuer die meisten abschnitte werden natuerlich nicht alle variationen verwendet, die anordnung wird dann automatisch angepasst, man kann aber immer auf die grundanordnung zurueckgehen. Damit lassen sich grafisch sehr schnell die strukturen festlegen mit denen das GBS verwaltet werden soll. Ist ein stellwerk zugeordnet dann wird die steuerung aktiv moeglich. Ist kein stellwerk zugeordnet ist nur eine ueberwachung gedacht. Dies alles gehoert zu den strukturen auf denen der AI einmal arbeiten soll. Fuer das AI-Modell braucht man ja eine gute abbildung der "welt" in der die entscheidungen getroffen werden sollen und alles soll ja in einem wohl definierten rahmen ablaufen. Zugeordnete funktionen koennen jederzeit wieder weggenommen oder hinzugefuegt werden. Es folgen noch weitere details zu den bahnhoefen, wodurch einzelne gleise bestimmten aktivitaeten zugeordent werden koennen. Ich brauche dazu keine kontakte, nur eindeutige gleisnamen in den bloecken. Auf bestimmten gleisen sind dann nur bestimmte aktivitaeten moeglich, wie anhalten eines personenzuges, oder durchfahrt eines gueterzuges. Wenn keine zugliste fracht zugeordnet ist, kann kein gueterzug in dem abschnitt fahren. Damit is das automatisch definiert.. und so weiter. Es lassen sich noch eine vielzahl von eigenschaften oder funktionen denken, deshalb sind die einzelnen digrammelement auch nicht fest definiert, sondern koennen erweitert werden. Die editierungsfunktionen sind jetzt soweit fertig, jetzt kommt noch das abspeichern und laden des diagramms. Dann gehts mit einer anderen komponente weiter. Ich muss ja noch die blockerkennung weitermachen und die automatische generierung der bloecke im Gbs fertigstellen. Ein solches diagramm mach natuerlich mehr aufwand bei der programmerstellung als eine einfache texttabelle, ist aber in der anwendung unvergleichlich schneller und uebersichtlicher. Mit der neuen schnittstelle kann ich ja sogar lua code hinter solchen symbolen verbergen und bei bedarf laden. Damit kann ich schneller auf einzelnen script komponenten zugreifen und diese nach meinen kriterien ordnen. Gruss Gmd

Ich misch mich mal kurz hier ein. Aus dem was ich gelesen habe schliesse ich daraus dass ein plugin zur ansteuerung und "Short Cuts" die bessere Loesung waere, wesentlich flexible, wie Neo ja schon sagte. Was ich fuer die erweiterung von steuerungsmoeglichkeiten in der EV machen wuerde und dann aufrufbar, unter anderem, durch simples plugin sind Macros, wurde ja oben schon angedeutet. Macros sind eine methode das MBS lernen zu lassen (in elementarem umfang). Macros wuerden erstellt durch schaltaktionen, die ueber gbs, direct am objekt oder ueber steuerfenster ausgefuehrt werden und das MBS zeichnet die einzelnen aktionen auf und man gibt dem macro einen namen und natuerlich auch schlagworte. Dann kann das jederzeit ausgefuehrt werden. Es koennen gruppen gebildet werden (schlagworte) und die macros koennen auf tasten im gbs gelegt werden. Die einfachste form eines Macros waere dann ein "short cut", ausgeloest ueber ev, taste, oder auch externe schnittstelle. Es laesst sich auch in der graphischen EV darstellen und noch manipulieren, zb. zeitverzoegerungen einbauen etc. Das gilt dann auch fuer animationen. Das waere fuer mich ein konzept dass sich gut in die jetzige logik einfuegt. Damit lassen sich externe geraet leicht anschliessen und benoetigen nicht eine "tiefe" programmierung. Die logik der macros wird dann durch ausfuehrungsbefehle ("short cuts") "durchgereicht". Damit sind externe gearete leicht auswechselbar und die logik verbleibt im MBS. Die grafische EV ist sehr gut geeignet die macros darzustellen und zu manipulieren. Durch diese mechanismen haette man auch eine einfache eingabemoeglichkeit fuer steuerungskomponenten die keine macros werden sollen, die man dann verfeinern kann. Ich habe die ersten elemente davon in meinem steuerprogram, so lege ich routen an. Im MBS setzt man start und ziel und die fahrstrasse wird geschaltet. Das ist ok und einfach zu definieren, ist aber ein sonderfall. Ich definiere routen, das sind wege die ein zug nimmt um einen fahrplan abzufahren und nicht die kuerzeste strecke zwischen punkten, also eigentlich viele fahrstrassen verbinden. Dafuer verwende ich macros, die die flexible definition von beliebigen fahrstrecken ermoeglicht und dabei auch alle moeglichen aktionen startet oder beendet, inclusive tuere oeffnen und schliessen, lautsprecher ansagen starten usw. Ich waehle allerdings nur bloecke aus, signale und weichen steuert das programm automatisch. Man kann das auch mit automatisch ermittelten fahrstrassen zwischen haltepunkten machen, aber die manuelle definition von macros erlaubt mehr variationen. Das bedeutet man kann mit der kirche ums dorf fahren bevor man am naechsten bahnhof ankommt . Gruss Gmd

DoppelDepot natuerlich, sorry... war ein langer tag regards Gmd

Prima, wieder was gelernt.. das doppelportal ist "close enough". Danke Gmd

Mehr ein vorschlag als ein request. Bei der liste von features fuer mein steuerprogramm habe ich unter anderem features wie eingleisigem schattenbahnhof mit ein und ausfahrt, oder auch einer zeitverzoegerung im berg nachgedacht. Mit meinem programm kann ich das alles machen aber ich denke es kommt allen zugute wenn das depot eine variante bekommt. Einfahrt an einer seite, ausfahrt an der anderen. Damit lassen sich lange fahrstrecken simulieren, zweiseitige schattenbahnhoefe und anderes. Vielleicht weiss ich ja etwas nicht und das deport kann das schon, dann lass ich mich gerne belehren. Gruss Gmd

Hallo, Ich habe ja nichts inhaltliches beizutragen zu diesem thread kann mich aber einfach nicht zurueckhalten mal einen post hier abzusetzen. Ueber die jahre habe ich etliches in Solidworks (3dCad) modelliert und danach in realitaet gebaut. Solidworks ist auch nicht gerade simple, aber blender "intimidated' mich immer noch. Weiss gar nicht mehr was das auf deutsch heisst. Ich muss einfach sagen dass ich eure geduld und ausdauer mit diesem modellbau total bewundere. Irgendwann werde ich vielleicht mal die motivation aufbringen da weiter hineinzuschauen. Ich habe mit interesse alle 16 seiten dieses threads gelesen, und man kann da eine menge lernen und die reise beginnen in der Klartexter schon weit fortgeschritten ist. Well done. Und noch ein wort zu den unglaublich detaillierten beitraegen von unermuedlichen unterstuetzern, insbesondere BahnLand. Maechtig beeindruckt von der grosszuegigkeit und ausdauer mit der ihr neueinsteigern helft. Vielen dank fuer die vielen guten informationen. Gruss Gmd

Neujahrsgruesse fuer alle auch aus Australien, alles Gute fuer 2025 und auch von unseren derzeitigen Nachbarn . Gmd

Vielen Dank fuer die vielen schoenen modelle. Gruss Gmd

Hallo nochmal im alten Jahr, mein naechster schritt: Fuer verschiedene funktionen benoetige ich kleinere, definierte anlagenteile und nicht immer das gesamte bild. Ein beispiel sind die abschnitte im stellpult (siehe oben). Diese sind mehr fuer den betrieb gedacht. Ich habe aber auch funktionen, die auf die gestaltung von teilen der analge wirken. Beispiel: Ein Laubwald, in einem bestimmten teil der anlage, soll langsam von Sommer nach Herbst umgewandelt werden. Ein modul der anlage soll complett dynamisch ersetzt werden. In einem teil der anlage (z.B. vor einem bahnhof) soll der fussgangerbetrieb tageszeitbedingt ersetzt werden. Objekte in einem teil der anlage sollen auf ebenen aufgeteilt werden. Ein wanderzirkus soll auf verschiedenen teilen der anlage auf- und abgebaut werden und zwischen den standorten transportiert werden. Baustellen sollen eingerichtet und wieder abgebaut werden. Ebenen sollen ein/ausgeblendet werden. usw. Fuer gestaltungsbedingte einteilung habe ich area und segment. Area ist eine teilanlage mit klaren, nicht zu vielen verbindungen zu anderen teilen. Segmente sind teile von areas mit bestimmten bedeutungen/funktionen und koennen, mussen aber nicht, einen gbs abschnitt darstellen. Um diese aufteilung effizient zu definieren und auch gleichzeitig alle objekte innerhalb eines teils zu finden bedarf es weiterer automatismen, sonst wird das muehsam. Ich verwende benannte Fluchtstaebe, um die ecken einer Area zu definieren und kann diese einlesen. Ich verwende ein layout bild wie oben als hintergrund eines diagramms und kann dann die areas als polygone zeichnen, basierend auf der position der fluchtstaebe. Die koordinaten werden transformiert zwischen dem diagramm in der analage und damit kann ich alle objekt innerhal einer area finden. Gleiches kann innerhalb der areas fuer segment geschehen, ich kann aber auch umgekehrt im diagramm segmente festlegen, wenn einmal die koordinaten des diagrams in bezug auf die anlage festgelegt sind. Gruss und alles gute zum neuen Jahr Gmd

Hallo aus Australien, Hoffe alle hatten gute Festtage und etwas zeit zum spielen . Wir hatten den kaeltesten 24ten Dezember in Perth seit Aufzeichnung, 23 Grad. Auch hier im Sueden, wo ich mich zur zeit aufhalte, aber da ist es ja sowiso kuehler, aber auch hier war es ein Record. Zwei tage vorher waren es 43 Grad in Perth. Ist halt ziemlich weit weg von Deutschland . Weihnachten bei 42 Grad is halt schwer vorstellbar wenn man auf der Norhalbkugel lebt. Ich habe immer mal etwas zeit un habe an meinem programm weiter gebastelt. Zunaechst mal am Gbs, allerdings habe ich ja nicht vor damit den verkehr zu steuern, sondern nur zu ueberwachen. Noch ein paar kleine kosmetische aenderungen muessen gemacht werden, dann gehe ich and die automatische streckenerzeugung basierend auf den erkannten bloecken. Eine manuelle nachbearbeitung is natuerlich moeglich. Ich sehe derzeit nicht dass ich das layout vollautomatisch erstellen kann, jedenfalls noch nicht in naechster zeit. Die referenzen zu den aktuellen gleisen, weichen und signalen werden dann automatisch erzeugt. Die farben bedeuten derzeit noch nichts, dahinter verbergen sich verschiedenste einstellungen, die dann zur visualisierung der zustaende verwendet werden. Zugnummern anzeigen usw. koennen gesetzt werden. Meine grosse Anlage laesst sich damit nicht wirklich vernueftig abbilden. das GBS wird einfach zu gross und unuebersichtlich und macht ja auch nicht wirklich sinn, da ja lange strecken nicht wirklich ein gbs brauchen, sondern nur teile and die verzweigter sind. Das fuehrt dann zu einer abschnitteinteilung, die jeweils einen relevanten abschnitt darstellt und moegliche teilabschnitte als detailsichten. Die verkuepfungspunkte im bild oben verbinden dann zum naechste abschnitt, falls vorhanden. Fuer die definition von abschnitten und ihrer beziehung untereinander habe ich ein eigenes diagramm gebaut. Bilder von der anlage sind vorbeitet und als abschnitte und teilabschitte vorsortiert. Diese koennen geladen und verknuepft werden und dienen dann im betrieb zum schnellen zugriff auf die gleisbilder und die zugeordneten fahrplaene falls vorhanden. So allmaehlich habe ich alle grundfunktionen und anzeigen fertig. Als naechstes geht es dann mehr und mehr and die tatsechliche erkennung und definition einer anlage. Bisher habe ich nur mit testdaten gearbeitet. Das ganze ist aber immer noch eine mehr experimentelle entwicklung, da ich immer wieder auch teile verwerfe, die mir nicht gefallen oder unpraktisch sind. Ich probiere funktionen aus und wenn sie mir gefallen, nehme ich sie ins konzept auf. Mit einer kommerziellen entwicklung ist das anders, das arbeitet man mehr direkt auf ein ziel hin. Alles gute zum neuen Jahr Bis bald und gruesse Gmd

Definitiv langsamer, und auch das laden dauert laenger, was nicht so entscheidend ist. Meine monster anlage die ich gelegentlich zum testen meiner software benutze laeuft nur noch mit 6 fps V8 mit 12 fps. Zugegeben sie ist gross, 60,000+ objekte, 30+ zuege. Das ist zu langsam. Ich kann nicht wirklich beurteilen welche moeglichkeiten Neo hat, da ich zuwenig ueber die grafik engine weiss, aber ich vermute dass er noch nicht am ende ist die neuen gpus zu nutzen. Ich habe keine problem eine 4090 in den rechner zu setzen, wenn ich weiss dass sie auch voll genutzt wird, was ich derzeit bezweifele. Ich hoffe auf verbesserungen in den naechsten versionen. Bis ich meine software einsatzbereit habe ist das sicher der fall , aber das nuetzt dir ja nicht so viel. Optimierungen oder aenderungen an grundsaetzlichen funktionen sind immer ein problem mit solch umfangreichen programmen, das will gut ueberlegt sein und auch nicht immer moeglich. Ich bin sicher Neo hat schon darueber nachgedacht und ist sich der tatsache bewusst. Gruss gmd