Hallo, ich könnte ein paar Ideen zu 3D Transfomartionen brauchen :) Ich hab 8x8x8 "Pixel" in 64 Bytes organisiert. Ich habe ein klein wenig Ahnung von 3D Transformationen, von Matrizen aber sowieso ;) Allerdings ist mir nicht ganz klar, wie ich das ganze sinnvoll und "performant" machen kann. Folgende Überlegungen hab ich bisher angestellt: Um eine Rotation machen zu können, brauche ich eine 8x8x8 Matrix aus Festkommawerten. Dann muss ich meine Datenstruktur mit dieser Matrix multiplizieren. Das ganze wird ziemlich teuer und groß, wenn ich meine Datenstruktur in eine Matrix konvertiere und diese dann gegen die Rotationsmatrix (und dann ja noch andere Transformationsmatrizen). Verschiebungen kann ich ja noch durch Bitshiftereien lösen, aber drehen, skalieren, ...? Das Ganze spielt auf nem Atmega. Gruß Mr.Green
Gibts bei den Projekten nicht einen LED-cube? Ich mein im dazugehörigen source solltest du etwas 'passendes' finden...
Also die Idee ist in der Tat so wie du sie beschrieben hast. Sollte doch ohnr Probleme auf deinem AVR möglich sein? Du multiplizierst zuerst alle Abbildungsmatrizen miteinander und dann diese Matrix der gesamt Abbildung mit der Bildmatrix.
Ja so müsste es schon funktionieren, ich stells mir aber recht "fett" vor. Meine Datenstruktur in eine Matrix wandeln, 512 Floats als Matrix z.B. für die Drehung nach rechts, 512 Floats für Drehung nach xxx...
Float?? das geht auch mit Festkomma-Arithmetik. Ich nehme an, du willst mit einem Byte jeweils einen bestimmten Zahlenraum abbilden. Hier gehe ich mal von -1 bis +1 aus. -128 bildet also "-1" ab, 0 ist die "0" und 127ist dann (127/128) = 0.9921875. Zwei Zahlen (signed char) werden Multipliziert und dann das Ergebnis um 7 geschoben. So passt es dann auch wieder in ein signed 8bit rein. Zuviele Multiplikationen machen allerdings das Ergebnis klein und rundungsfehler-behaftet. Du könntest auch mit "Minifloats" Arbeiten. Dazu deine Matrizen doppeln und in einer Matrix die Mantisse, in der anderen die Exponenten speichern. Nun wie gewohnt die Mantissen Multiplizieren. Danach nach hinten schieben bis das ganze wieder in Float rein passt. Die Anzahl der Schiebungen nach hinten muss dann auf die Summe der Exponenten beider Multiplikatoren dazugerechnet werden. Bei Additionen muss eine Unterscheidung eingebaut werden, ob einer der beiden Summanden zu klein ist(zu kleinen Exponenten aufweist), um das Ergebnis überhaupt noch zu beeinflussen. Als Referenz muss logischerweise die Zahl mit dem Größeren Exponenten genommen werden. \0
\0 schrieb: > bis das ganze wieder in Float rein passt Ich meinte natürlich "bis das ganze wieder z.B. in ein 8bit-char rein passt" Ein Minifloat kannst du dann z.B. mit einer Struktur sehr gut verwalten.
Moin Chris, kannst Du Dich auf wenige mögliche Drehungen um die Mitte beschränken? Dann reichen Dir je nach Drehung verschieden große "Offsettabellen" wenn Du die Symmetrien ausnutzt und mit Fallunterscheidungen arbeitest. Mit den einfachsten Drehungen beginnend: Für 90°,180° brauchst Du keine Tabelle, nur Fallunerscheidung für jede Achse Für 45° um eine Koordinatenachse reichen 4x4 Werte a 3+3 Bit, (mehr als 3 Pixel kann sich kein Wert verschieben) Pseudocode ohne Bitshifterei: NeueMatrix[x][y][z] = UrsprungsMatrix[x + OffsAusTabelle[i]][y + OffsAusTabelle[i+1] ][z] usw. Und die Wertetabellen erstellt Du vorher. Schiko
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.