Schnellere Sortierung?
Übersicht

![]() |
Xaymarehemals "Cgamer"Betreff: Schnellere Sortierung? |
![]() Antworten mit Zitat ![]() |
---|---|---|
Meine aktuelle Sortierung der Type ist extrem langsam(Ich gehe alle Partikel 3mal durch, was schon bei ~1000 Partikeln ruckelt). Kennt jemand eine schnellere, aber trotzdem genaue Sortierungsmethode?
(http://www.sorting-algorithms.com/ kenne ich, nur sind die codes so irre mini) BlitzBasic: [AUSKLAPPEN] Function eg_Particle_Emitter_Sort() |
||
Matthias |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Hay.
Erstmal würde ich vorschlagen die Camerakoordinaten in einer Variable Zwichenzuspeichern. EntityX(eg_Engine_Camera) Vieleicht kannst du dann auch noch dein Sortieren auf mehrere Mainloops verteilen. Was hat das für einen sinn die Partikel zu sortieren. |
||
flashmaxel |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Die Distanz auf jedenfall zwischenspeichern und einen effizienteren Sortieralgorithmus verwenden.
Du suchst immer den Partikel mit dem kleinsten Abstand zur Kamera raus und fügst diesen dann in eine neue Liste ein, das ist Selectionsort. Selectionsort ist, wie du auch auf der Seite http://www.sorting-algorithms.com/ sehen kannst nicht besonders schnell. Ich würde entweder Mergesort, Heapsort oder Quicksort verwenden. Die gibts zum Teil auch schon im Codearchiv z.B. hier https://www.blitzforum.de/foru...=quicksort - auch für Types- kannst du also direkt verwenden! Berechne also zunächst in einer Schleife die Distanz eines jeden Partikels zur Kamera und speicher das Ergebnis in dem Typeeintrag in einer Variable. Anschließen sortierts du den Type nach dieser Variable mit Quicksort! |
||
![]() |
Midimaster |
![]() Antworten mit Zitat ![]() |
---|---|---|
Na klar gibt es da Möglichkeiten....
Du scheinst die Partikel nach der Nähe zur Camera zu sortieren. Daher müßten Sie eigentlich nach dem ersten Aufruf der Sortierfunktion auch beim 2.Aufruf noch ziemlich sortiert sein. Deine Sortierfunktion fasst immer alles an und schichtet es neu um. Bei vorsortieren Felder ist das fast nicht nötig. Daher kommt ein Verfahren in Frage, dass mit vorsortiertem Feld besonders schnellzurechtkommt. In einem Beitrag vor einigen Tagen habe ich eine tolle Vergleichstabelle gefunden, wo man auch die Performance verschiedener Verfahren vergleichen kann. http://www.sorting-algorithms.com/ Dort gewinnt Insertion und Bubble-Sort für dein Problem. Und Bubblesort wird in diesem Beitrag bereits auf deutsch erklärt: https://www.blitzforum.de/foru...p?t=35032. Im Prizip ist Bubblesort schnell erklärt: Du fasst nur dann etwas an, wenn der folgende Eintrag (n+1) größer ist als der vorherige Eintrag n . In deinem Fall, wenn die Distanz größer ist. In diesem Fall vertauscht du dann die beiden Elemente sofort und weiter geht es bis nach unten. Dann beginnt der Spaß von vorne. Solange du in der vorherigen Runde noch mind. eine Vetauschung gemacht hast, musst immer noch ein weiteres Mal suchen. Findest du in einer Runde keine Vertauschung mehr, ist alles sortiert. |
||
![]() |
Xaymarehemals "Cgamer" |
![]() Antworten mit Zitat ![]() |
---|---|---|
Danke für den Link nach quicksort... suche nach "quick sort" hatte hier nichts ergeben.
Grandios wie man das überliest... Zitat: (http://www.sorting-algorithms.com/ kenne ich, nur sind die codes so irre mini)
@Matthias: SingleSurface Z-Sorting? @Midimaster: Sie sind nicht vorsortiert. Wenn nu jemand die Kamera nur eine Blitzenheit bewegt ist die "vorsortierung" komplett zu "random" geworden. |
||
![]() |
darth |
![]() Antworten mit Zitat ![]() |
---|---|---|
Hallo,
BubbleSort ist schlecht. Selbst für beinahe vorsortierte Listen ist es ziemlich uneffizient, weil es einfach Werte hin und her schiebt. MergeSort ist in diesem Falle auch nicht zu empfehlen, weil der nicht von bereits geleisteter Sortierung profitiert, er läuft immer ganz durch, ist allerdings viel effizienter als Bubble. Die beste Wahl hier wäre wohl tatsächlich QuickSort, Erklärungen, oder sogar SourceCodes (du warst doch der, der auf c++ wechseln wollte? Alternativ gibts die auch in Java oder Pseudocode). Oder du guckst hier nach. Code: BlitzBasic: [AUSKLAPPEN] ;Quick Sort Viel Erfolg mit deiner Engine, MfG, Darth |
||
Diese Signatur ist leer. |
![]() |
Midimaster |
![]() Antworten mit Zitat ![]() |
---|---|---|
Als sehr effizient erweisen sich auch Test, ob denn überhaupt alle Partikel sortiert werden müssen. Das kommt natürlich darauf an, zu welchem Zweck du die Sortierung durchführst.
Ideen, die Performance bringen: 1. Partikel, die hinter der Camera() liegen... 2. Partikel, die weit entfernt liegen... ...müssen vielleicht gar nicht sortiert werden, sondern wandern als Block ans Ende der sortierten Partikel. 3. Des weiteren könntest Du Partikel schon beim Entstehen an die richtige Stelle in die Liste aufnehmen. 4. Muss die Liste jeden FLIP sortiert werden? Vielleicht genügt es nach jedem 3. Flip, etc... @Darth "BubbleSort ist schlecht". Ah! Warum gibt es dann das Verfahren noch? Es ist wie im richtigen Leben: "kommt drauf an!". Bubble-Sort hängt Quicksort bei vorsortieren Listen auf jeden Fall ab! Und bei 60 FLIPs pro Sekunde wäre ich mir echt nicht sicher, wie oft eine solche Liste dann doch "vorsortiert" wäre. @Xaymar beschreib doch mal um welche Partikel es sich handelt und wozu das Sortieren nötig sein wird. |
||
![]() |
Xaymarehemals "Cgamer" |
![]() Antworten mit Zitat ![]() |
---|---|---|
Particle-Z-Sorting, Da ich ja mit SingleSurface arbeite. Und QuickSort ist wirklich gut dafür aktuell.
1. Sollte machbar sein 2. Die werden nicht eingezeichnet, allerdings noch berechnet(Wieso eigentlich...) 3. Lässt sich umsetzen 4. Sie wird alle eg_Particle_Sort_TweenMS sortiert(aktuell 2500ms) |
||
![]() |
darth |
![]() Antworten mit Zitat ![]() |
---|---|---|
Hallo Midimaster,
"BubbleSort ist schlecht", weil es ein (veralteter) Algorithmus ist, der ein Laufzeitverhalten von O(n^2) aufweist. Das heisst, bei doppelter Listengrösse, die vierfache (maximale) Arbeit, bei vierfacher Grösse die sechzehnfache Arbeit usw. (Siehe hier). Man hat gezeigt, dass gewisse Listen nicht schneller als in O(n*ld(n)) sortiert werden können (ld = Logarithmus Dualis (oder lb, binärer Logarithmus), sprich Logarithmus zur Basis 2). Der wächst, für grosse Listen, beinahe linear, d.h doppelte Listengrösse -> doppelte Arbeit usw. (Siehe hier). Warum gibt es das Verfahren noch? Weil der Algorithmus dazu so kinderleicht ist, dass er sich eignet um Anfängern die Sortierung zu erklären. Ganz einfach deshalb. BubbleSort hängt Quicksort vielleicht bei ganz kleinen Listen ab, die praktisch schon vollständig vorsortiert sind, das kann sein - das liegt daran, dass Quicksort rekursiv läuft und gewisse Dinge auf den Stack legt, was zu einem (minimalen) Geschwindigkeitsverlust führen kann. Allerdings ist Quicksort in jedem Falle BubbleSort vorzuziehen, ganz einfach weil der Algorithmus in (beinahe) jedem Falle effizienter ist. MfG, Darth |
||
Diese Signatur ist leer. |
![]() |
Midimaster |
![]() Antworten mit Zitat ![]() |
---|---|---|
@darth
danke für die infos. Ich hab es jetzt mal ausprobiert und muss zugeben: Quicksort ist besser! |
||
![]() |
Xaymarehemals "Cgamer" |
![]() Antworten mit Zitat ![]() |
---|---|---|
Die vorschläge ließen sich nur mäßig umsetzen. das meiste davon hat derbe die rechenzeit erhöht.
Kurze nebenfrage, würde es sinnmachen die Partikel in zwei listen aufzuteilen, einmal Near einmal Far? (Nur Near wird sortiert, Far bleibt unsortiert) |
||
![]() |
Midimaster |
![]() Antworten mit Zitat ![]() |
---|---|---|
Wieviele Partikel sind es denn? Und wie lange ist denn aktuell die Rechenzeit?
So wie ich das jetzt getestet habe, scheint das QuickSort ja unter 2 msec bei 10.000 Werten zu sortieren. Allerdings Integer-Feld und unter BMax. Ich denke mal, du verlierst die meiste Zeit dabei, die Fields der Typen "von Hand" zu kopieren. |
||
![]() |
Xaymarehemals "Cgamer" |
![]() Antworten mit Zitat ![]() |
---|---|---|
Partikelanzahl variiert zwischen 0 und 2^16(Durchschnitt: 2^13)
von Hand kopiere ich ja nichts, das macht alles Blitz Normale Rechenzeit: 0-2ms Mit Vorsortierung: 15-45ms(Bei erstellung) Mit Prüfen ob hinter der Kamera: 190-364ms Mit Prüfen auf entfernung: 66-153ms Alles ohne Debugger an |
||
GERMAX |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Schau mal da:
http://www.informatiktreff.de/...m/baum.htm vllt hilft das was und berichte von deinen Erfahrungen! |
||
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC |
![]() |
RallimenSieger des 30-EUR-Wettbewerbs |
![]() Antworten mit Zitat ![]() |
---|---|---|
Hallo,
ich habe mal einen Quicksort für Typelisten erstellt https://www.blitzforum.de/foru...p?p=126111 dieser sortiert innerhalb der Liste und kopiert nichts in ein Array! Und der Code ist schnell erstellt, Typename und Fieldname angeben fertig! Probiere das doch mal aus und sag mal was zu der Geschwindigkeit. |
||
[BB2D | BB3D | BB+]
|
BIG BUG |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Habe mal kurz Deinen Code oben überflogen und es dünkt mir als würdest Du für jeden Vergleich die Entfernung der Partikel neu berechnen. Wenn Du die anderen Sortierungen auch so implementiert hast, dann ist es jedenfalls kein Wunder wenn das nicht flutscht.
Habe mal ein bisser gegoogled aber nicht wirklich einen tollen Vorschlag gefunden, wie man Partikel im 3D-Raum möglichst effizient nach Tiefe sortiert. |
||
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final) |
![]() |
Xaymarehemals "Cgamer" |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ihr seit zu spät... Ich zitiere:
flashmaxel hat Folgendes geschrieben: Die Distanz auf jedenfall zwischenspeichern und einen effizienteren Sortieralgorithmus verwenden.
Du suchst immer den Partikel mit dem kleinsten Abstand zur Kamera raus und fügst diesen dann in eine neue Liste ein, das ist Selectionsort. Selectionsort ist, wie du auch auf der Seite http://www.sorting-algorithms.com/ sehen kannst nicht besonders schnell. Ich würde entweder Mergesort, Heapsort oder Quicksort verwenden. Die gibts zum Teil auch schon im Codearchiv z.B. hier https://www.blitzforum.de/forum...=quicksort - auch für Types- kannst du also direkt verwenden! Berechne also zunächst in einer Schleife die Distanz eines jeden Partikels zur Kamera und speicher das Ergebnis in dem Typeeintrag in einer Variable. Anschließen sortierts du den Type nach dieser Variable mit Quicksort! Der Binäre Baum wird mir relativ wenig bringen. Ich müsste den sozusagen bei jeder Z-Sortierung dann neu anpflanzen. Genauso wenig bringen mir leute die nur den ersten post lesen und bei allen anderen denken: "TL,DR!". Trotzdem danke für den versuch... @BIG BUG: Das Hauptproblem ist ja, das ich keine GeometryShader oder VertexShader in BB habe.(Beides würde das Z-Sorting auf die Grafikkarte verlagern) |
||
GERMAX |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Xaymar hat Folgendes geschrieben: Partikelanzahl variiert zwischen 0 und 2^16(Durchschnitt: 2^13)
von Hand kopiere ich ja nichts, das macht alles Blitz Normale Rechenzeit: 0-2ms Mit Vorsortierung: 15-45ms(Bei erstellung) Mit Prüfen ob hinter der Kamera: 190-364ms Mit Prüfen auf entfernung: 66-153ms Alles ohne Debugger an Welche Zeiten kriegst du denn wenn du das sortieren 10* 100* machst? Ähnliche oder deutlich verschiedene? |
||
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC |
![]() |
Xaymarehemals "Cgamer" |
![]() Antworten mit Zitat ![]() |
---|---|---|
Sortieren brauch ich doch nur einmal? Wo ist nu der unterschied zwischen einmal und 10/100 mal in einer schleife?(Außer dem deutlich höherem aufwand). Und btw immernoch an meiner letzten frage vorbei. | ||
![]() |
hecticSieger des IS Talentwettbewerb 2006 |
![]() Antworten mit Zitat ![]() |
---|---|---|
1.) Mir ist bis jetzt unklar, wozu eine bis zu 2^16 Partikel in Z zu sortieren sind. Darstellungsfehler treten nur innerhalb mehrerer transparenter Partikel hintereinander auf, die im übrigen kaum auffallen (tritt eher selten auf). Probleme von transparenten Partikeln die sich vor nicht transparenten Polygonen befinden, treten auch keine Fehler auf.
2.) Wer sich mit 1.) ''den wenigen Fehlern'' nicht abfinden kann, nimmt maskierte Texturen für die Partikel. Sind nicht nur etwas schneller in der Darstellung, haben zudem auch keine Fehler mehr. Lediglich so viele Anstallten kann man damit dann nicht mehr machen. 3.) Wer sich weder mit 1.) noch 2.) abfinden kann, sollte auf unnötige Funktionsaufrufe wie Math_Distance3 verzichten, und in diesem Teil der Funktion als direkten Code einfügen. Dabei - wie schon genannt - die Cameraposition nicht immer wieder auslesen, sondern in Variablen zwischen speichern. 4.) Innerhalb Math_Distance3 dann auf keinen Fall sqr ![]() |
||
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D |
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group