Rail Road Tycoon MFC in Action
-
Dieser Beitrag wurde gelöscht!
-
@Sternlicht4384 Hallo Sternlicht,
ja Du sagst es sehr schnell kann man mit so einem Riesenprojekt in die Eskalation wandern, ich bin dabei nun nichts neues hinzuzufügen, sondern die Stabilität und Prozesse innert der komplexen Vorgänge zu stabilisieren damit eine Veränderung nicht an anderer Stelle Auswirkungen haben kann muss alles in Aktionstiefen verankert sein die sich nicht gegenseitig berühren.
Zb. Das ein schneller Zug einen langsamen einholt, nun muss der rechtzeitig dessen Tempo übernehmen um nicht aufzufahren. Oder wenn ein Terminal(Bahnhof) bereits belegt ist, der Zug am Eingangssignal wartet bis der andere Zug das Terminal verlassen hat, da gibt es viele Szenarien an Signalen die vor einer Kollision erkannt sein müssen. Es gibt auch in der Demo noch viele Gleis Anschluss Unpässlichkeiten, außerdem fehlen die Tunnels noch. Es gibt also Doppelgleise Single Gleise Taper(Reduzierstück) Signale Terminals Weichen die man stellen kann über Lua oder händisch. Ich brauch das ganze restliche Jahr nur zur Optimierung und Sicherstellung der Abhängkeitsisolation. Das wird auch noch einige Jahre so weiter gehen bis wir old Sid Mayer das Wasser reichen werden, das müssen echte Programmierer gewesen sein, die das mit Assembler auf dem Amiga oder 286 ziger implemtiert haben.
Wenn das alles läuft und die Vorlage Assets plausible sind (siehe Binary all die meshes die dann optimiert mit drehenden rädern als Anim gespeichert werden müssen in Foldern mit einzelnen 3DS Dateien.. Haufen Holz alles für einen zu viel.Danke für deine Hinweise, vielleicht machst'e später mit, wenn es mehr zu bieten hat als aktuell ?
Grüße aus Preußen
K.
-
@KahnSoft : Ich muss dich leider enttäuschen. Das wird ein Spammer sein. Leute melden sich nicht in Foren neu an, um dann als ersten und einzigen Beitrag solche Texte zu verfassen. Da wird in den nächsten Tagen ein Edit kommen, der dann Werbung für ein Kasino macht.
@Sternlicht4384 : Für die 0.1% Chance, dass du kein Bot sein solltest: Entschuldigung. Ich bin ja auch immer fair und warte, bis der Werbelink tatsächlich erscheint, bevor ich jemanden sperre. Falls ich also Unrecht haben sollte, ist noch nichts passiert.
-
@SeppJ Ich hatte auch schon so den Verdacht... aber lass uns erst warten, was passiert. Offenbar scheinen Programmierer genau die Zielgruppe für (Online-) Kasinos zu sein.
Aber mal btt... Zu den MFCs in C++ kann ich nicht all zu viel sagen.
-
@KahnSoft Bin gerade beim Aufräumen wieder über mein altes Projekt mit dem Heightmap-Terrain-LOD gestolpert und dachte ich kann bei der Gelegenheit auch mal ein paar Screenshots posten, um das Prinzip zu verdeutlichen. Das soll nicht heißen, dass es das Nonplusultra ist - ich will das nur als potentielle Inspiration in den Raum stellen.
Heightmaps haben ja den Vorteil, dass man sie mit einer simplen Bild 1: Schachbrett-Triangulierung rendern kann, bei der die Vertices dann mit senkrecht zur Fläche den Werten der Heightmap moduliert werden.
Die Idee des "kontinuierlichen" LOD das ich implementiert habe ist, dass die Anzahl der Dreiecke mit jeder LOD-Stufe vervierfacht wird und dabei aus einer quadratischen "Zelle" mit zwei durch eine diagonale Kante verbundenen Dreiecken vier solcher Zellen mit 8 Dreiecken werden. Um den Übergang "fließend" zu machen wird zwischen der einen Zelle und den vier Zellen "gemorpht", was bei dieser dieser Methode bedeutet, den zentralen Vertex einer Vierer-Zelle in Richtung eines der Eckpunkte zu verschieben (Bild 2: LOD-Übergangs-Moprhing) bis 6 der Dreiecke verschwunden sind. Ab dem Punkt wird dann das niedriger aufgelöste Mesh verwendet.
Diesen Übergang kann man dann von der Distanz zur Kamera abhängig machen, was dann so aussieht:
Bild 3: Kontinuierliches LOD auf Mesh
Oder mit aufmodulierter Heightmap:
Bild 4: Kontinuierliches LOD mit Heightmap
Und texturiert und mit simpler Beleuchtung:
Bild 5: Kontinuierliches LOD mit Texturen
Ich finde die Methode insofern ganz gut, weil das Landschafts-Mesh nur langsam in eine höhere oder niedrigere Auflösung "morpht", wenn man sich nähert oder entfernt. Die Veränderungen der Geometrie sind dabei nicht so offensichtlich, als wenn man ab einer gewissen Distanz direkt in eine andere Auflösung "springt".
-
Hallo Finnegan,
ah so meinst du das der Lod mit der Höhe zunimmt, tatsächlich habe ich das hier so, das es Grundplatten(Chunks) gibt, die mit zunehmender Entfernung weniger Dreiecke zeigen. Die Höhe der Hügel hat hier keine Kopplung mit der Grid-Auflösung.
Eine Highmap kam leider für das Projekt nicht in Frage weil die Dimension der Karte fast eine Millionen Dreiecke Seitenlänge aufweist. Mit dem Chunks erreiche so trotz der riesigen Dimension bis zu 1Khz Bildwiederholraten, denn ich muss auch noch Züge und Gleise rendern, diese unterliegen auch einem Lod, der ist einfach je weiter ein Mesh entfernt ist desto weniger seiner Dreiecke werden gerendert, die kleinen stücke fliegen zuerst aus der Pipe , und die größten teile zuletzt.
https://www.flexxvision.de/Download/Chunks.jpg
So kann ich unendlich viele Gleise Loks und Terrains rendern, das Terrain wurde Z-Seitig mit der Perlin Noise angehoben was diese Hügel produziert, da kann ich dann generisch nich mehr machen, allerdings verfügt die Engine auch über Highmap Terrains.
https://www.flexxvision.de/Download/Highmap.jpg
Hier im Bild in einem anderen Kontext ohne Lod's
Ja die Weise die Dreiecke zu verdichten bei unterschiedlichen Z -Höhen habe ich noch nicht implementiert, das würde sich gut mischen mit den Chunks die im zweiten Bild jedoch nicht eingesetzt werden, da die Größe mit 30Hz Echtzeit Z Variation von einer Kamera kommend schnell genug war.Sehr interessant wie Du das umgesetzt hast, obschon das erste Raster ohne Textur viele doppelte Linien aufwies.
Im Moment mache ich nicht gerade viel am Projekt, mal sehen wann ich wieder loslege.
Vielen Dank für deine Ausführung , das ganze heißt Vertice Quaternation https://medium.com/@Ksatese/b-spline-terrain-reconstruction-and-quaternion-camera-in-opengl-ec66491c0623
Naja ist ja bald wieder kalt draußen, und dann hat man mehr musse
Gruß
K aus B.
-
@KahnSoft sagte in Rail Road Tycoon MFC in Action:
ah so meinst du das der Lod mit der Höhe zunimmt, tatsächlich habe ich das hier so, das es Grundplatten(Chunks) gibt, die mit zunehmender Entfernung weniger Dreiecke zeigen. Die Höhe der Hügel hat hier keine Kopplung mit der Grid-Auflösung.
Nein, das hat nichts mit der Höhe zu tun, sondern ist auch ein System, das mit zunehmender Entfernung von der Kamera die Grid-Auflösung reduziert. Es würde aber durchaus Sinn machen, auch mit zunehmender Steigung die Auflösung zu erhöhen, bei besonders steilen Anstiegen werden ansonsten einzelne Dreiecke sehr lang gezogen. Das ist aber ein sehr simples Heightmap-Rendering, dass ich da implementiert habe: Die Der Heightmap-Wert an der Position eines Grid-Vertex bestimmt direkt seine Höhe. Das ließe sich sicher noch etwas intelligenter machen, um die Qualität des Renderings zu erhöhen.
Eine Highmap kam leider für das Projekt nicht in Frage weil die Dimension der Karte fast eine Millionen Dreiecke Seitenlänge aufweist. Mit dem Chunks erreiche so trotz der riesigen Dimension bis zu 1Khz Bildwiederholraten,
Das Grid-Rendering sollte mit sowas klar kommen dank LOD, aber die Heightmap selbst kann schon ziemlich groß werden. In meinem Fall ist das eine simple 16-Bit Grausttufen-Textur (8-Bit ist eher ungeeignet für Heightmaps, da es wegen der nur 256 Abstufungen unschöne Treppenartefakte erzeugt). Und mit der Methode hast du natürlich recht: Eine 1000000x1000000 Heightmap-Textur mit 2 Byte pro Pixel wäre etwa 1,8TiB groß.
Alternativ könnte man die Heightmap aber auch prozedural auf der GPU und ebenfalls in einer entfernungsabnhänigen Auflösung generieren, dann sollte der Speicherbedarf nicht so hoch sein. Das ist ja auch bei dir bereits bereits eine prozedurale Landschaft, wenn ich das mit dem Perlin Noise richtig verstehe.
Vielen Dank für deine Ausführung , das ganze heißt Vertice Quaternation https://medium.com/@Ksatese/b-spline-terrain-reconstruction-and-quaternion-camera-in-opengl-ec66491c0623
Ist das die Technik, die du für das Landschaftsrendering verwendest? Wenn ich das beim groben Überfliegen richtig verstanden habe, werden dabei implizite B-Spline-Flächen auf die Höhendaten (Heightmap-Textur oder on-the-fly-generierter Perlin Noise) gefittet und dann daraus die Geometrie generiert. Ich ziehe da keine so klare Grenze und würde das ebenfalls den Heightmap-Techniken zuordnen. Allerdings den fortgeschritteneren, während mein Ansatz eher primitiv ist.
Es ist auch so, dass die von mir beschriebene Methode für kontinuierliches LOD nicht unbedingt an Heightmaps gekoppelt ist. Die kann man in der einen oder anderen Form eigentlich immer anwenden, wenn man es mit so einer gleichförmigen Schachbrett-Triangulierung zu tun hat, wie das z.B. auch bei deinen Chunks der Fall ist. Es ist halt lediglich eine einfache Methode um verschiedene LOD-Stufen fließend ineinander übergehen zu lassen, anstatt harte Grenzen zu haben.
Hier is z.B. so eine harte Grenze bei dir (aus dem "Chunks" Screenshot). Was passiert da, wenn man näher an den hinteren Chunk herankommt? Ich vermute mal, der springt von einem Frame auf den anderen in eine höhere Auflösung (?). Die primäre Motivation meines Ansatzes ist nämlich, eben solche Sprünge zu vermeiden und die LOD-Übergange kontinuierlich mit der Kamera "mitwandern" zu lassen und so die auflösungsbedingte Veränderung der Geometrie weitgehend vor dem Betrachter zu verstecken.
Das LOD wäre damit nicht mehr an die Chunks gebunden, sondern ausschließlich an Kameraposition. Chunks in diesem Übergangsbereich müssen natürlich eine höhere Auflösung haben, damit man z.B. in einem Vertex-Shader diesen Überhang hinein-transformieren kann. Ich denke schon, dass sich dein chunk-basiertes System und so ein kontinuierliches LOD nicht unbedingt ausschließen.
Aber letztendlich ist das nur ein nicht ganz so wichtiges Detail und du hast gewiss erstmal andere Prioritäten. Auch ist es fraglich, ob diese LOD-Sprünge überhaupt auffallen, so wie du die Landschaft aktuell renderst. Das ist also eher was für weit unten auf der Prioritätsliste - aber vielleicht ist es ja eine Idee für den letzten Feinschliff irgendwann mal
Sehr interessant wie Du das umgesetzt hast, obschon das erste Raster ohne Textur viele doppelte Linien aufwies.
Ich denke das was du mit den "doppelten Linien" sind diese Übergänge hier von einer LOD-Stufe in die nächste. Ja, die sind etwas unschön und sie erzeugen stellenweise ein paar degenerierte Dreiecke. Die treten aber nur in diesen Übergangsbereichen auf und driften dann reissverschlussartig auseinander, wenn man näher herankommt. Diese "doppelten Linien" hat man dort, wo das Gitter z.B. 10% in die höhere Auflösung "gemorpht" ist und die niedrigere Auflösung noch zu 90% dominiert. Die ergeben sich schlicht aus dem Schema, dass ich anwende um zwei LOD-Stufen ineinander zu überführen.
Vielen Dank für deine Ausführung , das ganze heißt Vertice Quaternation https://medium.com/@Ksatese/b-spline-terrain-reconstruction-and-quaternion-camera-in-opengl-ec66491c0623
Auch dir vielen Dank. macht Spass sich über sowas auszutauschen und interessant zu sehen, wie du sowas umsetzt. Den verlinkten Artikel werd ich mir nochmal in Ruhe durchlesen. Wenn ich nochmal sowas umsetze, würde ich sicher auch in Richtung NURBS/B-Splines mit GPU-generierterter, prozeduraler Landschaft gehen und vielleicht versuchen, das kontiunuierliche LOD dabei zu integrieren. Auch ist mein Ansatz noch lange nicht perfekt, vor allem wegen dem eher simplistischen "Morphing"-Schema. Das lässt sich sicher noch weiter verfeinern.
-
@Finnegan sagte in Rail Road Tycoon MFC in Action:
s
Hi Finnegan ,
ist das die Technik, die du für das Landschaftsrendering verwendest?
Nein aber die Seite hat viele Aspekte die man sich ansehen kann, oder integrieren könnte, ist rein sporadisch aus dem Netz gewählt, mein Chunksystem musste ich selber herstellen, und ist von anderen erstmal abgekoppelt .Die primäre Motivation meines Ansatzes ist nämlich, eben solche Sprünge zu vermeiden und die LOD-Übergange kontinuierlich mit der Kamera "mitwandern"
Ja also das Chunksystem basiert ausschließlich auf den Kameraabstand, es ist vollständig flüssig Sprünge sind mit dem Auge nicht erkennbar es hat 5 Detailstufen, in der Ferne werden mehr als 90% der Dreiecke entfernt, und das kann man gar nicht sehen, die Sache läuft sehr feinstufig , und das ist erst der Anfang, durchaus könnte es sein das ich da nochmal dran gehe, aber für den Moment gibt es keine Probleme Artefakte oder Sprünge, auch nicht wenn ich eine Lok verfolge mit hoher Geschwindigkeit. Sie erreichen umgerechnet bis zu 160 Km/h die Zeit Basis und die Lokomotive länge geben diesen Wert der Physischen Geschwindigkeit, das Terrain fliegt wie bei einem Racing an einem vorbei.
Auch die primitive Mesh reduzierung liefert sehr gute LOD Ergebnisse, allerdings kann ich hier noch mehr fine Tuning später ansetzen, zb ein Haus mit einem Tisch auf dem ein becher steht, der muss natürlich zuerst verschwinden auf Vertex ebene und am ende erst das Dach des Hauses, das ist noch nicht 100% gelöst, allerdings sieht man auch keine Problem beim vergrößern des Kameraabstandes.Sehr wichtig war das bei den Gleisen die bestehen aus Balast(Schotterbett) Sleeper(Schwellen) und Slicer (Schienen) hier fliegen zuerst die Schienen raus dann der Balast, und das Schottertet bleibt sehr lange liegen so hat man aus großer Entfernung noch immer die Gleisführung im Bilde. Allerdings wie bei den Meshes werden in der Entfernung immer mehr Dreiecke entfernt.
Naja nette Spielerei, ich muss nach den Aufräumarbeiten die fast abgeschlossen sind, weiter in die Zugsteuerung investieren was passiert an welchen Signalen Terminals, Weichen Doppelgleise das heißt bei mit RNA1-7 Das wird noch viel Zeit benötigen, schließlich wird das Verhalten auch über Lua gesteuert in Echtzeit.
Das kann schnell zur Lebensaufgabe mutieren , denn so einfach ist das alles nicht, mal ebend ein Spiel zu bauen , da muss man wirklich viel Motivation immer wieder neu aufbauen, und gerade diskussionen am Thema steigern genau diese.
In dem Sinne Netter Thread geworden, alles mögliche angesprochen, vielleicht gibt es auch andere die eine Frage dazu haben ?
Gruß Karsten
-
@KahnSoft sagte in Rail Road Tycoon MFC in Action:
vielleicht gibt es auch andere die eine Frage dazu haben ?
Ich finde die Preisgestaltung, im Vergleich zu den (möglichen/realen) Einnahmen, von Spielen wie Cities: Skylines II oder Transport Fever 3 viel zu hoch. Entwicklungskosten und Gewinne stehen einfach in keinem normalen Verhältnis mehr.
Sprich: Kleinere Entwickler bekommen meist zu wenig, große Studios zu viel vom Kuchen. Es geht nur noch um Gewinnmaximierung...
-
@Anon-81275 sagte in Rail Road Tycoon MFC in Action:
@SeppJ Ich hatte auch schon so den Verdacht... aber lass uns erst warten, was passiert. Offenbar scheinen Programmierer genau die Zielgruppe für (Online-) Kasinos zu sein.
Und da ist es soweit. Kimonowerbung. Das war zumindest mal was neues.
-
@SeppJ
Ich hab die Show verpasst.
"Wo viel Licht ist, ist starker Schatten"
Mich begleiten Häme + Flames eigentlich schon, seit ich im 1. Semester, unter ca. 150 Kommilitonen, Notenbester (+ ca. 10 Pkt. Bonus...) wurde. Und vorher dachte ich immer, dass es eigentlich kein Mobbing unter Studierenden gäbe... das ist inzwischen aber kein reines Schulphänomen mehr. In der Grundschule wird gemobbt, am Arbeitsplatz wird gemobbt und im Studium wird verdeckt gemobbt, was es noch viel schlimmer macht.
Aber gut, genug Offtopic nun.
