Hm, es macht ja sicher Spaß, gedanklich im dreidimensionalen Raum herumzuturnen, aber die Gefahr, dabei die Orientierung zu verlieren, ist enorm. Etwas Konkreteres, z.B. in Form von Code, wäre da bestimmt hilfreich.

Übrigens hatte ich schon vergessen, dass ich vor einem Jahr schon einmal eine Frage zu diesem Thema gestellt habe, in diesem Forum:
http://www.delphigl.com/forum/viewtopic.php?t=7134

Herausgekommen ist letzten Endes nicht viel. Wie gesagt, wenn man in Gedanken ein wenig durch die Szenerie galoppiert, übersieht man schnell die Tücken im Detail.

Ich kann nur Pascal, kein C (Du verwendest in Deinen Tutorials C habe ich gesehen). Das Erstellen eines Testprogramms wäre schon ein wenig Aufwand, denn man sollte ja schließlich genau beurteilen können, ob das Ganze stimmt, dh. man sollte es sehen können und auch verschiede große Kugeln, Dreiecke und Richtungen zur Verfügung haben. Aber ich kneife normalerweise nicht. Ich sitze hier auch auf einem Berg von nützlichem Code, also von daher wär es machbar.

Und es wäre schade, wenn Du diese Lösung einfach vom Tisch wischst. Ich glaube nämlich schon, dass das funktioniert. Ich habe mir das nicht nur ausgedacht sondern auch mit Geodreieck, Kugel-Ersatzobjekten und Bleistiften hantiert (das Vorstellen einer solchen Szene ist nicht ganz einfach).

Ich wäre bereit, ein solches Programm zu schreiben, wenn Du auch ein Pascal-Programm akzeptieren kannst. Braucht aber ein wenig Zeit, sagen wir: eine Woche, das wäre Donnerstag, der 11. Juni.

Ich denke auch dass das funktioniert was Traude geschrieben hat.
Übrigens konnte man dir gut folgen .

Interessant wäre auch noch ob man berechnen kann wo und wann der Schnittpunkt bei einer gleichförmig beschleunigten Bewegung ist.
Beschäftige mich nämlich auch gerade mit solchen Problemen.
Falls ich ein paar Techniken finde wie man bei Punkten, Geraden, ... Vorausberechnen kann, werd ich mich melden.


Andreas

Hallo Andreas,
ich freu mich, Dich zu sehen.


Klar, wär natürlich viel realistischer. ich beschränk mich jetzt mal aber auf die reine Geometrie und lege nur eine nicht beschleunigte Bewegung zugrunde. Die beschleunigte Bewegung könnte man dann ergänzen.
Viele Grüße,
Traude

Was nicht heißt, dass ich kein Pascal kann. Ich hab' jahrelang mit Pascal rumgeturnt und bin nur notgedrungen auf C umgestiegen, um an einem Open Source Programm mitarbeiten zu können.

Aber du hast schon recht, es macht keinen Sinn, sich auf blauen Dunst stundenlang mit einem Code herumzuquälen, der vielleicht überhaupt nicht gebraucht wird. Außerdem habe ich ja schon eine Lösung, mich interessiert nur theoretisch, ob es auch andere Wege gibt. Ist vielleicht auch mein eigenes Problem zur Zeit: Ich hab' in den letzten Monaten soviel an Code in den blöden Rechner reingehackt, dass ich alles durch die Brille { } oder meinetwegen begin-end sehe und Geodreieck und Zirkel neben der Tastatur schon eine dicke Staubschicht haben. Wirklich, ein guter Präzisionszirkel, Marke Haff.

Das muss ich überlesen haben. Würde mich sehr interessieren, was für eine Lösung Du hast. Ich werde mich in nächster Zeit auch in Deine Tutorials vertiefen, denn ich versuche, eine Engine zu schreiben und im Gegensatz zu den anderen bin ich mehr an Kinematik interessiert, weniger an den hübschen Oberflächen.

Im Laufe eines langen Threads verliert man oft die ursprüngliche Problemstellung aus den Augen. Also, das Verfahren, das inzwischen praktisch bewährt ist und das ich in meinem Tutorial etwas oberflächlich beschrieben habe, geht auf J.Rouwe zurück (Link im Tutorial). Rouwe hat die Zursammenhänge aber dermaßen kompliziert und knapp dargestellt und teilweise umständlich umgesetzt, dass ich etliche gedankliche Klimmzüge machen musste, um brauchbaren Code daraus zu gewinnen. Das Ganze Schritt für Schritt herzuleiten, war in dem Tutorial praktisch nicht möglich, und ich hatte ja auch offen zugegeben, dass ich es nun, nach einigem Abstand, auf Anhieb nicht rekonstruieren kann. Du kannst dich ja mal damit auseinandersetzen, aber ohne Rouwe zu lesen, geht es nicht. Und vielleicht ist deine Lösung besser verständlich. Sollte das der Fall sein, würde ich es liebend gern ins Tutorial einbauen, als eine verständlichere und besser nachvollziehbare Alternative.

Wobei es nicht nur um die Verständlichkeit bei sowas geht, sondern auch um die Performance.

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

Ist natürlich richtig, aber ich schreib lieber für mich verständlichen Code, als einen herzunehmen den ich nicht verstehe und bei mir einfüge.
Wenn das ganze dann nicht performant läuft, überleg ich mir entweder was neues, oder ich schau mal was ich im Internet finde und versuche das zu verstehen.

Hallo erin,
Ich habe mir die Berechnungsgrundlagen von Jorrit Rouwé heruntergeladen und ein wenig durchgeackert.

Grundsätzlich macht er es so:

Wenn man der Frage nachgeht, ob eine bewegte Kugel ein Polygon schneiden wird, dann kommt man zunächst unweigerlich zum Problem, ob die Kugel die Polygonebene schneiden wird. Der Berechnng, wann das sein wird, widmet er sich in Kapitel "3.1 Swept Sphere Versus Plane", wobei er hier im 3D Raum rechnet.

Ab hier wechselt er zum 2D Raum, dh. er projiziert alles auf die Polygonebene. Hier schaut das Ganze natürlich etwas anders aus: Kapitel "3.2 Swep Circle Versus Polygon". Zunächst habe ich mich an der Formulierung aufgehängt: "The Intersection between the sphere and the plane is a circle with a radius that varies along the path." Naja, gestern abend wars schon sehr spät. Heute morgen war mir dann klar, was er meint.

Also gut, um die Berechnung etwas weniger komplex zu machen, projiziert er alles auf die Polygon-Ebene und begibt sich damit auf 2D. Dabei handelt er sich aber ein Problem ein, das er vorher nicht hatte: wenn die Kugel durch die Ebene rauscht, ändert der Schnittkreis kontiniuerlich seinen Radius: 0 => KugelRadius => 0, so wie man auf dem Bild sieht, das er auf Seite 4 seines PDF-Files hat. Aus diesem Grund kriegt er in weiterer Folge dann eine quadratische Gleichung. Imho würde er sich das sparen, wenn er auf 3D geblieben wäre, denn die 3D Kugel ändert in unserer Aufgabenstellung ihren Radius ja nicht.

Ein Objekt, das fortwährend seine Gestalt ändert, ist mathematisch komplizierter zu behandeln als etwas, was gleich bleibt.

Vom grundsätzlichen Standpunkt kann er aber seine Aufgabe jetzt in 2D lösen.

Das Folgende bezieht sich auf das Kapitel: 3.5 Swept Circle Versus 3D Edge

Das ist im Prinzip jetzt nur mehr ein einfacher Test, aber er wird dadurch komplizierter, dass

a) der Kreis sich auf der Ebene bewegt (außer die Kugel nimmt eine Bahn durch die Ebene, die normal zur Ebene steht),
und zwar NICHT in gleicher Weise, wie sich die Kugel bewegt
b) sich der Schrittkreis (von der Ebene gesehen) kontinuierlich in der Größe verändert.

Ich habe mich noch nicht ganz durch die Berechnung durchgebissen, weil ich im Augenblick bei der Bezeichnung "current closest fraction" stecke.

Also, wenn er dann festgestellt hat, dass der Kreis die Kanten-Gerade schneidet, muss er schlussendlich noch feststellen, ob dieser Schnittpunkt auch auf der Polygonkante liegt.

So weit, so gut.

Was ich dazu anmerken möchte:


Ich würde Dir empfehlen, hier nicht das Verb "zugegeben" zu verwenden. In meinen Augen hast Du das auf eine offene und klare Weise gehandhabt. Ich nenne das "professionell behandelt". Klingt gleich viel besser und kommt meiner Meinung auch der Wahrheit viel näher.

Viele Grüße
Traude

Warum nicht? Wer will schon behaupten, er hätte alles jederzeit im Griff. Manche tun so und müssen sich unauffällig trollen, der berühmte Zacken in der Krone ...

Egal, Hauptsache ist doch die Freude am Funktionieren, und wenn man dann noch versteht, warum es funktioniert - umso besser. Noch schöner ist es, wenn andere es ebenfalls zum Funktionieren bringen.

Zum Aufsatz von Rouwe: Soweit ich mich erinnere, hat er alles erst mal alles auf 2D reduziert und dann in 3D transportiert. Diesen Vorgang habe ich als unheimlich umständlich empfunden, und irgendwo schien mir da eine Lücke zu klaffen. Der Code von Rouwe war (für mich jedenfalls) verständlicher als seine mathematische Beschreibung. Vielleicht schaust du den Code ebenfalls an, auch wenn er in C geschrieben ist. So groß sind die Unterschiede nicht.

Hallo Erin,
Ich bin noch nicht fertig, aus mehreren Gründen:

Erstens habe ich die Gelegenheit ergriffen und stelle ein Programm her, das noch Benchmarking auch können soll. Das bedeutet mehr Programm code.

Zweitens ist das Herstellen einer Simluation, die das Ganze visualisieren soll, keine triviale Aufgabe, aber das habe ich schon fertiggestellt - ich habe eine einfache Simulation eingebaut, wo die beiden Protagonisten (eine Kugel und ein Dreieck) die Fabe wechseln, wenn sie kollidieren.

Drittens stehe ich grade vor einem Problem, mit dem ich nicht gerechnet habe: ich habe drei ganz simple lineare Gleichungen mit drei Variablen, die sollte man eigentlich algebraisch mit Matrizenrechnung lösen können, aber ich steh grade auf dem Schlauch, wie ich das programmtechnisch in den Griff kriege.

Und viertens bin ich ein elender Perfektionist und mag keine halben Sachen abliefern. Die Berechnung des eigentlichen Problems ist erst zur Hälfte fertig. Ich bin auch draufgekommen, dass meine Lösung nicht funktioniert. Dafür kann ich aber jetzt mit einer neuen Lösung aufwarten, die sicher funktioniert und auch keine quadratischen Gleichungen beinhaltet. Wenn ich fertig bin, stelle ich hier ein Bildchen als Dokumentation dazu, das auf einen Blick erkennen lassen sollte, wie ich es gemacht habe.

Naja, und ich brauch noch rund zwei Tage.

Ein Hinweis für Flash: Das Benchmarking funktioniert schon. Der Aufbau des Ganzen ist aber noch nicht wirklich so, dass sich ein Dritter auskennt, da muss ich noch dran feilen. Die erste Version für erin wird fürchte ich fürs Benchmarking aber noch ungeeignet sein: es ist eine Schrift notwendig und derzeit braucht meine Schrift die FreeType Library, und das möchte ich noch ändern, indem ich einfach eine gespeicherte Schrifttextur benutze. Das dauert aber zusätzlich noch ein Weilchen. Sollte jemand so einen Code zur Verfügung haben, so bitte ich um eine Codespende.

Traude

Danke, dass du das Thema Benchmark angehst. Du willst dann die beiden Kollisionsmechanismen miteinander vergleichen? Das klingt interessant - und aufwändig. Da du beide implementieren musst. Aber interessant ist es auf alle Fälle!

Wegen Texturefonts: Sowas sollte im Umlauf sein. Wer da ein Stück Code zur Verfügung hat, bitte hier posten inklusive Textur und Koordinaten. Das kann man dann ins Wiki hängen.
Lossys Lib ist natürlich noch besser als das, aber ich weiß nicht, ob das nicht die Messung beeinflusst. Da Lossy ja situationsbedingt die Textur erzeugt. Wir brauchen irgendwas stupides, dass immer gleich funktioniert und damit sich nur als Konstante in der Messung niederschlägt.

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

Ja, zu große Libraries sind hier fehl am Platz. Am besten sollte es überhaupt keine Abhängigkeiten geben.

Ich habe mir heute die Hacken abgelaufen nach dem Swept-Shpere/Edge-State-Of-the Art-Algorithmus, gibt aber nicht viel. Ich muss daher morgen nochmal eine Session im stillen Kämmerchen einlegen. Ich hatte zwar heute morgen eine Idee, die ganz offfensichtich in die richtige Richtung geht, aber mit mathematischen Schwierigkeiten verbunden ist.

sowas stupides hab ich hier noch rumliegen, inklusive Textur und einfach zu bedienen. Ich such das mal gleich rauß. Ich hab Die Klasse mal vor ein paar Jahren geschrieben um so stumpf und schnell wie möglich ein paar Zeilen in OpenGl zu schreiben. Hab das hin und wieder mal etwas überarbeitet, aber für den Zweck sollte es ideal sein. ... Es ging doch um simple Typographie, oder?

_________________
Klar Soweit?