Rail Road Tycoon MFC in Action
-
Hallo zusammen,
nach Monate langer Entwicklung in OpenGL C/C++ habe ich einen ziemlichen Grundstatus erreicht in Sachen Eisenbahn als Rail Road Tycoon Clon erreicht, noch immer suche ich nach Leuten die Bock haben
mit zumachen, ich gebe bereits einen Download mit allen Loks und Anhängern und dem dynamischen Lua Gleis-System zum Download preis. Alles in 3DSmax gehalten.Man kann die im Moment einzige Lok einfach durch eine ähnliche ersetzen. Das wird mit den Jahren wachsen bis zum 50 Player Game, es ist aber noch in der Alpha Phase, aber bereits jetzt sind alle
Grafiken und Skripte zugänglich und modifizierbar, erstmal nur ein Preview aber weichen gleise usw. haben bereits RNA1-6 Erreicht Desaster Kollisionen sind schon integriert aber offline sonnst würden alle sich
aus den Gleisen werfen, der Gleis Editor ist Spline Line basierend und an Komplexität zum Wahnsinnig werden, aber es wird bald die Basis gelegt sein, es ist massiv mit KI Unterstützung erstellt, bezüglich dynamischer Szenarien. Grüße aus Berlin ich freue mich wenn wer auch bock drauf hat. PreView
Karsten
-
@KahnSoft sagte in Rail Road Tycoon MFC in Action:
Habe den Link mal repariert und kurz reingeschaut. Ziemlich cooles Projekt!
Auch interessant, dass du das mit einer industriellen Visualisierungs-Engine umgesetzt hast. Die ist für so ein Spiel in diesem Simulations-Genre sicher nicht ganz ungeeignet, da es weniger auf neueste photorealistische Grafikeffekte sondern mehr auf passende Tools zur Modellierung und Simulation ankommt. Ich kann mir vorstellen, dass ein Action-Shooter vielleicht schwieriger wäre. "Professionell" und Spiele schließen sich aber nicht aus, letztendlich sind so ziemlich alle Spiele auch "Simulationen"
.Was mich bei dem Vorführungsvideo interessiert hat: Haben die Chunks ein fixes LOD oder gibt es da einen kontinuierlichen Übergang? Und wenn fix, wie werden die "Nähte" an den Rändern gehandhabt? Die passen ja meist meist nicht sauber zusammen und erzeugen Löcher, wenn man die einfach so nebeneinander setzt.
Ich habe vor Jahren mal einen Heightmap-basierten Landschaftsrenderer gebaut und da ein kontinuierliches LOD verwendet, dass sich das gleichförmige Gitter der Heightmap-Geometrie zunutze gemacht hat. Habe nur noch vage Erinnerung, aber die Grundidee war 4 quadratische Zellen mit je 2 Dreiecken (Vertices in Y-Richtung durch die Heightmap moduliert) kontinuierlich zu einer Zelle mit zwei Dreiecken zu "morphen" (bzw. umgekehrt, wenn man in höheres Detail übergeht). Die Operation ist für so ein Heightmap-Gitter ziemlich simpel zu berechnen und kann in einem Vertex-Shader für die "Übergangs-Chunks" gemacht werden, die zwischen zwei LOD liegen. Ich fand das Resultat sehr brauchbar, da es visuelle "Sprünge" zischen den LOD vermieden hat (wenn man näher kommt oder sich entfernt). Fall so du sowas in die Richtung nicht eh schon machst, kann ich das auch gern nochmal rauskramen.
Hah! Und das hüpfen der Lok. Ich glaub ich sehe was hier passiert: Die Lok ist immer parallel zur Tangente der Schienen-Kurve, oder? So aus dem Bauch heraus würde ich denken, dass man am besten die Punkte findet, wo die Räder der Lok die Schiene berühren und das für die Neigung der Lok heranzieht. Z.B. zwei Punkte: Vorderrad und Hinterrad (für ne ganz simple "Lok"). Vielleicht kann man auch schauen ob die Schienen dabei die Unterseite der Lok berühren und so bestimmen, ob das ein Hügel ist, wo die Lok überhaupt drüber kommt ohne stecken zu bleiben.
Und was den Schienenbau angeht: Splines können echt fummelig sein, saubere Arbeit! Was für Splines sind das? Dass man die Punkte definiert, durch die die Schienen laufen sollen ist erstmal sehr intuitiv und eine brauchbare Funktion.
Anregung:
Ich persönlich bin bei so einer Schienen-Modellierung ein wenig "Stetigkeitsfanatiker" und versuche dabei immer auch die Krümmung stetig zu bekommen, wenn ich zwei Kurvensegmente verbinde. Bei interpolierenden Splines (z.B. Catmull-Rom), die durch die Kontrollpunkte laufen, finde ich das meist extrem schwierig und die Kurve wirkt dann oft ein wenig "matschig". Approximierende Splines (wie Bézier- oder B-Splines), bei denen die inneren Kontrollpunkte meist nicht auf der Kurve liegen fällt mir das wesentlich leichter. Da wird dann die Modellierung aber weniger intuitiv.
Man kann das denke ich auch automatisiert "glätten" und Koeffizienten finden, bei denen die Kurve durch die vorgegebenen Punkte läuft und an den Verbindungen krümmungsstetig ist. Da glaube ich aber, dass das nicht immer das gewünschte Ergebnis erzeugt. Das könnte sehr "volatil" sein und die Verbindung erstmal "Überschwingen" und eine riesige Schleife bilden lassen bevor sie dann (mathematisch korrekt) krümmungsstetig in das nächste Kurvensegment übergeht. Ich denke ein hybrider Modus wäre vielleicht ein guter Ansatz: Standardmäßig definiert man die Interpolationspunkte, durch die die Kurve laufen soll, aber man kann dann bei Bedarf umschalten und mit Approximations-Kontrollpunkten modellieren um die Krümmung besser "tunen" zu können. Die Kurven sollten sich für sowas von einer Repräsentation in die jeweils andere überführen lassen (z.B. Catmull-Rom <-> B-Splines).
Aber vielleicht hast du ja ganz andere Prioritäten im Moment, besonders wenn du schreibst, dass die Komplexität bereits jetzt "zum wahnsinnig werden" ist. Lass dich nicht von meinem Krümmungsfetisch kirre machen!
Wie gesagt: Cooles Projekt, halt uns gern auf dem laufenden - auch wenn ich persönlich gerade nicht die Zeit habe, da allzu tief einzusteigen