Wie berechnet man einen Punkt in einem Rechteck? - Seite 2 |
03.03.2016, 20:44 | Jane Doe | Auf diesen Beitrag antworten » | |||||||
Genau so. |
|||||||||
03.03.2016, 22:32 | riwe | Auf diesen Beitrag antworten » | |||||||
dann folge doch einfach dem Rat von HAL 9000. selbst mein ziemlich rustikales VBA- Programm ( ohne float - Format) benötigt für 100000 Punkte gerade einmal 0.08 s, für 1000000 0.8 s. |
|||||||||
03.03.2016, 22:40 | HAL 9000 | Auf diesen Beitrag antworten » | |||||||
Ich selbst hab's nicht implementiert, daher freue ich mich über diese Bestätigung, dass ich mit meiner obigen Schätzung nicht so weit danebenlag. |
|||||||||
04.03.2016, 00:39 | Jane Doe | Auf diesen Beitrag antworten » | |||||||
@riwe Dann versuch es mal anders herum. Lass eine wählbare Anzahl Punkte in einem wählbaren Zeitabschnitt berechnen und schau wie viel FPS Du da noch rauskriegst. Wenn Du zum Beispiel 1000 Punkte pro 100ms berechnen lässt, dann werden Deine FPS ganz schön in den Keller gehen, denke ich. Denn das wären 10000 Zufallswinkel + 10000 Bestimmungen der zu schneidenden Strecken + 20000 Schnittpunktberechnungen + 10000 Zufallspunkte auf der errechneten Strecke pro Sekunde. Wenn Dein Rechner da nicht in die Knie geht, dann hast Du entweder einen Supercomputer, oder ich mache was total falsch. |
|||||||||
04.03.2016, 00:50 | riwe | Auf diesen Beitrag antworten » | |||||||
es scheint mir, das beste an deinen Ausführunden ist dein letzter Satz das ist doch dein Problem nicht meines. oben hast du doch geschrieben: genau so! und mein uralter PC braucht halt die von mir genannten Zeiten. als pensionierter Fliesenleger oder so habe ich keine Ahnung, was du plötzlich mit FPS und umgekehrt meinst. aber wenn es dir hilft: mache weiter so |
|||||||||
04.03.2016, 01:01 | Jane Doe | Auf diesen Beitrag antworten » | |||||||
Nicht gleich so negativ, denn das war doch nicht böse gemeint ! Mit dem 'Genau so' meinte ich das Deine Punkte alle innerhalb der zwei Rechtecke und innerhalb eines Winkelbereichs sind. FPS bedeutet Frames per second, also Bilder pro Sekunde. 24 FPS braucht der Mensch mindestens um eine Abfolge von Bildern noch als Bewegung und nicht als einzelne Bilder wahrzunehmen. |
|||||||||
Anzeige | |||||||||
|
|||||||||
04.03.2016, 13:27 | HAL 9000 | Auf diesen Beitrag antworten » | |||||||
Nach dem "Gejammer" hab ich das jetzt doch mal in C probiert, mit vollen 64 Bit Floatingpoint "double" und sogar gutem Zufallszahlengenerator (Mersenne-Twister mit 64 Bit Ausgabe) - Ergebnis: Über 13 Millionen generierte Punkte pro Sekunde im Singlethread-Modus (i7-3770, 3.4GHz), mit 8 Parallelthreads steigt es auf über 70 Millionen Punkte pro Sekunde. Das ganze aber reine Berechnung, d.h., ohne irgendwelche Grafikausgabe. |
|||||||||
04.03.2016, 15:30 | Jane Doe | Auf diesen Beitrag antworten » | |||||||
Hm. Also bei mir werden die Punkte nicht nur berechnet, sondern auch weiterverarbeitet und grafisch dargestellt. Allerdings sind 13 Millionen Berechnungen schon ein großer Unterschied zu dem was ich bisher rausschlagen konnte, also werde ich mich nochmal an die Optimierung setzen. |
|||||||||
04.03.2016, 16:26 | HAL 9000 | Auf diesen Beitrag antworten » | |||||||
Die Kernroutine sieht bei mir so aus: Prozessparameter (Namen hoffentlich selbsterklärend): halfwidth_inner_rectangle, halfheight_inner_rectangle, halfwidth_outer_rectangle, halfheight_outer_rectangle, lower_angle, higher_angle (beide in radiant) Voraussetzungen: 0 < halfwidth_inner_rectangle < halfwidth_outer_rectangle 0 < halfheight_inner_rectangle < halfheight_outer_rectangle 0 <= lower_angle < higher_angle Vorberechnet (kann man auch innerhalb der Prozedur über zwei zusätzliche Multiplikationen erledigen) inner_tanangle = halfheight_inner_rectangle / halfwidth_inner_rectangle; outer_tanangle = halfheight_outer_rectangle / halfwidth_outer_rectangle; Benutzte Prozeduren: frandom() ... double Zufallszahl im Intervall [0,1)
|
|||||||||
04.03.2016, 17:28 | Jane Doe | Auf diesen Beitrag antworten » | |||||||
Danke für das Beispiel, aber wo genau berechnest Du denn die Schnittpunkte ? :O |
|||||||||
04.03.2016, 17:44 | HAL 9000 | Auf diesen Beitrag antworten » | |||||||
Die Schnittpunkte mit dem Rechteck? Na das sind (xin,yin) und (xout,yout) - ist doch ersichtlich, wo die berechnet werden. |
|||||||||
04.03.2016, 17:48 | riwe | Auf diesen Beitrag antworten » | |||||||
nicht "jammern" nur ein schöner Code, die Spiegelung ist sehr elegant |
|||||||||
04.03.2016, 18:03 | Jane Doe | Auf diesen Beitrag antworten » | |||||||
Ich glaube ich habe gerade einen Knoten im Gehirn. Kannst Du bitte kurz erklären wie Du damit auf die Schnittpunkte zweier Strecken kommst ? Meine Routine dafür sieht folgendermaßen aus:
Wobei x1,y1 die Punkte der ersten Strecke und x2,y2 die der zweiten sind. |
|||||||||
04.03.2016, 18:08 | Jane Doe | Auf diesen Beitrag antworten » | |||||||
Ach Mist...Jetzt hats die Formatierung meines Codes zerpflückt. |
|||||||||
04.03.2016, 18:15 | HAL 9000 | Auf diesen Beitrag antworten » | |||||||
Wir haben hier bei den Rechteckseiten doch den Sonderfall von achsenparallelen Strecken (d.h. zur x- oder y-Achse) - da kann man doch die Schnittpunktrechnung drastisch vereinfachen - was ich dann auch getan habe. |
|||||||||
04.03.2016, 18:50 | Jane Doe | Auf diesen Beitrag antworten » | |||||||
Stimmt, Du hast Recht. Das hatte ich nicht bedacht, sondern bin von einer allgemeinen Schnittpunktberechnung ausgegangen. Kein Wunder daß das bei Dir um einiges schneller läuft. |
|||||||||
04.03.2016, 18:55 | URL | Auf diesen Beitrag antworten » | |||||||
Das habe ich dir hier schon gesagt |
|||||||||
04.03.2016, 19:12 | Jane Doe | Auf diesen Beitrag antworten » | |||||||
Das mag sein, aber nicht jeder kann etwas mit dieser Formelschreibweise anfangen. |
|
Verwandte Themen
Die Beliebtesten » |
|
Die Größten » |
Die Neuesten » |
|