Hallo,

ich habe ein kleines Problem und zwar versuche ich mir an zig kleinen selbstgeschriebenen Demos Partikel -systeme & -verhaltensweisen beizubringen.
Ich bin momentan bei folgendem Problem:

Wie kann man in untenstehender Skizze herausfinen, wohin der Punkt abprallt?

Wie hier in der Skizze Soll mein Programm eine Bitmap einlesen und alles Schwarze als Kollisionspunkt erkennen.
Das Problem ist: Wie bekommt man heraus, was für eine Linie vorliegt, also letztendlich wohin der Punkt abprallt.

Vielleicht hat ja jemand eine spontane Idee?!

PS: Ich habe schon eine Lösung, nur die ist extrem buggy...

PPS: Mir liegen die "Kollisionspunkte" als Array vor; die Partikel an sich sind kein Problem

Muss es ein Bild als Ausgangsbasis sein?

Wenn du's schaffst aus den Bildinformationen Vektoren zu machen hast du gute Chancen dass zu berechnen. Nur...sowas rauszufinden is quasi Bilderkennung. Das wird dann gerne Komplex. Du solltest lieber ein Format einlesen, wo von den Linen Start und Endpunkte gegeben sind. Da kannst du dann leicht Vektoren draus machen und per Schnittwinkelberechnung denn neuen Bewegungsvektor berechnen.

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

ohne reibung und trägheit machst du auf deine linie einen rechten winkel dort wo partikel und linie aufeinandertreffen, und spiegelst dein partikel daran. das partikel läuft dann zu dem schnittpuhkt und dann zum gespiegelten partikel hin. theoretisch.

_________________


"User Error. Replace User and hit Continue."

Das ist leider nur allzu wahr. Um die Normale von solch einer gerasterten Linie zu bekommen, musst du dich der Bilderkennung bedienen. Corel Draw hat AFAIK eine Funktion, die nennt sich Vektorisierung. Funktioniert angeblich recht gut. Aber ich glaube kaum, dass du sowas selber nachbauen willst. Also bleibt dir wohl nur noch übrig, ein anderes Format zu verwenden.

Im 3D Studio Max würde man z.B. für dein Problem einen sog. Deflektor benutzen. Der bezieht seine Position allerdings auch nicht aus einem Bild... Oder einem Array, was ja im Prinzip das gleiche ist.

Mir fällt jetzt spontan nur eine Möglichkeit ein, das ganze relativ einfach zu berechnen:
Geh mal mit deinem geistigen Auge an die Stelle, wo dein blauer Punkt ist.
Geh dann so weit nach unten, bis du den ersten Pixel deiner Linie erreicht hast.
Prüfe dann, ob sich links oder rechts ein Pixel der Lnie befindet.
Wenn links einer ist (so wie hier), dann gehe einen Pixel nach rechts.
Merke dir die aktuelle Position.
Gehe jetzt wieder so weit nach unten, bis du einen Pixel deiner Linie erreicht hast.
Merke dir auch diese Position.

Du hast jetzt zwei Positionen. Wenn du von dem Y-Wert der letzten Position den Y-Wert der ersten Position abziehst, bekommst du die Länge der Strecke. Je größer dieser Wert ist, umso länger ist die Strecke, umso steiler geht es bergab.

Mithilfe von Trigonometrie solltest du dann den Steigungswinkel bekommen können.

EDIT:
Hier noch ein Bild. Hoffe, das ganze halbwegs verständlich ausgedrückt zu haben

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Und wenn die Linie Senkrecht ist, haste ne nette Endlosschleife -> Spezialfälle abdecken -> wieder mehr arbeit -> Mist ... hätt ich nur die Ausgangsbasis anders gewählt.

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

nicht zu vergessen das man bei solche linien nicht umbedingt all diese Abschnitte auf gleicher x Koordinate gleich lang sein müssen, wenn man nicht grad sehr ausgewählte steigungen hat => für genaue Werte noch mehr Arbeit

Du könntest folgendes machen, wenn kollision dann:

du guckst dir die umliegenden z.b: 7 mal 7 (oder 5 mal 5) Pixel an.
wenn einer schwarz ist, berechnest du den neuen geschwindigkeitsvektor, der enstehen würde, wenn dein Partikel an einer geraden apprallt, welche durch seine Position und den schwarzen punkt geht.

Sind etwa 10 punkte von den 49 schwarz, dann nimmst machst du das für diese 10 punkte und nimmst den mittelwert der berechneten vektoren

Das sollte ne zuverlässige Näherung geben und wenn mans optimiert dauerts denke ich mal nicht all zu lange!?!?

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Danke für die vielen (sehr guten) Ideen.

An Frase's Überlegungen habe ich mich auch mal versucht und eine - wie oben gesagt - sehr Anfällige Methode entwickelt.
Es gibt leider zu viele Ausnahmen...

Der letzte Vorschlag von geo ist sehr interessant. Mal sehen, ob ich das in den nächsten Tagen mal so ausprobiere. (Klausuren stehen vor der Tür. Daher wenig Zeit...)

Also ich weiß ja nicht in wie weit du dich damit auskennst und das halbwegs sinnvoll umsetztbar ist. Aber ich persönlich würde dann gleich Nägel mit Köpfen machen. Also bevor man da etwas hinfummelt was im Endeffekt wahrscheinlich nicht wirklich schnell sein dürfte könnte man sich ja mal umschauen ob es nicht ähnliche Fälle gibt.

Forenadmin Sascha Willems hat auf seiner Seite unter dem Menüpunkt Newton ein paar interesante Beispiele veröffentlicht die deinen Anforderungen verdammt ähnlich sind. Evtl wäre das sogar die "einfachste" und optimalste Lösung.

Ich denke das ganze selber zu schreiben ist auch nicht schwer. du musst erstmal deine "map" (ich nenn die bilddatei mal so) einlesen und die soliden stellen finden und in wände(,linien,ebenen .. wie auch immer) zerteilen (dazu gleich mehr). Wenn du das geschafft hast, ist die kollision recht einfach wie luketheduke schon beschrieben hat (glaub ich). Ist ja dann nur n bissle Vector rumgerechne.
So nun zum größeren Problem, wie bekommt man aus der bilddatei ne map. Mein Vorschlag hat den nachteil, dass du nur linien mit einer stärke von 1pixel setzten darfst.
du gehst dann alle pixel des bildes durch und wie in einer art floodfill von jedem soliden pixel zu seinen nachbarn(also den pixeln die auch auf der linie liegen).
wenn du an einer stelle nicht weiter kommst, hast du das ende der linie erreicht. schon kannst du die ebenen-gleichung aufstellen(rictung der linie = startpixelpos-posDesEreichtenEndpixels)(normalvector der ebene ist dann auch kein prob).
Das klappt schonmal in allen Fällen, wo sich keine Linien überschneiden.
Für diesen Fall musst du noch bei jedem abgearbeiteten Pixel prüfen ob er auf der linie, die bisher entstanden ist(nach der oben genannten formel) liegt, bzw. nur in einem gewissen toleranzbereich abweicht. wenn die abweichung zu groß ist liegt er wahrsceinlich nicht au der linie und du sellst den pixel nochmal zurück um später von dem aus nochmal zu starten("floodfill").
Das bedeutet, du musst nicht nur aus performance-gründen(obwohl die hier zu vernachlässigen sind, ist ja pre-runtime) sondern auch wegen des algorithmus ein kontroll array inder größe des bildes haben, um die infos über jeden pixel zu speichern (ob er schon geprüft wurde oder nicht).

wenn man an der idee einwenig dran herumtüfteltmüsste das so gehen wie du dir das vorgestellt hast. hoffe ich konnte helfen.

_________________
www.extrawurst.org

Noch eine andere Möglichkeit:

Wenn du es schaffst, den Anfangspunkt und den Endpunkt der Linie zu ermitteln, dann hast du schon die halbe Miete. Du kannst dann nämlich die Breite und die Höhe der Linie bestimmen.

Den Anfangs/Endpunkt bekommt man ganz einfach. Man muss nur z.B. von links nach rechts alle Spalten im Bild durchgehen. Sobald in einer Spalte ein schwarzer Pixel ist, weiß man, dass er zur Linie gehört. Und beim ersten Entdecken eines schwarzen Pixels hat man ja logischerweise einen der Endpunkte.
Für den Endpunkt macht man es genau andersherum. Hat den Vorteil, dass die oben angesprochene Ungenauigkeit und Fehleranfälligkeit weitgehend ausgemerzt sein dürfte.

Schwieriger wird das ganze, wenn 2 Linien sich schneiden... Aber im Moment scheint es ja nur eine Linie zu geben

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

frase, dass deckt sich ziemlich mit meiner idee,ne...
wobei ich auch das sich schneiden zweier linien löse

_________________
www.extrawurst.org