Hallo zusammen!

Vielleicht kennt ihr das alte Game "The Incredible Maschine". Man hat verschiedene Gegenstände und Tools zur Verfügung (z.B. Förderband, Ball, Seil) und muss die geschickt miteinander verknüpfen um eine bestimmte Aufgabe zu lösen... Z.B. Pistole zertrennt ein Seil, woran ein Ball hängt, der dann runterfällt und dann aufs Förderband fällt, usw.. Man baut sich so eine kleine "Maschine" zusammen. Vom Konzept her ähnlich wie Lemmings, jedoch einfach mit Physik... Jedoch wird in "The Incredible Maschine" nicht wirklich physikalisch korrekt gerechnet (nicht viel, auf jeden Fall).

Ich programmiere zur Zeit an einer kleinen Physikengine und wollte mal Ideen für ein ähnliches Game sammeln! Die Engine ist noch lange nicht fertig, sie soll im Prinzip schlussendlich auch Wärmeaustausch und so Zeug beinhalten. Ein Ballon, welches aufgrund der Wärme aufsteigt, usw. Mal schauen, ob das alles noch bei einer begrenzten CPU-Auslastung drinliegt.

Falls ihr weitere coole Ideen habt, bitte posten! Die Physikengine kann noch nicht so viel (bis jetzt nur inelastische Stösse und Reibung), ein kleines Demo ist im Anhang (Code noch völlig unoptimiert, deswegen nicht so schnell).

Das Spiel soll in 2D sein (obwohl die Engine schon 3D rechnet).

Danke!

PS: Sorry, passt wohl nicht in diese Sparte... Meinetwegen könnt ihr's ins Off-Topic verschieben.

Sieht verdammt genial aus!
Außer einigen kleinen Mankos ( Rechteck gerät "in" den Stern bzw. in die Zahnräder ) wirklich absolut spitze !

Könntest du mir erklären WIE du das gemacht hast?
Bin nunja, nicht kompletter, aber ich bin Anfänger.
Könntest mir evtl. den Source geben / posten?
Würd ich 100 pro nicht verwenden können und so, würde aber denke ich, sehr viel lernen können.
Auf jedenfall top!

Als Idee: du könntest noch soetwas wie Flüssigkeiten einbauen, die auf Oberflächen sind, wo der Körper dann hinabgleitet .

Der Fehler taucht ab und zu bei spitzen Ecken auf und liegt an der Kollisionserkennung. Dort weiss der Algorithmus nicht so recht auf welcher Seite das Objekt ist...
Die Kollisionserkennung wird aber sowieso noch ausgetauscht, bzw. Spitze Objekte wird es dann schlussendlich einfach nicht geben.
Flüssigkeiten? Ja, was Vereinfachtes in der Richtung wär durchaus möglich. Danke für die Idee

Also ich wäre auch mal an diesem code intressiert !
Um ein bisschen reinzugucken und zum lernen !

Mfg

Am Code wirst du nichts lernen. Bringt wahrscheinlich mehr, wenn du einfach regelmässig den Physikunterricht besuchst

Ganz kurz die Schritte zusammengefasst: Aus einer gegebenen Konfiguration werden Berührungspunkte zwischen Objekten gesucht, die in ein Gleichungssystem geschrieben und dieses gelöst. Die Lösung gibt dann ungefähr die Konfiguration im nächsten Zeitschritt (vereinfacht gesprochen).

Jetzt willst du natürlich wissen, wie das Gleichungssystem aussieht. Ich poste hier keine Herleitung in Ascii-Format und der Code bringt wird dich nicht weiterbringen. Da du mir das nicht glaubst () meinetwegen geb ich hier den Code fürs Aufstellen des Systems. Der Code macht ca. die Hälfte der Berechnungsprozedur aus. Der Rest ist dann nur noch ein Solver:

Da das jetzt nicht Open Source ist gibt's auch nicht den kompletten Code. Da ich aber den Code den Leuten von Omorphia geben werde, kann du ihn vielleicht in einiger Zeit anschauen.

Und nun Back zu Topic. Aber wie's aussieht hat niemand mehr eine coole Idee

vieleicht kannst du noch sowas einbauen das wenn z,b, ein ball irgendwo runterfällt nach dem aufprall wieder ein kleines stück hochspringt

Ja das kommt noch. Im Moment gibt's nur inelastische Stösse. Elastische Stösse sind aber einfacher zu realisieren.

vieleicht kannste ja auch sowas wie federn reinnehmen, so was mit Dehnung und so

Jo, stimmt. Seile und Federn wären cool. Ein Trampolin für runterfallende Kugeln wär auch noch was Danke

wenn das programm fertig is, postest du es dann hier im DF? würde nämlich dann gerne mal die fertige Version sehen.

Klar könnte aber noch eine Weile dauern, bis nämlich meine Ferien beginnen.

Hier noch eine kleine Demo-Scene, die ich vor einigen Wochen für ein Projekt (mit noch 2 anderen Leuten) gemacht hab. Läuft ziemlich langsam. Ab 2GHz funktioniert's einigiermassen. Es zeigt ein gasgefüllter Ballon und eine Kugel, die drauffällt. Sowas soll auch ins Game rein. Da 2D sollte das dann schneller laufen. Ein Seil (Anleitung: Maus bewegen) hab ich auch schon vor einiger Zeit gemacht (2002/2003 war das)
Muss "nur" noch alles ins Game rein (und in 2D wegen Geschwindigkeit).

Kleine Echtzeit-Flüssigkeitssimulation, die ich evtl. auch ins Game einbauen könnte. Weil das ganze aber nicht so gut "verträglich" mit der obigen Starrkörpersimulation ist, wird es vielleicht aber nicht gehn (ausser ich finde einen Umweg..) :\

Das sieht mal wirklich geil aus! Respekt.

Also ich hab ja Kp, ob sowas schwierig zu programmieren ist (noobs können sowas ja nicht einschätzen), aber das scheint gut zu werden, was du da vorhast.

Na ja, wo ich die Flüssigkeit sehe: Wie wärs damit, die in Elemente reinzufüllen, damit sich deren Schwerpunkt verschiebt?

Und du kennst ja wahrscheinlich den Effekt, wenn du ein rohes Ei drehen lässt, das wär doch auch ein geiler Effekt, wenn auch etwas kompliziert zu berechnen (Ich habs damals nicht hinbekommen). Das ist allerdings eher was für 3D...

Komm nicht ganz nach was du mit den gefüllten Elementen meinst... Das Problem ist, dass die Gleichungen auf einem (unsichtbaren) Gitter gerechnet werden und die Geschwindigkeiten innerhalb einer Zelle konsistent sein müssen; Wände müssten deswegen immer parallel zu einer Koordinatenachse sein, deswegen geht das auch mit dem Ei nicht so gut, da die Grenzen rund sind. Oder besser gesagt: Es geht nicht ohne zusätzlichen Rechenaufwand.

ich denke, er meint, dass die Flüssigkeiten in den Körpern sind und sich dort bewegen, sodass sie ihren Schwerpunkt verändern und sich stärker drehen. Man könnte das so machen, dass man mit der Maus bestimmen kann, wo sich die Flüssigkeit im Körper aufhalten soll, so hat man mehr Einfluss auf die Sache, die da vor sich geht d.h. man klickt in eine Ecke und das Wasser fließt dorthin, was den Körper dazu bringt mit der Ecke nach unten zu fallen

PS: Das Flüssigkeitenprog is richtig gut, Respekt

das seil ist aber wohl noch nicht soo ganz ausgereift: es dehnt sich, als gäbe es keinen widerstand. und dann läuft die dehnung parallel nach hinten durch. du solltest eine federkonstante einbauen, oder das seil undehnbar machen... aber die flüssigkeit ist nun wirklich genial. da hast du sicher auch den inneren zusammenhalt zwischen den teilchen miteinbezogen? so dass sich nicht kleine tropfen bilden, obwohl richtiges wasser z.B. durch die wasserstoffbrücken zusammengehalten werden würde. aufjeden fall ist das genial. weiter so! achja, ich tu ja so, als ob ich bei omorphia mitarbeiten würde (bin zu dumm oO ich hab bisher nix gefunden, was ich schaffen könnte.. oO), da werd ich dann sicher mal den ganzen code sehn können ^^

Das Seil hab ich mal vor langer Zeit programmiert, klar, das lässt sich noch um einiges verbessern. Das war eher da, um einige Beispielideen zu posten. Wenn jemand noch andere Ideen hätte, dann raus damit!

Die Oberflächenspannung der Flüssigkeit ist nicht berücksichtigt. Zum einen ist es ein kleiner Effekt und zum anderen ist es für ein Game. Kleine Spritzer gibt's auch ohne Oberflächenspannung. Die werden dann einfach nicht rund... Das Problem bei der Oberflächenspannung ist, dass man die Krümmung beim Phasenübergang berechnen muss. Das geht natürlich viel zu lange.

Wasserstoffbrücke usw.: Die Teilchen, die man sieht, die sind nur zur Visualisierung da. Das sind Fluidpartikel und sind nicht mit Molekülen zu vergleichen. Das Fluid wird kontinuierlich als Vektorfeld gerechnet und die Partikel bewegen sich dann einfach entlang dieses Vektorfeldes. Das Vektorfeld wird wiederum aus einer Differentialgleichung (Navier-Stokes-Gleichungen) in jedem Schritt gewonnen. Was konkret gerechnet wird, sieht man also nicht: Das ganze wird auf einem fixen z.B. 64x64 Gitter gerechnet und in jedem Frame werden die Geschwindigkeitskomponenten an den fixen Gitterpunkten berechnet. Die Fluidpartikel "spüren" sich also gar nicht. Das wäre auch viel zu zeitintensiv, wenn man ausrechnen müsste, welche Partikel wie nahe an anderen Partikel sind.

In einem Game muss man mogeln, wo man nur kann. Es muss nur bedingt physikalisch korrekt sein. Das Fluidprogramm berechnet für ein inkompressibles Fluid die Massen und Impulserhaltung mit "Slip"-Randbedingungen auf einem diskreten Gitter, Luft drumherum hat keinen Druck (keine Luftblasen, die aufsteigen)
"Richtiges Wasser" verhaltet sich anders: Oberflächenspannung, Kompressibilität, (annährend) "No-Slip" Randbedingungen, (annähernd) kontinuierlich. An die Viskosität von Wasser komm ich "dank" numerischer Diffusion auch nicht ran.

Das ganze läuft im Vergleich zu echtem Wasser viel zu langsam. Es sieht eher aus wie Öl... Tja, und das bei 100% Prozessorauslastung

Ist es irgendwie möglich mit Delphi Metaballs zu erzeugen? Das wäre dann 3D, aber es würde, wenigstens recht dicht an Wasser herankommen.