Hallo,

Ich möchte eine Scheibe rotieren, auf der am Rande Zahlen
sind, nur das die Zahlen ihre senkrechte-lesbare Position
beibehalten sollen. Das gelingt mir zwar schon, indem ich
die Zahlen vorher auf Ihren Ursprung zurückführe, dann
entgegengesetzt rotiere und wieder an den Ort auf der Scheibe
schiebe, aber vielleicht gibt's da eine Einfache Function oder
Verfahrensweise, die nicht so viel Performance kostet?


Vielen Dank für's reinschauen.

hi,
mmh mal sehen
du zeichnest eine scheibe und drehst ("rotationswinkel") die dann, richtig?
danach zeichnest du zahlen die "an der scheibe locker hängen soll", richtig?
die zahlen befinden sich an bei einem bestimmten winkel ("positionswinkel") an der scheibe, richtig?

also dann könntest du die scheibe zwischen glpushmatrix() und glpopmatrix() drehen und zeichnen und danach die position der zahlen berechnen
ich geh mal davon aus das 0° oben in der mitte der scheibe sind:
X= sin(degtorad(rotationswinkel+positionswinkel))*radius;
Y= cos(degtorad(rotationswinkel+positionswinkel))*radius;

ich hoffe mal
1. das deine frage richtig verstanden habe,
2. das ich dir irgendwie helfen konnte.

_________________
ghost-site.de

Danke für die Antwort, alles richtig erkannt. Werde Deine Vorschalg ausprobieren.
Kann mir aber vorstellen, das die Berrechnungen Performance kosten.

Also was ich bisher habe:




Was wäre jetzt rein rechentechnisch besser (schneller) ?
Ich könnts sicher irgendwie messen, aber vielleicht gibt's da
schon Erfahrungswerte.

Viele Grüsse Tom.

die antwort liegt jetzt aber mal auf der hand:

was ist nun schneller? für jede zahl die du zeichnest die modelviewmatrix auf den stack schreiben, einpaar matrixtransformationen machen und die matrix wieder von stack nehmen oder mal kurz einen sinus und einen cosinus errechnnen?

kannst du dir die richtige anwort denken?

_________________
ghost-site.de

Hmmm. Ich will ja nicht unken aber ich wäre da nicht so überzeugt.

Seit der Geforce besitzen Grafikkarten eine T&L (Transformation und Lightning) Einheit die nicht Anderes macht als die Positionen und die Lichter zu berechnen. Diese Einheit wurde Speziell dafür gebaut damit man eben nicht mehr alles mögliche auf der CPU berechnen sollte.

Außer Frage steht auf jeden Fall, dass das Pushen und Popen der Matrix sehr anspruchsvoll sind aber Sinus und Cosinus sind auch nicht ohne. In Shadern sind die sogar die mit Abstand rechenintensivste Anweisung.

Ich muss aber gestehen, dass ich es selber nicht genau weiß aber in meinen Augen hat es durchaus einen Grund warum das erfunden wurde. Um es genau zu wissen müsste man das aber mal messen.

hoppla ja ok die standart sinus und cosinus funktionen errechnen ja auf unmengen (weis grad nich wieviele) stellen genauigkeit.
da könnte man ne eingene schreiben die nur sagen wir 3 oder 4 Stellen genauigkeit (sollte reichen für das problem) errechnet.
Oder noch besser eine mit wählbarer genauigkeit

mmh T&L Einheit hab ich ja noch nie gehört, naj man lernt ja nie aus, aber irgendwann *ineinegeldreichezukunftblick* werd ich mir wohl auch mal ne GeForce kaufen.

_________________
ghost-site.de

An die Einführung von T&L erinnere ich mich noch gut ... das stammt aus dem Jahre 2000 und wurde damals erstmals bei DX7 unterstützt und brachte einen merklichen Geschwindigkeitsvorteil bei der Berechnung. Ich würde wie Lossy ebenfalls darauf setzen, dass die Berechnung per CPU wesentlich mehr kostet als dies über die Grafikkarte zu schieben.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

In diesem Fall würde ich (wenns wirklich schnell gehen soll) Sinus/Cosinus Tables verwenden und die Winkel im 256er Maß angeben.

Im Wiki findest du auch was zu dem Thema: Billboard

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut