Abwicklung - unfold by rotations to a net

hawe shared this question 1 month ago
Answered

Beim Abwickeln eines 3D Körpers zu einem Netz finde ich es sehr schick, wenn die Polygonflächen über alle Kanten rotierten. Bei einem regelmäßigen 7-Eck-Prisma sind das 7 geschachtelte Rotationen, z.B.

https://www.geogebra.org/m/ggc2pmzy

per script zusammen geführt z.B.

/wG8XE0R8H9bnwAAAABJRU5ErkJggg==

hat jemand eine bessere Idee dazu - ein alternatives Verfahren?

Zumal die App instabil wird bei zu vielen Rotations-Kanten...


Hallo Michael,

gibt es eine Grenze für geschachtelte Commands?

Best Answer
photo

Hab mal eine Version angehängt, die die neuen Positionen der unteren Ecken berechnet. War nur etwas Sequence und Zip nötig: Erst Liste der Gesamt-Rotationswinkel, damit die Liste der unteren Kanten einfach um die z-Achse rotiert (hab genaugenommen keine Kantenliste sondern 2 Punktlisten genommen, aber kann man natürlich mit den Kanten oder Flächen gesamt machen), dann noch die Differenzliste, davon die Partialsummenliste, plus eine Punktaddition und schon hat man die finalen Punkte. Kann man noch ein bisschen vereinfachen, wenn man will.

Comments (3)

photo
1

Evtl. ist es effizienter, für jede Fläche erst die Gesamtbewegung zu berechnen und dann auszuführen anstatt alle Rotationen einzeln auszuführen. Keine Ahnung, ob Geogebra da etwas schickes Einfaches hat, aber im Notfall selber berechnen. Da es nur um Prismen geht und Du die Deckflächen anscheinend auch unabhängig abrollst, behalten alle Rotationsachsen ja ihre Richtung bei, sind also praktisch alles "nur" Rotationen in 2D und sollte die Berechnung etwas einfacher machen. Die zu berechnende Achse der Gesamtrotation behält ja die Richtung bei. (Oder man nimmt eine Standardachse, muss dann aber noch eine Verschiebung berechnen.) Evtl. hilft es, den "Trick" der Comutergraphik zu nutzen und mit einer Extra-Dimension zu arbeiten, um auch Translationen mit einer Matrix-Multiplikation darstellen zu können. (Also "helfen" im Sinne des einfacheren Formulierens, nicht der Geschwindigkeit wegen. GeoGebra ist ja vermutlich nicht auf effiziente Matrixmultiplikation getrimmt.)

Außerdem lassen sich die Gesamtbewegungen ja prinzipiell sukzessive berechnen, für jede weitere Seitenfläche kommt noch eine Bewegung hinzu. Damit könnte der Iteration-Befehl hier sehr nützlich sein, um eine Liste dieser Bewegungen zu berechnen.


PS: Bei den Berechnungen geht übrigens irgendwas schief, wenn man r verändert.

photo
2

Hab mal eine Version angehängt, die die neuen Positionen der unteren Ecken berechnet. War nur etwas Sequence und Zip nötig: Erst Liste der Gesamt-Rotationswinkel, damit die Liste der unteren Kanten einfach um die z-Achse rotiert (hab genaugenommen keine Kantenliste sondern 2 Punktlisten genommen, aber kann man natürlich mit den Kanten oder Flächen gesamt machen), dann noch die Differenzliste, davon die Partialsummenliste, plus eine Punktaddition und schon hat man die finalen Punkte. Kann man noch ein bisschen vereinfachen, wenn man will.

photo
1

Vielen Dank fürs Mitdenken - super Ansatz gefällt mir sehr...

Ich muss Dein Verfahren noch etwas analysieren - ein kleiner Fehler in NetVerticesU (7->n) gefunden.

Die Polygone der Seitenflächen eingebaut

NetFaces=Flatten({{Polygon(VerticesU(n), VerticesO(n), NetVerticesU(1) + (0, 0, h), NetVerticesU(1))}, Sequence(Polygon(NetVerticesU(k), NetVerticesU(k) + (0, 0, h), NetVerticesU(Mod(k, n) + 1) + (0, 0, h), NetVerticesU(Mod(k, n) + 1)), k, 1, n - 1)})

und schwubs hab ich wieder die gleichen Instabilitäten wie bei meinem Modell auch. Wenn ich t_0 als Animation laufen lasse, dann gehen die Listen

NetVerticesU und NetFaces nach einigen Durchläufen ins Nirwana ein. Die Liste der NetVerticesU allein scheint durchzuhalten...

Das Problem hatte ich schon öffter mit Manipulationen an längeren Listen...

photo
© 2021 International GeoGebra Institute