VisualZusi

[Carsten Hölscher]

Den Ansatz eines "dummen" eigenständigen Programmes ist m.E. nicht zielführend:
- Es ist grundsätzlich kein sinnvoller Designansatz, die ganzen Grafikdaten auf niedriger Ebene über so eine Schnittstelle zu übertragen. Ein Ansatz wie bei einem Mehrnutzersystem erfordert aber eine Nachprogrammierung der Zusi-Logik in erheblichem Umfang
- Wenn es gut handhabbar für die Add-On-Entwickler sein soll, muss auch der 3D-Editor mit der Schnittstelle ausgerüstet werden, damit der Bastler direkt sieht, was er baut. Diese Nutzerschnittstelle ist aber durch diverse interaktive Funktionen sehr komplex und kaum sinnvoll in ein externes Programm zu übertragen.

Also diesen Ansatz wird es definitiv nicht geben.

Einzig sinnvoller Ansatz wäre die Einbindung einer engine auf dem normalen Weg. Es kann gut sein, dass die Lage inzwischen anders aussieht als vor einigen Jahren als ich die Entscheidung zu treffen hatte.
Also wenn jemand etwas in der Richtung für Zusi 3.x zu meiner Entlastung bewirken möchte, dann könnte er mal den Stand der Dinge recherchieren bezüglich Einbindung in Delphi. Es muss nicht zwingend Freeware sein, wenn die Bedingungen passen.

Carsten

[Stephan/Taschi]

leute das wär ne Grafik

http://www.youtube.com/watch?v=qkgK1aUJ ... re=related" target="_blank

ps3 hab ich.. nur das game kostet 100€

*hust* Das ist, soweit ich das sehe, auf Videobasis (vergleichbar mit diesen lustigen Flashgames, die es auch aus Japan gibt, deren Name mir aber gerade entfallen ist). Für eine betrieblich akkurate Simulation ist das viel zu unflexibel, da sich Fahrstraßen, Signale und Gegenzüge nicht dynamisch generieren beziehungsweise stellen lassen.

[MichaelT]

An der Stelle darf ich mal mein ganz allgemein gehaltenes Statement abgeben:

Ich finde die Grafiken der aktuellen Spiele (hier ein Shooter) sehr schön. Insbesondere von der CryEngine bin ich begeistert -hier zeigt sich eine erfolgreiche deutsche Softwareschmiede.
Nun gehen auch die Simulationen mit dem Trend zu besseren Grafiken. ABER:

Welchen Nutzen habe ich davon? Bringt es mir etwas, wenn ich mit ~100 km/h die Kieselsteine auf den Texturen erkennen könnte? Von Fahrten mit dem ICE mal ganz abgesehen.
Bringt es mir etwas, wenn ich die schönen Licht/Schatten/Wettereffekte betrachte und mir ein Zugsicherungssystem eine Zwangsbremsung reinknallt, weil ich nicht aufgepasst habe?
Ich finde, das lohnt sich höchstens bei Rangierfahrten oder im Stillstand. Natürlich kann ich mal eben die Realismuseinstellungen auf "Einfach" stellen und damit 80% dessen was die Simulation ausmacht "Ade" sagen und es fortan "Spiel" nennen, aber dafür brauche ich keinen Simulator.

Von daher, schön wenn man es hat, aber notwendig finde ich es gerade mit der doch sehr ansehnlichen Zusi 3 Grafik nicht.


Noch kurz zum Thema Trend: Ein ganz bekannter Flugsimulator, der bald auf dem Markt erscheinen soll, zeigt übrigens haufenweise Screenshots von wunderschönen Bodenobjekten... erste Sahne, wenn ich in einer Höhe von 18.000 Fuß und etwa 800 km/h darüber hinweg fliege.

[ThSchulz]

leute das wär ne Grafik

http://www.youtube.com/watch?v=qkgK1aUJ ... re=related" target="_blank

ps3 hab ich.. nur das game kostet 100€

Und was ist, wenn du an einer Stelle wo man normalerweise 300 fährt dann mit 40 langschleichst? Dann dürften die Gleise und alles drum herum sehr matschig aussehen, da du dich bei der Simulation ja nicht selbst bewegst, sondern nur der Film der Führerstandsmitfahrt schneller oder langsamer wird. Aber die Idee dahinter finde ich bis Heute genial!

[Arne M]

Nja schade wenn ich niemanden überzeugen kann.

Einzig sinnvoller Ansatz wäre die Einbindung einer engine auf dem normalen Weg

von mir aus, wenn das selbe bei rauskommt ^^
Ich bin nur stark interessiert an einer angemessenen Grafik und würde es dafür auch ganz alleine machen.
Doch damit ich hier helfen kann braucht es eben die möglichkeit in C++ zu arbeiten. (kann auch innerhalb von zusi passieren in einem "C++ kompatiblen raum" ) mal abgesehen davon, dass die existenz einer gescheiten "delphi-engine" unwahrscheinlich ist.
Und wenn ich dabei nicht helfen kann müssen die ressourcen dafür wo anders abgezogen werden und da hab ich halt so meine ängste:
1. es wird wahrscheinlich von vielen zusianern für zu unnötig abgetan und die dafür notwendigen ressourcen als zu wertvoll für andere projekte erklärt.
2. Es wird zwar irgendwie gemacht, aber halbherzig und dann kommt wieder das "was willst du? is doch ok"-argument (weil eine delphi-engine evtl nicht mit ihren für c++ erhältlichen kollegen mithalten kann)
3. Es stellt sich in der to-do liste soweit hinten an und/oder seine implementierung dauert so lange dass bei inbetriebnahme es auch nicht mehr wirklich beindrucken kann.
4. In ein paar jahren ist es wieder out, eine überarbeitung muss her und es heisst "nein, den stress machen wir nicht nochmal"

Es ist grundsätzlich kein sinnvoller Designansatz

natürlich nicht , aber lieber einen riesen umweg gehen, als gar nicht ans ziel zu kommen.

Abschliessend kann ich nur nochmal meine hilfe anbieten und betonen, dass grafik auch die attraktivität von Zusi erhöht, dass dürfte vor allem für jmd interessant sein, der es an geschäfliche kunden verkaufen möchte und damit seine brötchen verdient.
Mal abgesehen dürfte auch Otto-normalverbaucher ( der sich ja bekanntlich nicht mit zusi anfreundet ) seinen gefallen finden.
Grafik ist in der breiten gesellschaft leider nunmal ungemein wichtig.
Ähnlich wenn ich beim autokauf für ein premiummodell zahle. Bequem sein und fahren tut auch mit billig stoff, aber die dicke lederausstattung wird trotzdem irgendwie erwartet.

grüße
arne

[Arne M]

Da fällt mir noch spontan genesis ein, die hat als hauptstrache delphi7

http://www.genesis3d.com/" target="_blank

sie ist open source, verspricht aber nicht viel und dürfte noch den stand haben, als du dich gegen eine engine entschieden hast

[Carsten Hölscher]

Nja schade wenn ich niemanden überzeugen kann.

Der Ansatz ist halt nicht wirklich sinnvoll.

Mit entsprechenden Wrappern sollte man doch jede Engine mit Delphi-Schnittstellen versehen können, oder? Das wäre dann die Tätogkeit, die hier gebraucht würde.

Carsten

[Roland Ziegler]

Jede "Engine", oder IT-mäßig allgemeiner ausgedrückt: "Middleware" hat die Aufgabe, elementarere Vorgänge in einer tieferen Ebene zu kapseln und in vereinfachter, gebündelter Form auf höherer Ebene anzubieten. Das ist dann besonders effektiv, wenn die Art der Anwendung bestimmten Mustern folgt und genau diese Muster in der Engine implementiert werden. Passen die Muster nicht zur Anwendung, nützt die "Engine" wenig. Middleware wird daher häufig als Säulenmodell mit Querstreben konzipiert, moderner Begriff "Framework". Ein solches Framework erlaubt den vertikalen Durchgriff, falls die höheren Ebenen nicht wirken. Einigermaßen uninteressant wird es dann, wenn der vertikale Durchgriff mit hinderlichen horizontalen Abhängigkeiten verknüpft ist. Das muss nicht schlechtes Design bedeuten, es kann schlicht sein, dass das Framework von anderen Anwenderanforderungen ausgegangen ist.

Was auf den ersten Blick dramatische Vereinfachungen zu versprechen scheint, kann sich bei näherem Hinsehen durchaus als größere Bürde herausstellen. Es hat schon seinen Grund, dass Eisenbahnsimulationen bislang ihre Zugriffe auf die 3D-Hardawre noch immer direkt, bzw. über eigene Engines bewältigen, einzelne Ausnahmen bestätigen die Regel.

Recht spannend war der sehr ehrgeizige Ansatz von MSTS 2 (jener Versuch von MS selbst, nicht der davor von Kuju). Man hatte vor, die Engine des Flight Simulators zu adaptieren, die durch ihre dynamische Terrain-Auflösung brillierte. Der Algorithmus dazu wich fundamental ab vom dem, was Graphics-Engines typischerweise lösen. Ein wesentlicher Aspekt bei der graphischen Darstellung einer Eisenbahnsimulation ist die Tiefe des Raumes. Natürlich will man den Gegenzug schon in weiter Ferne erblicken. MS glaubte, darauf eine elegante Antwort zu haben. Das Ergebnis können wir leider nicht begutachten, da das Projekt bekanntlich eingestellt wurde.

[Arne M]

Mit entsprechenden Wrappern sollte man doch jede Engine mit Delphi-Schnittstellen versehen können, oder?

mhhh... wenns geht? warum nicht. wäre bereit mich auch in sowas einzuarbeiten.

@Roland

Was auf den ersten Blick dramatische Vereinfachungen zu versprechen scheint, kann sich bei näherem Hinsehen durchaus als größere Bürde herausstellen. Es hat schon seinen Grund, dass Eisenbahnsimulationen bislang ihre Zugriffe auf die 3D-Hardawre noch immer direkt, bzw. über eigene Engines bewältigen, einzelne Ausnahmen bestätigen die Regel.

Da hast du natürlich recht!
Ich fasse deine beschreibung nochmal auf:
In dem fall einer grafik-engine soll unsre middleware für uns die umsetzung der naturgesetze übernehmen. Dazu benötigt sie eine genügende beschreibung unserer scene. Da diese naturgesetze (fast ) überall im universum gültig sind, ist die notwendige schnittstelle theoretisch überall gleich und kann sich auf wenige und sehr ähnliche informationen beschränken.
Die sache hat nur einen haken: keine hardware ist leider fähig die naturgesetze im vollen umfang zu berechnen, das bild ist also leider unvollständig. In der regel begnügt man sich damit. Doch an manchen stellen fällt es aus irgendwelchen gründen nunmal auf. Um das im spezialfall dennoch speziell zu regeln muss man schummeln. Und nun sind extra informationen notwendig, die einer weiteren "säule" oder einem quereinstieg bedürfen um eine damit verbundene korrektur des "Fehlers" durchführen zu können.
Da die hardware immer leistungsfähiger wird, kann die schnittstelle bei gleichbleibendem anspruch theoretisch kleiner werden.
Aus diesem grund bin ich mir sicher, das eine engine heutzutage unseren anspruchen genügen könnte! aber wir werden es nie herausfinden solang WIR ES NICHT MAL ÜBERPRÜFEN und über das könnte, könnte nicht diskutieren.
Hinzukommt, dass carsten viele wichtige elemente einer perfekten "eisnbahn-engine" schon implementiert hat, die man vlt auch weiterhin nutzen könnte.

Wie auch immer ich präsentiere jetz einfach mal die heissesten kanditaten:

OGRE:
Ogre hat die größte community aller freien engines, sie konnte deswegen schon immer sehr viel und immer ein bischen mehr als irrlicht.
bemängelt wird, dass sie leider deswegen auch sehr zugemüllt ist und nur in bestimmten populären bereichen wirklich gut ausgeprägt ist. wenn auch, so heisst es, der code tief in ihrem inneren als sehr profellsionell gilt und sie ( know how vorausgesetzt ) gut erweiterbar ist.

Irrlicht:
Irrlicht hat die wohl klarste schnittstelle. ihre haupt architektur gilt als sehr gut und aufgeräumt. Die community ist ebenfalls sehr groß.
aufgrund ihrer einfachheit gilt sie als sehr gut erweiterbar. leider kann sie nicht ganz so viel und liefert oft nur das notwendigste. das ist eigentlich auch gewollt, denn so unterband man den kunkurezkampf zu vieler unterschiedlicher lösungsansätze. dafür existieren viele versionen, die von ihren besitzen speziell für sie selbst auf einem TOP niveau sind und man seine persönliche irrlicht engine hintenrum gut mit deren stoff auf seine wünsche "pimpen" kann.

(ein guter weitere kandidat wie ich finde)
OpenSceneGraph
bisher weniger bekannt, doch wohl sehr gut und stark im kommen. wird wohl hauptsächlich von flight gear (der open source antwort auf MS flightsim) benutzt und tummelt sich vorallem in der ...ACHTUNG: simulationsszene!! und bedarf deswegen genauerer betrachtung.
im hinblick auf rolands beschreibung über microsofts ansatz dürften uns die jungs von flight gear wohl sehr interessieren. und
das finde ich wirklich beindruckend:
http://www.youtube.com/watch?v=8XVvsdt4Sts

zum schluss möchte ich noch hinzufügen:
Irrlicht hat wohl leider als einziger ein delphi parsersystem.

also, lasst uns das mal prüfen, all unsre ansprüche sammeln und dann doch mal einen virtuellen stresstest veranstalten.
Vlt sind wir ja ganz zufrieden...

arne

[Arne M]

wens interessiert: google trends
http://www.google.com/trends/?q=++++Ogr ... all&sort=0" target="_blank

[Carsten Hölscher]

Bitte wende mal richtige Groß-/Kleinschreibung an, das ist so doch nicht wirklich gut zu lesen.

Zu den wichtigsten Anforderungen: Es müssen große Gelände in UTM-Koordinaten effizient verwaltet und kontinuierlich geladen werden können. Das Gelände muss aus flexiblen Koordinaten gebildet werden können (keine Heightmap im klassischen Sinn). Man muss auch den Editor darauf aufbauen können. Lieber DirectX als OpenGl. Es muss möglich sein, eigene bahnspezifische Daten im Datenformat zu ergänzen.

Wie sieht es denn mit der crysis-engine aus?

Carsten

[Arne M]

ok....lieber Dx als OpenGl......
Meistens können Engines beides.

Zu den wichtigsten Anforderungen: Es müssen große Gelände in UTM-Koordinaten effizient verwaltet und kontinuierlich geladen werden können.

uff... sowas hat eigentlich jede fast 3dengine. Nur mit unterschiedlichen Lösungsansätzen. Fast alle die ich kenne regeln das auf Quadtree /Octree-Basis. Fast alle nehmen ihre Informationen aus heightmaps und basteln sich daraus ein großes gelände mesh, dessen Vertex Abstände sich mit dem Näherkommen immer wieder halbieren (wenn in diesem quadrat vorhanden). Wenn man darin ein loch haben haben möchte, tut man dies meist über eine transparente Textur an der Stelle.
Ich glaube du denkst da halt stark an deine Einschnitte und Bahndämme. Eine sehr spezielle Lösung, die in der Regel einfach durch eine genügend hohe Auflösung an der Stelle gelöst wird. Es ist auch möglich einzelne Quadrate ganz auszublenden, wobei das nächst geringer aufgelöste Quadrat immer nur dann auch vollständig ausgeblendet wird, wenn 3 von 4 teilquadraten nicht besetzt sind. (So wurde es auch schon im MSTS1 gelöst, nur das die damals maximale Auflösung von 5x5m die Bahndämme schrecklich hat aussehen lassen)
Heutzutage klappt das eigentlich sehr gut, in Crysis zb liegt die Geländeauflösung vor deinen Füssen bei wohl fast 10cm. Dabei kannst du in den Hubschrauber einsteigen und ohne laden zü müssen ans andere Ende der fast 20km langen Insel fliegen.
Beachte: Nur weil du jetz scharfe Bahndammkannten haben möchtest muss noch lange nicht deine gesamte Heightmap so aufgelöst sein.Es genügt dass nur an den ensprechenden stellen die Auflösung so hoch ist. (Quadtree prinzip)
Dann gibt es je nach dem Intelligente "Entfernungs-Auflösungs" verfahren, die den winkel zum nachbarn berücksichtigen. (Kannten werden also später in eine niedrigere ebende aufgelöst als der rest)

Für deine spezielle Lösung wirst du also sehr wenig finden, ohne die Engine erweitern zu müssen, oder du verabschiedest dich von deiner jetzigen Lösung.

Zu dem ergänzen von Informationen ins Format:
Würde ich in der Regel nur in Notfällen machen, sondern eher die Zusatzinformationen in einer extra Datei auslagern. Mit den ganzen Tools, die es heutzzutage gibt kann sowieso alles auf der Festplatte zu einem großen, komprimierten etwas zusammengeschmolzen werden. Aber in jeder Engine gibt es ja grundsätzlich irgendwo eine Methode, die diese Datai lädt und liest! Finde sie und schreib sie um!
Wenn du also auch die Leistung deiner Lokomotive in die die *.3ds unten dranschreiben willst, so tus doch.

Zur CryEngine:
Ich kann nicht allzuviel zu sagen, habe nur mal ein bischen mit der SDK rumgespielt. Aber es ist in erster Linie eine "EierlegendeWollmilchsauMega200MillionenEuroSuperEngine" mit ihr braucht man vieles gar nicht mehr zu coden, sondern es gibt für fast alles eigene Tools usw. Es ist weniger eine Grafik-Engine als schon eine Game-Engine die alles bietet. Was die so kostet wenn man sie anwendet weiss ich nicht, ist aber mit Sicherheit nicht billig


was MSTS2 wohl glaub ich verwandt war sowas hier:
http://www.youtube.com/watch?v=k7Yn4F1d ... re=related

grüße arne

[Carsten Hölscher]

Das Geländeraster steht nicht zur Disposition, sonst reden wir von einer neuen Software.

Carsten

[Arne M]

Wenn du unbedignt so daran hängst, dann lass den Geländeteil in Zusi und übergib es der Engine Polygon für Polygon......

Deine Welt is ja auch nicht rund oder so, sondern leztendlich ein gewöhnliches karthesisches System.

Nja wie auch immer, ich möchte dir jetz auch nicht andauernd auf die Nerven gehen, vlt können wir uns bei nem Stammtisch nochmal ganz genau darüber unterhalten.

arne

[Carsten Hölscher]

Es hat nichts mit "Dran hängen" zu tun. Ist schlichtweg grundlegende Basis des Geländemodells und das muss passen, wenn was Vernünftiges bei rauskommen soll.

Carsten

[Roland Ziegler]

Das war einer der Punkte, die ich mit dem Säulenmodell ansprach. Die "Engine" geht möglicherweise davon aus, dass das Geländemodell bestimmten Mustern folgt, wie wir sie auch in manchen Büchern finden. Aber der dortige Entwurf ist weder der einzig mögliche noch der einzig sinnvolle. Und ruckzuck bricht eine ganze Säule der "Engine" weg. Gibt es zudem noch die erwähnten Querabhängigkeiten, bricht möglicherweise auch noch eine zweite oder dritte Säule weg und der halbe Tempel stürzt ein.

[Michael_Poschmann]

..., bricht möglicherweise auch noch eine zweite oder dritte Säule weg und der halbe Tempel stürzt ein.

Möglicherweise hat ja ein gewisser Samson Ziegler an den Stützen herumgefuhrwerkt...

Ich beobachte die Diskussion mit einem gewissen Interesse, aber natürlich fachlichem Abstand. Das ist weiterhin nicht mein Haupt-Schaffensgebiet. Angesichts der Projektarbeiten im Hintergrund gerade an diesem Wochenende möchte ich dennoch noch mal meiner Verwunderung Ausdruck verleihen, warum Energie in einigermaßen gelöste Probleme und sicherlich noch nicht ausgereizte Bereiche gesteckt werden soll. Hier droht das Rad neu erfunden zu werden. Stattdessen haben wir noch einen langen Hausaufgabenzettel vor uns - wie wäre es, sich diesen Dingen mit gleichem Elan zuzuwenden? Bitte nicht mißverstehen, ich möchte diese Diskussion keinesfalls wegdrücken, aber sie bindet dennoch nennenwert Energie und Schaffenskraft, auch an namhafter Stelle.

Gruß
Michael

[Arne M]

Gibt es in Zusi3 einen Wireframe Modus? Wie auch immer, ich schau mir das Geländemodell mal ganz genau an, vlt reden wir ja auch aneinander vorbei...... und beim nächsten Stammtisch reden wir nochmal ausführlich drüber.


Viele Engines beruhen auf dem SceneNode prinzip, dass heist ein SceneNode ist ein etwas, dass eine Örtlichkeit im Raum besitzt. Sie haben parents und childs und alle Typen sind in der Hinsicht mit einander verwandt und kompatibel. Diese verschiedenen Typen von SceneNodes haben alle untschiedliches Verhalten und Arten zu Rendern. So gobt es zb. Terrain SceneNodes, Octree, LODSceneNodes, Wasser, Partikel, Animiert.....Wobei viele wieder eine verwandtschaft mit anderen pflegen, so kann zum beispiel ein Animiert gleichzeitig ein LOD-SN sein.
Dieses System ist so gedacht, dass man in der Anwendung der Engine einfach neue machen kann und damit bis in die tiefen der Shader vordringen kann. ( Jenachdem wie weit man es braucht, stop ist bei einzelnen Polygonen, Vertex usw )
Theoretisch verstehe ich nicht, warum das also ein Problem darstellen soll. Praktisch...klar. Deswegen werde ich bei Zeiten mal Carstens Geländemodell verstehen lernen und eventuell mal versuchen es in eine Engine zu laden. (wenn carsten damit einverstanden ist) (vlt muss ich Roland oder dir mal die ein oder andre Frage stellen) aber durch das gelingt / gelingt nicht sind wir nachher auf jeden Fall schlauer.

Grüße arne

[Carsten Hölscher]

Das Gelände hat schon diverse spezifische Eigenschaften, die man irgendwie im Datenmodell berücksichtigen muss.
Die verschiedenen 3D-Objekte leiten sich aus einer recht abstrakten Basisklasse ab, das ist wohl bei Dir mit "Scenenode" gemeint?

Testdaten sind natürlich kein Problem.

Carsten