Beiträge von romzac256

    Letztendlich bin ich in der Altstadt und sehe rundum nur das Gebirge.

    Das "weisst" zwar du - aber auch erst nachdem die hingeguckt hast. Der Computer muss die Sichtbarkeit halt immer erst berechnen - und zwar bei jedem Frame. Was wäre, wenn du dich aufwärts bewegst, und irgendwann die Plattenbau Dächer sichtbar werde? Zwar nur ein stück, aber generell sichtbar. Ich nehme an, dann möchtest du nicht darauf verzichten? Im Übrigen glaube ich nicht, dass die Leute von EEP die Renderreoutine komplett selber geschrieben haben. EEP wird sich auch eines Frameworks wie DirectX/OpenGL zum rendern bedienen. Und die werden schon weltweit wissen, was sie für eine gute Grafikausgabe brauchen. ;)

    Nicht Meine Bahnwelt,aber die US Modelle sind 1A gestaltet:be_1::bp_1:

    Also alleine dafür lohnt es sich, mit US anzufangen ;)

    Äh, noch eine Frage zu Texturen: dh alle anderen BISHER auf Modellen verwendeten Firmen (Dhl,Maersk, Evergree , Fedex, etc. etc) sind genehmigt? Was würde eine Firma dazu bringen, mal dafür und mal dagegen zu entscheiden?*
    Ich hatte mal gedacht, Trend holt eine Allgemein-Lizenz für das Spiel ein, die dann alle Kons bei ihrer Entwicklung benutzen dürfen? Es ist ja total umständlich, wenn jeder Kon einzeln anfragen muss.
    Na gut, so ist es halt zz.
    Merci und guten abend :)

    Andere Graka kaufen ;)

    Das ist wirklich eine super geniale Anlage!
    Ich komme aus dem EN Kreis, und habe vor ein paar Jahren bei der extraschicht Im Ruhrgebiet die Zeche persönlich erlebt.
    Höchsten Respekt dafür! <3

    Dürfte ich aus Interesse fragen, was die für ein roter Güterwaggon ist, der mit 6 Rohren beladen ist?
    Im Shop kenne ich nur die kbs442, wo man entweder 3 oder 4 Rohre als Ladegut per Schieberegler aktivieren kann.
    Würde mich freuen wenn mir jemand das Shop Set zu den 6 Rohren verraten, vielen Dank:
    Entlang der Ruhr Zeche Nachtigall Stahlwerk

    Ich hoffe dass es wirklich nur an der Registry Einstellung selber liegt.
    Wie ich lese hast du eine Radon Grafikkarte. Seit irgendeiner Traberversion in 2020 gab es damit auch Problem. Ich hatte das damals in 2020 sehr lange hier rum gefragt, bis es irgendwann als Problem bewiesen und anerkannt wurde. Danach gab es Version 16 den Patch 3 (oder 4?), und nach dem Patch ging es tatsächlich. Damals hatten recht viele Leute mit einer Radeon dieses Problem.

    Ich hoffe Trend hat von damals gelernt, und den richtigen Source Code mit nach Eep17 übernommen ;)

    Ja genau, das hier ist auch ein schönes Beispiel, für genau das gleiche Grundproblem. Wenn die Länge zumindest bei der "Eingabe" unbeschränkt wäre, würde das alles in einem Rutsch fluppen <3

    Nabend nochmal. Naja, also Ich habe oben nicht alle Kommentare ganz verstanden, aber:
    1. ja genau, das Ergebnis von Cubic Splines ist seeehr sub optimal.
    2. Ich möchte einen "gleichmässigen" langen Bogen bauen, mit nur wenigen Grad Winkel, aber über eine langen Weg, 1-2km, um an einer ganz bestimmten Zielstelle raus zu kommen. Dafür gebe ich im Arc zb zuerst "+5" Grad ein. Dann klicke ich 10x auf vorwärts kopieren, und sehe dass ich nach 1 Kilometer nicht an der richtigen x/y Stelle raus komme. Also 10 Gleise löschen, diesmal probiere ich es mit 4 oder mit 6 Grad, je nachdem ob ich links oder rechts daneben war. Also neues Gleis wieder 10x kopieren. Nun ein bisschen zu weit in die andere Richtung. Nochmal 10 Gleise löschen, diesmal mit 4.5 Grad oder 5.5 Grad probieren. Ok, so langsam komme ich da raus wo ich hin wollte.

    Jetzt kann man natürlich den Taschenrechner bemühen, und aus der Differenz von x/y/z Koordinate das Bogenmas ermitteln, und dann daraus mit Arcus-Sinus/Cosinus/Tanges-Hyperbolikus den Winkel direkt ausrechnen. Das ist aber genau das Gegenteil von einer "automatisierbaren" Lösung :)
    3. wenn ich Fluchen wollte, würde ich Fluchwörter wie "foxdevilswild" benutzen :P
    4. die Frage ist schon realistisch: offensichtlich kann der EEP code eine komplizierte Cubic Spline Interpolation ausführen, aber er kann nicht 1000m durch 120m teilen um dadurch innerhalb von einer Code Schleife 8 ganze und ein 9tes Stück mit 40m zu generieren?
    5. es geht hier nicht zwingend darum was Bahnbauweise/"Realität" ist. Es geht darum, wie die Software bei der Erstellung eines Virtuellen Modells "unterstützen" kann. Es geht darum die "Eingabe" zu vereinfachen - das Ergebnis/die Ausgabe/das Gleis darf weiterhin auf 120m beschränkt bleiben.
    (kleiner Exkurs: ich kann ein Gleis auch um 180 Gard um sich selbst verbiegen, so dass der Zug danach auf dem Kopf steht. Runter fallen tut er aber trotzdem nicht. Er klebt an der Spline. Entspricht das der Bahnbauweise? :S )
    6. hier das Wort "Bitte" ausgeschrieben :saint:

    Ach kommt Männers, das ganze hier ist "Software", die wächst Stück für Stück, irgendwann wird es schon soweit sein 8)
    Cheers und Gute Nacht

    Ich würde mir einfach wünschen, wenn die Gleislänge im Eingabefenster nicht mehr auf 120m beschränkt wäre.
    Man sollte einfach 1km / 1000m eingeben können, und dann wird das Gleis dahin gelegt.
    Kann doch im 3ten Jahrtausend nicht so schwer sein ?
    Dass man immer noch an diesen 120m festhält, phhhttt 8o

    romzac256

    Vielen Dank für deine Bildkommentare. Man probiert halt alles mal aus, ob draußen in echt, ob in EEP oder im Modellbahnzimmer.

    Ich glaube kaum, dass andere Modellbahnsoftware dieses Vergnügen bietet.

    gerne gerne. Eep bietet natürlich unendlich viele Möglichkeiten, aber ich kann nicht jedes der täglichen 1000 Fotos bewerten. Es hängt davon ab, was mir die Zufallsfunktion unter neue Bilder gerade in der aktuellen Minute anzeigt. Und wenn ich dann durch sie "strukturelle Harmonie" des Bildes so angetan bin, lasse ich das auch gerne wissen.

    bezüglich der ganzen Performance Problemen hätte ich auch einen Vorschlag, der mir bei meiner eigenen Arbeit am Laptop - leider ohne 3D graka - gekommen ist.
    Viele Modelle liegen ja heutzutage in mehreren LOD Stufen vor. Allerdings ist die Entfernung, ab der die LOD Stufen runter skaliert werden, wohl hart ein compiliert im Modell. Meisten erst ab einer Entfernung von X 100en Metern wird die Anzahl der Dreiecke reduziert. 300, 500, 700 meter, was auch immer.

    "Aber" was spricht denn dagegen, auf leicht betuchten Pc/Laptops, nicht schon VIEL FRÜHER eine andere LOD Stufe zu starten ? Ich selber möchte auch gerne im Urlaub am Laptop an meiner Anlage bauen und planen - auch im 3D Modus, um die Objekte korrekt zu positionieren. Für diesen "Baumodus" könnte ich vorübergehend sehr gut auf LOD0 verzichten, und auch direkt in nächster Nähe Lod1, lod2, Lod3 akzeptieren. Erst wenn ich wieder zu Hause bin, würde ich die Anlage auf der 3D graka wieder mit Lod0 befahren.

    Ich fände es super, wenn man die Entfernugsstufen für die LOD Umschaltung frei definieren könnte.
    Danke und gute Nacht.

    Zitat

    Das Sortieren von zigtausenden Flächen nach ihrer Entfernung ist verdammt viel Arbeit! Deshalb arbeiten die meisten Rendering-Engines ohne Sortierung und "zeichnen einfach drauf los". Das ist im Normalfall immer noch performanter, als wenn alles erst sortiert würde.

    Naja, laut Shop Beschreibung haben einige Modelle ja mehrere Tausend Eckpunkte. Ob sich "einfach drauf los zeichnen" wirklich lohnt, wenn es am Ende doch verworfen werden kann, stelle ich mal dezent in Frage - auch wenn ich es weder für / noch gegen Beweisen kann.

    Um nochmal auf die "Schlauheit" zurück zu kommen. Ich würde als Tick mehr Meta-Informationen für ein 3D Objekt vorschlagen, zb diese angesprochene "Box". Wenn man den "Schwerpunkt" eines Objekt kennen würde, welches der Homnos oder irgendeine Art "Compiler" einmalig beim Bauen feststellen kann, und dazu die weiteste mögliche Entfernung einer der äußeren Punkte, dann könnte man sehr schnell logisch schließen: "falls Schwerpunkt z-Koordinate plus maximaler Radius-z-Koordinate KLEINER gleich Wand-z-Koordinate" dann schmeiße das Objekt direkt weg.
    Da der GRÖSST mögliche Radius des Objekts, die "Box" / die Sphäre verglichen wurde, können alle anderen Punkte - innerhalb des Radius/der Box/der Sphäre - nur noch weiter weg sein. Es lohnt sich gar nicht mehr alle einzelnen Punkte weiter zu untersuchen, wenn die Hauptbedingung erfüllt wurde.

    Allerdings sind Meta-Informationen jeglicher Art sehr Produktspezifisch. Wenn OpenGL / Directx nicht genügend "extra" Infos annehmen wollen, ist es natürlich egal, ob ein Homnos/Compiler irgendetwas im voraus bereit stellen kann.

    Ob die fehlende parallele CPU Nutzung hier etwas bewirken kann, kann ich nicht beurteil. Dafür müssten wir ja wissen, ob die Occlusion auf der CPU oder in der GPU ausgeführt wird. Ansonsten hätte ich gedacht, die CPU berechnet die "Spielregeln". Also neue Zug-x-y Koordinate = alte x-y Koordinate + Spline-Vector-Richtung mal Geschwindigkeit. Diese "Spielregel" wird höchstwahrscheinlich nicht in der GPU sein.

    Naja, wie auch immer. Ich kann es auch nicht besser. Aber ich wäre tatsächlich bereit, für ordentliche Leistung mal etwas an Trend zu zahlen. Nicht für 10-70%, das ist Pillepalle. Aber angenommen E18 schafft mal nen Sprung von 200-300 % Performance. Dafür könnte ich zB gerne bis 99 eur ausgeben. Aber die Performance muss sich dann auch beweisen lassen, und nicht mur ein Marketingspruch sein ;)

    Also ich weiss zwar nicht wie EEP intern arbeitet, aber "früher" hatte mir die ct Zeitschrift erklärt, es gäbe mindestens 2 Ansätzen:
    1. feststellen welches 3D Objekt überhaupt gerendert werden muss. Das alleine geht durch vergleichen der "Normalen" (= aktuelle Blickrichtung), mit den Eckpunkten der 3D Objekte. Danach können alle Ecken -> Kanten -> Flächen nach ihrer Entfernung vom Sichtpunkt sortiert werden. Und nun sollte die Grafikengine clever sein: komplett verdeckte Flächen können nun direkt verworfen werden, weil sie in der aktuellen Blickrichtung gerade eh nicht sichtbar sein werden.

    2. das "Rendern" der Grafik auf den Screen. Erst ab jetzt kommen die Texturen ins Spiel, die irgendwie gedreht, gestreckt, gestaucht werden müssen. Ebenso Schatten, BUMP Effekte, AntiAliasing, und das angleichen mit der Wiederholfrequenz des Monitors.

    Da die Menge an Grafik die der Benutzer am Ende mit dem Auge "sieht", zwischen Bild 1 bis Bild 4, nur gering zunimmt, aber die Performance stark einbricht, vermute ich ein Problem in Teil 1 der Berechnung. Irgendwie müsste der Algorithmus besser Optimiert werden. Wenn eine Hauswand vor mir 90 % des Screens verdeckt, sollte man sich gar nicht mehr erst Fragen, ob die Objekte "dahinter" LOD haben oder nicht. Egal wieviel Lod, sie werden nicht gerendert. Und das sollte auch unabhängig von "ab 750m" sein !

    Weiss denn jemand, ob diese Sortierung nach Entfernung von der CPU oder der Graka chip ausgeführt würde?
    Mein 2. Punkt oben repräsentiert "Arbeit", aber der 1. Punkt ist "Schlauheit" ;)

    Vielleicht gibt es mehrere EEPer, sowie ich, die verschiedene Anlagen haben die sie verbinden moechten und nicht direkt in einer Linie oder einem Winkel von 90 grad.

    Das kann ich zu 100% unterstützen, so etwas habe ich auch schon gelegentlich versucht. Ich persönlich würde einen Modul Editor bevorzugen, wo man mehrere Puzzle-Teile (Anlage) mit der Maus fließend um einander herum bewegen kann. Ob in dem Moment des Abspeicherns die Gleise exakt anschließen, sollte jedem selber überlassen sein. Wenn nicht, einfach später die finale Anlage manuell nachbearbeiten, mit den Gleisverbindungs Funktionen.

    und noch eine extra Funktion bitte: es wäre ein kleines Träumchen, wenn man nachträglich auch die z-Höhe eines Moduls verändern kann, bevor man es mit den anderen Modulen verbindet. Einige Szenen, die zb in den Bergen spielen, wirken noch besser, wenn das entsprechende Modul höher als das Flachland drum herum liegt. Danke vielmals.

    Irgendwo weiter oben stand in irgendeinem Kontext, es möge jedem User selber überlassen werden, wie er/sie/es sein System/Grafikkarte belastet. Dem möchte ich mich gerne mit einem weiteren Punkt anschließen: der mir unter Eep16 noch aufgefallenen weitesten Render-Entfernungs Beschränkung von ... öhhhmm... 2km glaube ich!
    Ich weiss nicht wie diese Grenze entstanden ist. Wahrscheinlich weil der Hersteller "Angst" hatte, dass eine langsame Grafik ihm direkt angelastet wird - anstatt dass der User erkennt, dass ein langsames System vollständig in seiner eigenen Hand liegt - und deshalb diese 2km Render Tiefe als Reputations Notlösung gefunden wurden.

    Ich habe sogar ein Beispiel wo mir das richtig aufgestoßen ist: als ich nach meinem Kanada Urlaub letztes Jahr die Spiral-Tunnels modellieren wollte, inklusive ca. 4km langem Zug zum durchfahren. In Kanada konnte ich vom Berg aus bei klarem Wetter den 4km langen Zug komplett sehen - aber im EEP 3D Fenster wurde es halt irgendwann ausgegraut / ausgenebelt.

    Da ich die Mehrheit der User für clever genug halte, und heutige aktuelle Grafikkarten echt ne Menge hergeben, würde ich mich freuen, wenn Render-Tiefe nicht im System hart codiert wird, sondern frei konfigurierbar dem User bleibt. Gruß.