Schaut gut aus und ist denke ich für das Einsatzziel das du anstrebst ideal.

Ein wenig erinnert es mich aber an Phys2D

//edit: Beispielprogramm auch gleich mal ausprobiert...

Das Programm ist bereits sehr intuitiv, aber leider konnte ich keine Objekte löschen, da auf der mittleren Maustaste bereits eine andere globale Aktion von Windows gelegt war. Vielleicht kannst du eine alternative Methode zum löschen der Objekte bereitstellen.
Was auch geändert werden sollte ist, das man Kreis und Rechteck zeichnen zeitgleich aktiv haben kann. Vielleicht kannst du die beiden sich ausschließen lassen oder einfach die Auswahl welche Form man nun zeichnen will ebenfalls mit einem Slider oder einer Dropdown ermöglichen.

_________________
(\__/)
(='.'=)
(")_(")

Sehr schick! Das macht schonmal riesen Spass einen ziemlich großen Klotz von oben auf hunderte Kleine draufzuschmettern und zuzusehen wie sie seitlich herausquillen.

Ein paar Sachen sind mir noch aufgefallen:

- Der Viewport ändert seine Größe nicht mit dem Fenster.
- Wenn man ein Objekt mit der rechten Maustaste festhält und ganz still hält, fängt das Objekt an sich gegen den Uhrzeigersinn zu drehen.
- Man kann Objekte auch mit der linken Maustaste löschen.
- Wenn die FPS stark sinkt (bei vielen Objekten) fallen schnelle Objekte durch relativ dünne statische Objekte hindurch.

Werden die Objekte die nach unten rausfallen eigentlich gelöscht?

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Wirklich ein tolles Programm. Habe gar nich gedacht wie viel Spaß es machen kann einfach mal ein paar Dinge fallen zu lassen.
Die Bedinung gefällt mit auch wirklich gut und ist sehr schnell zu verstehen.

Was mir aber aufgefallen ist, in feste Rechtecke kann man neu Objekte hineinstzen, aber in Kreise funktioniert das nicht, wenn man das probiert werden sie ausen an das den Kreis angesetzt. Außerdem scheint die Reibung irgendwie kaum eine Auswirkung zu haben, oder habe ich nur nicht geau genug hingeschaut?

Man könnte den Play-Butten statt ihn Blau zu hinderlegen vieleicht auch einfach durch ein Pausesymbol ersetzen, so sieht man schneller ob man gerade im Pausemodus ist oder nicht.

Auf jeden Fall ist das Programm aber schon richtig toll. Mich würds freuen wenn irgend wann vieleicht noch flüssigkeiten hinzukommen würden.

Gruß Alexander

Mich würde interessieren, wie du die Physik umgesetzt hast. Ich habe so etwas vor geraumer Zeit auch probiert, hatte dann aber diverse Probleme bei der Umsetzung.
Hab mir auch schon einige Tutorials angeschaut gehabt, aber bin damit nie so richtig glücklich geworden. Was die Kollisionserkennung angeht habe ich keine Probleme, aber die physikalische Interaktion will bei mir nicht klappen

mfg

Respekt! Hübsches Programm.

Ich finde, dass die Idee auch sehr gut ist. Eine Physikengine 2D dürfte z.B. für sehr schicke Jump'n'Run-Spiele nützlich sein.

Ich studiere Physik und muss leider sagen, ich wüsste nicht, wie man sowas realisieren könnte
Rechnest du Trägheitsmomente aus, oder wie funktioniert das?

Achja, ein Zoom wäre cool.


Viele Grüße!

Physik in 2D ist noch relativ einfach(zumindest ohne Joints). Am hässlichsten ist dabei die kollisionserkennung.
Jedes Objekt braucht folgende statische Eigenschaften
Masse(skalar)
Trägheitsmoment (skalar und keine Matrix da 2D)
Koordinaten des Schwerpunkts(vektor, legt meist den lokalen Ursprung fest)
Form(nur für kollision)
Dynamische Eigenschaften:
Geschwindigkeit(vektor)
Ort(vektor)
Drehung(skalar)
Winkelgeschwindigkeit(skalar)

Die Zeitentwicklung ohne kollision ist trivial, da Geschwindigkeit und Drehung die Ableitungen von Ort und Winkelgeschwindigkeit sind und selbst Zeitlich unverändert sind.

Bei Kollision muss man von der Kollisionserkennung folgende Eigenschaften mitgeteilt bekommen
Ort der Kollision
Normale der Kollision

Nun wissen wir dass die Kraft auf beide Körper entgegengesetzt gleich ist. Außerdem können wir über Normale und Kollisionsort das jeweilige Drehmoment auf die Körper in abhänigkeit der Kraft darstellen. Damit sind bereits 3 Gleichungen für 4 beim Stoß veränderlichen Größen. Da die Änderung der Größen vom Kraftstoß (Kraft*Zeitintervall) abhängt, brauchen wir noch eine 4. Gleichung um den Betrag des Kraftstoßes zu bestimmen. Hierfür kann bei einem elastischen Stoß beispielsweise der Energieerhaltungssatz dienen.

Bei mehreren Interaktionen gleichzeitig (kommt eigentlich nur durch Joints vor), würde ich die verschiedenen Interaktionen nacheinander anwenden. Üblicherweise sollte sich das Problem dadurch iterativ der korrekten Lösung annähern.

Eine perfekte kontinuierliche Kollisionserkennung ist dagen interessanter:
Ich stelle alle Körper durch Polygone dar. Wenn 2 Polygone ursprünglich nicht kollidieren, kann eine Kollision nur dadurch geschehen dass ein Eckpunkt des einen Polygons durch eine Kante des anderen Polygons dringt. Wann/ob genau das geschieht lässt sich zwar nicht analytisch genau errechnen, durch iterative Lösung z.B. Gauss sollte es jedoch in annehmbarer Zeit möglich sein. Vorher muss man natürlich ausreichend "early outs" einbauen, dass einem die Performance nicht einbricht. Eine weitere Hässlichkeit ist jedoch dass dann die Kollsionen in der Reihenfolge ihres Auftretens ausgewerten werden müssen. (Zumindest wenn man perfekt rechnen will). Für die meisten Anwendungen dürfte es jedoch ausreichen keine wohldefinierte Reihenfolge für die Kollisionen innerhalb eines Frames zu haben. Dies ist bei komplexeren Joints ohnehin nicht mehr mögich.
Eine gangbare Alternative dürfte dagenen eine adaptive Anzahl an subframes sein. Erst bestimmt man die ob eine Kollision potentiell stattfinden kann, in dem man die Boundingboxes verwendet, die den gesamten Raum den ein Körper während des frames irgendwann einnimmt abdecken. Falls diese Boundingboxen kollidieren kann man mit erhöhter framerate nach Kollisonen suchen. Dabei sollte die Framerate von der Größe der Körper (je kleiner desto höher) und der Geschwindigkeit (je größer desto höher) abhängen. Sonst kann es passieren dass schnelle Körper dünne Körper ohne Kollision durchqueren.

Joints machen das ganze natürlich deutlich komplizierter, da viele Körper dauerhaft gleichzeitig interagieren und die Constraints der Joints eigentlich die ganze Zeit über erfüllt sein sollten. Und wenn man ein Constraint erfüllt, man meistens die anderen wieder kaputt macht, und man sich wieder nur iterativ an die Lösung herantasten kann.

In 3D kommt als zusätzliche Schwierigkeit noch die Zeitentwicklung in Spiel, da bei Körpern mit einem nicht trivialen Trägheitstensor die Winkelgeschwindigkeit selbt ohne Interaktion zeitabhängig ist. Die Zeitentwicklung der Drehung lässt sich somit wieder nicht analytisch darstellen. Die Kollisionsbehandlung wird dagegen nicht sonderlich viel schwerer.

_________________

Hallo!

Danke für das Feedback, ich werde mich wohl erstmal dranmachen die Steuerung bzw. die Oberfläche zu verändern. Die genannten Fehler / Verbesserungsmöglichkeiten werde ich versuchen umzusetzen.
Was die Frage nach der Physik angeht, hat The-Winner ja schon einiges geschrieben, falls noch weitere Fragen da sein sollten kann ich die gegebenenfalls auch beantworten.

Das Problem bei der Steuerung ist, dass man an diesen Smartboards nicht viele verschiedene Eingabemöglichkeiten hat. Eigentlich hat man ständig einen Linksklick. Dazu gibts noch eine Taste am Board, mir der der nächste Druck ein Rechtsklick wird. Mittlere Maustaste gibts garnicht und ne Tastatur kann man sich einblenden lassen, ist aber zu umständlich, als dass man es benutzen könnte. Das heißt ich muss ein paar mehr Buttons auf die Leiste unten machen, um ein paar mehr Variationen zuzulassen.

Außerdem ist es so, dass wenn man auf die Leiste unten kommt das soviel CPU Zeit kostet, dass die Simulation anfängt zu ruckeln. Da muss ich wohl vollständig auf OpenGL setzen... Das wird nochmal Arbeit.

Markus

Ich hoffe das Ganze wird nicht zu Off-Topic

Die Kollisionsnormale und die Kontaktpunkte zu berechnen ist absolut kein Ding, nur was dann genau folgt weiß ich nicht man muss ja praktisch für jedes Objekt (sagen wir mal Polygon) eine neue Geschwindigkeit und eine neue Winkelgeschwindigkeit berechnen. Wie genau ?

mfg

Hallo!

Also, der Impuls, der auf die beiden Körper hinterher wirkt unterscheidet sich nur beim Vorzeichen. Er hängt natürlich auch von der Relativgeschwindigkeit der beiden Körper ab. Ich hab hier mal ein Paper, leider auf Englisch, was ich auch benutzt habe. Die Herleitungen sind da ausführlich drinne.

http://chrishecker.com/images/e/e7/Gdmphys3.pdf

Ich hoffe das hilft dir weiter. Das Thema selbst in einem Post hier zu erläutern würde wohl ein bisschen dauern. Dazu hab ich im Moment leider keine Zeit, vielleicht finde ich die in den nächsten Tagen.

Um nochmal auf den Post von Rüdiger einzugehen:

Ja, ich rechne die Trägheitsmomente aus, da es nur 2D ist, braucht man keinen Tensor auszurechnen, der sich dazu auch noch ändert. Für ein Rechteck ist die Formel zB.

m * (Breite*Breite + Höhe*Höhe) / 12

Für einen Kreis ist die Formel auch nicht schwer, zu finden ua. auf Wikipedia

Markus

Sieht schon sehr cool aus, gut dass auch konkave Polygone unterstützt werden. Welche Techniken verwendest du für die Triangulierung und die Kollisionserkennung ?

Moin,

für die Triangulierung verwende ich im Moment noch den Ear-Clipping Alogithmus aus
dem Wiki.
Ich speichere die Punkte, die mit der Maus gezeichnet werden, und erstelle damit erstmal ein Polygon. Dann werden alle Polygone eines Körpers Trianguliert und neu angeordnet, um dann
den Massenschwerpunkt zu berechnen.

Zur Kollisionserkennung benutze ich SAT.

Markus

Hallo,

sehr schönes Projekt - fast schon so gut wie Chipmunk Physiks.

Übrigens: Die GUI-Erinnert mich an irgendwas... Und die Benennung der GUI-Klassen (TglSkinElem, TglSkinElemList, TglSkinItem, TglSkin) auch (man ersetze "gl" durch "Ad" ). Erstaunlich ist auch, dass dein GUI-System genau die gleichen Zeichenfehler wie meins hat. Ich muss dich daran erinnern das der Sourccode von Andorra 2D unter der CPL steht und alle Änderungen daran früher (oder später) veröffentlicht werden soll(t)en (in deinem Fall wohl die glSkin.pas).

Das soll dich jetzt nicht daran hindern meinen Sourcecode zu verwerten (schließlich verwenden den auch einige kommerzielle Projekte, die dann auch noch Geld damit verdienen), doch die oben genannte Regel solltest du beherzigen...

Ich freue mich auf neue Versionen und weiter so mit deinem Projekt,
Andreas

PS: Auch schön das jemand was mit meine Triangulierungsalgorithmus anfangen kann - wenn du den irgendwie verbessert hast, kannst du ja den Code im Wiki aktualisieren.

_________________
http://audorra.sourceforge.net//http://andorra.sourceforge.net

Moin,

du hast natürlich vollkommen recht. Könntest du mir bitte mal ne PM schreiben, was ich da zu tun habe? (mit einer Beschreibung der Zeichenfehler, mir sind keine Aufgefallen)

Zu der Triangulierung: Ich hatte ihn in einer früheren Version benutzt, jetzt aber nichtmehr, da er sortierte Vertices benötigt. Ich
habe viele Versuche unternommen den Algo dahingehend (und noch weiter) zu verbessern, bin jedoch nicht zu einem wirklichen Ergebniss gekommen.
Deswegen löse ich das ganze jetzt auf eine andere Weise.

Markus

Ich möchte das gleich nochmal Nutzen um darauf hinzuweisen, dass verwendeter Fremdcode bitte auch bei der Projektbeschreibung mit erwähnt wird. Egal ob es eine Lizenz sagt oder nicht. Das gilt insbesondere für Code anderer DGL Mitglieder. Das hat verschiedene Gründe:
1. Immernoch erhält man wenig Feedback. Wenn man etwas geschaffen hat, möchte man gern auch wissen ob es jemandem nutzt.
2. Es zeigt, dass die Community nicht nur darin besteht die selbe Website zu öffnen, sondern auch in der gegenseitigen - wenn auch indirekten - Hilfe zu Ergebnissen zu kommen.
3. Um auszuschließen, dass der Verdacht aufkommt sich mit fremden Federn zu schmücken.
4. Um nützlichen Code auch nach außen hin bekannt zu machen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Moin Flash,

ich habe mal meinen letzten Beitrag im Projektthread editiert. Ich hoffe jetzt ist alles (auch mit der PM) geklärt.

Markus