Oh, stimmt habe ich nicht ganau genug hingeschaut...
Der fehler ist ein rundungsfehler.
Ich habe in der betreffendedn funktion alles von single auf extended umgestellt (frisst nur minimal performance, weil die funktion nicht oft benötigt wird) und dachte, jetzt müssten die rundungsfehler so extrem selten auftreten, dass es garnicht mehr auffällt. naja verdacht
Muss ich mir wohl noch was einfallen lassen.

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

Numerikfehler sind in der CompGrafik echt zum Kotzen. Bei meinem Atomsimulator flackern andauernd die Polygone der Atombindungen. Ich denke bei mir liegt das auch an Rundungsfehlern. Eigentlich ist die einzige Möglichkeit das flackern wegzugriegen, die Mathe genauer zu machen, die ergebnisse dann aber grob zu runden. (in der Hoffnung dadurch nur seltener Fehler zu erhalten)

Wenn jemand ne Lösung findet soll er die mal unbedingt vermelden. Bin da auch interessiert.

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

Bei mir tritt der Fehler wie folgt auf:

eine Function wandelt eine Vektorbasis ind 3 Winkel um:

(der erste Winkel dreht um die x-achse der zweite um die entstandene y-achse, der dritte um die neu entstandene z-achse,
Die Vektorbasis braucht meine physikengine, die drei Winkel braucht opengl zum rendern)

Ich denke, der Fehler tritt immer dann auf, wenn ein Vektor der Basis fast genau in x,y oder z Richtung zeigt (also die werte (1,0,0), (0,1,0, oder (0,0,1) annimmt).

Ich müsste jetzt jeden dieser Spezialfälle (3vektoren * 3möglichkeiten = 9 Fälle) abtesten und falls er eintritt eine entsprechende Berechnung für diesen fall schreiben.

Diese Berechnungen wären zwar fiel einfacher als der allgemeine Fall, dar zwei Winkel (jeh nach Fall) etweder 0 oder pi/2 oder pi oder 3pi/2 sind, und nur der dritte berechnet werden müsste, aber ich habe einfach keine lust dass alles aufzuschreiben und zu überdenken

Außerdem würden die Abtestungen der 9 Fälle wohl oder übel die Pperformance drücken.

Ich denke aber, wenn man die Bberechnung einer Rotationsmatrix ausenander nimmt, müsste es das auch eine optimiertere Möglichkeit als meine ergeben.

p.s. ich stelle wenn ich zeit habe mal meine geometry unit auf meine homepage, falls es jemanden interessiert.

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

Du schreibst, es gäbe Probleme mit der Reibung da die Füße des Robos rutschen würden. Da muss ich dich beglückwünschen. In der Praxis ist das ja ganz genauso. Wenn du mal die 6Beiner laufen siehst, wird dir auffallen, dass das kein gleichmäßiges Vorwärts ist sondern ein ziemlich rumgerutsche welches Vorwärts gerichtet ist .

Also so verkehrt ist das Reibungsmodell dann doch nicht.

PS: Ich glaube das rutschen verschwindet bei den realen Robos durch ihr zunehmend imenses Gewicht. Nur so als Tip.

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

Das mit dem gewicht geht nicht... Wenn mann das gewicht erhöht steigt zwar die reibung, aber die benötigte kraft steigt ebenfalls!
Das problem ist, dass ich das rutschen der füße nicht durch erhöhen der reibungskonstanten in den griff bekomme!?!

außerdem können z.b. kleine änderungen in der simulationsgeschwindigkeit, den härtekonstanten u.s.w. die laufeigenschaften des Roboters erhäblich beeinflussen...
Es könnte also sein, dass der Roboter bei jemandem mit einem schnelleren prozessor als ich ihn habe deutlich lansamer läuft als bei mir

Naja, wie gesagt ich arbeite drann. Ich habe gedacht, eventuell könnte mann mit nem aufwendigerem iterationsverfahren was erreichen... mahl sehen.

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

Hi!
Ist ja ziemlich lustig mit dem Roboter
Ich wollte nur anmerken, dass in der Demo die Sicht ziemlich blöd ist! Die Kamera kreist um den Mittelpunkt der Fläche, aber der Roboter startet an der Seite, das Resultat ist, dass man den Roboter kaum zu sehen bekommt.

jep. is zwar ne coole demo, aber nicht wirklich ausgereift. und die vier buttons sind fies.....

_________________


"User Error. Replace User and hit Continue."

Also da kann ich luketheduke nicht ganz zustimmen. Zwar musst du hier und da noch feilen, aber das Ganze ist ja eine "Demo", soll also nur anschaulich deine Arbeit darstellen. Und dazu taugts ja einwandfrei, bis auf die Kameraführung
Also physikalisch schauts wahnsinnig gut aus, hab nicht gedacht, das sich in Zeiten von Newton noch so genau mit Physik beschäftigt. Weiter so!

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Na gut, habe noch ne Demo hochgeladen. jetzt ist die kamera auf den Roboter gerichtet, es gibt ne Onboard Kamera und man kann den Roboter steuern

Es ist ja leider noch etwas unausgereift... Aber danke für den Lob

edit: und noch mal neu hochgeladen (nur die 1.0b demo). Habe jetzt was am reibungsmaodell verbessert... Wackelt zwar mehr als vorher, rutscht aber nicht mehr ganz so stark.

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

Genial mit der OnBoard Kamera.
Find ich cool wie der Roboter da rumwackelt, hat was

_________________
www.audi32.de

Kanns sein dass in der neuen Version die Tasten nicht mehr da sind? Bei mir werden jedenfalls keine angezeigt... o_O

sorry, habe die tasten nur in der 1.0 und die neue kamera und die steuerung nur in der 1.0b ... Ähm ... vielleicht update ich dass heute nacht noch mal.

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