PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : XNA PlaneIntersectionType


del_4901
2008-06-16, 11:19:03
Kann mir einer mal bitte dieses Verhalten erklären? (XNA GS 2.0)

Vector3[] ptr = new Vector3[2];
ptr[0] = new Vector3(24, 0, 0);
ptr[1] = new Vector3(25, 0, 0);
BoundingBox bb = BoundingBox.CreateFromPoints(ptr);
Plane plane = new Plane(new Vector3(1, 0, 0), 24.5f);

PlaneIntersectionType pty = plane.Intersects(bb);
if (pty == PlaneIntersectionType.Front)
Console.WriteLine("This is Bullshit");

Plane plane2 = new Plane(new Vector3(1, 0, 0), -24.5f);
pty = plane2.Intersects(bb);
if (pty == PlaneIntersectionType.Intersecting)
Console.WriteLine("WTF, this is working??");

Das ist doch nicht wirklich so gewollt??? Oder etwa doch?
http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.plane.aspx
Also ich bin verwirrt, wer weiß welcher Praktikant das da gecodet hat.

Oder ist das vllt. nur bei mir so?

Gast
2008-06-16, 19:41:51
Die Dokumentation zur BoundingBox sagt:


There are a few drawbacks of using the bounding box for collision detection.
[...]
Empty space in the bounding box can result in false positives when checking for collision.


Ich denke das ist hier die Ursache des Problems. Der Spezialfall einer BoundingBox ohne Volumen wird bei den Kollisionstests nicht berücksichtigt. Also Vorsicht mit solchen Konstruktionen.

del_4901
2008-06-16, 19:52:38
Die Dokumentation zur BoundingBox sagt:


There are a few drawbacks of using the bounding box for collision detection.
[...]
Empty space in the bounding box can result in false positives when checking for collision.


Ich denke das ist hier die Ursache des Problems. Der Spezialfall einer BoundingBox ohne Volumen wird bei den Kollisionstests nicht berücksichtigt. Also Vorsicht mit solchen Konstruktionen.
Nee das hat ausnahmsweise damit mal niks zu tun, ich kann auch mit (24,1,1) testen, kommt das selbe bei raus.

Gast
2008-06-16, 19:58:35
Hm es könnte sein, dass die Distanz anders herum gemessen wird. Laut Dokumentation ist es ja die Distanz vom Ursprung entlang des Normalenvektors.
Ich nehme mal an, wenn der Ursprung in Richtung des Normalenvektors liegt ist D positiv, ansonsten (wie hier) negativ.

Wenn man sich den Code im Reflector ansieht scheint das zu passen. Der Konstruktor, welcher die Ebene aus drei Punkten erstellt setzt D wie folgt:


this.D = -(((this.Normal.X * point1.X) + (this.Normal.Y * point1.Y)) + (this.Normal.Z * point1.Z));


Nimmt man also N=(1,0,0) und P=(24.5, 0, 0) kommt -24.5 raus.

del_4901
2008-06-16, 20:02:06
Hm es könnte sein, dass die Distanz anders herum gemessen wird. Laut Dokumentation ist es ja die Distanz vom Ursprung entlang des Normalenvektors.
Ich nehme mal an, wenn der Ursprung in Richtung des Normalenvektors liegt ist D positiv, ansonsten (wie hier) negativ.

Wenn man sich den Code im Reflector ansieht scheint das zu passen. Der Konstruktor, welcher die Ebene aus drei Punkten erstellt setzt D wie folgt:


this.D = -(((this.Normal.X * point1.X) + (this.Normal.Y * point1.Y)) + (this.Normal.Z * point1.Z));


Nimmt man also N=(1,0,0) und P=(24.5, 0, 0) kommt -24.5 raus.

Der Debugger zeigt mir D genau so an, wie ich es gesetzt habe. Da soll mal einer durchsehen.

Gast
2008-06-16, 20:03:10
Ich denke das ist einfach nur unzureichend dokumentiert. "Entlang des Normalenvektors" soll denke ich heißen, dass die Distanz für Punkte in Richtung des Normalenvektors ansteigt und in der Gegenrichtung sinkt. Da der Ursprung hier in der Gegenrichtung liegt ist die Distanz wohl negativ.

Gast
2008-06-16, 20:05:14
Der Debugger zeigt mir D genau so an, wie ich es gesetzt habe. Da soll mal einer durchsehen.

Das ist schon richtig. D wird genauso wie angegeben gespeichert. Aber es wird beim Kollisionstest auf die gemessene Distanz in Richtung des Normalenvektors draufaddiert und nicht subtrahiert.


float num = ((this.Normal.X * vector2.X) + (this.Normal.Y * vector2.Y)) + (this.Normal.Z * vector2.Z);
if ((num + this.D) > 0f)
{
return PlaneIntersectionType.Front;
}
[...]

del_4901
2008-06-16, 20:05:31
Ich denke das ist einfach nur unzureichend dokumentiert. "Entlang des Normalenvektors" soll denke ich heißen, dass die Distanz für Punkte in Richtung des Normalenvektors ansteigt und in der Gegenrichtung sinkt. Da der Ursprung hier in der Gegenrichtung liegt ist die Distanz wohl negativ.
Eins von beiden ist es definitiv, entweder unzureichend dokumentiert, oder einfach nur verbuggt. Denn "entlang des Normalenvektors" heißt für mich, das wenn ich den Normalenvektor um die Distanz verlängere, ich auf einem Punkt der Ebene liege.

Gast
2008-06-16, 21:41:55
Naja die Frage ist ja: sieht man das vom Ursprung aus oder von der Ebene? Sieh es mal anders herum. Leg den Normalenvektor auf die Ebene. Wenn du ihn um die (diesmal negative) Distanz verlängerst landest du im Ursprung. Ich denke das ist schon so gedacht (und kein Bug), aber eben recht ungenau dokumentiert.

del_4901
2008-06-16, 22:04:00
Naja die Frage ist ja: sieht man das vom Ursprung aus oder von der Ebene? Sieh es mal anders herum. Leg den Normalenvektor auf die Ebene. Wenn du ihn um die (diesmal negative) Distanz verlängerst landest du im Ursprung. Ich denke das ist schon so gedacht (und kein Bug), aber eben recht ungenau dokumentiert.
Da steht eindeutig "from the origin" es ist also nicht nur ungenau sondern falsch dokumentiert.

Xmas
2008-06-17, 00:03:39
Die übliche Ebenengleichung ist A * x + B * y + C * z + D = 0.

del_4901
2008-06-17, 00:14:06
Die übliche Ebenengleichung ist A * x + B * y + C * z + D = 0.
Aber nicht in der Mathematik nach der hesseschen Normalform ist es A * x + B * y + C * z - D = 0 oder auch <Vn * Vp> = D